Similar project Alaska

[sfcgeorge]

Just making both projects aware of each other so that the maintainers might borrow ideas, join forces, or just so people googling can see alternatives. https://github.com/mavenlink/alaska

[diclophis]

Heya @jhawthorn ... nice project ;)

So.... I am not sure what to do here honestly... I ran a benchmark and the difference in performance between alaska and execjs-fastnode is not significant enough for either to really claim which is "faster" (And some of the difference could be more-so just minute differences in /usr/bin/nodejs performance more than any grand architectural difference between the two projects)

In fact, these two projects are very much twins in a sense that they seem to address the same issue in the same way.

The current plan for alaska is basically to keep it fresh by fixing any new bugs encountered by the community (my organization (mavenlink inc.) has since moved on to other mechanisms for doing asset compilation in rails (webpack/yarn/etc) ... so there is very little momentum at the moment to add any new features.

The frontier of these two projects I think is getting a little bit more publicity and adoption within the community and also possibly enhancing solutions around "isomorphic rendering" / "server-side rendering" of JSX and what have you in newer hybrid rails/react applications.

I have attempted to use alaska as the experimental "backend" for a rails/react application (via https://github.com/reactjs/react-rails#server-side-rendering ) and ran into some issues with the nodejs process halting / crashing on long running processes which I imagine is just due to some missing garbage-collection / connection retry logic (and also could be caused by the environment my application was running in).

Long story short... I think either of these two projects actually would benchmark as the "fastest server-side react/jsx rendering engine" for future rails applications if we can work out the kinks.

Please let me know what your thougts are...

[sfcgeorge]

@diclophis Thanks for your input and benchmarking. I thought they looked similar in implementation and goals, but thought you would both have a better perspective.

Personally I tried execjs-fastnode for no particular reason, just had to choose one, and it seems to work great.

My use case is actually nothing to do with Sprockets (though I may also use it to speed that up!) I'm writing a Capybara driver for JSDOM, so booting up a new Node instance on every spec was crazy slow. With this method it's way faster, fantastic.

Also, the way Capybara chains methods I actually need persistent state (that these ExecJS drivers both provide). AKA visit page, find element, click it, query it's state. With the standard Node driver these steps all happen in their own Node so it doesn't work.

Finally, I tweak the node_runner.js to re-enable require() as I see no reason to disable it and the library I'm using doesn't work without.