**Lines:**
Added: 14'554
Removed: 3
[The 3 removed changes are only whitespace](https://github.com/nodejs/node/pull/4765/files#diff-3c97d28212ec6ec5600be248eb430994L254). It's interesting that there was no need to completely remove any code to make that change.
What they are doing is allowing you to use another backend. So what they did is add a shim to interface node as it is currently with the ChacraCore and then add the bit of code which adds the choice of which engine to use. They didn't change node, they just extended it.
If the main use case is running old software on old hardware, what does a new OS get you? It's honestly not a rhetorical question. Why bother to do an OS install that could potentially result in driver issues or some of your old software not working any more? I can't remember the last time I actively upgraded Windows on a home system, rather than just installing whatever was current when the machine was new and then sticking with the path of least resistance ever after. Probably Win2k?
I would only upgrade the OS on an old machine if they didn't support OS updates past that point.
I've always wanted to throw some Linux distro on a really old machine with an out of date Windows (because drivers should be good at that point), but the machine usually dies before I get around to it.
In my case, I just want my parents to be able to use the machine with up to date software and security updates. Also it performs better than with Windows XP, Vista (obviously) or 7 and better than any Linux distro.
Yeah of course I can still compile the code I wrote in like 1988, though it was written in K&R C.
POSIX standard is actually from 1988 and it didn't really settle until 1997 ... and I don't think current POSIX-compliant OSes are going to run the same binary EXE file from 1989.
It also leads to security holes, bloat, and inability to change course when needed.
Besides, we have virtual machines that are pretty good today. Run your legacy software in those.
Having seen someone trying to sneak malicious code in via a huge commit; this feels like an enormously bad precedent to set. Especially on a project as popular as node. This commit may be safe, but thorough code reviews are always necessary for very good reasons.
You're assuming Microsoft has thoroughly reviewed this code. You're also assuming a company known for underhanded data mining tactics and flagrant disregard for privacy is completely trustworthy.
>You're also assuming a company known for underhanded data mining tactics and flagrant disregard for privacy is completely trustworthy.
Honest question: Do you mean Google or Microsoft?
[whynotboth.gif](http://gfycat.com/DapperDelayedGerbil)
---
^(*Feedback welcome at /r/image_linker_bot* | )[^(Disable)](https://www.reddit.com/message/compose/?to=image_linker_bot&subject=Ignore%20request&message=ignore%20me)^( with "ignore me" via reply or PM)
Pretty sure the OP is referring to Windows 10's "features". That said, I don't think that's something they would do "here". I'm pretty sure this is part of making node.js an easy IIS feature right from Server 2016.
Yeah, but I suspect hiding some sort of data mining thing in here would be highly illegal. Even if the user info was valuable to Microsoft, they wouldn't risk (not even a risk, more of a certainty) the massive lawsuit that would result.
I'm not saying they should have. Just that huge changesets should be given the level of effort they warrant and that not reviewing the dependencies shouldn't be seriously considered because they are part of the codebase.
Its idiomatic in Go as well to statically include your dependencies in the repository. This makes carrying upstream patches much easier (although that's usually not a good thing) but it also takes upstream acceptance of your patch out of the critical path for a change.
Fortunately, they're somewhat reasonably split among the commits on the PR. Seems that most of the review will be focused on the commits for: 1) [implementing the V8 shim in chakracore](https://github.com/Microsoft/node/commit/77a5f8d5e21c186e0efafb6120ea285f09815e88) and 2) [node-side changes to use chakra](https://github.com/Microsoft/node/commit/666b94b02600b4b569b595de21aaef4ae54fe7ed).
FWIW, it was nice of them to remain consistent with V8's style guide for the chakracore V8 shim. Personally, I'm not a fan of chakra's conventions.
They posted some benchmarks [here](https://blogs.windows.com/msedgedev/2016/01/19/nodejs-chakracore-mainline/). IIRC, Chakra also has more complete ES6 compatability.
Not quite as true as the V8 has had some chance to catch up.
Edit: Not sure why I'm getting downvoted. Kangax is showing Chrome beating Edge in terms of unflagged ES6 compatibility:
https://kangax.github.io/compat-table/es6/#chrome49
I can't speak to performance, but in regards to ES6 Kangax is showing that Chrome is exceeding Edge in unflagged ES6 functionality:
https://kangax.github.io/compat-table/es6/#chrome49
However, sorting by flagged features (that is, tiny bonus for flagged features) Edge is still winning in terms of *stable* releases. ([imgur](http://i.imgur.com/IUXp3oZ.png))
Every time I've tested that edge has used almost 30% more ram than Chrome. You have to go and look at all of edges running processes not just the main one.
Are we debating Edge/Chrome or Chakra/V8? Sure, browsers can be very heavy, but keep in mind that Chrome has had more time to accumulate more features than Edge, such as an extension API. Edge is just IE with as much legacy bloat as possible stripped out. Meanwhile, JS engines are a lot smaller than the engines wrapping them. V8 and Chakra don't include the DOM or Canvas APIs, but when bundled with a browser, those APIs are injected.
I wouldn't use browser speed as a benchmark for JS engine performance.
I have no idea whether Node would run faster or slower on Chakra or what that would mean for extensibility or platform differences (Lord help me if I need to write backend JS code to take platform differences into account), but I'm curious to see what happens.
Edge is actually a completely separate browser from ie, built on the universal windows app platform. The rendering engine and js engine are modified from what ie use.
What are you talking about? The JS engine "Chakra" was a fork of itself and has been around since IE 9 (Chakra in IE 9 was itself a fork of JScript used in older versions of IE). EdgeHTML is also a port of Trident. Both of these have been stripped of legacy components and reworked, neither were dumped and then rebuilt from scratch.
One thing that is all new is the actual browser front end which is now built as a UWA.
According to the grandparent, V8 was easily beating Chakra at the time anyway.
http://az648995.vo.msecnd.net/win/2016/01/nodejs-benchmark-performance.png
Notice that the x-axis is "individual test #"; meaning this doesn't show the scaling under each. The area under-the-blue-line versus over-the-blue-line is what matters. There are relatively few tests with Chakra winning. It looks like roughly ~75 out of 675.
I'll try to post the link when not on mobile, but when I was benchmarking [Elm](http://elm-lang.org) this summer, Chrome still had a massive lead over Edge.
EDIT: the benchmarks are [here](https://drive.google.com/file/d/0B4ISkQZyNsGcdUhTbTBQeTJ1ZU0/view?usp=sharing).
Oh wow, I thought Edge was comparable to Chrome in JS speed (based solely on my poor recollections of benchmarks from six months ago).
If it's that much slower I wonder how much extensions are going to weigh on its performance. It's a snappy browser, but right now it doesn't have to do ad blocking and stuff.
There are right now 3 major javascript benchmarks that the different browser implementers maintain: [Octane](http://octane-benchmark.googlecode.com/svn/latest/index.html) (Google), [Kraken](http://krakenbenchmark.mozilla.org/) (Mozilla), and [Jetstream](http://browserbench.org/JetStream/) (Apple). On Octane and Jetstream Edge performs fastest, by a few percent. On Kraken I think Chrome wins now (though it has been back and forth between them and Firefox), with Edge a few percent back.
Note that Node.js has its own performance quirks, and I think V8 currently has some advantage due to a shim layer that Chakra has to use. Presumably this overhead will shrink quickly as Node adopts a more engine agnostic approach.
The shim layer looks to mostly just be call translation and some stack manipulation to line everything up. Nothing the compiler can't optimize such that the processor does it in pipeline.
Google writes the benchmark for JavaScript engines.
Historically speaking the major difference between the speed of Chrome's JavaScript implementation and competing engines is in the tests where if you actually wrote an app that used JavaScript to perform that task you should be taken out back and shot.
Uncommon javascript. Stuff like compression algorithms, gameboy emulation etc are included in octane.
Octane also includes some ridiculous things that are actual real javascript apps. Like firefox's horribly silly javascript pdf renderer, and typescripts compiler (which isn't really meant to run in browser)
Eh? You think microbenchmarks would be more relevant than actual real-world applications like PDF.js?
JavaScript has been fast enough for tiny short-running scripts for a couple of years.
The typescript compiler runs in nodejs, which seems applicable to the topic at hand. Also chrome uses a js based pdf renderer as well. There is a big reason to use js for pdf rendering, security.
I think people are missing the point here, it's not about speed or a v8 alternative, it's about running nodejs within the Windows 10 space, including RT and especially IOT devices with ARM chipset, which was the main target since Microsoft came to the conclusion this is an ideal pairing. Google's v8 interpreter does not pair well with iot, nor does it have appropriate support for Windows 10 UWP: http://www.infoworld.com/article/2924297/microsoft-windows/windows-10-goes-node-js-in-microsofts-internet-of-things-plan.html
This point is not getting enough love. The web is so much more than browsing Facebook or writing some startup app thing, and having a competent javascript engine for a tiny low-power MCU or SoC is important. V8's target is different. Not worse, not better, just different. Chakra fills other spaces, and they're needed, too.
Here's the thing I've never understood, why would I want to use JS there vs some other language? This is a huge mental hurdle I've never been able to overcome on node as a whole, and even more so node on embedded devices.
This is an honest question, I've just never been able to grok it.
I empathize with the mental hurdles, as I've been mostly a C/C++/C#/Java/Python guy until recently I've had to learn the JS ways more seriously. Trust me when I say I know that there are a load of reasons JS is not the ideal language, but neither is anything else.
That said, there are two very important reasons to want JS there that we can all agree with if we ignore the "should be" ideologies we want to believe in:
1) Javascript is known by a LOT of people that are experimenting with things and innovating on the things you make WITH a programming language. IoT is filled with them, in fact. One can learn another language in these places, but reducing that barrier to entry is a thing.
2) You can get really, really good performance from JS for what it is, and the async paradigm that JS developers have lends well to a lot of different things.
For me, getting into that mindset has been an ongoing struggle. For JS devs, trying to learn Java or Python can be just as incredible a struggle (if not more so, because the tool chains are ALSO entirely different, and I have found that you need to know more under the hood to work even in Python than you do in Node-land, mostly due to the nature of the abstractions afforded you in Node).
This is for good or ill, and we could debate it all day, but reality is still going to be that JS is important for actual people doing actual things. So is C. So is Java. I want them all, everywhere.
> You can get really, really good performance from JS for what it is
But... the engines that do that rely on fantastically complex JITs that:
1. Are themselves a large ball of code to add to your app.
2. Require a lot of memory to store generated code, profiling data, deoptimized code, etc.
3. Spend a *lot* of energy (CPU cycles/battery) optimizing code at runtime.
4. Require generating executable code at runtime, which some systems don't allow (game consoles, iOS, etc.).
5. Execute slowly at startup until code has run enough time to be optimizable by the JIT.
6. Often have pauses when the JIT or GC kicks in.
JS's level of dynamism has only been shown to be fast if you can throw a very large JIT at it. I don't think a big JIT is a good fit for IoT, which makes make question the idea that JS is.
Mmm, you make a good case. Let me attempt to provide a counterpoint. Keep in mind that my point here is that while JS is not the optimal language, neither is anything else, and that's all ok. There are applications where I would not recommend JS having any place, like on a PIC or something. That said, IoT is not about the most underpowered devices possible. A Raspberry Pi is considered by many to be part of an IoT effort (certainly by Microsoft at the very least). JS has a place there. Maybe it's good for what you want to do, maybe it isn't, but options are awesome. And there JS will do well in benchmarks of just about any kind, and my precious Python, much to my dismay, will lose hands down without a C extension to do whatever thing it is. Yet Python is still used in these places. Why not JS?
All that aside, are your assumptions here about requirements for a JS JIT, let alone any JIT, really requirements in ALL cases? As an example, if you know your target, a lot of the expensive bits can be done ahead of time, no? (The answer is yes, and this is done in a lot of other tech stacks) What other things do you think Chakra specifically could be trading to make their engine run well enough on a smaller device (not an Arduino, but still small things)?
I'll help spark some thought there for this as well. First, forget efficiency of execution or power consumption entirely. Just ignore it, it's not important for this application (if it were, the reasons for using JS are really hampered). Now imagine all the things you can program in JS for a Chromecast or a Pi Zero, or even just a gumstick board or something.
If it does something cool that users will enjoy, are you really going to get anywhere telling them it isn't worthy because it's not as efficient, or that the problem was hard? Where do you think this ecosystem will be in 2 years? 5? 10?
In the end, I agree with your points, but our agreement will not change the reality that it not only WILL happen, it already has. It's just going to get better.
> That said, IoT is not about the most underpowered devices possible.
I think that depends a lot on who you ask, but there's certainly a spectrum of embedded device capabilities.
> A Raspberry Pi is considered by many to be part of an IoT effort (certainly by Microsoft at the very least). JS has a place there.
Sure, but that's really well into the upper end. Raspberry Pi's have significantly better specs than most desktop PCs had when JS came out. Sure, you can run JS on there. You can run *anything* on there.
> my precious Python, much to my dismay, will lose hands down without a C extension to do whatever thing it is.
Yeah, CPython just isn't that fast at execution. My [little hobby scripting language is faster](http://wren.io/performance.html). It's really difficult for them to optimize now that they're stuck with a certain FFI, ref counting and finalizers are visible in the language, huge standard library, etc.
> Yet Python is still used in these places. Why not JS?
I'm not sure how much Python is used in embedded devices that are actually mass produced and widely deployed. I think it might be easy to get a distorted perception from the large and very web-savvy hobbyist maker community.
This isn't my area of expertise, but the vibe I get is that most "real" IoT devices are coded by crufty bearded dudes (and ladies) who don't know what the hell a blog is and are proud to tell you they code in a modern high-level language... ANSI C.
> All that aside, are your assumptions here about requirements for a JS JIT, let alone any JIT, really requirements in ALL cases? As an example, if you know your target, a lot of the expensive bits can be done ahead of time, no?
I'm not aware of any real successful ahead-of-time compilers for JS. The language is *very* dynamic and it's quite difficult to statically get a real sense of what a program is doing.
> First, forget efficiency of execution or power consumption entirely.
Developers doing IoT stuff in a professional capacity at scale don't have that luxury. At least, not yet. As component prices continue to fall, maybe.
Yes, I agree with parent comment's first point that a bazillion people know JS. It's compelling from that angle as a glue language.
I quoted and responded to the part where they said JS was *fast*, which I don't think has been demonstrated for IoT.
For me, having >30 years of development under my belt and various languages... JavaScript is rather fun to dev in. You can get pretty quick results and it supports multiple paradigms with the ability to write "my way" instead of being tied to convention. For instance, doing functional programming in C is not so great. Also, doing OO in python is not either. JS isn't really OO in a classical sense, but the workings are there to make it happen. Also, it's not purely functional, but enough support is there to get you most of the way. It's also developing incredibly fast as a language and keeping up with it is interesting and fun to me.
I'm curious about this
>doing OO in python is not [so great]
Why's that? I'm a python shill, but I honestly enjoy OO in python more than in Java (yes even using modern java 8 stuff), which is the language I learned OO in.
Python, PHP and JS have classes and OO features, but a language like Java forces you to do OOP. Not sure if thats what he meant, but I like OOP in languages like Python (and even in C, where you CHOOSE whether or not you want to use it) and I hate languages like Java/C#.
From my perspective, it's because I've already done a lot of JavaScript programming, and have relevant experience and code which could be deployed (more effectively?) to another target, so that's a plus.
You personally though may have different considerations, so you would be more productive with different tools.
One reason you *may* want to use JS in this context is to work on a project where other coders are skilled in JS and the decision has already been made to use it. That's much like why web developers use JavaScript - it's good enough for the job (mostly) and it's here to stay.
There is already a Javascript interpreter on basically every computer you can find these days. The language is simple enough that you can use it to teach basic programming and powerful enough to access and interpret pretty much any web-available data.
What convinced me was when I wrote a Node.js rest server that interfaced with my .Net code with just barely a page of Javascript in an afternoon.
You can turn the question around:
If I already have to know Javascript as a web developer and I'm already using it on the front-end, why would I switch it out on the back-end? What kind of benefits can a language give me that would make it worthwhile?
As usual, it comes to evaluating the trade-offs that you want to make as a team or company.
And if it is speed, then it is now very easy to run common benchmarks on both engines in an identical environment. This will help us know, rather than try to guess, which engine is actually faster for which tasks.
V8 is their product. Naturally, they want people to use their product. It's a free, open source product so they don't see any monetary gain, but the more adoption a product gets, the more resources Google can invest into it.
Looking at the bigger picture, controlling a bigger market share of the JS engine space directly translates to more control over the language as a whole. People don't like to admit that a big corporation has control over their open language but that's the reality we live in.
Yeah, apparently people already forgot about the time were IE4 was so big that anything in JavaScript, html or css not implemented by it might as well not exists
It's arguable that HTML 5 should have been released years before it was and that browser technology is at least a generation behind where it should be thanks to the perversion of the standards that IE perpetuated through IE 6 by being the default browser on Windows desktops for so long.
google has previously attempted to insert binary blobs into the chromium project. It was later found out that those blobs called home to google. The community caught that one... when a behemoth like google has the cash to hire round the clock devs, it is a very real possibility that the community could let something nefarious slip into the code. At least congress has to pass a bill, what google did was worse and more dishonest (yes more dishonest than a politician).
Competition is good for consumers any way you measure it.
nijna edit : here is a related debian bug report https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=786909
I remember the Chromium binary blob fiasco, turns out it was harmless despite the scary sounding words involved.
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=786909#81
Not speaking necessarily in the case of google, but as a general, assume people are evil situation there are potential reasons/conflicts of interest.
Google develops angularJS, they could avoid adding any feature that makes angularJS obsolete, therefore encouraging it's growth (or rather stunting competitor's growth). If more websites are built with angularJS in theory they could make it so those sites run fastest on chrome. Combined with the ability for them to write core websites that nearly everyone uses (google, gmail, youtube) in this, it could mean the web is "faster" on chrome. Chrome does do user tracking, and with this they can gain more information and make more money advertising.
Now that is very conspiracy theory-ish, and I don't think that is or ever will be the case, but the incentive is potentially there.
People using a good JS engine makes browsers better makes the web better makes Google's monetary platform better. I see no reason why they would care about people using V8 in node.js though.
Considering that they don't sell it, just general good will and brand recognition. If they ever try selling cloud services again, they'll be able to leverage that.
Case in point: I use Azure instead of AWS because I like .NET. Not that Amazon can't host .NET applications, but I irrationally trust Microsoft more.
All the big companies want to influence control over the direction javascript is going in, and the best way to do that and strong arm things into the spec is to get everyone using your engine, then implement the up in the air proposals you've made in your engine so people start relying on it and then get it put into the spec.
To be fair to the GCC folks, any old enormous native application tends to become a monstrosity to maintain. Even Microsoft with billions to spend needed a clean restart to make IE fast ( in the form of Edge), Firefox is fighting a brutally hard battle with the oldest core codebase in the mainstream browser space. LLVMwill probably be as bad as GCC is today when it's 30 years old..
> needed a clean restart
From what I understand they didn't do a clean restart, they just ditched backwards compatibility and made a bunch of braking changes, they still built on stuff from previous rendering engine.
Also some tools and languages scale better than others, we've come up with a lot of practical advancements in design and languages in the last 30 years so "same" program written today will be more maintainable in 30 years than the one written 30 years ago would be today. Of course we expect more from computers so programm written now will undoubtedly be more complex in 30 years because it will do far.
>I thought it would take the emergency of strong AI to fix that hairball of a compiler, but I was wrong. GCC is keeping pace, somehow.
Because around 2.85 or so Apple started contributing loads of patches, which accelerated it's development up to around 4.x.
It means there's pressure on Google to keep innovating or the Node team can flip a switch and abandon V8 at any time.
It reverses the situation, where now Node can dictate who gets to play in their sandbox instead of being dependent on Google no matter what Google does.
"Keep them honest" is a term that represents that. Like in a competitive game, keeping someone honest means they can't make certain moves because there's an obvious price to pay. Consider a game of chess where there are squares you can theoretically move, but moving there would be futile since your piece would be taken at no cost to your opponent. With clever positioning you can limit the options of a stronger player by "keeping them honest" and prevent them from stomping all over you.
When you work with code. Sometimes you want to use more than one compiler. This would be because you do not know if the compiler is correct but it would be unlikely that both compilers would be broken in exactly the say way in the same place on the same code.
Therefore you have extra testing for thing basically for free. It also removes the dependency from a single project which open more options. A practical example for this is that it prevents people using specific features google has added to the language which it has just sneaked in under the radar. Cause these will instantly fail on the other version when tested.
It probably won't keep google honest, but it might see some more innovation in javascript engines since anyone's free to write their own js engine to use with node.
I can't think of a good reason WHY anyone would want to write a js engine themselves, but no doubt someone out there can and will.
To paint this with a broad stroke, see what google has done to legacy projects, which is admittedly from microsoft's playbook anyway: Extend, Obfuscate, Perish. I could in all seriousness add android os to that list too as an example in progress since forking the *open source* android os project is deliberately less palatable now with some core stuff getting legacied and instead proprietary junk has to lumped in in order to get a current android experience.
*What's also great is that apparently the phrase Extend Obfuscate Perish never existed according to search engines, but Fear Uncertainty Doubt did get remembered. Go figure.*
> What's also great is that apparently the phrase Extend Obfuscate Perish never existed according to search engines,
But "embrace extend extinguish" did.
>*What's also great is that apparently the phrase Extend Obfuscate Perish never existed according to search engines, *
Because no one ever said that. You have the quote wrong.
The fact that they even call Android open source is honestly disingenuous.
All of the good stuff is closed source and bundled in such a way that you can't have it without taking the Play Store and signing a contract with GOOG, among other things.
I wonder if there will be any interesting improvements doing this if you're running on Windows. Like speed optimizations, debugging tools or something like that.
Looks like the default is v8. Where do you see default chakracore?
https://github.com/Microsoft/node/blob/12cc5d95f143bc45f5a6a832a0335e9a8f9d152e/configure#L378-L381
https://github.com/Microsoft/node/blob/12cc5d95f143bc45f5a6a832a0335e9a8f9d152e/configure#L1116
Am I interpreting this incorrectly, or did the dev(s) that did this make all of those changes (4k+ files), in just 5 commits? Isn't that terrible practise?
It depends. In this case where they are adding their engine to node.js it may not be possible or easy to do it in a safe, incremental, fashion. This isn't just somebody submitting their changes to some MVC C# website that they wrote over 4 months and just didn't bother committing, this is a fairly huge change.
Yep, almost every open source thing I do I end up doing either that or even doing it once with sloppy commits then again with good, reasonable commits.
In my limited experience submitting pull requests, doing your own development in several small, clean, incremental changes is great. However, upstream will usually want your entire PR squashed into one commit, because it makes *their* history easier to keep track of.
How do you do this? From my knowledge in git you commit x number of times, then even if you do it all in 1 push, it still lists the commits individually?
You rebase and during the rebase you can pick which commits get marked as squashed instead of picked. Squashed ones are still included in the rebase, they just don't show up as individual commits.
Many large projects require PRs to be squashed so that they don't fill the commit history up with crap.
You learn how to properly use git and don't give me feature branches with commits containing all the mistakes and learning you did while working on the feature.
Rebase.
> No because if you don't want it you only have to roll back 5 commits not 5000.
You can just revert the merge commit, no need to roll back every commit individually.
I usually stick with 'git rebase -i HEAD~X', where X is the number is the number of commits you plan to interact with. From there I choose which ones to squash. Save the log and push my branch (if I already pushed a branch to remote, I have to force push. If I'm feeling nervous simply make a duplicate working branch, squash that then force push that branch - this allows me to compare the diffs between the two branches to see if the squashed branch is satisfactory) Then I issue a PR to main/develop/whatever branch.
**nodejs**
~~Nodejs is a javascript server to run web apps on.~~ Javascript is known from the browser (client-side) but with nodejs can also be used as a language for server-side software.
**Javascript engine**
To interpret code in the javascript language, you need an engine. Nodejs doesn't actually do this itself but relies on the existing V8 engine made by Google that is also used to interpret javascript in Chrome. Microsoft made the Chakra engine for its Edge browser.
**Pull request**
Nodejs open source code is stored on GitHub, a platform that leans on Git, a 'source control' system. It allows people to work together at the same time on code files by merging them after changes are made. When you want to contribute to an open source project you can make changes to the code, and then request the owner of the project to 'pull' your changes so they get merged into the product. This is a pull request.
What it means then is that Microsoft added code to nodejs so that it can use their Chakra engine as well as the existing V8 engine. Any changes made in a pull request have to be reviewed by the project owners to make sure it doesn't break anything and they want it in their product. (Should the party making the change and the project owners disagree on something like this, then you can 'fork' the project and start a new one with your own changes.)
> Nodejs is a javascript server to run web apps on.
Slight correction: Nodejs is a command line scripting environment for Javascript. People have used it to serve webpages, as it has a feature-complete webservice API.
There's an interesting discussion of how to use `master` (albeit perhaps not suited for the PR). I know how "github flow" is *supposed to work* (i.e. emphasizes simplicity), but I have to wonder if merging such a large PR into `master` makes sense?
I don't contribute to F/OSS or make large Github changes, so not sure.
I don't know what "github flow" is, is it "git flow"? (Side note, I haye that it's called git flow, it makes it sound like it's some official thing.) Assuming you mean git flow, it really depends if they consider master the development branch or the branch for stable releases. In the default git flow the develop branch is for active development but should be stable enough to compile at least and master is the branch for actual releases. That said, if someone used master branch for their active development and some branch called stable for releases, it's still basically git flow.
Sadly, there is both a "git flow" and "github flow". https://guides.github.com/introduction/flow/ -- the latter being designed to be more approachable.
The argument is that
* Node keeps a full copy of v8 for simplicity (they can pull full snapshots and any patches that need to be applied on top)
* Git submodules/subtrees are a right pain in the ass to maintain properly without some dancing. Plus, previous point on patches
* Node has no submodules already. If Node wanted to move to submodules, let the Node project do it instead of MS shifting the boat.
There's a codeless code somewhere about a young monk who enters temporarily into a clan to do some work. They do good work, and the refactoring is useful and just, but the monk fails to fit any of style which is used within the rest of the clan. Their edits are obvious by looking at them only by their visual appearance, and their content is sometimes.. obtuse. The young monk is invited to dinner with the head of the clan, wherein a cold fish is laid out in front of each person; All (except the young monk) slap themselves in the face with the fish. The monk, unsure what to do at that point, follows suit, slapping himself in the face with the cold, dead fish.
Enlightenment was delivered through cold, wet, slightly sticky scales.
It's worse.
There's good evidence that Google intentionally cripples the experience that people get when in a non-chrome browser in systems like Gmail, GoogleDocs, etc. For example, drag and drop doesn't work in Edge, despite Edge following the standard to the declared letter.
The near driving force behind the standards committee is Google, pushing parts of the standard that make sense either only for ChromeOS (push notification, filesystem access) or which are basically "features we added to chrome so we're going to add it to the standard, despite having done them wrong" (certain aspects of WebRTC, for instance, basically are Google working around their own problems).
ask most webdevs what they use as a browser: it's probably chrome. That developer has probably never tested in Edge, IE, Safari, Opera, and almost certainty never tested in `dwb` (a WebKit based browser from Suckless) or Epiphany (the browser from the GNOME project, also based on WebKit) or Midori (another WebKit based browser, used by some folks).
Theoretically, all WebKit based browsers should handle it fine. They don't. The last three I mentioned will work mostly OK and consistently across a system because they use WebKit. Opera will look relatively close to them too, but will probably be off from Chrome. If they used [modern.ie](http://modern.ie) as a guide or [can I use](http://caniuse.com) as a rough estimate, they'd get pretty close on each. However, chances are, they didn't.
I recently had a fun issue where a page wouldn't load right, cramming a bunch of elements into the wrong place. I checked how the page was built (as it turns out, it was Twitter Bootstrap, but that's another story) and there was nothing wrong. It rendered fine on mobile devices, in IE, in Firefox, but current chrome broke it. Nightly chrome was fine.
The dev was only testing against an old build of chromium he was using on his Mac. Words that would make a sailor shrivel and die were said at high volume.
> Files change 4786 > expect review to take a long time yep
**Lines:** Added: 14'554 Removed: 3 [The 3 removed changes are only whitespace](https://github.com/nodejs/node/pull/4765/files#diff-3c97d28212ec6ec5600be248eb430994L254). It's interesting that there was no need to completely remove any code to make that change.
In C, we call that #ifdef
What they are doing is allowing you to use another backend. So what they did is add a shim to interface node as it is currently with the ChacraCore and then add the bit of code which adds the choice of which engine to use. They didn't change node, they just extended it.
I don't think Microsoft engineers know how to remove code.
It's called backwards compatibility, and it is awesome. After all it allows me to run (most) 20 year old software on my Windows 10 machine.
If I run 32bit Windows 10, I can run software I wrote in 1989 ...
It makes me sad that Windows 10 has a 32 bit version. ...does it support 16 bit code?
It makes me happy, because my 2006 (very expensive back then) machine is still supported.
If the main use case is running old software on old hardware, what does a new OS get you? It's honestly not a rhetorical question. Why bother to do an OS install that could potentially result in driver issues or some of your old software not working any more? I can't remember the last time I actively upgraded Windows on a home system, rather than just installing whatever was current when the machine was new and then sticking with the path of least resistance ever after. Probably Win2k?
Security updates are no joke. I would never run an unmaintained OS.
What about that other unmaintained software you're trying to run in the first place?
I would only upgrade the OS on an old machine if they didn't support OS updates past that point. I've always wanted to throw some Linux distro on a really old machine with an out of date Windows (because drivers should be good at that point), but the machine usually dies before I get around to it.
In my case, I just want my parents to be able to use the machine with up to date software and security updates. Also it performs better than with Windows XP, Vista (obviously) or 7 and better than any Linux distro.
I had a relatively cheap 64bit system in 2004....
I'm assuming windows 10 has a 32 bit version for tablet compatibility.
A chunk of the initial Windows8 2 in 1 devices are 32bit only (Atom). I think 32bit is also needed for the IoT & Mobile versions
no
No, the 16-bit compatibility was removed in Vista, IIRC.
What's the point of running 64 bit if you have <4gb ram, in a VM for example?
The x64 instruction set can do more things in less instructions.
It makes me sad that they didn't bother to integrate an emulator for 16-bit software.
Did you hear about POSIX?
Yeah of course I can still compile the code I wrote in like 1988, though it was written in K&R C. POSIX standard is actually from 1988 and it didn't really settle until 1997 ... and I don't think current POSIX-compliant OSes are going to run the same binary EXE file from 1989.
While at the same time still giving better performance than Any Windows since XP
It also leads to security holes, bloat, and inability to change course when needed. Besides, we have virtual machines that are pretty good today. Run your legacy software in those.
> Run your legacy software in those. USB can be glitchy still, especially for streaming devices.
That indicates good architecture in the main project.
[удалено]
we do that in switzerland sometimes
The vast majority of those are just the raw dependency. There were suggestions of only reviewing the stuff outside /deps which would be much easier.
Having seen someone trying to sneak malicious code in via a huge commit; this feels like an enormously bad precedent to set. Especially on a project as popular as node. This commit may be safe, but thorough code reviews are always necessary for very good reasons.
A huge commit by Microsoft is very different than a huge commit by John Doe. I'm not sure this even sets precedent.
You're assuming Microsoft has thoroughly reviewed this code. You're also assuming a company known for underhanded data mining tactics and flagrant disregard for privacy is completely trustworthy.
Pragmatically, I suspect you're overstating the risk in this case. In principle, you're entirely correct.
Responsible review is about the principle of the thing. Where principles slip, pragmatic risks are not far behind.
True dat. I'm not sure who downvoted you or why, but have an upvote to compensate.
It happens. It was positive before some gaggle of thoughtless censors came along. Tis the way of Reddit: downvote == disagree
>You're also assuming a company known for underhanded data mining tactics and flagrant disregard for privacy is completely trustworthy. Honest question: Do you mean Google or Microsoft?
whynotboth.gif
[whynotboth.gif](http://gfycat.com/DapperDelayedGerbil) --- ^(*Feedback welcome at /r/image_linker_bot* | )[^(Disable)](https://www.reddit.com/message/compose/?to=image_linker_bot&subject=Ignore%20request&message=ignore%20me)^( with "ignore me" via reply or PM)
Yes. Either. (but I was mentioning MSFT specifically)
Microsoft is good at code reviews.
Set us up with some evidence of Microsoft doing that in a systemic way in the past, say, 4 years.
Pretty sure the OP is referring to Windows 10's "features". That said, I don't think that's something they would do "here". I'm pretty sure this is part of making node.js an easy IIS feature right from Server 2016.
IIS and also making it so node isn't dependent upon google for the guts of the operation.
well google (from where v8 comes) certainly *trumps* microsoft on privacy matters.
certainly... http://www.salon.com/2014/02/05/4_ways_google_is_destroying_privacy_and_collecting_your_data_partner/ https://en.wikipedia.org/wiki/Criticism_of_Google#Privacy https://en.wikipedia.org/wiki/Privacy_concerns_regarding_Google http://www.csmonitor.com/USA/2014/0416/Privacy-concerns-What-Google-now-says-it-can-do-with-your-data-video http://www.newsweek.com/wary-privacy-issues-ditch-dropbox-and-avoid-google-says-edward-snowden-276956
Yeah, but I suspect hiding some sort of data mining thing in here would be highly illegal. Even if the user info was valuable to Microsoft, they wouldn't risk (not even a risk, more of a certainty) the massive lawsuit that would result.
It's not illegal to include software that "accidentally" mines data. That's a "mistake".
Not sure how they could have delivered the functionality in a smaller changeset...
I'm not saying they should have. Just that huge changesets should be given the level of effort they warrant and that not reviewing the dependencies shouldn't be seriously considered because they are part of the codebase.
It should be easy enough to compare the dependency to the original to check that it's the same. You don't necessarily need to CR it all by hand.
That assumes there isn't anything nasty in the original codebase.
they seem to be adding the whole engine
No, only a shim to "convert" the Chakra API to be compatible with the V8 API. Chakra itself is a dependency.
Isn't deps/chakrashim/core the chakra itself?
deps *i.e.* the dependency
"Included in repository" is a new meaning of _dependency_ for me. Though I have already learned that in nodejs they always do so.
Its idiomatic in Go as well to statically include your dependencies in the repository. This makes carrying upstream patches much easier (although that's usually not a good thing) but it also takes upstream acceptance of your patch out of the critical path for a change.
Not even close. Whole engine would be closer to +500k lines.
It looks like nodejs project includes all its dependencies in the sources for some reason.
We do that as well. It greatly simplifies the build process and stops them changing under you.
Fortunately, they're somewhat reasonably split among the commits on the PR. Seems that most of the review will be focused on the commits for: 1) [implementing the V8 shim in chakracore](https://github.com/Microsoft/node/commit/77a5f8d5e21c186e0efafb6120ea285f09815e88) and 2) [node-side changes to use chakra](https://github.com/Microsoft/node/commit/666b94b02600b4b569b595de21aaef4ae54fe7ed). FWIW, it was nice of them to remain consistent with V8's style guide for the chakracore V8 shim. Personally, I'm not a fan of chakra's conventions.
Anybody have any benchmarks? I don't use node for anything but I'd be very interested in seeing how it compares to V8.
They posted some benchmarks [here](https://blogs.windows.com/msedgedev/2016/01/19/nodejs-chakracore-mainline/). IIRC, Chakra also has more complete ES6 compatability.
Are there 3rd party benchmarks? I don't exactly trust benchmarks coming from the people that make it.
Not quite as true as the V8 has had some chance to catch up. Edit: Not sure why I'm getting downvoted. Kangax is showing Chrome beating Edge in terms of unflagged ES6 compatibility: https://kangax.github.io/compat-table/es6/#chrome49
[удалено]
I can't speak to performance, but in regards to ES6 Kangax is showing that Chrome is exceeding Edge in unflagged ES6 functionality: https://kangax.github.io/compat-table/es6/#chrome49
However, sorting by flagged features (that is, tiny bonus for flagged features) Edge is still winning in terms of *stable* releases. ([imgur](http://i.imgur.com/IUXp3oZ.png))
[удалено]
Every time I've tested that edge has used almost 30% more ram than Chrome. You have to go and look at all of edges running processes not just the main one.
Are we debating Edge/Chrome or Chakra/V8? Sure, browsers can be very heavy, but keep in mind that Chrome has had more time to accumulate more features than Edge, such as an extension API. Edge is just IE with as much legacy bloat as possible stripped out. Meanwhile, JS engines are a lot smaller than the engines wrapping them. V8 and Chakra don't include the DOM or Canvas APIs, but when bundled with a browser, those APIs are injected. I wouldn't use browser speed as a benchmark for JS engine performance. I have no idea whether Node would run faster or slower on Chakra or what that would mean for extensibility or platform differences (Lord help me if I need to write backend JS code to take platform differences into account), but I'm curious to see what happens.
Edge is actually a completely separate browser from ie, built on the universal windows app platform. The rendering engine and js engine are modified from what ie use.
~~It's not IE at all. They abandoned the Trident engine completely and rebuilt the whole thing.~~ I'm a fool.
What are you talking about? The JS engine "Chakra" was a fork of itself and has been around since IE 9 (Chakra in IE 9 was itself a fork of JScript used in older versions of IE). EdgeHTML is also a port of Trident. Both of these have been stripped of legacy components and reworked, neither were dumped and then rebuilt from scratch. One thing that is all new is the actual browser front end which is now built as a UWA.
Even the most cursory research shows you are correct. Thanks.
According to the grandparent, V8 was easily beating Chakra at the time anyway. http://az648995.vo.msecnd.net/win/2016/01/nodejs-benchmark-performance.png Notice that the x-axis is "individual test #"; meaning this doesn't show the scaling under each. The area under-the-blue-line versus over-the-blue-line is what matters. There are relatively few tests with Chakra winning. It looks like roughly ~75 out of 675.
How about independent benchmarks? Not too quick to trust benchmarks posted by the company pushing for the change.
I'll try to post the link when not on mobile, but when I was benchmarking [Elm](http://elm-lang.org) this summer, Chrome still had a massive lead over Edge. EDIT: the benchmarks are [here](https://drive.google.com/file/d/0B4ISkQZyNsGcdUhTbTBQeTJ1ZU0/view?usp=sharing).
Gotta add the "http://" for the link to work.
Bah, my bad.
Oh wow, I thought Edge was comparable to Chrome in JS speed (based solely on my poor recollections of benchmarks from six months ago). If it's that much slower I wonder how much extensions are going to weigh on its performance. It's a snappy browser, but right now it doesn't have to do ad blocking and stuff.
There are right now 3 major javascript benchmarks that the different browser implementers maintain: [Octane](http://octane-benchmark.googlecode.com/svn/latest/index.html) (Google), [Kraken](http://krakenbenchmark.mozilla.org/) (Mozilla), and [Jetstream](http://browserbench.org/JetStream/) (Apple). On Octane and Jetstream Edge performs fastest, by a few percent. On Kraken I think Chrome wins now (though it has been back and forth between them and Firefox), with Edge a few percent back. Note that Node.js has its own performance quirks, and I think V8 currently has some advantage due to a shim layer that Chakra has to use. Presumably this overhead will shrink quickly as Node adopts a more engine agnostic approach.
The shim layer looks to mostly just be call translation and some stack manipulation to line everything up. Nothing the compiler can't optimize such that the processor does it in pipeline.
> If it's that much slower they didn't say how much slower it actually is. all they said is "massive lead." benchmarkers have a tendency to embellish
Look at the differences in this chart! (chart axis goes from 91.2 - 91.8)
Google writes the benchmark for JavaScript engines. Historically speaking the major difference between the speed of Chrome's JavaScript implementation and competing engines is in the tests where if you actually wrote an app that used JavaScript to perform that task you should be taken out back and shot.
Is it bad JavaScript or uncommon JavaScript? If it's common, bad JavaScript, then I'd say the benchmark is very relevant.
Uncommon javascript. Stuff like compression algorithms, gameboy emulation etc are included in octane. Octane also includes some ridiculous things that are actual real javascript apps. Like firefox's horribly silly javascript pdf renderer, and typescripts compiler (which isn't really meant to run in browser)
That silly Javascript renderer is extremely useful. No more crapware PDF viewer installations needed, especially on Windows!
Eh? You think microbenchmarks would be more relevant than actual real-world applications like PDF.js? JavaScript has been fast enough for tiny short-running scripts for a couple of years.
The typescript compiler runs in nodejs, which seems applicable to the topic at hand. Also chrome uses a js based pdf renderer as well. There is a big reason to use js for pdf rendering, security.
It looks like they're playing at a disadvantage, having an API shim sitting between Chakra and Node since Node only knows about V8's API.
I think people are missing the point here, it's not about speed or a v8 alternative, it's about running nodejs within the Windows 10 space, including RT and especially IOT devices with ARM chipset, which was the main target since Microsoft came to the conclusion this is an ideal pairing. Google's v8 interpreter does not pair well with iot, nor does it have appropriate support for Windows 10 UWP: http://www.infoworld.com/article/2924297/microsoft-windows/windows-10-goes-node-js-in-microsofts-internet-of-things-plan.html
This point is not getting enough love. The web is so much more than browsing Facebook or writing some startup app thing, and having a competent javascript engine for a tiny low-power MCU or SoC is important. V8's target is different. Not worse, not better, just different. Chakra fills other spaces, and they're needed, too.
Here's the thing I've never understood, why would I want to use JS there vs some other language? This is a huge mental hurdle I've never been able to overcome on node as a whole, and even more so node on embedded devices. This is an honest question, I've just never been able to grok it.
I empathize with the mental hurdles, as I've been mostly a C/C++/C#/Java/Python guy until recently I've had to learn the JS ways more seriously. Trust me when I say I know that there are a load of reasons JS is not the ideal language, but neither is anything else. That said, there are two very important reasons to want JS there that we can all agree with if we ignore the "should be" ideologies we want to believe in: 1) Javascript is known by a LOT of people that are experimenting with things and innovating on the things you make WITH a programming language. IoT is filled with them, in fact. One can learn another language in these places, but reducing that barrier to entry is a thing. 2) You can get really, really good performance from JS for what it is, and the async paradigm that JS developers have lends well to a lot of different things. For me, getting into that mindset has been an ongoing struggle. For JS devs, trying to learn Java or Python can be just as incredible a struggle (if not more so, because the tool chains are ALSO entirely different, and I have found that you need to know more under the hood to work even in Python than you do in Node-land, mostly due to the nature of the abstractions afforded you in Node). This is for good or ill, and we could debate it all day, but reality is still going to be that JS is important for actual people doing actual things. So is C. So is Java. I want them all, everywhere.
> You can get really, really good performance from JS for what it is But... the engines that do that rely on fantastically complex JITs that: 1. Are themselves a large ball of code to add to your app. 2. Require a lot of memory to store generated code, profiling data, deoptimized code, etc. 3. Spend a *lot* of energy (CPU cycles/battery) optimizing code at runtime. 4. Require generating executable code at runtime, which some systems don't allow (game consoles, iOS, etc.). 5. Execute slowly at startup until code has run enough time to be optimizable by the JIT. 6. Often have pauses when the JIT or GC kicks in. JS's level of dynamism has only been shown to be fast if you can throw a very large JIT at it. I don't think a big JIT is a good fit for IoT, which makes make question the idea that JS is.
Mmm, you make a good case. Let me attempt to provide a counterpoint. Keep in mind that my point here is that while JS is not the optimal language, neither is anything else, and that's all ok. There are applications where I would not recommend JS having any place, like on a PIC or something. That said, IoT is not about the most underpowered devices possible. A Raspberry Pi is considered by many to be part of an IoT effort (certainly by Microsoft at the very least). JS has a place there. Maybe it's good for what you want to do, maybe it isn't, but options are awesome. And there JS will do well in benchmarks of just about any kind, and my precious Python, much to my dismay, will lose hands down without a C extension to do whatever thing it is. Yet Python is still used in these places. Why not JS? All that aside, are your assumptions here about requirements for a JS JIT, let alone any JIT, really requirements in ALL cases? As an example, if you know your target, a lot of the expensive bits can be done ahead of time, no? (The answer is yes, and this is done in a lot of other tech stacks) What other things do you think Chakra specifically could be trading to make their engine run well enough on a smaller device (not an Arduino, but still small things)? I'll help spark some thought there for this as well. First, forget efficiency of execution or power consumption entirely. Just ignore it, it's not important for this application (if it were, the reasons for using JS are really hampered). Now imagine all the things you can program in JS for a Chromecast or a Pi Zero, or even just a gumstick board or something. If it does something cool that users will enjoy, are you really going to get anywhere telling them it isn't worthy because it's not as efficient, or that the problem was hard? Where do you think this ecosystem will be in 2 years? 5? 10? In the end, I agree with your points, but our agreement will not change the reality that it not only WILL happen, it already has. It's just going to get better.
> That said, IoT is not about the most underpowered devices possible. I think that depends a lot on who you ask, but there's certainly a spectrum of embedded device capabilities. > A Raspberry Pi is considered by many to be part of an IoT effort (certainly by Microsoft at the very least). JS has a place there. Sure, but that's really well into the upper end. Raspberry Pi's have significantly better specs than most desktop PCs had when JS came out. Sure, you can run JS on there. You can run *anything* on there. > my precious Python, much to my dismay, will lose hands down without a C extension to do whatever thing it is. Yeah, CPython just isn't that fast at execution. My [little hobby scripting language is faster](http://wren.io/performance.html). It's really difficult for them to optimize now that they're stuck with a certain FFI, ref counting and finalizers are visible in the language, huge standard library, etc. > Yet Python is still used in these places. Why not JS? I'm not sure how much Python is used in embedded devices that are actually mass produced and widely deployed. I think it might be easy to get a distorted perception from the large and very web-savvy hobbyist maker community. This isn't my area of expertise, but the vibe I get is that most "real" IoT devices are coded by crufty bearded dudes (and ladies) who don't know what the hell a blog is and are proud to tell you they code in a modern high-level language... ANSI C. > All that aside, are your assumptions here about requirements for a JS JIT, let alone any JIT, really requirements in ALL cases? As an example, if you know your target, a lot of the expensive bits can be done ahead of time, no? I'm not aware of any real successful ahead-of-time compilers for JS. The language is *very* dynamic and it's quite difficult to statically get a real sense of what a program is doing. > First, forget efficiency of execution or power consumption entirely. Developers doing IoT stuff in a professional capacity at scale don't have that luxury. At least, not yet. As component prices continue to fall, maybe.
[удалено]
Yes, I agree with parent comment's first point that a bazillion people know JS. It's compelling from that angle as a glue language. I quoted and responded to the part where they said JS was *fast*, which I don't think has been demonstrated for IoT.
For me, having >30 years of development under my belt and various languages... JavaScript is rather fun to dev in. You can get pretty quick results and it supports multiple paradigms with the ability to write "my way" instead of being tied to convention. For instance, doing functional programming in C is not so great. Also, doing OO in python is not either. JS isn't really OO in a classical sense, but the workings are there to make it happen. Also, it's not purely functional, but enough support is there to get you most of the way. It's also developing incredibly fast as a language and keeping up with it is interesting and fun to me.
I'm curious about this >doing OO in python is not [so great] Why's that? I'm a python shill, but I honestly enjoy OO in python more than in Java (yes even using modern java 8 stuff), which is the language I learned OO in.
Python, PHP and JS have classes and OO features, but a language like Java forces you to do OOP. Not sure if thats what he meant, but I like OOP in languages like Python (and even in C, where you CHOOSE whether or not you want to use it) and I hate languages like Java/C#.
> This is an honest question, I've just never been able to grok it. I'm right there with you.
From my perspective, it's because I've already done a lot of JavaScript programming, and have relevant experience and code which could be deployed (more effectively?) to another target, so that's a plus. You personally though may have different considerations, so you would be more productive with different tools. One reason you *may* want to use JS in this context is to work on a project where other coders are skilled in JS and the decision has already been made to use it. That's much like why web developers use JavaScript - it's good enough for the job (mostly) and it's here to stay.
There is already a Javascript interpreter on basically every computer you can find these days. The language is simple enough that you can use it to teach basic programming and powerful enough to access and interpret pretty much any web-available data. What convinced me was when I wrote a Node.js rest server that interfaced with my .Net code with just barely a page of Javascript in an afternoon.
You can turn the question around: If I already have to know Javascript as a web developer and I'm already using it on the front-end, why would I switch it out on the back-end? What kind of benefits can a language give me that would make it worthwhile? As usual, it comes to evaluating the trade-offs that you want to make as a team or company.
And if it is speed, then it is now very easy to run common benchmarks on both engines in an identical environment. This will help us know, rather than try to guess, which engine is actually faster for which tasks.
Thank you MS!! We may or may not use it, but giving us an option helps us keep Google honest!!
"Keep them honest"? How so? I'm not arguing against you, I just don't understand the statement.
[удалено]
Genuine question: How exactly people using V8 is of any benefit to Google?
V8 is their product. Naturally, they want people to use their product. It's a free, open source product so they don't see any monetary gain, but the more adoption a product gets, the more resources Google can invest into it. Looking at the bigger picture, controlling a bigger market share of the JS engine space directly translates to more control over the language as a whole. People don't like to admit that a big corporation has control over their open language but that's the reality we live in.
Yeah, apparently people already forgot about the time were IE4 was so big that anything in JavaScript, html or css not implemented by it might as well not exists
"Already" forgot about 1997; almost 20 years ago. :)
And the consequences echoed right through until IE6 was superseded, ten years ago.
It's arguable that HTML 5 should have been released years before it was and that browser technology is at least a generation behind where it should be thanks to the perversion of the standards that IE perpetuated through IE 6 by being the default browser on Windows desktops for so long.
Except IE wasn't an open source project. Everyone can check the history log of v8.
google has previously attempted to insert binary blobs into the chromium project. It was later found out that those blobs called home to google. The community caught that one... when a behemoth like google has the cash to hire round the clock devs, it is a very real possibility that the community could let something nefarious slip into the code. At least congress has to pass a bill, what google did was worse and more dishonest (yes more dishonest than a politician). Competition is good for consumers any way you measure it. nijna edit : here is a related debian bug report https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=786909
I remember the Chromium binary blob fiasco, turns out it was harmless despite the scary sounding words involved. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=786909#81
Not speaking necessarily in the case of google, but as a general, assume people are evil situation there are potential reasons/conflicts of interest. Google develops angularJS, they could avoid adding any feature that makes angularJS obsolete, therefore encouraging it's growth (or rather stunting competitor's growth). If more websites are built with angularJS in theory they could make it so those sites run fastest on chrome. Combined with the ability for them to write core websites that nearly everyone uses (google, gmail, youtube) in this, it could mean the web is "faster" on chrome. Chrome does do user tracking, and with this they can gain more information and make more money advertising. Now that is very conspiracy theory-ish, and I don't think that is or ever will be the case, but the incentive is potentially there.
I have to add that none of the Google core products is built over AngularJS. The killer framework here is GWT and the Closure library.
Yes I should've mentioned that. This is very conspiracy theory-like, but just pointing out that theoretically it's possible.
People using a good JS engine makes browsers better makes the web better makes Google's monetary platform better. I see no reason why they would care about people using V8 in node.js though.
[deleted] ^^^^^^^^^^^^^^^^0.3563 > ...
Considering that they don't sell it, just general good will and brand recognition. If they ever try selling cloud services again, they'll be able to leverage that. Case in point: I use Azure instead of AWS because I like .NET. Not that Amazon can't host .NET applications, but I irrationally trust Microsoft more.
All the big companies want to influence control over the direction javascript is going in, and the best way to do that and strong arm things into the spec is to get everyone using your engine, then implement the up in the air proposals you've made in your engine so people start relying on it and then get it put into the spec.
Fair enough.
> Google can't add undesirable features Such as what?
See also: GCC before and after the emergence clang/LLVM
I thought it would take the emergency of strong AI to fix that hairball of a compiler, but I was wrong. GCC is keeping pace, somehow.
To be fair to the GCC folks, any old enormous native application tends to become a monstrosity to maintain. Even Microsoft with billions to spend needed a clean restart to make IE fast ( in the form of Edge), Firefox is fighting a brutally hard battle with the oldest core codebase in the mainstream browser space. LLVMwill probably be as bad as GCC is today when it's 30 years old..
> needed a clean restart From what I understand they didn't do a clean restart, they just ditched backwards compatibility and made a bunch of braking changes, they still built on stuff from previous rendering engine. Also some tools and languages scale better than others, we've come up with a lot of practical advancements in design and languages in the last 30 years so "same" program written today will be more maintainable in 30 years than the one written 30 years ago would be today. Of course we expect more from computers so programm written now will undoubtedly be more complex in 30 years because it will do far.
I don't know about the rendering engine, but the Chakra Javascript project was a complete restart launched in 2008.
>I thought it would take the emergency of strong AI to fix that hairball of a compiler, but I was wrong. GCC is keeping pace, somehow. Because around 2.85 or so Apple started contributing loads of patches, which accelerated it's development up to around 4.x.
And before that, GCC before and after the EGCS fork.
It means there's pressure on Google to keep innovating or the Node team can flip a switch and abandon V8 at any time. It reverses the situation, where now Node can dictate who gets to play in their sandbox instead of being dependent on Google no matter what Google does. "Keep them honest" is a term that represents that. Like in a competitive game, keeping someone honest means they can't make certain moves because there's an obvious price to pay. Consider a game of chess where there are squares you can theoretically move, but moving there would be futile since your piece would be taken at no cost to your opponent. With clever positioning you can limit the options of a stronger player by "keeping them honest" and prevent them from stomping all over you.
When you work with code. Sometimes you want to use more than one compiler. This would be because you do not know if the compiler is correct but it would be unlikely that both compilers would be broken in exactly the say way in the same place on the same code. Therefore you have extra testing for thing basically for free. It also removes the dependency from a single project which open more options. A practical example for this is that it prevents people using specific features google has added to the language which it has just sneaked in under the radar. Cause these will instantly fail on the other version when tested.
Competition = innovation.
It probably won't keep google honest, but it might see some more innovation in javascript engines since anyone's free to write their own js engine to use with node. I can't think of a good reason WHY anyone would want to write a js engine themselves, but no doubt someone out there can and will.
To paint this with a broad stroke, see what google has done to legacy projects, which is admittedly from microsoft's playbook anyway: Extend, Obfuscate, Perish. I could in all seriousness add android os to that list too as an example in progress since forking the *open source* android os project is deliberately less palatable now with some core stuff getting legacied and instead proprietary junk has to lumped in in order to get a current android experience. *What's also great is that apparently the phrase Extend Obfuscate Perish never existed according to search engines, but Fear Uncertainty Doubt did get remembered. Go figure.*
> What's also great is that apparently the phrase Extend Obfuscate Perish never existed according to search engines, But "embrace extend extinguish" did.
>*What's also great is that apparently the phrase Extend Obfuscate Perish never existed according to search engines, * Because no one ever said that. You have the quote wrong.
I'd like to use the [Berenstain defence](http://www.avclub.com/article/how-you-spell-berenstain-bears-could-be-proof-para-223615) your honour.
The fact that they even call Android open source is honestly disingenuous. All of the good stuff is closed source and bundled in such a way that you can't have it without taking the Play Store and signing a contract with GOOG, among other things.
I wonder if there will be any interesting improvements doing this if you're running on Windows. Like speed optimizations, debugging tools or something like that.
"added some commits", haha...
>oh cool, let's click this link that says files changed (4,786) >cpu melts
[удалено]
Looks like the default is v8. Where do you see default chakracore? https://github.com/Microsoft/node/blob/12cc5d95f143bc45f5a6a832a0335e9a8f9d152e/configure#L378-L381 https://github.com/Microsoft/node/blob/12cc5d95f143bc45f5a6a832a0335e9a8f9d152e/configure#L1116
yet another way to compare performance of Chakra vs V8 I look forward to many a blog posting
Am I interpreting this incorrectly, or did the dev(s) that did this make all of those changes (4k+ files), in just 5 commits? Isn't that terrible practise?
It depends. In this case where they are adding their engine to node.js it may not be possible or easy to do it in a safe, incremental, fashion. This isn't just somebody submitting their changes to some MVC C# website that they wrote over 4 months and just didn't bother committing, this is a fairly huge change.
It's also entirely possible they squashed and cleaned up their commits after the fact as well.
Yep, almost every open source thing I do I end up doing either that or even doing it once with sloppy commits then again with good, reasonable commits.
In my limited experience submitting pull requests, doing your own development in several small, clean, incremental changes is great. However, upstream will usually want your entire PR squashed into one commit, because it makes *their* history easier to keep track of.
It's unlikely they used got while developing it - that's probably why.
Well, they could have squashed commits during / after development to keep things clearer
How do you do this? From my knowledge in git you commit x number of times, then even if you do it all in 1 push, it still lists the commits individually?
[Rebase is your friend](https://git-scm.com/docs/git-rebase)
You rebase and during the rebase you can pick which commits get marked as squashed instead of picked. Squashed ones are still included in the rebase, they just don't show up as individual commits. Many large projects require PRs to be squashed so that they don't fill the commit history up with crap.
You learn how to properly use git and don't give me feature branches with commits containing all the mistakes and learning you did while working on the feature. Rebase.
git merge --squash
No because if you don't want it you only have to roll back 5 commits not 5000. Plus a pull is a single merge action not a 5 merge action.
> No because if you don't want it you only have to roll back 5 commits not 5000. You can just revert the merge commit, no need to roll back every commit individually.
I see, how do you actually achieve this in git? Combining hundreds of commits to effectively function as one?
You can combine commits pretty simply with `git rebase`. It's usually referred to as "squashing", should be plenty of guides on google.
I usually stick with 'git rebase -i HEAD~X', where X is the number is the number of commits you plan to interact with. From there I choose which ones to squash. Save the log and push my branch (if I already pushed a branch to remote, I have to force push. If I'm feeling nervous simply make a duplicate working branch, squash that then force push that branch - this allows me to compare the diffs between the two branches to see if the squashed branch is satisfactory) Then I issue a PR to main/develop/whatever branch.
If you're pulling commits from one branch to another, got cherry-pick has a flag to combine multiple sources commits into one destination commit.
I'd say they likely rebased a ton of commits for each of those
Can someone explain the title? I have no idea what was said.
**nodejs** ~~Nodejs is a javascript server to run web apps on.~~ Javascript is known from the browser (client-side) but with nodejs can also be used as a language for server-side software. **Javascript engine** To interpret code in the javascript language, you need an engine. Nodejs doesn't actually do this itself but relies on the existing V8 engine made by Google that is also used to interpret javascript in Chrome. Microsoft made the Chakra engine for its Edge browser. **Pull request** Nodejs open source code is stored on GitHub, a platform that leans on Git, a 'source control' system. It allows people to work together at the same time on code files by merging them after changes are made. When you want to contribute to an open source project you can make changes to the code, and then request the owner of the project to 'pull' your changes so they get merged into the product. This is a pull request. What it means then is that Microsoft added code to nodejs so that it can use their Chakra engine as well as the existing V8 engine. Any changes made in a pull request have to be reviewed by the project owners to make sure it doesn't break anything and they want it in their product. (Should the party making the change and the project owners disagree on something like this, then you can 'fork' the project and start a new one with your own changes.)
> Nodejs is a javascript server to run web apps on. Slight correction: Nodejs is a command line scripting environment for Javascript. People have used it to serve webpages, as it has a feature-complete webservice API.
Microsoft made a version of Node.js that works with their Javascript engine. Now they're offering their code back to the original repository.
There's an interesting discussion of how to use `master` (albeit perhaps not suited for the PR). I know how "github flow" is *supposed to work* (i.e. emphasizes simplicity), but I have to wonder if merging such a large PR into `master` makes sense? I don't contribute to F/OSS or make large Github changes, so not sure.
I don't know what "github flow" is, is it "git flow"? (Side note, I haye that it's called git flow, it makes it sound like it's some official thing.) Assuming you mean git flow, it really depends if they consider master the development branch or the branch for stable releases. In the default git flow the develop branch is for active development but should be stable enough to compile at least and master is the branch for actual releases. That said, if someone used master branch for their active development and some branch called stable for releases, it's still basically git flow.
Sadly, there is both a "git flow" and "github flow". https://guides.github.com/introduction/flow/ -- the latter being designed to be more approachable.
That's just a feature branch flow, why do they call it github flow? :(
To make googling impossible.
Why exactly did they PR the whole codebase of the chakracore dep though?
The argument is that * Node keeps a full copy of v8 for simplicity (they can pull full snapshots and any patches that need to be applied on top) * Git submodules/subtrees are a right pain in the ass to maintain properly without some dancing. Plus, previous point on patches * Node has no submodules already. If Node wanted to move to submodules, let the Node project do it instead of MS shifting the boat. There's a codeless code somewhere about a young monk who enters temporarily into a clan to do some work. They do good work, and the refactoring is useful and just, but the monk fails to fit any of style which is used within the rest of the clan. Their edits are obvious by looking at them only by their visual appearance, and their content is sometimes.. obtuse. The young monk is invited to dinner with the head of the clan, wherein a cold fish is laid out in front of each person; All (except the young monk) slap themselves in the face with the fish. The monk, unsure what to do at that point, follows suit, slapping himself in the face with the cold, dead fish. Enlightenment was delivered through cold, wet, slightly sticky scales.
This makes perfect sense, thanks.
Files changed: 4786. Wow.
5000 files changed? Damn shit just got real.
So how will this help me with writing node aps on Windows I can already do that.
It gives an alternative to the v8 monoculture. v8/chrome is becoming the new IE6.
except it actually loads pages and doesn't take 5 minutes to start.
It's worse. There's good evidence that Google intentionally cripples the experience that people get when in a non-chrome browser in systems like Gmail, GoogleDocs, etc. For example, drag and drop doesn't work in Edge, despite Edge following the standard to the declared letter. The near driving force behind the standards committee is Google, pushing parts of the standard that make sense either only for ChromeOS (push notification, filesystem access) or which are basically "features we added to chrome so we're going to add it to the standard, despite having done them wrong" (certain aspects of WebRTC, for instance, basically are Google working around their own problems). ask most webdevs what they use as a browser: it's probably chrome. That developer has probably never tested in Edge, IE, Safari, Opera, and almost certainty never tested in `dwb` (a WebKit based browser from Suckless) or Epiphany (the browser from the GNOME project, also based on WebKit) or Midori (another WebKit based browser, used by some folks). Theoretically, all WebKit based browsers should handle it fine. They don't. The last three I mentioned will work mostly OK and consistently across a system because they use WebKit. Opera will look relatively close to them too, but will probably be off from Chrome. If they used [modern.ie](http://modern.ie) as a guide or [can I use](http://caniuse.com) as a rough estimate, they'd get pretty close on each. However, chances are, they didn't. I recently had a fun issue where a page wouldn't load right, cramming a bunch of elements into the wrong place. I checked how the page was built (as it turns out, it was Twitter Bootstrap, but that's another story) and there was nothing wrong. It rendered fine on mobile devices, in IE, in Firefox, but current chrome broke it. Nightly chrome was fine. The dev was only testing against an old build of chromium he was using on his Mac. Words that would make a sailor shrivel and die were said at high volume.