The State of JavaScript - Brendan Eich

Any toolkit that attempts to shoehorn a consistent experience on the web is doomed to failure. People have made efforts, earnest efforts, at solving the problem (dojo, ext, closure, capuccino). None have caught on and at the moment I'm assuming none will.

Bakground paragraph: I've been thinking about the issue since 2004 or so and always assumed that a widget toolkit would develop like it did for desktop environemnts and one or two would eventually win. The launch of mobile app development changed things. The kinds of apps being delivered were outright better than what equivalent web apps were delivering. Not the perf, I assume perf is going to be solved by better hardware and engine improvements, but what the apps accomplish. My conclusion is that every project has a semi-fixed budget of resources and that web developers burn roughly 50% of that budget on building a custom one-off interface solution for every project they work on. The obvious answer is components but component frameworks had not been catching on so the question is why.

The normally cited problem is the composition problem. It's incredibly difficult to achieve component isolation in the DOM and the Web Components effort is attempting to address. I approve the effort but I do not believe it will solve the problem. It's possible(ref yui3) to write components that will cleanly drop into pages that keep their CSS tweaks class based and that restriction isn't unreasonable in an app. Component use happens more frequently in apps but is not the default like it needs to be to escape the one-off tar pit. The issue is social.

The web's roots in documents mean that pretty much everybody wants a custom UI. All existing component libraries, following desktop toolit precedents, come as a packaged markup/CSS/behavior combo. These two requirements are opposed and that opposition is the core problem. I have never used a component library and not had to customize a signfiicant number of components. When doing so, I either have to maintain a private fork of the component or suffer in download/perf as the framework is super heavy and caters to all possibilities. The yui3 (and looks like current dojo) approach of core+plugin composition with auto dependency resolution is the best solution I know of but overriding is still non-trivial. Tweaking the CSS usually means having to build a complete theme and using generated markup is hit and miss.

My current thinking is that Web Components are a start but there needs to be a good solution for selectively overriding a part of the markup and for overriding style. CSS preprocessor features are also required to achieve styling goals efficiently. The rise of Bootstrap might prove me wrong by starting as an incomplete system, getting buy in (multiple themes, adoption for simple uses), and growing to a more complete one but we'll see.

The "no view source" argument is pretty weak. Most major websites nowadays serve you unreadable compressed JS soup already. Personally, I'd love to have a cross-browser bytecode alternative to Javascript, preferably running in a VM accessible outside of a web browser.

I agree ... and I'll extend it by asking why you'd "dis" the other languages he attacks. Once again the old adage is proved: "When all you have is a hammer, everything looks like a nail". Let's get over the JS insecurity, admit it's useful for some tasks and that it sucks for others and get on with some useful discussion about when each of those statements is true.

You're right. Browsers are constraining innovation to a top-down approach, where browser vendors try to design and implement alternatives to things like TCP, POSIX.

What would be better is if browser vendors exposed a core low-level API to trusted installed web apps (as opposed to web pages) and then let open source build on that.

For example, instead of coding up IndexedDB and leaving no alternative, just provide proper POSIX, and let the database community do its thing.

I've been doing audio processing in Flash for a while (most recently, sample-based synthesis implementing a decent portion of SFZ and SF2, with 64-voice polyphony and filters) and I did have to push an unusual degree of effort into optimizing the sample copying code, with a Haxe macro that generates an optimal inlined loop for each combination of parameters. It can still use up most of a core when maxed out...

...however, I did some math and some extrapolation and determined that within the next three to five years this domain will be completely reasonable to approach from JS, driven by a combination of technologies:

-access to GPGPU from the browser. DSP work can generally be defined in terms of a shader, although it's still a very poorly understood area.

-more general-purpose cores, faster JIT performance, and possibly single-threaded hardware improvements as well. These things compound easily, so we could end up with a 50-100x larger JS performance envelope for this domain without even considering the GPU.

-maturation of the existing and planned audio APIs for common tasks. As you point out, this isn't interesting from a "ground-breaking tech" perspective, but in covering typical application needs, it's as important as the others since it's both convenient and optimized out of the box.

-maturation of cross-compilation technologies, smoothing over the "code has already been written" issue.

In a lot of ways, all JS has to do to be competitive is the "catch-up" work. It takes quite a while in tech time, but in human time, most of us will be around in the next decade.