Le 25/03/2014 21:41, Steve Fink a écrit :
> Sort of a mangled transcript of the embedding meeting at the 2014
> Toronto JS work week.
>
> Users
> - AMO for linting etc.
This might be better served by eslint moving forward
https://github.com/eslint/eslint/
> - Gecko
> - GNOME Shell
> - MongoDB was, but switched to V8
>
> If you want to validate against Spidermonkey, you kind of need to use
> Spidermonkey. Or heuristics.
To validate what?
> Lars: what advantage does spidemronkey give?
> - asm.js
> - support/IRC
> - at least formerly, spidermonkey had advanced features
Debugger API. Upcoming memory introspection features.
I think the debugger API is full of potential and seriously underused.
> till: boldest version is to recreate something like Spidernode and
> promote it as NodeJS with asm.js and more support for newer language
> features. asm.js seems to be a good answer to quite a few things that
> nodejs does. NodeJS has a strength in being easily extensible by native
> modules, but it sucks in shared hosting environments, because the native
> stuff has to be trusted by whoever runs the server. Used because
> reimplementing in JS would be too slow or too much work. Both are
> addressed by asm.js, and would be persuasive to get members of the
> NodeJS community to switch to our version.
How common a use case is it?
It's never been a problem for me or the people I know who use Node.js
(admittedly a small subset).
I think V8 has been catching up on asm.js-like code, so it's already
possible to use asm.js on Node today with decent performance (to solve
the shared hosting environment trust issue).
> Would be boldest and most resource intensive. Would require not only
> making a nice API, but would have to match V8's API.
>
> Lars: I assume that the most popular NodeJS extensions are
> syscall-heavy. What's asm.js's answer?
>
> till: One I hear frequently is image processing. Or DB stuff. But yes,
> quite a few do use system stuff.
>
> Lars: but asm.js has an ffi? Waldo: yes mjrosenberg: to JS.
>
> Waldo: if you provide it with a fucntion that does the C stuff, it can
> do that.
>
> till: if integrated with typed objects, it would be nice. Marty
> mentioned yesterday that game engines almost always integrate some
> scripting language. If that were spidermonkey, then in a modified
> version of emscripten, we could directly use a browser's host JS.
>
> mjrosenberg: I got a basic HelloWorld to work, but lost the changes. I
> wonder if something similar could be used for NodeJS/Spidermonkey.
>
> till: I think you can debug NodeJS with the Chrome debugger, though it
> isn't ideal.
Debugging is clearly an area where everyone agrees Node sucks
(especially because the stack trace is small and contains only the last
callback call which is rarely enough context to understand where an
error is from). Though I haven't looked at whether the situation will be
improving in Node 0.12.
SpiderNode has no value for itself (and asm.js isn't enough to convince
me at least). However, with the Debugger API, you give JS devs an
opportunity to solve the problem by themselves (where the V8 debugging
API seems too high barrier). I'm sure lots of people would use
SpiderNode if it promised a better debugging story.
> till: we seem to be perceived as the engine implementing the newest JS
> features.
On par with V8 from what I hear (just different features).
> Waldo: someone was complaining that V8 has Object.observe implemented
> and it made some AngularJS application way way faster. We might want to
> be conservative in assuming that we're ahead on various ES6 things.
Hmm... A fanboi for sure...
https://bugzilla.mozilla.org/show_bug.cgi?id=800355#c5
From what I know, Object.observe makes bad (in the sense of "not
following AngularJS assumptions for good performance" [1]) AngularJS
applications way way faster. It's unclear if the impact on performance
is otherwise that significant.
In any event, Object.observe really is an expected feature (44 cc's on
the bug with no technical progress certainly is an indication of something)
> till: I've heard it a number of times, and even if it's not clear cut,
> should we try to be perceived that way?
>
> Waldo: I think it's a reasonable thing.
>
> till: I'm absolutely convinced it's a big deal.
At which cost, though? Proxy.create is still around and I have stopped
counting the number of blog posts, gist, tweets where I've had to tell
people they were using an outdated API. The only reason ES6 hasn't
failed is because V8 keeps pretty much everything new behind a flag.
Not having feature flags on SpiderMonkey is an eventual problem. Might
become a very serious problem with FirefoxOS as some may venture to rely
on SpiderMonkey-specific features for the sake of being smart (whaddup
Object.prototype.watch and __noSuchMethod__ ! ... and '@@iterator' if
someone finds that)
David
[1] Interesting talk on the topic
http://www.youtube.com/watch?v=mVjpwia1YN4