Just to chime in my high-level 2-cents as someone who wasn't there. I don't think SM is ready for a stable API. There are a lot of big embedder-facing changes that I'm making, including:
* Fundamentally altering error reporting semantics ( bug 981187 and friends ) * Removing default compartment objects ( bug 981218 ) * Removing saved frame chains (bug 979730 ) * Removing the Request API ( bug 722345 ) * Removing JSContexts ( bug 650361 ) Give it a year, and then let's have this discussion again. bholley On Tue, Mar 25, 2014 at 7:48 PM, Till Schneidereit < [email protected]> wrote: > On Tue, Mar 25, 2014 at 6:21 PM, David Bruant <[email protected]> wrote: > > > 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/ > > > No, it wouldn't, unfortunately: this is for Gecko app addons, so it has to > take all the slight weirdness into account that our implementation of the > language supports. > > > > > > > > - 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? > > > See above, addons. That's why we can only really use SpiderMonkey. This > isn't a planned project, btw: it's in active use right now. > > > > > > > > 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. > > > Agreed, and we talked about this. > > > > > > > > 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). > > > It's an open question, but yes: this argument isn't likely to carry too > much weight. > > > > > > > > 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. > > > We'd essentially get that for free, including the forthcoming memory and > perf analysis tools that'll be implemented using the debug API as their > transport. So apps could just be debugged using the Firefox devtools. > > > > > > > > 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). > > > The real question is where we can and want to be on that front in a > timeframe that's of interest for the topic at hand. > > > > > > > > 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) > > > Object.observe is pretty awesome, IMO: I really like data binding. I don't, > however, have any knowledge about how it is prioritized. > > > > > > > > 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) > > > > We've essentially adopted a very similar approach: features that're not > fully baked are only available in Nightly and Aurora. For ES6 that's not > really an issue anymore at this point. > > Also, "the only reason ES6 hasn't failed"? Bold words. > > > > > > David > > > _______________________________________________ > dev-tech-js-engine-internals mailing list > [email protected] > https://lists.mozilla.org/listinfo/dev-tech-js-engine-internals > _______________________________________________ dev-tech-js-engine-internals mailing list [email protected] https://lists.mozilla.org/listinfo/dev-tech-js-engine-internals
