And over here in the native world we've had drag and drop ui builders for 20+ years. I can't believe how slowly the wheel is being re-invented (over and over and over again) in the web world... when will the DOM and JS die and real innovation starts happening again.
Your lament is certainly warranted. It has taken two decades for the desktop to arrive in the browser. However, the journey has been a long one because our browsers has taken a long time to mature, and there are different players with different agendas.
Not to mention that client-server architecture handles majority of people's needs and it has been that way since PHP and RoR until jQuery, ajax suddenly became not enough. We've seen early prototypes of SPA and Flash web applications during this time but the costs were very high. It is lower now since MV* arrived in the browser and we have the tech to replicate a desktop app in the browser but with limitations which is being eroded thanks to thin clients like nw.js, electron, etc (even NPAPI was too thick).
Much as creating a desktop was impossible for early versions of Windows for the average joe, the introduction of a UI/Software builder from MS lowered that barrier of entry significantly but as you know, things moved away from isolated desktop apps to the web and we had to figure it out all over again.
I think the front-end development will eventually be commoditized to the point where somebody could use a tool to generate clean, tested, plumbing code. Back-end is also seeing some of this, particularly with automatic REST api generation tools and write-once-for-both-front-and-backend would be a good catalyst.
Speculation at best but we are in for some interesting times ahead.
The formula is: new operating-system/vm/browser > new programming language > new libraries > new ui builder :). Choose any one and re-create everything that comes after. Rinse and repeat en-millennium.
At some point in the next 10 years, a browser vendor will put out a new language that will have revolutionary new features like a 'built in type system' and 'compile time errors', and users will be amazed at how their browser now only uses .1% of their CPU to load a page and wonder why this language wasn't created sooner. And then as developers we will get to live through another golden age of UI Builders as we stoke the bonfire with the tens of thousands of man hours wasted creating JSX, 'components' and javascript/DOM hacks in general.
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.
