Comment by TheAceOfHearts | Hacker News Reader

Comment by TheAceOfHearts | Hacker News Reader

Parent Full thread

From their wiki [0]:

> 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 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

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 :-)

https://docs.google.com/presentation/d/19KTud9_3I3MgJiYlVdF9...

https://github.com/roboprog/nashorn_play

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

We are using J2V8, found Nashorn to be a bit lacking in performance.

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.

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.

- 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.

> The world is async

While that may be true, most algorithms, recipes, procedures, and instructions are synchronous. So human beings are used to synchronous programming.

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.

Reply on news.ycombinator.com