JavaScript – The monkeys in 2013(blog.mozilla.org)
blog.mozilla.org
JavaScript – The monkeys in 2013
https://blog.mozilla.org/javascript/2014/01/23/the-monkeys-in-2013/
18 comments
We really need a monkey version of nodejs and node-webkit. Mozilla's engine looks more solid for universal use, there are more interesting features and experimentation. The only problem is that it's harder to embed in another software, but it looks that it is changing and I really hope it will change.
> Mozilla's engine looks more solid for universal use
> The only problem is that it's harder to embed in another software
Well , you cant have it both ways. There was spideymonkey-node a few years ago , but Mozilla doesnt seem interested in maintaining that. In fact there are quite a few mozilla abandonned projects,(XULRunner...) that could have competed with node-webkit.
Well , you cant have it both ways. There was spideymonkey-node a few years ago , but Mozilla doesnt seem interested in maintaining that. In fact there are quite a few mozilla abandonned projects,(XULRunner...) that could have competed with node-webkit.
You are thinking of SpiderNode, and/or NodeMonkey. Other than the principals leaving Mozilla for Facebook, this work was superseded by Tim Caswell's Luvmonkey:
https://github.com/creationix/luvmonkey
Turns out Node is really well factored, so emulating the V8 API on top of SpiderMonkey, especially back in 2011 as the Spider-Node-Monkey project tried, is harder. It's the "long way 'round".
Binding libuv to any engine that implements ES5+ is easier and gives Node interop.
As for XULRunner, sorry -- no leverage. If you see some, make it a business and show us up.
https://github.com/creationix/luvmonkey
Turns out Node is really well factored, so emulating the V8 API on top of SpiderMonkey, especially back in 2011 as the Spider-Node-Monkey project tried, is harder. It's the "long way 'round".
Binding libuv to any engine that implements ES5+ is easier and gives Node interop.
As for XULRunner, sorry -- no leverage. If you see some, make it a business and show us up.
>Turns out Node is really well factored, so emulating the V8 API on top of SpiderMonkey, especially back in 2011 as the Spider-Node-Monkey project tried, is harder. It's the "long way 'round".
Also: (i know i will get downvoted for saying that) but nodejs code is poorly written[0].. leaking v8 internals all over the place.. so to plug another js engine backend into it would be a very good exercise in tour-de-force
[0] - In a enginnering perspective, not pragmatic : cause nodejs does whats supposed to pretty well :)
Also: (i know i will get downvoted for saying that) but nodejs code is poorly written[0].. leaking v8 internals all over the place.. so to plug another js engine backend into it would be a very good exercise in tour-de-force
[0] - In a enginnering perspective, not pragmatic : cause nodejs does whats supposed to pretty well :)
All that is needed is a standalone "interpreter" with a REPL that can do some basic OS tasks and a pretty good way of starting simple web servers. Yes, small web services that can interop with larger systems, nothing more.
You say 'could have competed with node-webkit' despite the fact that XULRunner existed for many years, was used to ship commercial products, and still withered on the vine because nobody gave a shit about it.
It's not a product anyone wants. node-webkit will likely get left by the wayside in the same fashion once people realize the issues with building graphical desktop applications on top of a browser.
It's not a product anyone wants. node-webkit will likely get left by the wayside in the same fashion once people realize the issues with building graphical desktop applications on top of a browser.
Those graphs should really start at 0, the improvements (as good as they are) are needlessly exaggerated.
One could argue that it's not so bad in this case, since the variable is not an absolute value but just a "score".
I believe that they are absolute values though. IIUC, a browser doubling their score on one of these benchmarks is an approximation for being twice as fast at performing the benchmarked functionality. Firefox's improvement was enormous in 2013, but these graphs make their improvement seem (eyeballing it) about 5 to 10x more than it was.
I agree, but it is rarely the fault of the person presenting them. Unfortunately most "easy to use" graphing technologies (with Excel being the worst offender) take the most deceptive graphing techniques and make them defaults.
> most deceptive graphing techniques
They are deceptive because they exaggerate features of the data in order to improve perception of configuration changes. If every graph started at zero, many datasets would look like flat lines... not a great user experience when graphing.
They are deceptive because they exaggerate features of the data in order to improve perception of configuration changes. If every graph started at zero, many datasets would look like flat lines... not a great user experience when graphing.
[deleted]
Of course it's the fault of the person presenting them. If they are competent enough to understand what they are presenting, they are competent enough to adjust a y axis baseline.
Good news! Hannes updated the graphs to fix this.
Insteresting to see the VM to go into the meta-circular direction with code being written directly in JavaScript.
Kudos. And I wish you all would reconsider your nomenclature.
Dang, I thought my favorite band was getting back together.
I knew I couldn't have been the only one who thought that after reading the title.