React isn't a standard, it's a GUI framework. They're proposing compatibility layers for other GUI frameworks on other platforms, with no intention of replacing those other frameworks. Of course it's possible, because other such compatibility frameworks are available and quite successful. What React offers that the others do not is that the development environment is familiar to web developers.

If you use a strict subset with a defined API, it can be close to native performance. This has been seen with asm.js already. It may be that specific domain logic suffers, because that will likely break the boundaries of "strict subset" for a framework like React, but that is going to be a smell in GUI code no matter what your environment.

Yeah, insofar as interpreted code may present a way to escape sandboxing, which in turn could lead to security problems, which in turn could lead to plummeting profits.

All code symbolizes the despair and longing of the programmer.

JS is not a functional programming language. It has a lot of functional attributes, but it is very heavily skewed toward imperative approaches to problems, and it's a stateful mess.

The syntax is far from JS's only problem.

Nothing you said makes my point nonsense. The only thing that is going to go head-to-head with JS is a properly functional language. The fact that JS adopts more functional concepts and encourages more functional approaches only underscores that.

This is fascinating, and I think it gets to a lot of the gripes I see in comments here. Basically, the longed-for slashdot of old was designed for rapid consumption of low-density news data at a fast pace. The slashdot we all experience now provides that, but the complaint is that the superficial browsing you describe yields less of a fix for data-hungry readers than it used to.

Frankly, I think the level of discussion has gone up as the level of satisfaction has gone down. I come here for the comments.

Thanks for at least giving me some interesting meta-discussion!

Frankly, the only thing that's going to upend the JS dominance of client-side web programming is a functional language. There isn't a compelling reason to trade OOP horses on the web. There's a good reason to choose a better paradigm for the problem. A functional paradigm with a good immutability story is going to have a much better time convincing people to rethink how they program web apps with a focus on user interaction over time.

There isn't much point in vying for who can do the best at mixing data and behavior. Separating those will be a good way to compel people to consider alternatives.

Genuine question: don't you?

CoffeeScript has too much in common with JavaScript, with too many of its own esoteric compromises, to be a good compile-to-JS contender. It also has the disadvantage of being fucking awful.

If we're picking languages that compile to JS, we have a lot of options. Why would we pick something that is such a derivative work? If I'm going to be that close to the metal, I'd rather just write on the metal.

Since JavaScript is increasingly also a compilation target, the fact that it continues to dominate is a good indicator that the competition among compile-to-JS languages is strong.

One of those biggest companies on earth promotes both Go and Java as compile-to-JS languages with less success than I would expect.

Granted I'd prefer to see ClojureScript grow, but I am not placing any bets there.

I hope that depends whether you're counting sittings versus time spent.

I think it's "grammar nazi". They're not actually National Socialists about grammar, it's just a figure of speech.

Okay then... there was literally nothing involving violence or threats in the story.

War on Christmas