Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Temporary fork enables Node.js to optionally use the Chakra JavaScript engine

github.com

Post reply on HN
Print view View original

81–90 of 104 posts

Re: Temporary fork enables Node.js to optionally use the Chakra JavaScript engine

#81

Post by angersock »

Twirrim wrote: post #78
zpao wrote: post #74

Earlier quoted context omitted.

> Might lead to a SpiderMonkey version of Node.js at some point, too. I worked on that 4 years ago :) " rel="nofollow">http://zpao.com/posts/about-that-hybrid-v8monkey-engine/> . The Node community at the time wasn't a huge fan, though it's effectively the same thing that MS just did (build a minimal V8 API shim on top of another JS engine). I guess everybody is ok with a little fragmentation now. Our intention was a…

Also that's going to potentially add a ton of work for people developing libraries. With a single engine behind it, the coding efforts can be focussed on writing and profiling something to be fast on v8. If you get replaceable engines, now developers have to either: 1) Ignore all but V8 (or spidermonkey, or chakra etc.) 2) Create different versions of their libraries for different engines. ( 3ish) write multiple path…

Having a decent shim to code against instead of having to deal with the internal gooiness of different JS engines is actually very much preferred. By throwing a shim over the JS execution layer, they actually make the life of extension developers much easier.

Re: Temporary fork enables Node.js to optionally use the Chakra JavaScript engine

#82

Post by nemothekid »

ksherlock wrote: post #38
bryanlarsen wrote: post #25

Earlier quoted context omitted.

That's a feature, not a bug. It lets A rely on version 0.9 of X while B relies on version 0.8.

That can introduce other problems. https://news.ycombinator.com/item?id=8213273 http://i.imgur.com/AZJti8I.png

I don't see how this npm's problem - the language itself doesn't let you catch this problem - and the pattern itself is dangerous. I'd have to agree with IsaacSchlueter here.

If I have a library (libA) that uses fooV1 and another (libB) that uses fooV2, there is no reason I should expect those two dependencies to interop with each other (except explicitly stated by the developer).

The solution (that there should be one set of dependencies) is an even worse problem that currently afflicts the Golang community, which they have decided to solve the same way npm has decided to solve it - vendoring.

Now with Golang, if you only have 1 set of dependancies, and one of your libraries depended on an older version - your program just won't compile (unless you update the library to use fooV2) and I'm not sure how thats useful to anyone. Most people will just tell you should have have just versioned that dependency.

Re: Temporary fork enables Node.js to optionally use the Chakra JavaScript engine

#84

Post by bsimpson »

Twirrim wrote: post #78
zpao wrote: post #74

Earlier quoted context omitted.

> Might lead to a SpiderMonkey version of Node.js at some point, too. I worked on that 4 years ago :) " rel="nofollow">http://zpao.com/posts/about-that-hybrid-v8monkey-engine/> . The Node community at the time wasn't a huge fan, though it's effectively the same thing that MS just did (build a minimal V8 API shim on top of another JS engine). I guess everybody is ok with a little fragmentation now. Our intention was a…

Also that's going to potentially add a ton of work for people developing libraries. With a single engine behind it, the coding efforts can be focussed on writing and profiling something to be fast on v8. If you get replaceable engines, now developers have to either: 1) Ignore all but V8 (or spidermonkey, or chakra etc.) 2) Create different versions of their libraries for different engines. ( 3ish) write multiple path…

Using @zpao's example, most Python developers use CPython and either don't know about PyPy or have never used it. As such, I'd expect most of the long-tail of Python libraries to have been written and tested against CPython.

That hasn't prevented PyPy, IronPython, JPython, etc. from existing/thriving.

Re: Temporary fork enables Node.js to optionally use the Chakra JavaScript engine

#85

Post by esailija »

consptheorist wrote: post #36
bhouston wrote: post #10

It would be cool if the JavaScript engine was interchangable in NodeJS and IO.JS so you could pick Chakra, V8 or SpiderMonkey very easily. SpiderMonkey is faster than V8 these days on a lot of benchmarks.

I can attest to that. I was experimenting a couple of days ago with high duty and extreme DOM nodes crunching and FF's SpiderMoneky blew Chrome's V8 out of the water for 7 - 9 multiples gain in performance measured in time elapsed to complete the operations. Chrome's V8 engine at this point is so overrated

How do you live in such a bliss ignorance where supposedly an order of magnitude difference in performance between two state of the art browsers doesn't make you reconsider even for a second that you might have not written a working benchmark? :)

Sorry but unless you have deep knowledge of how both engines and browsers work (knowing how `appendChild` is actually implemented for starters), you simply cannot write a working benchmark. Even then, it's very hard and tedious.

If you don't have time to obtain such expertise, you could take a shortcut and compare realistic end-to-end benchmark. E.g. if your game runs at 210-270 fps in firefox but only at 30 fps in chrome, then you could claim that "firefox blows chrome out of the water".

