Vue.js frontend possible? #1841
Comments
|
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:
@fredkingham has done more Vue / Opal integration than me personally though |
|
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 ;-) |
|
@fredkingham ist there any code available publicly? ;-) |
|
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
|
|
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. 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? |
|
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
|
|
Sure. When time-to-market is releveant then using whatever provides you with a fast solution is good. My 2 main aims are:
I didn't understand that part. did you mean JSON/Vue is a good way, or not? |
|
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
|
|
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... |
|
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
|
|
This sounds great.
definitely. I just wanted to state that my GDAPS project will allow more than one frontend. This could be anything, and
for OPAL definitely,for GDAPS not...
definitely
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. |
|
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? |
|
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.
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 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.
As small as possible, but non 0.
Very much depends what your project is - feel free to drop a line |
|
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? |
|
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. |
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?
The text was updated successfully, but these errors were encountered: