Vue.js frontend possible?

[nerdoc]

More a question than an issue. This project is really promising.
Is there a way to support Vue.js instead of Angular? I don't expect you to support that, it's me that want so use Vue instead - so I'd just like to know:
Would it be (easily) possible to write a Vue.js frontend for Opal? Or is the Angular part so deeply integrated that it can't be changed?

[davidmiller]

Short answer: Possible yes, trivial no.

Longer answer: The design of Opal 0.x isn't to make front end explicitly pluggable, but to allow customisation of the front end using the components provided (in Angular). That said, the front end consumes JSON APIs, we've seen proof of concept applications use Vue.

More strategically, Angular 1.x is EOL soon, and the jump to 2.x is large enough to require a full scale rewrite. After much discussion, the current plan is to jump javascript ships to Vue, and try to reduce the overall javascript front end dependency, for Opal 1.x.

We've done some work towards this, mostly exploratory, broad conclusions are:

• If you're going to have to rewrite anyway, Angular 2 doesn't seem like the right bet right now
• React effectively forces you to be all SPA JS front end, without a way to progressively enhance / mix & match
• Pure Web 2.0 Django will make it hard to to some things well that are expected of modern UX
• Vue gives us the best balance of JS functionality where it enhances things, while allowing pages that are more straightforward to be rendered with raw Django

@fredkingham has done more Vue / Opal integration than me personally though

[nerdoc]

Ok, thanks, this looks promising. I've written a Django plugin system that should it make easy to create Django applications which consost of "modules", each containing a server part, and a frontend part - namely Vue.js - it is still not stable, but usable. I created this originally with a EMR in mind - which is my long term goal. Now that I see OPAL, I think I could bet on that too, as it does many things exactly as I wanted a system to work - except Vue as frontend ;-)
I decided to create my system more generic,and named it GDAPS: Generic Django Application Plugin System.
What I wanted to say: If you want to have a look at my project, maybe it could be of some help in OPAL too: https://gitlab.com/nerdocs/gdaps

[nerdoc]

@fredkingham ist there any code available publicly? ;-)

[fredkingham]

Nothing that I would use in anger, just prototypes, and arguably too many prototypes at that ☺ https://github.com/fredkingham/opal-vue <https://github.com/fredkingham/opal-vue/tree/master/opal_example_app> is probably the most advanced. Was opal with a full vue front end. This used vue router etc. My current theory is that that is too much. I don't want to rewrite the world when the js world moves. My assumption is that the js world will move us more inline with raw webcomponents. Therefore a vue abstraction that lends itself as close to web components as possible, IE without a routing layer seems sensible as loading a page (particularly if a lot of it is cached in *.js/*.vue) is very cheap Stage 1 just adds in web pack to the scaffold. Stage 2 is add entry points to the vue config by default for each of the apps. I have a version that does this with a management command called on webpack start like this https://github.com/fredkingham/simple-opal-vue/blob/master/frontend/vue.config.js (although the management command would return a list of plugins) Is this the best way? Still open for debate. I don't think its bad, I just wonder if it could be better. Stage 3 is to figure out how we actually want to do forms as this is where a lot of the strength of js comes in. I don't have an answer. I want to do some experimentation. Very open to your thoughts! I looked at GDAPs, it seems cool! It shares a lot of philosophy with Opal.

…

On Tue, 24 Mar 2020 at 14:47, Christian González ***@***.***> wrote: @fredkingham <https://github.com/fredkingham> ist there any code available publicly? ;-) — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#1841 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAQTDX6E4QGJWSMIKMZD4ELRJDBZ3ANCNFSM4LHBZ7NQ> .

-- Fred Kingham Open Health Care openhealthcare.org.uk

[nerdoc]

In fact, I designed GDAPS for use with a EMR. And I am open for input too. You may be right that in 5+ years Vue may be replaced by the community of Js enthusiasts with AnotherAwesomeJsFramework(TM). That was my main concern using Vue, although I think it is almost perfect (except routing and vuex). But I didn't find anything else.
In medical world, we have to support development for many (and I mean MANY) years. That's the point, because all the medical record applications are so old and look as being written for MS-DOS or Win3.1 - in fact, they ARE. But: they all have long-term framework support. It works - somehow.

So your approach setting up Django with an (REST) API using FHIR is great. I tried to design GDAPS to be frontend agnostic - although the state is still early. Qt as frontend would be a good possibility too for medical applications, if it evolves and makes REST (or GraphQL?) querying easier.

So - my question should be asked better: is OPAL designed - or could it be re-designed more frontend-agnostic?

[fredkingham]

I think, and David may have his own opinion, is that I as a user of the framework wouldn't see front end independence as a massive benefit. I want a django/rails batteries included rather than an easily switchable front end. My requirements for opal are... I want something to automatically give me forms and display so that I don't have to think about it in a very fast and easy way. I want sass out of the box. I would like scaffolding to be pluggable so that I can change the display templates/form templates and from that I could put in my front end of choice without too much trouble. I want FHIR (or some interroperable engine) out of the box (or trivial) Being able to switch in react rather than vue, is interesting as a developer but wouldn't let me provide features to the users quicker which is my core requirement. I think GraphQL has legs but I think json in a view rendered into the template as arguments to vue feels like it cuts out a lot of middle men and makes testing easier. GraphQL to offer external apis to other hospital systems could make sense. thoughts?

