I'm sympathetic to some of the conclusions here but jeez, this is a really bad argument. A lot of other commenters point out ways that it's bad, and they're mos

I'm sympathetic to some of the conclusions here but jeez, this is a really bad argument. A lot of other commenters point out ways that it's bad, and they're mostly right. The crux of the issue is that the argument really relies on the notion of comparing two things that supposedly do "the same thing", but you really have to ignore almost everything that could ever factor into the decision between them in order to consider them the same, and what the thing is shifts from moment to moment. The Advent of Code example is fine. Here, we have two different algorithms that perform the same computational task, and there's a performance gap because they're not the same algorithm and have have radically different time complexities. In the Clojure vs. Clojurescript example, the author has picked a library that can run tests on the JVM or as transpiled JS code in a browser. The end result code is doing the same thing in a different sense because it implements pretty much the same algorithm (modulo technical differences in the underlying intermediate platforms). But the first performance comparison is between the Clojure and Clojurescript compile times. Trust me, there's almost no sense in which compiling the Clojure language to the bytecode it was designed to be compiled to and translating it into a different high level language in a performance-sensitive way can be considered the same task. So it's unclear why that's supposed to be meaningful. And the test-timing comparison is also a little funny, since the JS still has to be JIT compiled to machine code, which is much more complex than the equivalent bytecode compilation - there's a sense in which it's more similar to the Clojure compilation step (which takes 6.5 seconds) and it happens in less than a second. But anyway, one can argue that all-in-all it's the same code and it's doing the same thing in the end and the one that does it in the browser is slower. But that's only the case because of that specific choice to compare library tests that can target either the JVM or the browser. That's not a choice that makes sense in general. You don't pick between those two compilers in a vacuum - you're not going to use Clojurescript unless your code needs to run in a browser. And you _can't_ use vanilla Clojure in that case. If running in a browser is a requirement, then the compile speed and runtime performance of vanilla Clojure is meaningless because it doesn't run on the platform your program is being delivered on. The author is comparing a library that can be compiled either way and run on either platform - but the actual real world code that library is used in wouldn't have that property, and the performance comparison is pretty meaningless. I'm going to skip the next bit because it goes further off the rails in ways that are mostly unimportant. I think there are some less charitable ways to read the conclusion, but let's go with this: don't build applications (especially things like text editors) on the web platform, because it's super inefficient. You can make faster applications, therefore, you should. Here's the thing: you won't, and if you do, they won't succeed. We wish our text editors weren't so resource intensive, but the responsiveness of basic text editing operations isn't what most of us look for in an editor. There are slimmer native text editors out there; their development and the development of the surrounding ecosystem moves incredibly slowly because they weren't built on a pre-existing extensible platform that thousands of developers are familiar with and so very few people want to work on them. And that makes them cumbersome for a lot of tasks, which means a lot of people won't use them. The platform that our bloated text editors are built on is part of what they do. So a faster editor that isn't built on a familiar, extensible platform doesn't do the same thing faster - it does a subset of the things I care about, at the expense of the reasons that cause me to put up with my current editor's bloat. You can make a faster X for any X that runs on the web platform, but to do that you're going to have to build it on less general-purpose, extensible technologies, and in many (but not all!) cases, that alone going to doom the project. And if you want to build something that does all the things the web platform does, but more efficiently, good luck. Sure, HTML/CSS/Javascript are built on a lot of design missteps, so it's theoretically possible, but I think the ship has sailed on starting completely over.