61–70 of 104 posts
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.
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.
Embrace: https://nodejstools.codeplex.com/ http://azure.microsoft.com/en-us/develop/nodejs/ Extend: https://github.com/Microsoft/node Extinguish: ?
Given all that Microsoft has been doing lately I'd really be surprised if this is all an elaborate ruse to squash node. Having been around when the actual "embrace, extend, extinguish" was running at full throttle, though, I can tell you what it does looks like: "Full access to UWP APIs from Node.js applications" When you use platform-exclusive features then you not only lose a major strength of node, but you put the…
Earlier quoted context omitted.
> The CEO responsible for that whole ordeal is gone. When do people decide Microsoft has behaved long enough to be given a second chance? If the company clearly changes it's course, right? Though it doesn't seem to be the case, despite two CEO changes since Bill Gates. Recent news show more or less what they are still up-to. Yesterdays plans to stop producing Windows and "Win10 as a service": https://news.ycombinator…
All you did is make a list. Can you expand this into something coherent? Office uses a documented XML format now, Silverlight is dead, and I don't see how Xbox One is in any way relevant. Not sure how making Windows free is "embrace, extend, extinguish." Most operating systems are free. People make new languages based on old ones all the time, so you're going to have to expand on the problem with TypeScript. I could…
It's still formats that can't be fully implemented without breaking compatibility with MS products.
PS: Personally I like what MS doing now and I accept that this can be serious change, but that would be dumb to trust them until like 3-5 years pass at least.
"This temporary fork enables Node.js to optionally use the Chakra JavaScript engine on Windows 10, allowing Node.js to run on Windows on ARM." (the submission title has been updated after I posted this, was initially "MS releases a fork of Node that uses the Chakra JavaScript engine instead of V8") Looks like they intend to merge back with node mainline... ? EDIT: Found this: http://blogs.windows.com/buildingapps/201…
The question is why should node/io.js take such a pull request. It adds support for an irrelevant platform and would add the burden of maintaining the 'wrapper' which will probably break on every v8 update.
Though this is a job that is already done by JXCore.
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
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 think the node_modules directory structure is a novel, though straightforward, solution to the problem of interdependent module versioning. It's very Unix; it reminds me a bit of GNU stow. It makes perfect sense that it will be tweaked in the new npm to be less redundant, but it only really makes sense to tweak systems that already work perfectly. (Otherwise they should be fixed first, then tweaked.) Certainly it's better than having a separate LD_LIBRARY_PATH setting for every command invocation! (even that doesn't fix everything...)
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?
> The CEO responsible for that whole ordeal is gone. When do people decide Microsoft has behaved long enough to be given a second chance? If the company clearly changes it's course, right? Though it doesn't seem to be the case, despite two CEO changes since Bill Gates. Recent news show more or less what they are still up-to. Yesterdays plans to stop producing Windows and "Win10 as a service": https://news.ycombinator…
I also really don't understand how a 1994 memo or the Microsoft Network plan are relevant. Those are both pre-lawsuit, how are they relevant today?
Interesting that Microsoft forked Node instead of io.js. The Microsoft repo says, "This branch is 16 commits ahead, 29 commits behind joyent:master".
I work for MS, right now we're working on win10. Some of the UI is written in html/js now, so I'm not surprised by this at all. I'm guessing we'll see some native node.js apps on windows in the future.
IMO it's not too surprising - it's relatively simple to fast forward to io.js from where it is now, wheras reverse engineering it backwards to Node compatibility would be mayhem.
Earlier quoted context omitted.
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…
Meanwhile it's also a "who cares?" problem for the npm people. They don't use this OS, and don't expect ever to do so. I think the node_modules directory structure is a novel, though straightforward, solution to the problem of interdependent module versioning. It's very Unix; it reminds me a bit of GNU stow. It makes perfect sense that it will be tweaked in the new npm to be less redundant, but it only really makes s…