Can you tell me what are Servoy’s plans for the future JS support and are there any new interesting features currently supported ?
Also will Servoy change Rhino with Nashorn
Hi,
I doubt that Servoy will spill the beans (no pun intended) on future developments.
As for any new interesting features currently supported. What features do you need? Is there something you can’t do yet?
Nashorn does not have ES6 support and is only recently getting their heads around to speccing it out for Java 9.
As far as ES6 features go, it’s kind of a game changer. ES5 is going to look awfully dated this time next year. (Reference: https://kangax.github.io/compat-table/es6/)
A parallel interesting question is when is Servoy going to integrate NodeJS into the JVM. NG client only needs the JDBC drivers and maybe a few other Java libraries.
so you mean that we suddenly should execute it in the NodeJS V8 javascript engine?
I think that would be even harder then doing nashorn (which also would be quite hard for us especially supporting a 3th party plugins and all that integration of our java object model (SOM) in the javascript engine.
IF it would be possible to integrate NodeJS (so the Google V8 engine) then that would be a huge undertaking.
Then suddenly the app server would also be specific to a platform (now the application server dir works on all operating systems)
Not to mention that we are moving away from the application server a bit and the deploy model is becoming really purely a WAR, so all this stuff should work in a java servlet container
NGClient needs a lot more then just jdbc drivers, the pure application server needs jdbc drivers, ngclient itself doesn’t even need that…
Just brainstorming around the main issue I see going forward on this subject. Getting left behind on ES6 features is one thing — solving for this alone doesn’t net you much. Solving for the ability to easily integrate javascript packages from the NodeJS world on the server with the ability to connect to legacy Java-based stuff…now that is intriguing.
Compiling Javascript to Java-byte code (Rhino and Nashorn) means this approach will always lag what’s happening in the Javascript world. Especially these days with Evergreen browsers pushing everything forward so much faster than the traditional Java release schedule can possibly keep up with.
So instead of implementing Javascript in Java, maybe the solution is to bring the Javascript to Java. Any rule against rocking more than one application server at the same time?
Sure it would be a challenge but I wouldn’t bother with trying to map things over 1-to-1. Get it rolling and then iterate on the bridging. Maybe allow us to choose which server to run a server-side code on. Example: I could do something with the current http plugin or with any one of the bazillion XHR packages for Node. End result comes together in sort of normalized “Servoy context” that is then proxied to the client.
Musings…
but this is all about integration,
the rhino engine is only a very small part of servoy
(by the way most of the time javascript is not compiled to byte code… but interpreted)
huge huge amout of code which is all written in java is the client itself and all the foundsets/database manager code
I personally haven’t looked at this yet, but what should be able to be done is if you run your servoy js developer code in a nodejs container that then all the special object model that we provide must go back into the java vm because thats where all our code runs in…