It is fast or it is wrong

This is the point about Clojurescript too: yes it compiles slower and runs slower, but it allows access to what is essentially the world's largest and most complete UI framework, known as the browser. That makes apps cheaper and faster to produce, at the cost of sluggish/bloated performance. The market has indicated that this is an acceptable tradeoff. Until some other solution can match it on these axes, Electron/Javascript/React SPAs will dominate.

I work with a Qt-like C++ GUI framework (JUCE), but we've seen increasing portions of our front-end work replaced with Electron/React Native. It saddens me to see binary sizes and memory consumption balloon, because native development encourages you to care about these things. But even I cannot deny the order-of-magnitude improvements in productivity from hot-reloading, a deep (if byzantine) system for styling and layout (including text), and reuse of modular components across all platforms.

Otherwise we would all be programming assembly, or heck, just write machine code directly and skip the time-consuming assembler.

Speed is important, but so is good debugger support, productive UI tools, developer productivity, training requirements, available libraries, target market, etc. At the end of the day, most people make pragmatic decisions, taking lots of factors into account.

A good historical example of this is Word vs. WordPerfect. There are many reasons why Word won, but one of them is that WordPerfect was written in assembly. This was helpful at the beginning as it was good for performance, but their developer productivity suffered as the codebase increased. This resulted in fewer features, which is also something that customers care about.

Few customers care how quickly you can do something they don't want to do.

Also, he's conflating toy problems, where getting the big-O right is the only important thing, with real-world applications where the constants are also important.

Really I don't know about JS Hell, but C++ compilers aren't slow because nobody has tried to speed them up, rather the nature of C++ is that it is slow to compile. Every so often somebody rage quits C++ and starts a language like Go because of this.

The real data point is that Clojurescript is only slightly slower to execute than real Clojure, but takes two orders of magnitude more time to compile.

He's right though that people have to move on past Electron. Lately I have been building applications in Python/tkinter and I still can't get over how fast it is on both my mac and PC both to start up and when running. There is none of the "spend 30 seconds watching a splash screen" that we're are accustomed to with advanced applications in Java and C++ (eg. PyCharm and Photoshop)

Another thing that impresses me is the size and speed of small GUI applications written in C for Windows such as this little utility:

https://docs.microsoft.com/en-us/sysinternals/downloads/disk...

I think MacOS is also part of the problem. Lately I added a new keyboard to my Mac and I thought I was having Bluetooth problems but the main reason it was unresponsive was that the spellchecking baked into the OS would cause keyboard input to lock up for a few seconds periodically.

Later on I noticed that web browsers on Mac OS (Safari/Firefox/Chrome) seem to "go to lunch" and not respond to mouse clicks for 5 seconds every so often. I imagine this impacts Electron apps.

I think people have been "frog boiled" into expecting computers to be slow.

And that's when you can reason about the access patterns. When you're running things out of a browser, you are even further removed from the metal and likely using a grab bag of web frameworks and libraries that you don't control (or fully understand). And it's easier to keep using them rather than think about what it would take to make things run well and invest in that future. (You may not even have the ability to make that decision).

Luckily, it does seem that people are becoming aware of the issue, at least in some circles. I've now seen a number of articles with titles like "Why I have turned my back on the church of Object Oriented Programming," and with people like Mike Acton speaking at cppcon [2] to talk about data structuring, hopefully the next generations of application developers will be equipped to make things fast again.

[1] https://www.youtube.com/watch?v=HLk4eiGUic8

[2] https://www.youtube.com/watch?v=rX0ItVEVjHc

Then VSCode came along and showed that it wasn't all Electron's fault, there's a right way to do it. With faster platforms what you get is the room to do things wrong (inefficiently) with hardly anyone noticing.

> So what do these numbers tell us? Basically, to process exactly the same code, you can either spend ~8 seconds, 24 seconds or 78 seconds. Your choice.