It's very easy (just look at 80%+ of jsperfs) to construct benchmarks that don't look completely broken to the untrained eye but actually are. The common theme is the benchmark missing many aspects of realistic code and being reduced to measuring irrelevant optimizing compiling features. For example the benchmark could only be measuring how thorough the engine's dead code elimination pass is even though what you wanted to benchmark is string concatenation performance.

Re: Temporary fork enables Node.js to optionally use the Chakra JavaScript engine

#86

Post by bastawhiz »

Ezhik wrote: post #83

I wonder if MS is going to end up open sourcing Edge? Between this and the fact that Visual Studio Code uses Chromium, it really seems like where MS should head, but who knows.

I'd expect them to open source various components of it before they open source the whole shebang. I.e., I'd expect to see them put Chakra out, maybe the browser chrome, the parsers, etc. before they put out all of edgehtml.dll. I could be wrong.

Edge (and particularly IE) are fairly heavily tied to the OS in a bunch of places. IE, for example, can do weird FTP and Windows Explorer stuff. The infamous "Internet Settings" dialog and the way IE deals with stuff like proxy servers is only sort-of part of IE. IE's network stack is largely dependant on the bits and pieces available in the OS below (consider IE11 can only use SPDY on Windows 8). I wouldn't be surprised if open sourcing the browser wholesale would start unraveling a lot of things that MS doesn't intend to be public.

Re: Temporary fork enables Node.js to optionally use the Chakra JavaScript engine

#87

Post by wehrkeoruw »

SXX wrote: post #32
mkr-hn wrote: post #24

Earlier quoted context omitted.

Looks like it's been close to a decade. The CEO responsible for that whole ordeal is gone. When do people decide Microsoft has behaved long enough to be given a second chance?

I think it's pretty clear that this would take long time. Reputation it's not something company can get just by changing CEO or releasing few things as open source. After all they still continue their aggressive patents usage and there is still uncertainness around audio/video codecs for web standards mainly because of Microsoft. Pretty sure others may remember some areas where their politics didn't changed for a bit…

Reputation no, but the behavior itself? Quite possibly.

Re: Temporary fork enables Node.js to optionally use the Chakra JavaScript engine

#88

Post by espadrine »

bryanlarsen wrote: post #25
pionar wrote: post #20

Earlier quoted context omitted.

Actually, I was thinking, what's up node? Each dependency keeps a private copy of its dependencies? How messed up is that? Or am I just reading that wrong?

That's a feature, not a bug. It lets A rely on version 0.9 of X while B relies on version 0.8.

Having node_modules/X@0.9/ and node_modules/X@0.8/ would allow it as well. Yet each dependency would not keep a private copy of its own dependencies.

Re: Temporary fork enables Node.js to optionally use the Chakra JavaScript engine

#89

Post by ygra »

CHY872 wrote: post #52
frik wrote: post #29

Earlier quoted context omitted.

How long will Microsoft wait till the fix MAXPATH and other limitations? (and various other Win32 limitations that are usually a legacy porting helper thing from Win16). There would have been a good point with the introduction of Win64API - but Microsoft forgot about it and was apparently busy with something else.

I doubt it's too high up on the list of priorities. It would require really careful work to work in a backwards compatible way (there are almost certainly a tonne of apps that expect I guess the main thing is that it's one of those 'who cares' problems. The only time I've ever seen this limitation being complained about, it's by people who've had problems with npm. That directory structure is undoubtedly horrible and…

I had the problems with a Java codebase in SVN (back when your user profile was still under C:\Dokumente und Einstellungen\Username\...

Apart from that there is a backwards-compatible way of using longer paths, which is prefixing with \\?\. Since MAX_PATH is a hard-coded constant there can only be an opt-in way of dealing with the problem. Sadly many application or framework developers these days still don't opt in.

It also creates the problem that if Application A can create such paths and Application B cannot read them, you'll be annoyed too. And Application A might just disable long path support to mitigate the problem, leaving the whole state as it is.

Re: Temporary fork enables Node.js to optionally use the Chakra JavaScript engine

#90

Post by Ezhik »

bastawhiz wrote: post #86
Ezhik wrote: post #83

I wonder if MS is going to end up open sourcing Edge? Between this and the fact that Visual Studio Code uses Chromium, it really seems like where MS should head, but who knows.

I'd expect them to open source various components of it before they open source the whole shebang. I.e., I'd expect to see them put Chakra out, maybe the browser chrome, the parsers, etc. before they put out all of edgehtml.dll. I could be wrong. Edge (and particularly IE) are fairly heavily tied to the OS in a bunch of places. IE, for example, can do weird FTP and Windows Explorer stuff. The infamous "Internet Setti…

I wonder if making it standalone will be a part of the whole 'ditching IE legacy' process?
Post reply on HN