The kernel doesn't have a DOM. On the Web, the number of GC'd objects that every "process" has to deal with exceeds the number of file descriptors by an order of magnitude.
Also, you do have a choice: you can compile your favorite language to JS, even low-level ones via asm.js.
> Why do you get to dictate whether we can or can't develop on the web? You leave us with a horrible choice, use what we consider to be one of the worst modern languages, or not develop. Why do you get to make our professional lives miserable?
That's not the choice: you can compile your favorite language to JavaScript. That's what source maps, asm.js, and the like are for. And JS is being improved all the time; it's not static.
Trying to add another language has been tried multiple times and has always failed, because having two languages that both interact with the DOM is much more difficult than just improving JS.
Semi-serious question: Other than backwards compatibility, do browsers need to have a DOM? It seems like many web app devs spend more time fighting against the DOM than working with it. Why not just make the browser expose a generic GUI model? Let web devs interact with Webkit or QT directly?
Generic GUI toolkits are very often worse than the DOM. I've worked with Swing, MFC, SWT, Android, and iOS, and all of them are significantly more complicated than the DOM is. They do function at a higher level of abstraction, and the two really nice things they give you are components and a sane layout system (solved by WebComponents and Flexbox, now if only all the major browser vendors would just adopt WebComponents...), but in general I've found that iOS development is about 1.5x-2x slower than web development and native Android development is about 3x slower, roughly on par with Swing or SWT. MFC was a clusterfuck, I wouldn't even go there.
The way frontend devs for other platforms deal with it is to specialize in the nuances of the platform and effectively build your app around the capabilities that Google/Apple/Microsoft/Sun provide. That's fine, and makes for a fairly uniform, polished experience if you have good devs, but it significantly restricts the set of apps you can build. The reason web developers like developing for the web is because it doesn't make you a sharecropper in Google/Apple/Microsoft's world, while building a full-featured GUI framework into the browser would.
I've found JavaFX's scenegraph approach rather neat. Effectively it borrows from HTML, but where the basic node set is designed to be UI elements rather than co-opting a set that was designed for text documents. It seems to take a surprisingly small amount of code to sketch up an interface.
React's not bad on the web side (especially with Scala.js) but fudging around layouts in components with divs and Bootstrap still feels clunky.
I still remember how super easy and fast was to make a GUI in Delphi/C++ Builder - what took a month in MFC/Swing took about an hour in Delphi. Even Qt feels like a massive step back from this...
The kernel doesn't have a DOM. On the Web, the number of GC'd objects that every "process" has to deal with exceeds the number of file descriptors by an order of magnitude.
Also, you do have a choice: you can compile your favorite language to JS, even low-level ones via asm.js.
> Why do you get to dictate whether we can or can't develop on the web? You leave us with a horrible choice, use what we consider to be one of the worst modern languages, or not develop. Why do you get to make our professional lives miserable?
That's not the choice: you can compile your favorite language to JavaScript. That's what source maps, asm.js, and the like are for. And JS is being improved all the time; it's not static.
Trying to add another language has been tried multiple times and has always failed, because having two languages that both interact with the DOM is much more difficult than just improving JS.