This is really cool. I saw that jjs was bundled with java 8, and saw this possibility.
I wonder if it is compatible with node js frameworks like express. I think that node has a lot of native code to implement various functions, so it would probably require a lot of work.
I don't know why this link keeps getting posted. Javascript on Java in server land has been around for some time and I even talked about some other frameworks that do this in a previous duped link https://news.ycombinator.com/item?id=12760128
I don't mind new libraries but it doesn't even explain how it is different or interesting or if prefers async to sync (I think it is sync).
Hell you can even use Rhino Servlets like 15 years ago. The only thing that is new is Nashhorn but even that isn't that new. It is sad that Javascript is this sticky now.
> It's an alternative to Node.js for Java projects. PurpleJS makes it easy to build performant and lightweight Javascript server applications without the complexity of Node.js asynchronous programming model.
Do you have any benchmarks that show what performance is like?
I don't think you can avoid "the complexity of ... asynchronous programming model". The world is async, and we should build better tools to interact with it, not cover our ears and pretend otherwise. They also mention isomorphic applications, but the browser is async, because everything is event driven! How are you expecting to avoid that? Even if allowed to do some things synchronous (e.g. data fetching), it'll cause your UI to freeze.
Both the browser and node use the `console` global for logging, but you've chosen to create a `log` object instead of following the existing convention. Even though I think `log` is a better identifier, I would've opted to maintain compatibility with existing ecosystems instead of doing my own thing.
This got me to look up some info on Nashorn and I landed an Oracle article [1]. They use a `with` statement in one of the examples. I don't think I've ever seen someone using `with` in the wild. It's generaly frowned upon, and justifiably so, IMO. I couldn't find any info on what version of JS they support.
Although full compatibility with node would be very challenging, I think you could get pretty far just by supporting CommonJS and the built-in modules.
I played around with Nashorn/jjs recently - if anyone's curious how roughly things work I did a little write-up here with a couple of examples showing some simple use-cases: http://blog.mclemon.io/discover-a-linux-utility-jjs
Yep - you're right in that it's not fast. On my post I nabbed a graph from someone who did some performance measurements and the difference is pretty stark.
How these tests are run will potentially create large differences. For instance, pure Nashorn will compile each script _every_ time before executing it. PurpleJS only compiles a script once and then caches it for re-use.
I did a presentation on using Nashorn (and jjs) about a year ago at SacJUG (our local Java user group). It's pretty interesting the level at which you can intermix Java and Javascript in Nashorn.
I tinkered with the idea of using a library called Spark on Netty to make web services in JS, but this library (and others mentioned here) actually did the job :-)
I also did a lightning talk demo on Nashorn vs Node performance a few months ago (local JS user group).
For the little string mashing benchmark I put together (originally to compare sequential / fork / thread performance in various languages), Nashorn's (Java 8) JIT eventually catches up and passes Node. Alas, it's one of those "O(n) for large n" problems where n has to be around a million before this happens.
... And Perl still mops the floor up with all of them. (Perl is good at string handling, even if not so much at many other things)
I actually used Spark via the "Nasven" wrapper for maven to create the simple thumbnail server I wrote about on my post (it's at the end of a lot of boring text): https://github.com/smcl/thumbooo
So long as one executor is executing the recipe/procedure/etc it makes sense to simplify directions to make them appear synchronous. When I turn my computer on and wait for it to start, I don't literally freeze up and stop breathing. I go do other things and wait for a signal that startup is complete or I poll the status of the computer from time to time. The synchronous instruction "wait for the computer to start up" is interpreted as "do whatever you want or need to do until the computer has started up".
As soon as two parties are involved, instructions start making sense asynchronously. Try writing a recipe for baking a cake by two bakers, keeping both chefs occupied the entire time. You'll see that the instructions must be read asynchronously otherwise each baker would not be able to continue reading his/her instructions when a "thread" of operation for the other baker has been called out.
Async is not parallell. With Node, only one of your bakers would actually be working at a time since Javascript does not support multithreading! Only way to achieve this would be dispatching to other node processes and start handling this yourself. With the JVM however you could actually do things in parallell without any such RPC handling.
- Performance: I guess looking at Nashorn performance tests would be relevant. Additionally, PurpleJS apparently compiles a javascript file on first run an then caches it for next execution, until the file is changed or the app is restarted. This would affect performance extremely over running the scripts from scratch each time. Compared to Node, you can for instance utilize a 32 core processor with a single runtime - compared to starting 32 node runtimes.
- Async: PurpleJS is a pure server-side framework. Thanks to the JVM it is capable of providing traditional multi-threaded approach to SSJS development which is both easier to understand and debug. The JVM helps you cope with the parallellism. I assume it should even be possible to add event driven capabilities to PurpleJS as well given that Java has a powerful event system.
Isomorphic: I see your point. However isomorphic scripts are naturally limited to anything that will successfully run on both server and client. For instance the DOM is just as little accessible to Node as it is to PurpleJS.
Apparently there is a new issue for 'console' in PurpleJS issues now - seems reasonable.
You kid, but - it can be a great setup. Especially if you have complex JS code on the client you want to run on the server and your company uses a lot of standard Java libraries/services you want to interact with.
Also to be looked forward to, the Graal Javascript implementation (https://github.com/graalvm). It says supported, but I don't think they have started marketing it yet. Probably still has ways to go, but if it ends up as good as the Ruby implementation, there is much to hope for.
I normally turn to ringojs[1] for "off-browser javascript" with Java integration. It's been around nearly 20 years[2] now! Is this a new take on the same concept? The examples seem web application focused, but there's not even a mention of JSGI[3] or whether it was even considered.
Not to mention there are dozens of other frameworks that support using Javascript directly like Vert.x, Jooby, Wicket (vaguely remember), Spring and even raw servlets and netty can all be programmed in Javascript using Rhino or Nashhorn.
The amount of code required just to write a "hello, world" is ridiculous.
This thing that we programmers do is supposed to (I thought) reduce the complexity of writing code so we can focus on the problem. This takes it to a whole new level of "where the hell is the code that's actually doing what I want it to".
It may work great and be horribly useful. But having to dig thru 4 subdirs just to get to the code that actually does something ... that was a horrible experience.
32 comments
[ 3.8 ms ] story [ 86.6 ms ] threadI wonder if it is compatible with node js frameworks like express. I think that node has a lot of native code to implement various functions, so it would probably require a lot of work.
https://avatar-js.java.net/
I guess it hit some roadblocks.
https://blogs.oracle.com/theaquarium/entry/project_avatar_up...
I don't mind new libraries but it doesn't even explain how it is different or interesting or if prefers async to sync (I think it is sync).
Hell you can even use Rhino Servlets like 15 years ago. The only thing that is new is Nashhorn but even that isn't that new. It is sad that Javascript is this sticky now.
> It's an alternative to Node.js for Java projects. PurpleJS makes it easy to build performant and lightweight Javascript server applications without the complexity of Node.js asynchronous programming model.
Do you have any benchmarks that show what performance is like?
I don't think you can avoid "the complexity of ... asynchronous programming model". The world is async, and we should build better tools to interact with it, not cover our ears and pretend otherwise. They also mention isomorphic applications, but the browser is async, because everything is event driven! How are you expecting to avoid that? Even if allowed to do some things synchronous (e.g. data fetching), it'll cause your UI to freeze.
Both the browser and node use the `console` global for logging, but you've chosen to create a `log` object instead of following the existing convention. Even though I think `log` is a better identifier, I would've opted to maintain compatibility with existing ecosystems instead of doing my own thing.
This got me to look up some info on Nashorn and I landed an Oracle article [1]. They use a `with` statement in one of the examples. I don't think I've ever seen someone using `with` in the wild. It's generaly frowned upon, and justifiably so, IMO. I couldn't find any info on what version of JS they support.
Although full compatibility with node would be very challenging, I think you could get pretty far just by supporting CommonJS and the built-in modules.
[0] https://github.com/purplejs/purplejs/wiki
[1] http://www.oracle.com/technetwork/articles/java/jf14-nashorn...
I tinkered with the idea of using a library called Spark on Netty to make web services in JS, but this library (and others mentioned here) actually did the job :-)
https://docs.google.com/presentation/d/19KTud9_3I3MgJiYlVdF9...
https://github.com/roboprog/nashorn_play
For the little string mashing benchmark I put together (originally to compare sequential / fork / thread performance in various languages), Nashorn's (Java 8) JIT eventually catches up and passes Node. Alas, it's one of those "O(n) for large n" problems where n has to be around a million before this happens.
... And Perl still mops the floor up with all of them. (Perl is good at string handling, even if not so much at many other things)
While that may be true, most algorithms, recipes, procedures, and instructions are synchronous. So human beings are used to synchronous programming.
As soon as two parties are involved, instructions start making sense asynchronously. Try writing a recipe for baking a cake by two bakers, keeping both chefs occupied the entire time. You'll see that the instructions must be read asynchronously otherwise each baker would not be able to continue reading his/her instructions when a "thread" of operation for the other baker has been called out.
- Async: PurpleJS is a pure server-side framework. Thanks to the JVM it is capable of providing traditional multi-threaded approach to SSJS development which is both easier to understand and debug. The JVM helps you cope with the parallellism. I assume it should even be possible to add event driven capabilities to PurpleJS as well given that Java has a powerful event system.
Isomorphic: I see your point. However isomorphic scripts are naturally limited to anything that will successfully run on both server and client. For instance the DOM is just as little accessible to Node as it is to PurpleJS.
Apparently there is a new issue for 'console' in PurpleJS issues now - seems reasonable.
[1]: http://ringojs.org/
[2]: http://helma.org/
[3]: https://www.sitepen.com/blog/2010/01/19/commonjsjsgi-the-eme...
Then we could run JavaScript on top of that!
This thing that we programmers do is supposed to (I thought) reduce the complexity of writing code so we can focus on the problem. This takes it to a whole new level of "where the hell is the code that's actually doing what I want it to".
It may work great and be horribly useful. But having to dig thru 4 subdirs just to get to the code that actually does something ... that was a horrible experience.