I like the proposal. It took me 20 years to master the 10% of C++ I understand and use. I wonder how new programmers will be able to pick up this language.
I was asked a question and provided an answer. So I don't care for syntax highlighting or colors in my editor and command line - big deal. I am not imposing my view on others.
When working with a command line one wants npm or any command to run as quickly as possible. Any graphics that slow operation of the command should be an opt-in, not an opt-out.
Everyone is entitled to their opinion, but some people prefer to suppress others' opinion.
A couple of years ago I was just about to throw out all my O'Reilly X Window/Motif books from 20 years ago and when I landed a contract to update a K&R C based Motif system running on 32-bit Solaris connected to - of course - Sybase. It felt like I travelled back in time.
Upon first seeing npm 3.x I immediately added `--progress false --color false` to my npm installs and never looked back. Color and terminal graphics are the work of the devil.
If it's a compile-time switch to build v8 or Chakra and it's not impeding Node development, there's no harm.
Node is a large code base. The Chakra merge will eventually work and pass all tests - give it some time. One cannot reasonably expect such a large merge to work flawlessly out of the gate. Even the IBM PowerPC port of the V8 engine took many months to stabilize - and it's the same v8 engine.
>>> I don't believe the web is stronger with more rendering engines and more JS runtimes... I think it's weaker
I disagree. I'm happy to see numerous JS engine implementations that embrace a common standard. If you have just one common code base you also have a common set of bugs. Competition is a great way to raise the bar and try out radically different design approaches. Take GCC and LLVM for example - who can argue that friendly competition hasn't helped them both immeasurably? Link Time Optimization, C++14 compliance - choice is a good thing.
Many posters in that Github Chakra pull request thread appear to be in the "Node is V8 and only V8" camp. This is disappointing. Since when is having a bigger developer community, supporting the latest ES6 standards, and having wider reach for NodeJS a bad thing? Look at what the friendly rivalry has done for the various browsers - the competition benefitted everyone and advanced technology immeasurably.
The Node fork JXCore supports Chakra, SpiderMonkey and V8 right now. It's pretty fast, probably because it's based on a pre-0.12 node fork when node was known to be faster than it is presently.
I hope the V8 C++ API doesn't become the defacto Node engine API. Node really needs a proper engine-neutral API. This way the native node modules can truly be portable across engines and across node versions.
Supporting additional JS engines would ultimately lead to a healthier ecosystem and higher quality JS implementations.
The state of documentation of Express 4 is not great. You have to look at the source code to see how it really works most times, or read someone's blog about how it used to work in Express 3 - but no longer does.
Whose decision was it to go from a "batteries included" web server module to one where users had to assemble a bunch of ad-hoc third party components to make a usable web server? I'm looking at you, body-parser.