The resources available to an individual for creating and reasoning are finite, and as long as one is able to give good reasons why they know that there is a better way, "there is a problem" may still be valuable information.

Right now, the world only has 3.5 base browser engines. Those browser developers have no interest in adding a new standard language like Python, even though more people prefer that to Javascript.

So, if you were to develop a new browser language, you need to build a new browser from scratch, and then move a billion people to it.

If you're going to imagine that as a utopian alternative to JS, be sure to be thorough about it and imagine 1995 Python dominating the browser landscape for years and then the advancement path the language has taken on the server playing out among several browsers. Then come back and tell everybody how much prettier it looks than JS (for bonus points, how much prettier than ES6).

While we're at it, as a general rant... I think it's weird that Python keeps coming up in these conversations.

It's a nice language, it really is. But it's in the same paradigm set and productivity class with JavaScript, Ruby, and Perl (and to a lesser extent, even PHP). The differences between these languages aren't that big and they're largely aesthetic.

If you prefer it, that's fine. If you find its particular set of choices aggregate some nice marginal gains to some additional productivity over the other languages I've listed in this class, I might even think that's a credible argument.

But if you can't get past the sting from JS's warts and learn to be largely as effective in it as you are in Python -- or if you think the real solution moving forward is to turn the entire fleet of supertankers involved in the web for retooling to use a language that's not that different -- I think that you're not thinking about your tools particularly keenly or carefully.

They are pretty big. At work I work on a Django-backed project that has a very fat JavaScript front-end client, and JavaScript is incredibly painful to work with compared to Python.

It's not merely aesthetics, but JavaScript in the browser is severely lacking in language features that allow it to scale to larger code-bases.

Also JavaScript has a pretty good variety of languages that compile to it. If you like C#/Scala/Swift use TypeScript. If you like Java use Dart. If you like Lisp ClojureScript.