My choice is I don't care in the least about these differences, and would gladly take the 78 seconds if that slow language had slightly better syntax or was slightly more expressive.

If I were working on a google scale code base and the difference was an hour vs 2 days, I might care then. But for the vast majority of programmers and applications, that's not relevant.

This is of course a bit of an overstatement, but I generally agree that (depending on the language you're using, and the problem you're solving), there are quick solutions and slow ones. However, based on the videos he posted, the author seems to have stopped just before the Advent of Code problem most likely to make his CPU cry! Day 14 didn't have an obvious optimal solution, so there were quite a lot of correct solutions that took seconds, not milliseconds. (If you're curious, check out this awesome post from /u/askalski [1] on getting it to run truly fast.)

Humans seem to be naturally inclined to pick the "best" option, and naturally frustrated by the fact that best changes so often depending upon the situation. In almost any situation as a programmer, you're deciding between several competing priorities. There's your speed as a programmer, your code's speed for the target hardware, your ability to get people to help you with the code, either via hires or online documentation, etc.

With regards to Advent of Code (which I also completed this year, and really enjoyed!), the "right" solution in Python could often be hundreds of times slower than the right solution in C or Rust -- just check out the benchmarks for similar toy problems [2]. That doesn't mean the solution is wrong, it just means that the author has decided that a couple seconds of the CPU's time are worth the benefit of using a higher level language, which is often a reasonable choice.

1: https://www.reddit.com/r/adventofcode/comments/a6wpwa/2018_d...

2: https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

But there's no point in turning something subjective into a one-bit moral requirement. Programs need to be fast enough to meet requirements and people have different opinions about what they require.

There is even an argument that slower is sometimes better. The large tech companies put enormous effort into reducing latency, but I'm thinking of writing a browser extension to add latency to some websites to make them less addictive. Where you stand on this is going to depend on what you're trying to do.

Erm. How about the ability to run in a web browser? You know. The single reason Javascript is popular. Maybe that?

This is completely true.

HTML is also more than a way to put pixels on a screen.

I'm utterly sympathetic to complaints about Electron apps (which I generally avoid because they feel wrong to me too), and to the idea that the web could/should perform better, and even that it is wrong for many applications.

But if one primarily conceives HTML as a pixel placement scheme, one is goig to make some poor judgments about what it's right or wrong for. This arguably works in tandem with the piece at some points -- "the web" in general (and some specific stacks or architecture choices) is/are probably used in situations it is wrong for because the related tech is what people know rather than because all the engineering decisions involve informed matches between characteristics and requirements.

And yet it reveals some limits about any judgment that the web in general is "wrong," and perhaps indicated the author should have demonstrated more of the wise principle of thinking about what one is getting. If there is one place where "it is fast or it is wrong" is often incorrect, it's in thinking.

