As someone on a team working very hard on cutting-edge techniques to improve web development, I disagree entirely. While I complain more than anyone I know about the underlying infrastructure, it's a salvageable situation.<p>In fact, because of the lack of standardization on a single toolset or approach (e.g. Cocoa, WPF, etc.), we're in a position to improve well beyond the current SoTA. Some examples:<p>React.js from IG/FB: One of the first opportunities in the browser to treat rendering as a stateless canvas, freeing us from the complexity of time-management.<p>ClojureScript[1] - and more importantly, the immutable data structures from ClojureScript, let us simplify our UI programs conceptually. And combining it with React (Om), we can make UI's both <i>fast</i> and <i>simple</i><p>Datascript & friends: Bringing entire in-memory databases client-side.<p>All of these, and the wide-open nature of the web as it exists today, means we're in a position to experiment with radically new ideas and find a much more efficient way of representing our goals. It's a really exciting time to be working on this stuff.<p>Nevertheless, I upvoted because I do believe we're in a plato's-cave situation with current practices in web-development. There's very little overlap between the desktop and web world, so many of the lessons haven't carried over - how to manage complexity, the important of tooling, etc. But we're making our way, bit by bit (or more recently, leap upon leap)<p>[1] I'm admittedly biased as I've put considerable amounts of effort into the project, and it's not without its warts. GC pressure can sometimes be very tough, and the tooling needs a lot of work.
> Tools That Convert to JavaScript are a HACK [..] they’re usually full of edge cases, varying browser support, inconsistent performance and other strangeness.<p>The second part is true of <i>any</i> platform that has multiple independent implementations, it isn't because compiling to JS is a hack (which it is; but that's irrelevant here). If everyone used the same browser with the same rendering engine and the same JS engine, we wouldn't have browser support issues, inconsistent performance, etc.<p>It's not just compiled-to-JS languages that have browser incompatibilites etc., it's also HTML and CSS, and non-compiled JS. The issue is the fundamental tradeoff of the web being a spec that anyone can implement, which keeps the web open. But it also means multiple implementations with different performance characteristics and so forth.<p>The web was never designed to be an ultra-consistent platform that is super-easy to develop for, which is what the article pines for. If you do want such a thing, the closest is probably Flash - good developer tools, single implementation. It was good for some things, but being a single implementation was one reason why it is losing popularity.<p>With all that said, the web is actually gaining powerful low-level capabilities these days. So you could build something more consistent on top of those. Specifically, you could render UIs using pure WebGL and avoid much of the overhead of the DOM and JS. And compile-to-JS languages can give you more predictable performance than JS itself, because they can emit simpler code (e.g., no garbage collection necessary). There is a big opportunity to create a tool using those two which would give a much better developer experience than the web currently has.
I've been doing this for 15 years and it sucks more and more. Now we have complex as hell client-side frameworks like Angular. A framework on top of my framework, great! More and more screen sizes/devices/browsers, but not a freaking way of handling any of this information because, for some stupid reason, the User-Agent header is useless. CSS media queries are useless. JavaScript window.size is useless.<p>The problem is: HTML is not made for applications, it's made for documents, linked documents. The day someone put a form in HTML hell broke loose and even after 20 years, the web is seriously broken and things are just getting worst. For example, date input fields; supported by Chrome and Safari, but not by Firefox. You want to localize it? IT SUCKS! I thought Java's Calendar was crap, but JavaScript's Date is pure mayhem... And I could go on and on about why HTML/CSS/JS is all a bunch of crap which, instead of evolving, are making things harder.<p>And now they want to add Future/Promise to JavaScript... HAHAHAHA!!!