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

91–100 of 104 posts

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

#91

Post by pmontra »

kuschku wrote: post #72
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.

Unless you create file paths that are so long that they break the default tools of the OS. That’s the point where you went too far.

Or the OS went too short, so to say. There are two problems here.

1) Windows' limit of 260 characters per path name is incredibly small for a modern OS and that was true many years ago as well.

2) Npm approach relied on well behaved OSes and file systems allowing long path names. It's not future proof because you don't know on which OS and file system you'll need to run, maybe some limited embedded device.

Ruby's rvm solved that problem with a single directory level and a gem@version naming scheme.

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

#92

Post by spion »

nemothekid wrote: post #82
ksherlock wrote: post #38

Earlier quoted context omitted.

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 o…

In the vast majority of cases, its not. But in the cases when people want to invent new globally useful abstractions, like bignum, promises, cleaner streams etc - i.e. to reshape the platform - they can't do that. For example, the overhead of adding bluebird as a dependency to every module quickly adds up, and bluebird had to fight with many issues stemming from multiple versions of it communicating with each other.

IMO while this has contributed to the growth of node the ecosystem, it also stifled the growth of node the platform.

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

#93

Post by consptheorist »

esailija wrote: post #85
consptheorist wrote: post #36

Earlier quoted context omitted.

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 wo…

Last night I made some serious "soul searching" and deep profiling and I successfully identified the culprit by the aid of time distribution spent for every function call in the module and it actually was even way worse than I had expected because it was an EXTREMELY popular native DOM method.

To add insult to injury, I also threw IE11 into the mix and did some test runs and surprise surprise it fared 2x-3x better than Chrome :).

To give you a glimpse into the numbers:

FF Dev 39: ~1000ms IE11: 2000ms - 3000ms Chrome42: 7000ms - 9000ms

BTW, these test runs were performed on a very capable machine (released 2014). Just imagine what the numbers would be on challenged and less than optimal configs or mobile/tablet devices. Not really in Chrome's favor.

So, under a real world scenario and real business problem and codebase, FF fared WAY WAY better than Chrome and even IE was ahead of Chrome too.

No, I am not interested in those flawed benchmarks or skewed results peddled by intellectual masturbation pros like you, I only care about real world examples and business cases.

Don't even bother asking about the offending method because I have a no asshole/douche allowed policy in place and it is not going anywhere anytime soon.

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

#95

Post by dspillett »

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…

> The only time I've ever seen this limitation being complained about, it's by people who've had problems with npm.

Recently that is where you'll have heard about it a lot, but people have been hitting the problem for years. I've hit it in a couple of distinct contexts in my time.

You hardly hear about it generally because people moan a bit then work around it so the problem goes away until next time, and sometimes people don't even moan about it because it is such an old problem they just think "oh, that again, better make my directory/file names and/or paths a bit shorter" and get on with their day.

The difference between this and with npm over recent times (causing the greater noise around the issue) is that twofold:

* linux/similar people hitting the problem in the wild for the first time (they've probably heard about it, but never had to deal with it) because their code is getting used on Windows which was much more a rare occurrence for them in the past, and being incredulous that such a problem exists in this decade

* Windows people wanting to use node and similar cool new tech on their preferred and/or mandated platform but hitting issues due to this problem in their environment (and in some cases being incredulous that someone wouldn't consider the implications of the limitation it in their design)

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

#96

Post by noinsight »

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 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.

If you work on the sysadmin side of things, this comes up almost every time with directories on network shares. Explorer, cmd and PowerShell can't handle them and you need to resort to using robocopy or 3rd party tools like FastCopy. To delete stuff you often have to resort to hacks like robocopy mirroring an empty directory into the path before deleting it.

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

#97

Post by efdee »

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.

No, it's a "bug". It is not required for loading specific versions -- those can be kept in a flat structure just as well. No need for the idiotic nesting.

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

#98

Post by efdee »

orik wrote: post #21
rational-future wrote: post #8

Earlier quoted context omitted.

With every new version of Windows, Explorer gets worse and worse. I personally switched to Directory Opus long time ago.

This isn't a limitation of Explorer, but actually is a very well documented part of the Windows API. MAXPATH has always been 260 characters. https://msdn.microsoft.com/en-us/library/aa365247(VS.85).asp...

It is a limitation of Explorer and CMD.EXE - Windows has had Unicode APIs to access paths up to 32767 characters, but for some reason they have Explorer and CMD.EXE use the older ANSI API which does not support it.

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

#99

Post by bryanlarsen »

efdee wrote: post #97
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.

No, it's a "bug". It is not required for loading specific versions -- those can be kept in a flat structure just as well. No need for the idiotic nesting.

IMO a flat structure would just be a confused mess. There would be hundreds of packages in that directory.

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

#100

Post by dpe82 »

gsnedders wrote: post #55
dpe82 wrote: post #50

Earlier quoted context omitted.

Yes. DOM manipulation in all major browsers is implemented in C/C++. The JS engine is just a wrapper; any noticeable performance difference in DOM manipulation is almost certainly due to differences in the underlying layout engine and not in the JS engine.

Well, there's one way in which the JS engine effects it: how efficiently one can call into C++ from JS. Mozilla have done a lot of work to reduce the cost of that in SpiderMonkey.

Sure, though in the grand scheme of things that penalty is pretty small when compared to the DOM operation itself. Eg. doing an appendChild() on an attached element and causing a reflow.
Post reply on HN