
It is fast or it is wrong - tosh
http://tonsky.me/blog/slow-wrong/
======
widdershins
The fact is that a viable, efficient, native and cross-platform GUI solution
has failed to emerge. Note the word 'viable'. Those who might suggest that Qt
covers that role have to explain why, even though it has been capable of fast,
attractive apps for a long time, nobody built Slack, Discord, Atom or VSCode
in it.

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.

~~~
pjmlp
> Those who might suggest that Qt covers that role have to explain why, even
> though it has been capable of fast, attractive apps for a long time, nobody
> built Slack, Discord, Atom or VSCode in it.

Because those are companies dominated by webdevs that can't be bothered to
learn anything else.

Even VSCode is probably a side effect of Microsoft trying to be cool and
cattering to the new generations that don't know anything else.

For me, it just made me buy a Sublime Text license instead.

~~~
bunderbunder
VSCode grew out of a project to make a browser-based IDE. So, when they
decided to make a desktop-like user experience instead, Electron was the
natural choice, as a way to make it a port rather than a complete rewrite.

You could argue that it's a similar story for things like Slack - for business
reasons, they more-or-less needed to have a web-based UI. If you're already
committed to that, then it makes sense to use Electron in order to maximize
your code reuse.

I can't speak to Discord or Atom. Those ones make less sense to me, but there
might be a reason there, too.

Speaking completely personally, Qt has never felt like a viable option for a
commercial project to me. It does have some bindings for other languages, but,
at least last I checked, they're all community supported. When you're talking
about language binding libraries, it's reasonable to think of "community" as a
polite way of saying "poorly". That can quite justifiably influence a person's
willingness to rely on them for non-hobby projects.

I don't like JavaScript much better than I like C++, but at least I can more
easily think of business cases for why I might accept being locked into
JavaScript. The ones up above, for example.

~~~
danellis
At least part of the reason is probably the lack of a good layout engine
that's more flexible than rich text and less complex than a web page. An
embedded browser gives them everything they need for their highly stylized
layout, but at a great cost.

~~~
pjmlp
You can do quite powerfull layouts with QML.

------
wheelie_boy
This is a very silly argument: compile and runtime speed is not the only
consideration to take into account.

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.

~~~
shhehebehdh
The article is interesting food for thought, but there’s a fundamental error.
In the toy algorithmic problems, having the wrong big O solution is wrong
because it doesn’t finish in a satisfactory amount of time. From this he seems
to infer that anything that takes longer than another alternative is “wrong.”
But the thing that made the toy solution wrong does not transfer to the other
example problems! An editor dropping frames clearly isn’t sufficient to render
it unusable for a significant slice of the target audience (proof by
existence).

~~~
alexashka
Replace 'wrong' with 'sucks' and you'll be much closer to getting what the
author's saying.

~~~
redka
Still doesn't make the metaphor make any sense. If anything, it is proving the
exact opposite point since when it comes to programing languages/environments
the difference in speed is much more comparable to the 10-30ms from the
example (negligible) than to the "years" \- the one being "wrong".

------
PaulHoule
He's got some good points but it is a garbled argument.

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...](https://docs.microsoft.com/en-
us/sysinternals/downloads/diskview)

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.

~~~
jakobegger
Yes, macOS is gradually becoming slow.

Worst thing is the Finder. Moving files between folders used to be instant.
Now it sometimes takes a few seconds for files to appear in a folder after you
drop them.

I have no clue why.

I tell myself that the problem is that the old, experienced programmers are
leaving, and inexperienced young programmers are too busy adding new features
(it works! good enough!) to make sure anything actually works well. And of
course that never would have happened if Steve Jobs was still alive. (Just
kidding. Steve Jobs loved fancy graphics that made everything slow)

~~~
zozbot123
> I tell myself that the problem is that the old, experienced programmers are
> leaving, and inexperienced young programmers are too busy adding new
> features (it works! good enough!) to make sure anything actually works well.

