>> Or, they could take their own medicine, and try and write the browser in JS. >You mean like Firefox?

This is a very strange comment, especially coming from you.

Everybody knows that the bulk of Firefox is not written in JS. You personally have spent years of your life working on a new programming language precisely because JS is not suitable for writing a web browser.

I'll take your position on JS seriously when you abandon Rust and begin writing the bulk of Firefox in JS.

It would actually be a very interesting experiment to try running Servo Emscriptenified (with SharedArrayBuffer, of course). I wouldn't want to write a browser in the full JS language, but that's precisely what asm.js is for.

"You should abandon Rust and write in JS" presupposes exactly the kind of strawman I've been arguing against. You don't have to abandon your favorite language!

Works on OSes. We have a choice.

In browsers, the OSes of the web, nope, just a bad language designed in 10 days that resists all attempts to make it not bad.

It doesn't really matter if you like javascript, there's so many people who don't.

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?

> Works on OSes. We have a choice.

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.

Also, the kernel's written in C (maybe Rust in part, soon). So much for language choice!

Sure, in userland, many languages compile to assembly. Hmm, where have I heard that word lately?

It doesn't actually work on (GUI) OSes - there is a strong incentive to write your app in the language and framework that is native to the platform, because you're asking for a lot of pain and a substandard customer experience otherwise. You write your Windows apps in C# and .NET. You write your Android apps in Java. You write your iOS apps in Objective-C, and now Swift. You write your Gnome apps in C with Gtk+, and your KDE apps in C++ with Qt, and your Eclipse plugins in Java with SWT, and your Emacs extensions in Emacs Lisp. In all these cases (except Apple), you can write your apps in a different language, but virtually nobody does, because you end up fighting the platform.

Servers and command-line tools are an exception because your interaction with the host platform is limited to a few dozen syscalls that can be easily bound to a number of different languages. Not so with most GUI software.

(Including Apple; the rule to the contrary didn't last very long after its introduction a few years ago.)

> just a bad language designed in 10 days that resists all attempts to make it not bad.

This is unnecessarily inflammatory. I've been writing JavaScript since back when it was called LiveScript and while it's certainly not my vision of the perfect programming language, it's come a long way. The code I write now is considerably cleaner, easier and more reliable than the code I was writing in 2005, much less 1995.

> Works on OSes. We have a choice.

No, it doesn't work on OSes. OSes only handle one language: the native machine code of that platform. Everything else must be compiled to it.

This is exactly the same as browsers.

Edit: At least two people disagree with me (-1 points) - would you mind elaborating why?

Your point is irrelevant, then difference then becomes the fact that at an OS level I can choose what code I compile into machine code and in the browser I can't.

No, for OS you decide which compilator to choose. As is with browsers. There are several languages (e.g. TypeScript, CoffeeScript, Dart) which can be compiled to JS.

That is not what I personally like (the processes of compilation and deployment I mean), but if you develop for OS then you have to compile before you run... In most OS.

> Your point is irrelevant, then difference then becomes the fact that at an OS level I can choose what code I compile into machine code and in the browser I can't.

Uh, what? You do have a choice in the browser. I don't understand.

The web consists of untrusted code. Thus it needs to run in an a sandbox. Creating a secure and fast sandbox is an incredible undertaking.

I think the web is getting better in this regard. Since the introduction of emscripten and asm.js there have been some improvements to the tooling and runtime to make it so you can just write your app in C or C++ without really thinking about JavaScript.

It's only a matter of time before other languages can have the same level of support.

I think you are onto something ;-).