Luddites weren't/aren't oriented around opposition to technology, but around a particular vision for the intersection between technology and people's lives.

Wisconsin.

Are you serious?

In Seattle, especially in the downtown/Belltown area in my experience, this is becoming less of a safe assumption. When I worked in Belltown, it was a rare day that I wasn't nearly hit by an impatient driver; now, working closer into the downtown core, the near-collisions are somewhat less but still far too frequent for comfort.

I do tend to assert my right of way where the vehicle's speed is not likely to do serious harm, because I'm not ready to give up safe pedestrian right of way that I've become accustomed to. But there are also times I have to actively dodge an oncoming vehicle to ensure my safety.

This premise is what lead to the evolution of higher-level programming languages in the first place. It turns out that the intersection of specification and correctness is still programming, at least for every iteration so far.

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.