Dart comes with a batteries included standard library inspired by Smalltalk (https://www.dartlang.org/docs/dart-up-and-running/ch03.html).

Dart should also feel familiar to people coming from C#. async/await support in Dart was designed by Erik Meijer (who worked on the feature for C#) and iirc he believes it is the Dart implementation is the cleanest implementation yet.

I don't see much similarity between Dart and Java.

Since that I have had to do a fair bit of python, php and JavaScript at work. I think if I hadn't seen Dart first I would have quite liked python.

The problem with Dart is that once you've been developing in it for a while it spoils you from liking anything else. I really cringe with python, JS etc autocompleting to a million irrelevant things.

And going back to Java you have the slow dev loop that comes with a compiled language.

At the end of the day I've simply never had a development experience anywhere near as productive and enjoyable as Dart.

However, it turns out having an AST of your Javascript code is really useful, and lets you do things like this: https://github.com/speedskater/babel-plugin-rewire

Give it a try. I like that it comes with a useful and well designed standard library (like Python).

It was a dream to use compared to JS. One show-stopper though: browser support. At the time, IE11 was just released and Dart had issues with IE11. Also, the Dart supported browser window is only the latest 2 versions of a given browser.

This totally killed our Dart prospects, as our target users in our business are generally non-tech savvy and we need to support older browsers like IE8/IE9.

Oh, you got Python 6, well we have Python 8 which breaks your code in subtle ways.

Just let me know when browser vendors are going to break down the two-tiered system, and let us run the legion of alternatives alongside -- instead of under -- JavaScript.

Or, they could take their own medicine, and try and write the browser in JS.

The complexity of doing that would be needlessly high compared to just improving JavaScript. Having to integrate a C++ DOM with a JS DOM is hard enough. Think about how you handle cross-language cycles…

> 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.

"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!

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.

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.

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.

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?

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.

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.

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?

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.

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

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

However, cries of foul "vendor lockin" erupted. So I dunno what to tell you, man.

> asm.js doesn't support threading.

asm.js supports threading, actually, through Web Workers and SharedArrayBuffer.

> it can't run native code.

This is true, but asm.js is relatively close to the metal. It's not very far from assembly language.

> it doesn't support meaningful debugging.

This is a tooling issue. While the situation is bad at the moment, it'll surely improve.

> it doesn't have a post-DOM API surface like pepper.

Why do you need a "post-DOM API surface"? If you just want to blit stuff to the screen, the DOM is actually no less efficient than Pepper: you can directly pass it pixel buffers, or call OpenGL routines.

With the threading issue, Web Workers are boxed up so tightly that there are a lot of operations, like passing objects between threads, or letting web workers have access to portions of the DOM, are impossible. Additionally, because everything's passed by value, there's a lot of copying that needs to take place; to expand on my prior example, sending a message to another thread would involve copying the object to send to the main thread, then copying it again to send to the destination thread. The alternative, transferrable objects, completely deletes the object being passed, and still can't be transferred between threads. Finally, there is no pooling control among threads, which means that there is a lot less control over what threads are running at any moment.

These problems all come back to the fundamental issue. There's no escape from javascript. Asm.js is fundamentally hung off of javascript with bailing wire and duct tape, out of fear of "breaking compatibility". Anyone that tries to experiment with a new language is immediately accused of trying to fracture the web. Thus, we stagnate, and everyone suffers for it.

It has all of these things. It has SIMD now, 64-bit support is improving, IEEE-754 is supported (though some of the checks aren't available yet, I'll give you that). Give it time.

> With the threading issue, Web Workers are boxed up so tightly that there are a lot of operations, like passing objects between threads, or letting web workers have access to portions of the DOM, are impossible. Additionally, because everything's passed by value, there's a lot of copying that needs to take place; to expand on my prior example, sending a message to another thread would involve copying the object to send to the main thread, then copying it again to send to the destination thread. The alternative, transferrable objects, completely deletes the object being passed, and still can't be transferred between threads. Finally, there is no pooling control among threads, which means that there is a lot less control over what threads are running at any moment.

Yes, but this stuff isn't applicable to asm.js. It shares a heap between threads, it's just like your old native code, and everything is triggering race conditions^B^B^B^B^B^B^B^B^B^B^B^B^B^B^B^B^B^B^B^B^B^B^B^B^B^B^B hunky dory.

> These problems all come back to the fundamental issue. There's no escape from javascript.

What's wrong with that? If you don't like JS, you can compile to it. It's an excellent compile target.

> Asm.js is fundamentally hung off of javascript with bailing wire and duct tape, out of fear of "breaking compatibility".

It's not just a compatibility hack, though managing to work on everything with no updates is a killer and awesome feature. It also avoids unnecessarily reinventing the wheel. It reuses as much of JS as possible. That's good.

> Anyone that tries to experiment with a new language is immediately accused of trying to fracture the web.

...well, yes, they're fracturing it. And usually needlessly. There'd be no benefit to a new language on the web. There's nothing a new language can offer which JS doesn't have.

> Thus, we stagnate, and everyone suffers for it.

What stagnation? Everything is moving rapidly. Things are improving all the time.

I'd say that the weaknesses of web workers is absolutely relevant. Though you see it as protecting the coder from themselves, there are design patterns out there, like publish/subscribe, that are useful in letting threads communicate, but not generating race conditions. DOM access and the like can be done sanely, but Javascript doesn't even give you that option.

Given the reasons described, it's a rather poor compile target. It's a plodding beast of a language that mishandles numbers, requires circuitous coding to handle basic concurrency, and otherwise behaves in ways other languages don't. Transpiling just barely hides its flaws.

I will restate that it is a hack, and a rather ugly one. Its attempts to maintain compatibility leave us with a virtual machine that is increasingly obsolescent. An "assembly language" designed in 2013 shouldn't be lacking support for 64 bit integers (or 8-bit or 16), should have good support for vectorization, and should provide some sort of register and/or stack model so that you can better clue in the vm as to what items are going to be frequently used in functions. The missing features could be handled much like JSON was early in its life, by including a library as a fallback. It would probably end up looking ugly as hell, but at the same time, it would work, and give a lot more long-term benefits.

Regarding alternative languages, Javascript isn't always the best language to describe a problem in. Sometimes your program's better written in C, or Lisp, or Fortran even. Why should you force your problem to fit the language?

Regarding stagnation, you can move quickly, yet not really go anywhere useful. COBOL had 7 major versions and several minor in 14 years. Does it mean that it's a useful language today? The stagnation comes in terms of how people think of problems, and how they try to wedge those problems to fit into Javascript. The web would be a much better place if we allowed more experimentation into languages and behavior.

Some were excited Dart might lead to some sort of bytecode VM being added, but that didn't lead anywhere. And since then, JS has become more bytecode-like, so it doesn't really matter now anyway.

In that sense adoption of Dart, ClojureScript, TypeScript, Elm et all will continue to accelerate JavaScript (language and runtime) improvements.

http://brendaneich.github.io/Strange-Loop-2012/#/21

Love it when a plan comes together!

None of these problems would be difficult to address if the four-member vendor cartel which controls web "standards" was willing to adopt NaCl. Of course they don't want to adopt it, but that is the real problem right there. Of the four, two members (at least—maybe now three) have an active interest in holding back the Web to protect their native app platforms, while one would rather reign in Hell (through its position of shared mastery over the Web hairball) than go broke in Heaven. As to support for other languages, I only have to point out that one of Mozilla's reasons for decrying Google's intended browser support for Dart was that Dart compiled to JS would not be competitive with the native Dart implementation.

Also: loser talk is loserly. PNaCl (did you mean PNaCl not NaCl? NaCl was never proposed by Google for the Web) like Dart fell to physics. All else is stamp collecting.

My point then was that if Google had had MS's IE4-6-era market share and lack of scruples, they could have pushed Dart into Chrome and started using it in their web properties, and the lack of equivalent performance between DartVM and dart2js -- especially due to lack of bignums and other affordances in JS, which lack Google materially increased by choosing to invest in Dart over JS -- would have stunk. It would have verged on the monopoly abuse of which MS was in fact convicted.

My point was not that JS must be the only way to run Dart simply because I or anyone at Mozilla (or anywhere else, MS and Apple included) prefers JS. That would be dumb, and it's clearly not what I wrote.

Browser vendors have to keep JS improving. That's a given. Adding the extra costs of DartVM and the inter-heap GC and write barriers to glue it into the shared DOM client side is a huge tax, which would have helped kill Mozilla faster. MS and Apple wouldn't pay that tax. Why should anyone? Again it's not about JS being uncompetitive. "Competitive" is what browsers are when they run web content better and faster. Dart has very little to do with this.

JS is very, very hard to replace, for reasons I summed up as "physics" (apologies to Rutherford) and won't belabor here. Yet the Dash memo proposed to do just that, to replace JS, using lame assertions about how JS couldn't be fixed.

That was not just lame posturing and excuse-making for a Lars Bak retention program. Given Google's power, it was a disservice to the Web as a standards-based and ever-evolving platform, whose caretakers are obligated to keep working on it in the open, not try proprietary end-runs. (Yes, of course, many people at Google work hard to improve the Web. Good for them, but not relevant to what happened with Dash.)

I'm happy to say I was wrong to worry about Google succeeding in acting like MS did with ActiveX/VBScript. Not that some at Google didn't try (or won't again with other stuff), but they failed with Dart. I predicted that, too, as an ultimate outcome after wasting years and megabucks -- including real opportunity costs to V8 and JS. So too did many at Google predict this crater.

Dart's a compile-to-JS language now, not due to any preference for JS by anyone at any browser vendor.

Get it yet?

I've never suggested that this is what you were saying there. Here I pointed to it as evidence that I was right that "one of Mozilla's reasons for decrying Google's intended browser support for Dart was that Dart compiled to JS would not be competitive with the native Dart implementation", where by "competitive" I was obviously referring to performance. Since we're agreed on that, the claim that everything I wrote above was wrong 'including "the" and "and"' goes out the window. (What I did point out to you at the time is that this was hard to square with the claims being made elsewhere for JS' wonderfulness as a compile target.) Your take on Google's intentions in proposing Dart is also completely in line with my argument that the vendors of major browser engines have huge power basically not constrained by anyone besides the other three vendors, as well as motives that don't always align with the public interest.

You wrote:

"As to support for other languages, I only have to point out that one of Mozilla's reasons for decrying Google's intended browser support for Dart was that Dart compiled to JS would not be competitive with the native Dart implementation."

The empty rhetorical flourish ("I only have to point out...") aside, this is rank question-begging. You assume that JS as Dart target being too slow must mean DartVM should win because of "competitive" force. Wrong on at least two counts (I'll ignore market power abuse):

First, DartVM may be faster at semantics JS supports due to optimization problems on the JS engine side. V8 in particular lost its founding team to DartVM, except for some moonlighting. Therefore "competitive" does not mean that JS cannot improve to be as fast when compiled from Dart as when the Dart source runs in DartVM.

Second, DartVM may have types and optimizations that JS lacks, bignums for example. Again "competitive" does not mean JS cannot change, and in fact bignums have been on the ECMAScript Harmony agenda since 2010, before "Dash" leaked.

In any competitive market with deep tech, there are lots of ways to meet a set of developer-facing language support/performance requirements. Even with all Google's billions, Dart and Chrome decision-makers couldn't ignore the compile-to-JS alternative and continue to justify developing and shipping DartVM + OilPan + all else not fully in hand to support JS and Dart with no performance regressions. Compiling to JS is the sole path forward for Dart on the Web precisely due to competition.

Citing my argument about bignums is perversely wrong, unless you assume DartVM is the only solution to any DartVM vs. dart2js performance disparity.

Such an assumption, like the one you seem to have made about NaCl, is anti-competitive, uneconomic, magical thinking. It requires indefinite amounts of time and money to fund all the work to have two VMs, a super-GC to collect cycles, write barriers as part of that super-GC, and more optimization to overcome the performance regressions imposed by those barriers (if possible). It assumes JS can't more cheaply be extended to be a fast-enough target language. You offer no proof.

BTW, you started out with NaCl and I still think you're mistaken about something pretty fundamental. NaCl was never proposed as a Web standard. Ok, suppose you mean PNaCl. The problem remains that PNaCl required a big API, Pepper, to reach the guts of chromium/Blink (originally WebKit) and the underlying OS. The problem with PNaCl was always Pepper, and again: competition killed Pepper as a cross-browser API.

It takes longer (it would have happened sooner with more cooperation from Google earlier, instead of the malinvestment on these two big follies), but JS is getting SIMD and shared memory threads, which are among the last few bricks still standing in the Pepper wall.

So PNaCl is evolving with Emscripten/asm.js now -- precisely due to competition -- and I would not hold my breath for PNaCl to remain based only on LLVM bitcode (with fixes requiring years and millions, to remove unspecified behavior). But feel free to hold your breath and then blame the "vendor cartel" if you like.

On that "vendor cartel" point, there are more web engines coming along, Servo (an open source project with multiple paying companies involved) among them. There's no cartel, just a big compatibility hill for any new engine to climb.

Adding gewgaws like NaCl and Dash slows down that climb. It's uncompetitive for the would-be market entrant. Why you think this requires collusion ("cartel") or Satanic pride ("reign in Hell") is unclear. Do you get many billion-dollar free lunches where you live?

Just let me know when Intel, AMD and VIA are going to break down the two-tiered system, and let us run the legion of alternatives alongside -- instead of under -- x86 assembly language.

> What does that even mean? It's nonsensical.

What it means is that the situation with browsers is not much different from the situation on native platforms. CPUs support one language, the browser supports one language. And yet I don't see anyone complain about CPUs only supporting one language, because you can compile anything to it. The same is true for JS, so why do people complain?

>Underneath x86 assembly language is the processor microcode, and underneath that is the actual hardware, and the two are intricately intertwined.

Underneath JavaScript is native code produced by a JIT compiler. It's not super-intricately intertwined with the underlying OS and hardware, but it's not incredibly abstract either.

>You can replace the hardware; C compiles, for example, to everything from ARM to x86 to Atmel's AVR harvard architecture.

>You can replace the language; everything from C to Swift to Rust can target almost any processor architecture, without externally enforced limitations.

You can also retarget stuff compiling to JS to compile to something else, like Lua.

>Microsoft can ship the CLR for ARM, x86, PowerPC.

> You can't replace JavaScript. Everything must pass through a JS JIT, and the JS JIT is written using functionality that 1) it requires, and 2) is totally unavailable to you.

Yes, everything must pass through a JS JIT... you don't have access to the underlying native code. But everything on a CPU must pass through its microcode translator. That uses functionality it requires which is unavailable to you.

> Microsoft can't ship a fully functioning CLR for JS.

This simply isn't true. You can write a CLR for JS that compiles to something like asm.js at runtime. Bytecode VMs with JIT compilation have been written in JS before, see Emterpreter for instance.

Because we don't write assembly ourselves. Unless we are doing micro optimizations, we don't even have to look at it. We do however, have to look at your shitty JS.

JS is not the "assembly of the web". It's a high level language. Your comparison is idiotic.

Well, you don't write assembly because it's not pleasant to write in. JavaScript is actually quite high-level by comparison, so you can write in it, and many people do.

> Unless we are doing micro optimizations, we don't even have to look at it. We do however, have to look at your shitty JS.

You don't need to look at generated JS either. If the tooling sucks then you do, but that is only because we live in early days, and the tooling isn't quite there yet.

> JS is not the "assembly of the web". It's a high level language. Your comparison is idiotic.

It is a high-level language! But it is also a good compiler target, and contains a low-level language (asm.js) which is also a good compiler target.

It's not a poor comparison.

Like Blink-in-JavaScript[0] ? ;)

[0] https://www.chromium.org/blink/blink-in-js

That's a legitimate complaint.

There's so much inertia that without the backing of the major browser manufacturers, any effort to introduce a change is doomed to obscurity.

People are allowed to complain, even while not being able or willing to work on a solution. We used to do that with DOS all the time.

I like Javascript, in many ways it's a neat little language, but manipulating the small little ad-hoc data structures (arrays and hashes, and combinations of them) that seems to be half of most programming tasks is definitely a step backwards compared to Python.

I'm a Python fan but I can't disagree more on that point. Python has terrible lambdas, and poor idioms when working with collections (list iteration over chainable/fluid interfaces).

Underscore.js, which at this point stands for 'idiomatic JS for collections', and the ES5 methods on arrays (filter/map) which are largely supported now provide a better way to handle arrays & hashes than idiomatic Python. With ES6 fat-arrow functions it's even better.

It's one of Python's biggest weaknesses when compared to other dynamic languages IMO -- that the idiomatic way to deal with 'collections' is not a chainable/fluid pattern, but instead to do multiple list comprehensions, or use the ugly filter-plus-lambda patterns which compose badly.

Double evens in a list:

ES6:

   [1, 2, 3]
       .filter(x => x % 2 == 0)
       .map(x => x * 2)

   [1, 2, 3]
       .filter(function(x) { return x % 2 == 0 })
       .map(function(x) { return x * 2 })

    map(lambda x: x * 2,
        filter(lambda x: x % 2 == 0, [1, 2, 3]))

    # or
    evens = [x for x in [1, 2, 3] if x % 2 == 0]
    [x*2 for x in evens]

EDIT: Removed the word 'objective' because I'm talking syntax.

    map(lambda x: x * 2,
        filter(lambda x: x % 2 == 0, [1, 2, 3]))

    [x*2 for x in [1, 2, 3] if x % 2 == 0]

I was not trying to illustrate that the backslash made it ugly (I've removed it - I was pasting from a repl). It's ugly because of Python's lambda syntax and the fact it does not compose 'sensibly', as compared to fluid interfaces. The logic is back-to-front for one.

> But the list comprehension version is just completely wrong:

No, it's not at all wrong. Your one-liner is not better and (I hope) would probably upset most teams for being less clear.

I was providing a like-for-like example. The multi-lining is not the criticism of the Python version. It's the composition that's at fault, the fact it does not feel like 'two coherent operations over a list' with two distinct conditionals.

The ES5/ES6 examples demonstrate this much more clearly IMO.

Presumably, these also are not completely clear to you:

    > [x * 2 | x <- [1, 2, 3, 4], even x]
    [4,8]
    > [x * 2 | x <- filter even [1, 2, 3, 4]]
    [4,8]

To say that a pretty uncluttered list comprehension is some challenge to read is just hyperbolic. These pipelines, even with newlines, can get pretty long and terrible too.

This sentence reveals a deep misunderstand of either what "objectively" means.

(FWIW, I prefer the ES5/ES6 syntax to Python here, as well; I just don't mistake that preference for something other than subjective.)

It's easy to pedantically point out I used 'opinion' in the same sentence as 'objective' but I'd hope you could apply 'the context of programming' to gather what I actually meant.

When we say 'objective' over matters of syntax I tend to think of 'If you put N programmers in a room they'd all agree this was better syntax'. That's how I feel about the above examples I posted.

That said I've edited my comment so I don't inflame other commenters to point out my glaring contradiction :)

'The depths to which JavaScript sucks are well-documented and well-understood.'

Same applies to Haskell. As with any language, humility please.

-Bob Burns

If one believes that "JS is the worst thing to happen to the web" and that "some other language would miraculously solve all of the problems" then going off into the wilderness to "create" is almost certainly a dead-end endeavour. A language is only one component of what's needed to replace JS - there's also winning over 4 major browser vendors who've dumped no trivial quantities of money, time, and PhDs into polishing this particular turd.[0] Then there's the standardisation peeps and so on. It's not so much a technical challenge - many existing languages could add support for DOM APIs and become an in-browser candidate relatively trivially - but a political one. And when was the last time you heard of someone solving a political problem by saying "hey guys, I've got a great idea here"?

Some not-absurd propositions:

    1. "The finance system is shit"
    2. "Modern government is shit"
    3. "JS is shit"

The only viable strategy for the average "hater" (whose "hate", incidentally, is emphatically not invalidated by his lack of perfect solution) is to try to affect top-down change. Now, no one person is likely to achieve this - even exceptional people have a fearsome challenge when faced with groupthink (Galileo, anyone?)

So what is in the "haters" toolbox? Well, seeing as web standards authorities are run like district councils in the 1980's (go try to find out how to make your view officially known on an ECMAScript draft), us in the peasantry have little but our ability to create and maintain a murmur - and occasional scream - of discontent which hopefully, one day, might have some psychological effect on those who do hold the power, because lord knows it's not us users. You may recognise this particular strategy from historical great hits such as "representative" "democracy" and friends where it has been, on the whole, a slow, inefficient, wasteful, but occasionally effective way of going about things.

So my well thought-out and actionable strategy is to ignore this advice and continue to grumble - and, if you can manage it, try to be just a little bit louder than last time: shit adds up at scale.

    [0]: Mr Eich told me himself that they're too invested in JS, see https://news.ycombinator.com/item?id=9264531

"...but things never change." I think you're wrong. Things do change. They just don't change at a pace that is fast enough and obvious enough for someone who feels passionate about an issue (Gay rights, Women's rights, Black's rights, all civil rights crusades, anyone?) And it often takes a long time for people to realize they need to be actively engaged instead of complaining from the sidelines before any change occurs.

By all means, continue to grumble on comment boards, just don't act surprised or upset when the direction of the thing you were grumbling about doesn't go the way you want it to.

I don't want a web where all my software and data is owned by other people who don't have my best interests in mind. JavaScript allows "free" websites to replace programs running on my machine which is fundamentally opposed to my goals. I don't want all the power that computers have brought to humanity to be concentrated in the hands of corporations, I want it to be free for anyone to use. I'm glad JavaScript is shitty and I wish it were shittier, because that would slow the growth of corporate control over our capabilities and data.

Conversely, I can write open-source javascript that does something useful for you, that does not mine your data or do anything of that sort.

I don't see how this relates to javascript.