You joke, but this is a real issue. It's hard to find any other explanation
for why the quality of commonly-used software has taken such a _massive_
nosedive in the latest 15 years, outside the FLOSS world (CADT syndrome
notwithstanding!) even as software was supposed to be "eating the world" by
now! Windows Vista, anyone? (Or, as some folks in Microsoft marketing used to
call it rather presciently, Windows "Mojave"?) I guess it just goes to show
that, yes, systems programming _still_ matters, as do projects that attempt to
open it up to a far broader audience while keeping and even strengthening its
focus on rigor, performance and correctness.

~~~
nl
I’ve been a professional software developer for over 20 years.

Commercial software is generally much better than it was 15 years ago.

Yes, Vista was bad but Win7 was good. You should have seen Win3 or 95 though.
You’d expect to have the computer crash multiple times a day.

~~~
zozbot123
Of course, _anything_ was good when compared with vista. Win 3 and Win 95 are
not directly comparable, as they were running on severely underpowered
hardware (and they could not pursue the sort of simplification that made OSs
on other low-end, "home computer" machines of the day more workable overall);
Vista does not have that excuse given the growth in system requirements wrt.
its predecessor.

(Even Microsoft had to give up not only on Vista but on Windows 7 itself for
"low-end platforms" \- they ultimately promoted a "Starter" version of the
latter that was specifically built to never even try to launch more than three
apps at the same time! I won't bother to attempt even the most cursory
comparison with what a proper, FLOSS alternative can still achieve on the same
hardware, even today...that would be tedious and ultimately beside the point.)

------
snek
The first half of this article made me think it was going to talk about how
clever algorithms can change a 1 year problem into a 1ms problem, think
outside the box, etc. Instead it took a nosedive into complaining about
electron, which definitely needs to be complained about, but this felt a bit
unfocused.