(See also: Knuth's rules about optimization.)

The example discussed throughout the article is Clujure vs. ClojureScript.

The author takes issue with the difference in compile time (6.5 seconds vs. 78 seconds, respectively).

But this really is an apples/oranges comparison. If the user expects to run the program in their browser, then any solution that doesn't deliver that experience is wrong. End of story.

If the user can't be bothered to figure out how to install your native or byte code binary, then your solution is wrong. Find a way to give the user what they expect or stop trying to write software for a living.

Here's a common programmer dilemma:

You are familiar with development system X. However, your users demand that your software run on platform Y. Platform Y doesn't support X natively.

What do you do?

One option is to refuse to learn the development tools for platform Y, bringing shims, transpilers and a bunch of other dreck needed to get X running on platform Y.

But the user will notice the difference and not like it.

You're better off learning the native development tools for platform Y, and delivering a native experience.

In other words, drop ClojureScript and write the application in JavaScript if your deployment target is the Web browser.

Some of the truisms in the article rubbed me the wrong way though:

> It’s not that they couldn’t build faster. They just choose not to.

I’m not sure I agree and I don’t see what it’s adding to the argument.

> in the end what matters is if you have a working program on your hand and if it can produce the answer in a reasonable time. It doesn’t really matter how the developer arrived there.

Is this sarcasm? From my opening comments you’ll see I disagree with this. But, I originally thought the author did too.

Then they go on to construct an analogy of a shitty train and an awesome plane that cost the same. Where did they get this part from? I thought the reason people chose e.g. Electron vs. native is that there is a different cost involved for the developers?

> It’s easy to find excuses why things are the way they are. They are all probably valid, but they are excuses.

I used to assert the opposite when I was young, to my parents: “It’s not an excuse, it’s a reason.” It’s easy to dismiss others’ arguments out of hand, but the fact is there is a reason for every decision made, even if you disagree with the reasoning. There is always room for more education. I just don’t see how we can make any headway if we ignore each other like this. This reads to me more like “I don’t understand why C++ or Rust compile slower.”

> We know way faster programs are possible, and that makes everything else just plain wrong.

It’s easy to fall into the right vs. wrong argument when talking about programming–binary logic, tests either pass or fail. But we’re in the human realm here, where I’m of the opinion that there is no right or wrong, only consensus. In the case of products, like Slack, consensus manifests as what the market will bear. I might not agree, but for the time being, the industry has deemed it “right.”

After researching how to create a GUI in Java, QT, GTK+, etc., I found out for myself that a platform-independent GUI design can be a difficult topic, especially when it comes to GREAT usability.

I don't think, that Electron Apps provide GREAT usability - they do their job and are cheap to produce. In a world where JavaScript and browser technologies are used to justify low maintenance costs, better portability and the lack of skills, it can be helpful to critically question the arguments for it, which the author does.

Especially when this attitude only shifts costs from the manufacturer to the customer, e.g. under the time-to-market aspect. While the manufacturer is saving time and money, the users and customers pay for it. And this is the real argument for me - manufacturers want to save costs. Costs for:

- qualified staff - maintenance - portable applications - time to market

In my opinion the only way prevent more and more Web-Based GUIs is doing it better and being successful with it - not an easy task.

So thank you for this polarizing but interesting article.

> “Wow, wow, slow down! This is even more unfair! Now it’s not just apples and oranges, now it’s toothbrushes and spaceships. You completely ignore what each language brings to the table. There’s a reason they spend so much time compiling, you know?”

So what's the reason if the resulting performance doesn't differ much? C/C++ build times seem insane to me. Every time I try to install an Aur package and see it starts building C/C++ I cancel it and give up the idea as I don't want to wait a day for my CPU load to drop below 100% and my SSD free space usually happens to be not enough anyway.

Transpilation, however, is by definition not optional. It is frustrating to hear a complaint about someone who chose to write in Clojure, itself a layer on the JVM interpreter, and then chose to support a transpilation target, Clojurescript. If compile times bother you, then pick another stack. However, if you want to write code in a functional way and target both the JVM and JS, then this is the price you pay.

VSCode has no problem doing this on my Mac. I was scrolling through a 4000000 line file the other day like butter.

Win32 however can’t resize the most basic window without flickering - which is why every decent Windows app uses its own non-native GUI layer. There’s nothing wrong with non-native solutions - they’re often better. We can have the best of both words. Native on some platforms just isn’t that great.

When making decisions about software in the world, performance is just one of many considerations. If performance was the only dimension, we wouldn’t have had reason to move past Assembly.

I'll take Ruby vs C as an example. If I was to test out a weekend project, I'd rather choose ruby, even if it's going to be slow, as I can focus on finishing everything in the few hours that I have

[For non-developers, I’d guess 95%]

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.

More often than not, somebody with far more domain specific insight than yourself thought about the same thing, and rejected it, constrained by some other more important issue you can't yet see.

That's not to say that no improvement is possible, just that you are in a global competition with millions of other smart people and moving things forward is hard and takes dedication, not just hand waving.