…

On Tue, 24 Mar 2020 at 15:40, Christian González ***@***.***> wrote: In fact, I designed GDAPS for use with a EMR. And I am open for input too. You may be right that in 5+ years Vue may be replaced by the community of Js enthusiasts with AnotherAwesomeJsFramework(TM). That was my main concern using Vue, although I think it is almost perfect (except routing and vuex). But I didn't find anything else. In medical world, we have to support development for many (and I mean MANY) years. That's the point, because all the medical record applications are so old and look as being written for MS-DOS or Win3.1 - in fact, they ARE. But: they all have long-term framework support. It works - somehow. So your approach setting up Django with an (REST) API using FHIR is great. I tried to design GDAPS to be frontend agnostic - although the state is still early. Qt as frontend would be a good possibility too for medical applications, if it evolves and makes REST (or GraphQL?) querying easier. So - my question should be asked better: is OPAL designed - or could it be re-designed more frontend-agnostic? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#1841 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAQTDX6KBSH7N2PE4BHROQDRJDH6JANCNFSM4LHBZ7NQ> .

-- Fred Kingham Open Health Care openhealthcare.org.uk

[nerdoc]

Sure. When time-to-market is releveant then using whatever provides you with a fast solution is good. My 2 main aims are:

• long lasting compatibility and maintainance. 30 years would be nice. (maybe a dream)
• extensibility versus stability - both should be handled in a proper way.
  FHIR is a must IMHO, because it is/will be the de-fact- standard in near future. I would rather say theother way round as you did: GraphQL as main communication protocol between (Django) server and frontend. FHIR for interoperability with other apps, devices etc.

I think GraphQL has legs but I think json in a view rendered into the
template as arguments to vue feels like it cuts out a lot of middle men and
makes testing easier.

I didn't understand that part. did you mean JSON/Vue is a good way, or not?

[fredkingham]

I meant in the angular world its was (maybe is!) frowned upon to pass in json in the template but instead everything is done vie api end points. Vue has the feature that you can just pass in json as arguments to vue components. This meant that in the angular GraphQL as more sophisticated querying can be done in the client, which is not really possible with traditional rest apis. For vue on the other hand if I'm doing most of my rendering on the server I can do my business logic when generating the template context, so GraphQL is not as important. TBH I haven't looked much at GraphQL, what I have looked at looks great, but I'm very much on the minimum thing that adds the most value and is most easily tested. If you want something to run for 30 years (I'd be happy with 10!), keeping technologies which will very probably change with fashion to a minimum makes sense. This is my current way of thinking, it's flexible!

…

On Tue, 24 Mar 2020 at 20:20, Christian González ***@***.***> wrote: Sure. When time-to-market is releveant then using whatever provides you with a fast solution is good. My 2 main targets are: - long lasting compatibility and maintainance. 30 years would be nice. (maybe a dream) - extensibility versus stability - both should be handled in a proper way. FHIR is a must IMHO, because it is/will be the de-fact- standard in near future. I would rather say theother way round as you did: GraphQL as main communication protocol between (Django) server and frontend. FHIR for interoperability with other apps, devices etc. I think GraphQL has legs but I think json in a view rendered into the template as arguments to vue feels like it cuts out a lot of middle men and makes testing easier. I didn't understand that part. did you mean JSON/Vue is a good way, or not? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#1841 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAQTDXZVQ7SYX6YQ7YMZKX3RJEIZPANCNFSM4LHBZ7NQ> .

-- Fred Kingham Open Health Care openhealthcare.org.uk

[nerdoc]

For me Vue is not a matter of rendering on the server, it's responsiveness. You can do things like you could do before with desktop applications now int a browser (or Electron). And this speeds up the user's work a lot. And to load a page fast, and load needed data later when needed is so great with GraphQL, because you have so few road-trips - you don't have to ask the server 5 times via REST.

But back to the proper theme...
OPAL having support for more than one frontend would give the project a bit more flexibility on the long term. You see how short-lived AngularJs 1 was, after a few years it is replaced with Angular2, completely incompatible. TBH, I doubt that Vue.js will be the same in 10 years. But REST will stay, and probably GraphQL too. We even have SOAP calls around in the medical world now, and pre-XML data formats like EDIFACT all over the place.
So in a fast changing world, the best bet on the long run is not to be the fastest, but to stay flexible.

[fredkingham]