------
Kapura
Reading through this reminded me a lot of what Jon Blow has been saying [1]
about programming as he's been writing his new language specifically tailored
for games. He talks about how ridiculous it is that C++ compiles can eat up so
much time in a programmer's day, and how programmers are not generally taught
how to write efficient data structures and thing about things like locality
and access patterns.

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](https://www.youtube.com/watch?v=HLk4eiGUic8)

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

~~~
jchw
It feels like large parts of the reason C++ compilation is slow could be
solved by modules. Maybe some day?

------
karmakaze
I remember when I tried Atom when it was hype, others loved it but it felt so
slow compared to SublimeText and InelliJ. I wrote off Electron apps right then
and there.

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.

~~~
InGodsName
My favourite text editor is VSCode.

I use sublime as a notepad.

Tixati is my favourite torrent client.

~~~
karmakaze
Me too. Sublime's always keep text even when rebooted without save makes it
the ideal notepad.

Don't think I run any other Electron apps. Used to run Slack and Spotify but
now just pin browser tabs. Some devs run Gitkraken which baffles me.

~~~
InGodsName
Yeaaa i also used git kraken to learn but now i find it bit bulky.

~~~
karmakaze
It depends on the hardware and what you're doing.

Admittedly I was running 10ish not-so-microservices on a dev laptop so
couldn't really spare the cycles or RAM. Now on a desktop machine with 32GB
and more cores I probably wouldn't notice but just don't like the idea of it
from my previous experience.

------
jonahx
Not only are these differences not the high-order bit of programmer time, for
most applications they're probably the _lowest-order bit_ :

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

~~~
sdenton4
Yeah, you're basically treating user experience as an externality, though. The
point is that the end user of the program doesn't care how expressive the
language is, they care how long it takes to run. And the overhead piles up as
the dependency stack gets deeper...

~~~
wtetzner
But the end user certainly doesn't care how long the program took to
compile,which is something the author lumped together with runtime.

But end users do care about programs not crashing and losing whatever they
were working on, they care about features, and they care about how long it
takes for them to get the features they want, all of which are impacted in
some way by the language and tools used by the programmer.

~~~
chii
I thought the article was alluding to the fact that the same code ran 10x
slower in JS, vs jvm

------
ragona
> there are two types of solutions you end up with: ones that can calculate
> the answer in a couple of milliseconds and the ones that would take years to
> finish

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...](https://www.reddit.com/r/adventofcode/comments/a6wpwa/2018_day_14_breaking_the_1_billion_recipes_per/)

2: [https://benchmarksgame-
team.pages.debian.net/benchmarksgame/...](https://benchmarksgame-
team.pages.debian.net/benchmarksgame/faster/python3-gcc.html)

------
whatshisface
Part of the problem is that most of the competition has made it from the 80s
or 90s unchanged. For all of its faults, the "web stack" has benefited from
far more development than tk or wx. I have tried a few things and web
development is the best GUI development experience by a long shot.

------
skybrian
I mean, for some jobs, you could make the argument "it runs in the browser or
it is wrong."

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.

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

That's how javascript was invented, stop trying to do dangerous science.

------
IshKebab
> You don’t get anything from being on JS, except a 2× performance hit and
> astronomical build times.

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

~~~
Lio
I think the one thing I appreciate about running in a browser is control.

A native app removes any chance to run an adblocker (I guess it might be
possible at the network level) and probably means that you won't be able to
add keyboard navigation as you'd get from something like Vimium.

I always find it very jarring to be using something like iTunes and to realise
that I can't Ctrl click something into a background tab.

~~~
dehrmann
With a lot of SPAs, you can't control-click have the components because
someone either didn't make it an a tag or didn't make the linked page render
on its own.

------
wwweston
> HTML is a pretty inefficient way to put pixels on a screen.

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

------
apo
I would rephrase the title: "It runs on the user's platform or it is wrong."

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.

~~~
Hendrikto
> 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?

Use Electron apparently…

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

Exactly. I do not like it at all.

~~~
ebiester
I don’t like it, but do you remember using QT or GTK apps in Windows or the X
shim on macs? Was that really better?

~~~
pseudalopex
GTK+ and especially Qt are still used. Both have had native rendering on macOS
for a long time. It seems like some people compare the most polished Electron
apps to the least polished examples of other frameworks.

------
qwerty456127
So true. The only problem there is no really good cros-platform GUI framework
so far. If only there was something like WPF (and in no way inferior to the
original) easily and naturally usable with a good selection of programming
languages on all the major platforms (Windows, Linux, Mac, Android, Ios) I
doubt many people would use Electron. The whole thing about browser-based apps
is they run everywhere seamlessly while looking eye-candy, being easy to
discover, one-click to run and written in a language with a steep learning
curve and that all is for free in whatever a case (while e.g. Qt requires an
expensive license if you want to make a non-free app).

~~~
jcelerier
Qt is LGPL, you don't need a license to maje a proprietary app with it
(chromium and thus electron are under LGPL too)

~~~
qwerty456127
Good. I've read at least PyQT required a license. Qt Design Studio (which
could be a "killer feature" to attract people to the platform) certainly does
and even for a free project acquiring a free license for it is either hard or
impossible.

~~~
pseudalopex
PyQt is GPL/commercial. Qt for Python is LGPL.

------
twblalock
Performance is a tradeoff. Sometimes shipping a feature is more important.
Sometimes cross-platform support matters more than native speed. Sometimes
performance optimizations are a distraction from other, more important, work.

~~~
giornogiovanna
I just wish there was something that had it all! But until that exists,
performance is one of those things where you just need to be adequate. Very
few people choose between applications based on performance, anyway (and it's
usually too late to switch if performance becomes a concern).

------
sixstringtheory
I agree with his basic premise that if a faster solution exists, it is better,
and believe that considering how many users a relatively miniscule development
team will impact warrants much more inconvenience on the developers’ part to
make the users’ experience better–an extra couple of days for me vs. possible
man-months of lost productivity in aggregate for my users.

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

------
sandreas
In my opinion, the article serves its purpose: It polarizes. And quite rightly
so. While it is relatively easy to develop portable websites, this does not
work for real Applications in most cases.

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.

------
qwerty456127
> The same applies to all languages with terribly long build times. It’s not
> that they couldn’t build faster. They just choose not to. C++ or Rust
> program compiles for too long? Well, OCaml could probably compile the
> equivalent program in under a second. And it’ll still be machine-level fast.

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

