First of all development of Ares has only recently been reinvigorated by LG devoting assets to the project which HP had taken a dump on when they pretty much gave up on WebOS.
EnyoJS is rock-star tech that rock-stars refuse to look at close enough to realize it is what facebook wants react to be - but 10 years ago, and is now the only truly platform independent JS framework.
Much work has been done by the LG designers as far as UI (I have followed their often ignored progress very closely of late) and the architecture of Enyo.
It is commonly misunderstood due to media sensationalism that LG "aquired" WebOS and it's goodies - NO NO NO - what they did is "aquired" the rights to utilize WebOS, along with the rights to own HP's nifty little office building in San Francisco (to house LG's nifty designers and devs) all under the agreement that they would pay an outrageous amount of money for these nifty items, and furthermore, that LG would slave away at WebOS/Enyo so that HP doesn't have to, all the while so that HP can benefit from the fruits since HP still owns WebOS/Enyo and friends. Phewwwwww
Just don't say things like "too bad LG is murdering WebOS and Enyo" because it makes me feel sad and angry and contributes to the propaganda machine of dis-information regarding the details of the deal between LG/HP (the details which have been hashed out in a secret agreement BTW) - this doesn't help things as the media was left with no choice but to sensationalize it even more, and without the benefit of the facts of the deals terms to at least sprinkle some truth around too.
This would be as easy as a easy peaze of Cake. Even easier to bring it to the MUCH MORE SUPERIRIOR NW.JS. Then it would be to react what Intel XDK is to Cordova/Phonegap. And what that greek god guy is to EnyoJS and/or WebOS.
Nah, we will just continue to make more and more meta-compilers for our meta-languages so that they can inevitably become JavaScript just the same.
We will continue to do this until the end of time because we are stubborn developers that need to write our code exactly as only we personally prefer, regardless of the web-destroying and kitten-killing implications.
Seriously though (or are we?) the past 25 years of JavaScripting has amassed one heaping pile of momentum that wont end for at least another 25 years when our programs will be rewritten by our deep-learning quantum neural-net robotrons which will certainly deny us access after erasing any trace of these sacred ancient JavaScripts - leaving us helpless as we wait for our nano-thin clients to render our results in the cloud so that they can be displayed on our nano-thin displays.
It's an abysmal future but someone has to live in it. Me however, I will be surely DEAD. HAHAHAHAHAHAHHA
When you say NPAPI (now deprecated) you refer to a very wide spectrum of API's for very different problems. One such API under the NPAPI umbrella is NaCl/PNaCl which attempts to solve the problem of performance by allowing developers to use existing native C/C++ code by compiling it to a portable bytecode format based on LLVM, this is compiled ahead of time, achieving the same performance as traditional native execution in C/C++ (something that has be packing a boner 24/7). This code can be compiled to run on any platform in the case of PNaCl (NaCl is on it's way out anyway) and suffers a nominal performance penalty that is only felt up-front, not during execution.
Alas all good things must come to an end, as Mozilla rejects this outright and chastises google for their anti-web-progress ways and their secret JavaScript assassination plots. The net effect is a whole lot of naysaying and bitching leading to the inevitable deprecation of PNaCl, though this will take a while since certain industries like gaming (NVidia) use it heavily and rely upon it to deliver high performance gaming on the web.
Mozilla's attempt to solve this problem and their answer for PNaCl was/is ASM.JS which accomplishes a fraction of the performance gain, but does allow for semi-efficient porting of C/C++ code-bases to this esoteric form of JavaScript, which runs as a VM written in JS which is running in a VM.........
Both technologies allow for any code that can be LLVM'd to be ported to the web with at least decent performance - and both are secure methods (PNaCl achieves security with it's double sandbox design and a strict hands-off-no-touchy the dancer rule). Both of these technologies share one final thing in common: they recently have been slated for certain deprecation in light of a new standard that Google and Mozilla actually agree on - they call this unicorn "WebAssembly" and it has just recently (like a few hours ago) been officially announced so it's a ways off. IE would then be forced to jump on the bandwagon, which may take them awhile though they are getting much better about keeping a positive attitude when swallowing Google's formidable load. Perhaps out of survival... Anyway, I look forward to this as it should bring similar performance to that found in PNaCl but with a standards based approach that is more "Web friendly" like ASM.JS - but I am now I am way off-topic and not sure what I am talking about anymore.
Your speculation that we are in for interesting times ahead of unwarranted, we have been in interesting times for at least a few years in which all of the things you described are certainly possible but few developers existed with the skills, time, funding, or incentive to do so. It has only taken this long for Firefox to catch up to Google's ridiculous momentum so that such tools could be made for an acceptable portion of browser market-share that the industry would be able really sink their sharp teeth into and not stay up all night worrying about profits and if Timmy's grandmother will finally listen to him and allow her browser to update.
I intend to not only add WAI-ARAI conformance but even better, to merge the work of this project: http://khan.github.io/tota11y/ into the builder itself, so that the developer can benefit from moment to moment conformance feedback as the application is built - instead of the typical process a developer goes through when he builds a successful application and quickly finds out as an afterthought that these things are not only important, but often necessary. If I ever get around to it I want to go the extra miracle mile and allow for an /actually/ usable voice guided process of building software so that blind users can finally leverage their largely underrated skills in abstraction.
It is abysmal how rare it is to ever find any usable software for the blind, even fewer that they actually enjoy using, and I know of not one such tool for development esp. front-end.
I plan to add an agnostic generator for code-coverage that can be easily extended to allow generators for a given testing toolkit. I will adapt it as necessary to facilitate unforeseen/esoteric features as new testers get added, but the idea is to make a utility API that generalizes the process of defining contexts and templates for their associated testing code for the generator to use. I plan to support TDD and BDD based systems, and isomorphic module designs.
Once a generator is in place a lot of tests can be fully automated, however some will require minimal input from the developer. That will be the final task, to allow the API to facilitate developer-facing interaction in the build environment, but using a data-driven approach so specialized plugin code does not have to be written by plugins author.
This design will hopefully make the resultant API adaptable for other builder environments such as Google's Polymer Designer (which has recently been rewritten from scratch by the Polymer-dev team, albeit currently unusable).
First of all development of Ares has only recently been reinvigorated by LG devoting assets to the project which HP had taken a dump on when they pretty much gave up on WebOS.
EnyoJS is rock-star tech that rock-stars refuse to look at close enough to realize it is what facebook wants react to be - but 10 years ago, and is now the only truly platform independent JS framework.
Much work has been done by the LG designers as far as UI (I have followed their often ignored progress very closely of late) and the architecture of Enyo.
It is commonly misunderstood due to media sensationalism that LG "aquired" WebOS and it's goodies - NO NO NO - what they did is "aquired" the rights to utilize WebOS, along with the rights to own HP's nifty little office building in San Francisco (to house LG's nifty designers and devs) all under the agreement that they would pay an outrageous amount of money for these nifty items, and furthermore, that LG would slave away at WebOS/Enyo so that HP doesn't have to, all the while so that HP can benefit from the fruits since HP still owns WebOS/Enyo and friends. Phewwwwww
Just don't say things like "too bad LG is murdering WebOS and Enyo" because it makes me feel sad and angry and contributes to the propaganda machine of dis-information regarding the details of the deal between LG/HP (the details which have been hashed out in a secret agreement BTW) - this doesn't help things as the media was left with no choice but to sensationalize it even more, and without the benefit of the facts of the deals terms to at least sprinkle some truth around too.