morebetterer

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.

Thank goodness we have you and others to police the jokes. Remain vigilant! Keep up the good work.

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.

I bet it was. Well done.

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.

Old code never dies.

No, never had a need for it.

I have a soft spot for those short-lived X-terminals as well. The golden age of computing.

Colors are great for web browsing, don't get me wrong. Just not near my code!

"Catered to", "dissuade", "push that choice" and "insanity"?

Now this is just getting silly. You are taking my comments far too seriously.

I don't even want color and terminal graphics done goodly. I code with two monochrome terminals on the screen using vim and the command line.

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.

What about:

* sqlite3 amalgamation: https://www.sqlite.org/download.html

* duktape javascript interpreter: http://duktape.org

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.

As long as each JS engine uses the same API (at this point V8's C++ API, hopefully something engine neutral later) what difference does it make?

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.

Keep in mind that native modules coded against NAN1 do not work with NAN2. Not sure about forward compatibility of NAN.

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.

https://github.com/jxcore/jxcore

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.

That thread doesn't show a lot of promise towards an engine neutral API.

I see Chakra has caught to up Dec 30, 2015 with the nodejs tree. Which branch are you basing the fork against?

Any progress in talks with Node.JS to make an implementation independent JS engine API for node?

Ironically Microsoft had to create a V8 C++ API facade over Chakra in order for Node to compile with it.

https://github.com/Microsoft/node/tree/chnext/deps/chakrashi...

It's interesting that the license of the Chakra shim is the V8 license:

https://github.com/Microsoft/node/blob/chnext/deps/chakrashi...

Constantly being interrupted to answer simple questions is a thankless task that has negative consequences to your own productivity. You ultimately have to do their work and have less time for your own, which can be stressful when on projects with tight deadlines (aren't they all?). At some point I realized that being overly helpful makes you an enabler of this rude behavior - why bother spending a few minutes researching something when the guy across from you can answer it immediately? Often it's better to say no and encourage more self reliance.

Isn't it possible to create multiple asm.js memory arenas?

Aside from a few game demos, is anyone using asm.js in production systems?

Good stuff.

Looking forward to the neutral binding layer for different javascript engines for Node.

Ideally for a given platform a native Node module should be ABI compatible with v8 Node or Chakra node - without the need for recompilation.

I am fully aware of that. I had to port orphaned NAN1 code to the new v8 API which I found easier to work with than NAN2.

Are you aware that NAN2's API is incompatible with NAN1's API? How is that backwards compatible?

It would be very interesting if you could share your team's challenges and insights in creating a Chakra shim that exactly mirrors v8's C++ API so that it's a drop in replacement for v8 for Node. Is it difficult to maintain the Chakra shim against an ever-changing v8 API?

Since NAN basically parrots the v8 API, I find it's easier to just code to the ever-changing v8 API, rather than the ever-changing NAN API. With the former approach you get readable and debuggable code. I'm not sure what NAN isolates you from if it doesn't have a strong API guarantee to protect you from future v8 API changes.