------
javajosh
A discrete compilation step is optional. The most sophisticated way to run a
program is within an interpreter where runtime analysis is used to determine
which parts, if any, of the program to compile, and with what "flags".

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.

------
conqrr
It's exactly apples and oranges being compared here. Languages and libraries
or framework overhead is nothing compared to the toll of Big oh complexity. In
fact the former doesn't even get multiplied that much as your input is pretty
much constant. You start your application once unlike the input to your npow3
algorithm taking in a massive dataset. Also languages can make development
more productive, which again is debatable but the slowness isn't comparable to
Big O complexity. I am all in for leaner and efficient languages or stacks but
I can live with bloated languages as opposed to inefficient algorithms.

~~~
alexashka
The author's point is that he wants to live with efficient algorithms,
efficient languages and tooling.

It is not an either/or proposition - we can have all the things, or at least
something significantly better than the current state of affairs.

------
jahewson
> Electron text editors can’t resize their own window in real-time and drop
> frames while you just move your cursor around.

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.

~~~
roel_v
"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."

This is so extremely wrong it's not even funny any more. WS_CLIPCHILDREN and
WS_CLIPSIBLINGS are the key here. Of course, many people don't understand them
(eventhough it's not hard and the Petzold came out, what, 25 years ago?) but
win32 is very well understood by now and it's trivial to make extremely fast
(by today's standards) UI's with it, and relatively easily, too.

~~~
dcbadacd
Not OP, but sure, if I spend a few hours as a new Windows programmer I can
finally make my native Windows application not flicker on resize, but that's
most likely not it, there's probably a s __tload of other things I have to
spend a few hours on to get things somewhat properly-working. It 's a massive
cost compared to what default web already offers.

Then I have to repeat that same years-long process for Android, iOS, OSX and
Linux.

Or I can just make a web application that's slightly slower. The decision was
super simple for me.

F* native development of UIs, it's stuck, everyone in it think it's fine - it
probably is if it's all you do - but what matters a lot of the time is the sum
of development cost across all supported platforms. _shudder_ That means it's
especially horrible if it's just you developing something, the chance that a
single developer could support all of the most used platforms (Win, Linux,
OSX, Android, iOS) is so unlikely due to the time required to learn just a
single one of those platforms.

------
gshulegaard
You can choose to die on the proverbial hill that is “performance”, but in
doing so all you are doing is looking at the world through a key hole.

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.

------
heroic
This is by far the weirdest of all arguments ever. The OP compares faster
execution of code to being a comfortable aircraft and slower to an
uncomfortable train. What he missed out on is, that it's easier to build out
code that may execute slow, but works(making it more comfortable - room for
quick changes to the product), rather than making something that takes a hell
lot longer to make(and then spend proportionately longer when you have to
change something)

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

------
aj7
Ask HN: How often is time needed to program the most important temporal
measure?

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

------
patsplat
This seems to be more a benchmark for ClosureScript rather than "the web"

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

~~~
pseudalopex
You make it sound like Python and Java are esoteric languages and that VS Code
has replaced all other text editors and IDEs.

Sublime Text became popular because it was a cross-platform graphical editor
that used a popular language for extensions. Atom became popular because it
was all that and free. VS Code became popular because it was like Atom but
faster.

~~~
catpolice
I didn't mean to imply that, if I did. That said, Atom and VS Code did gain a
big market share of the text editor/IDE space pretty quickly, and the author
called out Atom as something built on a web platform that was slow and bad
because it was built on the web platform, and further implied that we could
build better a better version of it if we abandoned the web platform.

My point was just that the new editors were successful in the ways that they
were (e.g. for web developers working with a quickly evolving language)
precisely because of the fact that they were built on an extensible platform,
and in spite of the performance issues.

I was an Emacs user a few years back. Then I started writing more Javascript
than lisp and picked up React. IIRC the point where I switched to Atom was
when the emacs syntax highlighting packages were choking on es2015, but I
could get support for JSX and stage-0 ES extensions if I used Atom. If Atom
had been built with a focus on performance over extensibility, those features
wouldn't have showed up as quickly as they did and I wouldn't have had any
reason to consider switching. Atom was extensible (and not uniquely so)
because it was built on a browser and didn't have to reinvent the language and
concepts that browsers already had for building basic UI features. I'm not
sure we're going to see a new, successful IDE for quickly evolving languages
that does reinvent that wheel, as it seems the author is suggesting that we
do, in the name of performance.

~~~
pseudalopex
Even web developers have always used Sublime Text and Notepad++ much more than
Atom in Stack Overflow's developer surveys. VS Code overtook Atom in 2017.
GitHub completely rewrote Atom's text rendering last year. Both VS Code and
Atom are migrating JavaScript code to C++. Maybe performance matters more than
you think.

Atom used TextMate language definitions until recently. VS Code uses an RPC
protocol designed to let any editor support any language. Emacs just isn't
very popular anymore.

What "basic UI features" are easier to build in a browser?

~~~
catpolice
That's interesting - I didn't know Notepad++ still ranked so high.

Oddly enough, I'm actually pretty acutely aware of how much performance
matters in this space - at my last job, I spent a year developing an IDE for a
custom in-house language/environment with some unusual required features. I
looked in to extending existing editors/IDEs. The web-based editors were too
slow for my application (which required a very large number of page updates
from remote sources) but extending the native editors was an unfathomable
pain. When I looked into things that didn't use a browser back-end, I was
budgeting a month just to learn enough about their plugin architectures to
determine if what we needed was possible without rewriting the UI code from
scratch, which I really wanted to avoid. From experience, working with raw
Java/C++ UI toolkit code is a nightmare compared to html/js and requires
orders of magnitude more LOC just to put anything on the screen that can be
interacted with.

In the end, I wrote my own web-based IDE from scratch, using a lot of
application-specific performance optimizations that would be really difficult
for a more generic, modular system (lots more care about what parts of the DOM
to touch and when went directly into the parser than would have been possible
with Atom/VSCode/CodeMirror/whatever at the time). I spent 6 months optimizing
it and it was only barely fast enough that you could type at close to 60fps in
big documents, but I don't think I could have made a native version that
worked at all in that time.

So I get it: performance is important, and there are cases where web-based
things either don't cut it or are barely acceptable.

My point wasn't that performance isn't important, it's that it's not the only
concern and pointing to the relative popularity of editors over time still
illustrates that. Notepad++ was released 12 years before VSCode (which has
only been around for ~3 years) and has had better performance this whole time,
but in the 2018 Stack Overflow survey, VSCode beats it in popularity. So
performance can't be the overriding factor in its relative popularity - it
became popular in spite of being slower than things that already existed.

The author of the original piece argues that the whole web-stack is _wrong_
and should be thrown out and replaced with something else, because it's slow
and people don't care about how easy it is to develop something if it's slow.
I don't think that's true, and the easiest way to see that is to note that we
already had faster things that were harder to develop and extend and they're
increasingly being rejected in favor of the opposite.

------
yholio
Put your money where your mouth is. If you think something can be improved,
and the cost of that improvement is justified by it's benefits, then you have
a valid business idea.

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.

~~~
TeMPOraL
> _If you think something can be improved, and the cost of that improvement is
> justified by it 's benefits, then you have a valid business idea. Stop
> wasting your time bashing Electron on your blog and start working on your
> idea, it could be the most important thing you have ever done and could make
> you rich and famous._

To be fair, preventing a small group of people from dumping disproportionally
large externalities on everyone else, to extract a little extra profit for
themselves, isn't a working business model. If it was, we would have solved
global warming and ocean pollution by now.

Slow software in general, and Electron in particular, is a collective action
problem. Solid, fast software gets outcompeted by half-assed bad engineering,
because the latter can get to the market first.

(Also known as the curse of "worse is better".)

~~~
notatcomputer68
Irc has been on the market for a long long time, but slack won anyway.

Maybe the extra features saved users more time then they lost from running
bloated JavaScript.

~~~
pseudalopex
IRC is a protocol. Slack is a service. That's another collective action
problem.