I think it rendering on the server is usually a lot faster than you suspect. Famously twitter did client side rendering and moved it back to the server to increase speeds. https://blog.twitter.com/engineering/en_us/a/2012/improving-performance-on-twittercom.html You also need to remember if you're just dumping json in pages, you can move as much to vue in terms of *.vue files and these will be cached in the client, so if you're worried about server side rendering speed that won't be too much. I think the problem with the js toolchain is that all of it is ephemeral. Should opal use yarn or npm, should it use web pack or grunt and all the other build tools. Should it use moment or date fns? Jest or Mocha? And when you start to debate build tools the api for defining your interface with your pluggable front end can become quite complex. E.g. at the moment opal doesn't have a build step because it uses compressor. So the theory for the next step is, 1. yes keep REST, allow a pluggable scaffold, that when you generate forms/display templates you can define the output (be it *.js, *.html, *.vue) and then you just use your own javascript wiring. 2. Have a single blessed toolchain which comes with default testing, sass, probably moment/lodash so you can get up and running quickly. 3. Keep as much on the server as possible so the blessed framework can be changed without too much issue 4. Keep urls on the server so that if you do decide to migrate js frameworks you can migrate piece by piece rather than have to do a single massive migration. I think this gives the flexibility of change with the benefits of batteries included.

…

On Sat, 28 Mar 2020 at 12:00, Christian González ***@***.***> wrote: For me Vue is not amatter of rendering on the server, it's responsiveness. You can do things like you could do before with desktop applications now int a browser (or Electron). And this speeds up the user's work a lot. And to load a page fast, and load needed data later when needed is so great with GraphQL, because you have so few road-trips - you don't have to ask the server 5 times via REST. But back to the proper theme... OPAL having support for more than one frontend would gibve the project a bit more flexibility on the long term. You see how short-lived AngularJs 1 was, after a few years it is replaced with Angular2, completely incompatible. TBH, I doubt that Vue.js will be the same in 10 years. But REST will stay, and probably GraphQL too. We even have SOAP calls around in the medical world now, and pre-XML data formats like EDIFACT all over the place. So in a fast changing world, the best bet on the long run is not to be the fastest, but to stay flexible. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#1841 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAQTDX5ZLDEQTHZIZ7L2G7DRJXRFLANCNFSM4LHBZ7NQ> .

-- Fred Kingham Open Health Care openhealthcare.org.uk

[nerdoc]

This sounds great.

1. yes keep REST, allow a plugg...

definitely. I just wanted to state that my GDAPS project will allow more than one frontend. This could be anything, and

2. Have a single blessed toolchain ...

for OPAL definitely,for GDAPS not...

3. keep much on the server

definitely

4. keep Urls on the server

partly. I think that the most important part is the API here. URLs and SSR are nice, but I think on non-HTML frontends too. Here URLs are useless - excluding API URLs.

I'm keen what is going on with your project. I don't know If I'm much of a help, but maybe. At least I'm a MD who knows a bit to code.

[andybak]

Very happy to read this thread as I've just had Opal suggested for a volunteer-led project and when I saw Angular my initial reaction was to run away. (I got burnt on an Angular project a few years back and have no desire to relearn any of it)

However - does this mean it's a bad time to use the current version of Opal?

For general extensions and customisation how likely am I to need to touch Angular code? How big will the breakage be when there's a switch to Vue?

[davidmiller]

I've heard lots of people say they've been horribly burned by Angular. It's not really been my experience - the only real headache-inducing downside is the shelf life of Javascript Frameworks. This is not an Angular issue.

Your mileage will obviously vary, but it's been my experience that the things that have genuinely burned me in writing/maintaining health applications have never been 'Nouns'.

Premature Optimisation, pressure resulting in a lack of rigorous code review, unreliable upstream systems to integrate with, unstable requirements, Being Clever (c.f Premature Optimisation), pre-existing failure modes of the cultural context of users - these are things I imagine likely to burn you.

For general extensions and customisation how likely am I to need to touch Angular code?

That's not a static thing - it depends on what you want.

If you need code that runs in the client, without writing a full Single Page App that just hits API endpoints, you'll have to interact with some of the APIs that the JS framework has.

The general strategy is to limit the points of exposure to specific DOM APIs that tie you to any specific framework API. That's not an Angular strategy, it's a JS framework shelf life strategy.

A decent example is https://github.com/odonto/odonto which has reasonably complicated form validation in it (because you're submitting something to an upstream government database) - the "Angular Code" is all in here https://github.com/odonto/odonto/blob/v0.32/odonto/static/js/openodonto/controllers/check_fp17.step.controller.js
The individual validation is in here https://github.com/odonto/odonto/tree/v0.32/odonto/static/js/openodonto/services/validators

You'll notice that the bulk of the files/code doesn't know or care about the framework it's using, it's operations on data.

How big will the breakage be when there's a switch to Vue?

As small as possible, but non 0.
The core dev team will have to migrate complex production applications, so there's going to be some work put into the migration strategy.

does this mean it's a bad time to use the current version of Opal?

Very much depends what your project is - feel free to drop a line

[lawrenceadams]

Hi all,

In the same vein as the above thread - given that AngularJS is due to drop LTS in a year- is there any news on a successor to AngularJS within OPAL?

[mslourens]

What about an upgrade to Angular x on a per component basis using NgUpgrade? That way you don't have to rewrite everything and can upgrade in small increments. I can help you with that, if you want. I have a lot of experience with Angular1 and Angular 2-11.