Hacker News new | past | comments | ask | show | jobs | submit login
It is fast or it is wrong (tonsky.me)
212 points by tosh on Dec 29, 2018 | hide | past | favorite | 182 comments

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.

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

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.

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

Electron exists because of Atom (yes, in that order). Electron was previously called Atom Shell[1] because it was created specifically to house Atom, although they mention it wasn’t created just for that. If there’s one app that has a reason to be built on Electron, it’s Atom, because it was an experiment to see how viable that solution would be.

But even they understand that solution wasn’t the best because it’s slow, so they’re experimenting with a model where the application logic is written in Rust and only the UI is built with web technologies[2].

[1]: https://electronjs.org/blog/electron

[2]: https://github.com/atom/xray

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.

You can do quite powerfull layouts with QML.

Discord also has an identical web UI.

that has less than half functionality (and across different browsers it may be even worse)

Qt includes JavaScript bindings. Python has commercial support. Java used to.

Electron is good for an MVP if you have or need a web app. Companies keep using it afterward because it commodifies developers and externalizes costs.

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

I doubt Microsoft (VSCode) is in that camp. Or that that was the main concern of the others. And I think that's a facile explanation anyway: the same kind of companies flocked to do native mobile apps in the past -- but nobody much cared for QT on desktop still.

It surely is, given the amount of love JavaScript has gotten since WinRT introduction, TypeScript, and Channel 9 sessions mostly done by newly hires.

Efficiency is more important for mobile apps.

I would argue that VSC beat faster and more mature editors for one simple reason -- intellisense. All the other editors allowed the seductiveness of intellisense to go unanswered for years.

Otherwise I'm not sure why most people care about the internals of their editor.

The Visual Studio Installer was rewritten from a native app to an Electron one.

They had a native app. They decided to throw it all away.

it's amusing how they managed to make the new installer as bad as old one was

Can you elaborate on that?

The JavaScript camp inside WinDev managed to get Electron to replace the WPF installer for VS 2017.

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

Tell me about it!

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

working on Max/MSP by any chance ?

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

But someone built Telegram with it, which is of fairly equivalent complexity (https://aozoeky4dglp5sh0-zippykid.netdna-ssl.com/wp-content/...).

Besides, I'd say that there are enough quality Qt apps in the KDE ecosystem to not need $ELECTRON app :-) just yesterday Krita was making the highlights for instance. Likewise, I doubt people being used to the power and speed of KDevelop or QtCreator would feel the need to switch to VSCode.

Even going outside of the "libre" ecosystem, there are many many many nice-looking recent apps written with it... take a look at substance painter (https://www.allegorithmic.com/sites/default/files/DML_1.jpg), the Blizzard launcher (https://i.kinja-img.com/gawker-media/image/upload/s--zbfvud8...), Native Access (https://support.native-instruments.com/hc/article_attachment...)...

I just downloaded Telegram because I was curious how Qt's macOS support was, and it turns out the Mac version of Telegram isn't even written in Qt.

I did eventually download the Qt version. It doesn't support emacs keybindings. I can't use ctrl+b ctrl+f to move my cursor in text boxes, like I can in every macOS native app and Electron app.

I think this is a pretty strong argument for Electron: It actually behaves like a native app.

I also think Telegram is lower complexity than Slack, Discord, Atom, or VS Code. For instance, as far as I can tell, it doesn't have features like emoji reacts, which I'd guess would be something easier to implement in HTML/JavaScript than in Qt.

The Emacs key bindings don't work in every Electron app. They also don't support Services.

I haven't used Allegorithmic's stuff recently, but my previous experience was that it's neigh unusable on a Mac laptop. Much worse than anything I've experienced in electron.

Substance Designer is a giant graph editor that should be perfect for multitouch trackpad pan/zoom gestures, but it doesn't support them. To zoom in and out you scroll up and down as if you're using a mouse wheel, but moving your fingers about 1mm will zip you instantly past where you were trying to get. And IIRC it expects a middle mouse button that you can drag to pan; on a laptop you get to two-finger-drag while holding down Option.

Electron, being based on a web browser, is probably easier to set up for various input types beyond keyboard and mouse.

EDIT: Here's an old video I recorded of the trackpad zoom. If you look very very very closely you might see my fingers move.


TLDR cross platform UIs still take work

The issue there is you're running a VFX application on a Mac :P I mean that 50% sarcastically and 50% sympathetically. Apple support has not been stellar the past few years across 3D applications. Not sure when the last time you used their products, but they did go through a redesign and things have improved a fair bit.

From the thread's master:

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

Most industry standard VFX applications utilize Qt for the UI and other application parts. It helps that there was a standards body (admittedly, very Linux biased but starting to open up) set up between vendors and studios for choosing major frameworks/libraries (VFX Reference Platform[0]):

* Autodesk Maya

* Autodesk 3DS Max

* SideFX Houdini

* Foundry Nuke

* Foundry Mari

* Foundry Katana

* Foundry Modo

* Allegorithmic Substance Painter

* Allegorithmic Substance Designer

With the exception of macOS in the very recent years, these applications work pretty seamlessly and efficiently. Qt is not as easy to get up and running with compared to web based frameworks like Electron, it does provide a pretty 'viable' framework for building cross-platform applications. Getting 'native' in appearance will probably never happen 100%, but Qt does a pretty bang-up job. Regarding the apps listed above, they all use custom styling so you get the same interface across all platforms, so native doesn't even matter anymore.

[0] http://vfxplatform.com/

I primarily ran it on my Windows desktop where it worked better (except for being tiny because they hadn’t implemented any sort of UI scaling for high DPI displays, making the 10pt-ish UI font nearly unreadable), so it wasn’t a huge deal, but still was disappointing. Faster CPU and much faster GPU on my desktop, but I’m not always at that computer.

The bigger bummer is that “cross platform” for this sort of thing is only talking about Windows, Linux, and maybe Mac. Substance Designer and Painter would both be outstanding to use on an iPad Pro as long as you had someone on desktop platform feeding you the 3D models.

> except for being tiny because they hadn’t implemented any sort of UI scaling for high DPI displays, making the 10pt-ish UI font nearly unreadable

Designer has had proper Hi-DPI/scaling support since early/mid-2017. Painter has the support, too, but not to the same degree. Apparently it rounds between 100% and 200%, but nothing in between. Although a user said 150% works.


> The bigger bummer is that “cross platform” for this sort of thing is only talking about Windows, Linux, and maybe Mac.

That I think is between Qt and Apple. Mari 4 came out at the end of last year and the macOS version has been in a perpetual beta since about 6 months after GA, but should arrive with the 4.5 release currently in beta (fingers crossed for those users). As reported by the dev team, it comes down to some serious stability and useability issues from Qt on macOS (the way they've implemented it) that is just not working well between various macOS versions. Some users the beta works fine, others not at all. And this happens to users of the same OS version and hardware.

I was pretty early on the 4K train (mid 2014), of all the things to not adopt that fast, texture editing software was pretty unfortunate. Glad to hear things are better now.

On the platforms, my bigger issue is the complete lack of iOS for these apps more than the iffy Mac support. It would’ve been really good.

Heck, even the Surface Pro would’ve been great if they’d properly supported gestures in the graph view. They didn’t though, and I don’t have a Surface Pro anymore.

>Most industry standard VFX applications utilize Qt for the UI and other application parts.

And most of their UIs look alien and unusable crap only a professional forced to use it would...

I've never seen an application that has a seriously broad range of functionality where I went "Wow. That's amazing." And not just from a visual standpoint, but from a navigation and process perspective.

It always takes a small adjustment period of getting used to the application's actions paradigm and you get over it. The UI's don't really get in the way, and you kind of stop caring about visual appearances after the first few weeks. At the end of the day, it's all panels and buttons. As long as it's internally cohesive and consistent.

>I've never seen an application that has a seriously broad range of functionality where I went "Wow. That's amazing." And not just from a visual standpoint, but from a navigation and process perspective.

Even so, 3D apps have it way worse than pro apps like Photoshop, Cubase, etc with equally "wide range of functionality".

I mainly use AutoCAD at work and I’m constantly thankful that it has a command line still. Hardly touch the UI except for the 3D view and whatever popup windows I summon with commands.

The ribbons thing admittedly is more discoverable, so occasionally I’ll look for something there instead of going straight to google, but once I know what it’s called I’m right back to the command line.

you mentioned "nice looking" but then linked everything that looks like homework project from some web design course instead of proper, intuitive app

"Emerge" is a very interesting choice of word. Why do we think that a property like "interoperability" could be emergent? Has it ever been?

Web browser developers have shown by example that you can come up with a sophisticated standard, including executable code, have everybody implement it on their platform, beat them into compliance with cool validation tests, and even starting with one of the worst possible architectures for performance (sending raw JavaScript code over the wire!) make it perform far better than anyone might have reasonably expected.

Meanwhile, operating system vendors are doubling down on proprietary APIs. These days you practically need to use the right programming language for your OS, too.

A whole lot of groups seem to have completely missed the web's lesson. Instead of "standardization is great", they heard "HTML/CSS/JS is the ideal substrate for writing applications".

> The fact is that a viable, efficient, native and cross-platform GUI solution has failed to emerge

FreePascal have one. TCL, before.

The bigger problem, I think, is the language tie-in. For get the amazing Delphi/FreePascal UI you need to work with pascal.

To get TCL-UI, you need to work with TCL. This mean anybody that not want to code on that not even consider the option.

And how integrate your language of choice? You need to pass by C. C sucks. SUCKS SUCKS SUCKS. Is so bad that is the glue for native development.

In the other hand, Elector/React Native is tied-in with JS. If C sucks, JS sucks even more, BUT, you DO NOT HAVE A CHOICE. Is Js or the highway by proxy of the browser. So, even if you code in other language, you MUST (not everyone, but enough) soon or later to accept this fate.

And interface with JS is not as bad as with C.

Delphi was a pretty fun thing: nice IDE and nice language (would prefer c-style, but still c++ is much less friendly), but terrible licensing made it niche (VS had completely free, including commercial use Express edition + non-comercial Pro licenses for students while Delphi was few bags of gold for personal license for whatever reason making it completely irrelevant on a global scope, freemium is the way to go with stuff like this, this is the exact reason why windows and office are so easy to crack) and you know, C sucks, c++ sucks, every language I ever heard of sucks but the ones that get laughed at the most: JS and PHP seems to suck much less in terms of usability but sure, lack of proper runtime/native compilers and GUI bindings make them niche (or used to, now unfortunately we have electron to make JS based GUI apps...)


The more of my project I can write in C, the happier I am.

People sometimes irrationally like sucky things. C's memory model, type system, and feature set are sorely lacking by modern standards.

Given the feature set of Turbo Pascal 6.0 for MS-DOS in 1992, C was already sorely lacking back then.

> The bigger problem, I think, is the language tie-in.

Same issue with WxWidgets, which is otherwise great - AIUI, it was started as a C++98-ish library with support for lots of pre-standard compilers, and a lot of its deep weirdness is a direct consequence of that. OTOH, at least it has good bindings for other languages like wxPython.

looking at available bindings I guess c++ is still the least terrible choice this or JS one yeah, I know, there are some py lovers but I can't stand this thing

Of all the popular non-functional languages, I think C and D are the ones that sucks less, but D is not as popular, so that leaves us with C.

And this is the main problem. C, alike JS, ruin the chances of anything else to take over. Pascal is one that could have been much better to rely on. D is nice. Rust is too, but the chances of them to replace C is like typescript replacing JS.

In the other hand, I wish C get allowed to improve much more, and do python2/python3 split (with better handling of the situation, of course), to remove lingering issues, clean the syntax/API, and just add algebraic data types, match and Option<T>, and a good UTF-8 string (the only additions that I think are worthwhile without making C too different).

I envision a C-good that transpile to C-classic and slowly take over.

While not what you envision, I recommend looking at Go if you haven't.

I experience bliss while writing stuff in Go. It is not as fast as C, but it is getting closer with every release. Garbage collection in Go is so fast now that there may as well not be any pause at all.

It's worth a look, in my opinion.

I have look at Go. It impress me the first time, specially the CPS stuff. But now I'm working on Rust (apart of F#, python, Swift). Rust is nice, but too strict, and is very hard to be productive on it.

The lack of generics kills Go for me. I know it's an old rag and they'll never add them, but I just can't get over it. Maybe I should try Rust...

C doesn't have generics, either.

I was recommending Go to someone that wanted C plus a few things. For me, that's Go.

Why does the lack of generics come up all the time?

There's a bit of new syntax, but overall it does what you asked for: https://ooc-lang.org/ even compiled down to C

It didn't get very popular though.

I think a lot of it is that browsers are far superior in creating the design you want. You may have to work around things, but you don't have to learn completely new things that are only for your application.

If you learn to make great looking and functional websites then you can make that into electron. Add to the fact that many services want to have a desktop and web application, it just makes a lot more sense to design its core in Js in a browser environment

As for the obligatory "qt can do that" qt uses chromium to do browser related tasks. The alternative is webviews which are unreliable in any full sized application.

To some degree I think the desire to have “any design you want” is anti-user: I really don’t want to use apps that have the design their developer picked for me, I want to use apps that respect the conventions of my system and the preferences I have set (e.g. on Mac, I want the accent color to be the one _I_ picked in System Preferences. On Linux, I want the apps to fit in with my choice of gtk or qt theme.)

These days Qt is fairly close to this ideal, even on Mac: apps like calibre look a bit weird but their menus are in the right place and their coloring roughly matches my os settings. Electron apps are all over the place: vscode, slack, etc. all pick their own design styles and ruin the visual consistency of my desktop.

> To some degree I think the desire to have “any design you want” is anti-user

To some degree? It is incredibly anti-user, especially if the user happens to have a disability. I know I've said this before but it is absolutely ridiculous that having a "dark mode" is considered some kind of notable feature in 2018, when in 1995 you could just set all your colors and fonts however you preferred them.

But that's the world we live in now. Personal computing is dead, you just rent your computing from some corporation and they'll tell you when to update and how everything should look and what you can and cannot install (for your own good comrade!).

As far as personal computing is concerned we're living in the darkest timeline. Makes me ashamed to have anything to do with the tech industry.

Something that actually blew my mind is that by default most Qt apps actually can accept a theme sheet by command line argument. This means that you can pretty much retheme any Qt app by adding a file and editing how shortcuts/registry/however else you can launch applications. I know that there is a programmatic way to do all that on linux but not sure of how for win and mac.

That's still a huge step down from the single configuration dialog we used in Windows 95. And it's slower.

On Linux, at least, there is such a central dialog. It’s just that Qt exposes the configuration via command line overrides

Well, I think what we call "design" has two parts: one is "theming" concerns and is made up of things like colors, icons and cursor shapes (to give an incomplete list); the other is more functional and has to do with the logical structure of the various inputs and outputs in a UI. Generally speaking, I think the former concern should be totally under the user's control while the latter concern is what UX people and front-end devs should be doing.

Comparing Calibre favorably to VSCode and Slack highlights how different perhaps audiences are: while I love what Calibre does, I really dislike its interface and vastly prefer VSCode and Slack.

I actually agree with that overall. The point was more that Qt has come a long way towards integrating with OS X.

For an apples-to-apples comparison, I’d rather use Slack through something like Adium that puts me in control of the ui. And VSCode would be nicer if it looked more like textmate.

UI is art, art doesn't fit in such limited terms as native UI. Your personal preferences of liking the same UI style should not hold back the potential useability improvements that electron apps do infact have. Their presentation of content and organization of information is on point in ways existing applications didn't have, that's why they're popular.

I'm pretty sure UI tends to be science, with art kept for flight of fancy systems interactive like Emacs, vim, the Leo editor or Bret Victor's ideas--none of which would pass muster in committee UI decisions in for-profit companies. Shells are some black art.

Art is about presentation of content, styling. Every cartoon has it's own way of doing 2D presentation in a way that content matches up to be pleasing to the eye. If UI is not designed to a consistent eye pleasing assortment of styled information, it doesn't work well. That's the whole point of native styling.

Speaking of "a viable, efficient, native and cross-platform GUI solution", I have high hopes for flutter.

Can Flutter really be called "native", though? As I understand it, it operates like Swing: it draws all of its own widgets. They do their best to emulate the platform's widgets, but it's not using the native APIs for them.

Yes, you are correct.

I think Flutter means native in the sense that it runs at native speed, perhaps even faster in some carefully selected apps

As for a look and feel thing, Flutter widgets feel alright to me..

i'm seeing a lot of complaints on iOS flutter apps of how the UI looks(microstutters/not frame perfect). it's only the usual small vocal minority but boy do they kill your app's reception on the programmer heavy social media

Can you link a specific issue that wasn't immediately a result of a problem with the user code, perhaps too much work on the main thread?

I have found the perf to be just fantastic on android. Especially compared to react native, which is a native offering.

android is fine,it's the iOS side that complains

AFAIK Flutter is "only" for Android and iOS, excluding desktop applications.

The flutter team has announced that it is now working on desktop and web ports of flutter.

What's interesting is that you can literally run the same app on all platforms, because flutter draws the whole ui in dart code, using the canvas. And well, dart can run basically anywhere now...

There are people successfully running Flutter on desktops, but it isn't currently the main thrust of the project.


I wish I could share this sentiment because Flutter really does look great, but I don't think it will succeed as long as it's based on Dart and not JavaScript.

That's very bold, considering the popularity of JavaScript, an esoteric, joke of a language in earlier times (no offence).

Bottom line, Its very safe to say that dart is a much better language than JS.

The language of choice has never ever, really mattered in software history.

And don't forget that the big G is behind this thing, which is well equipped to push it forward without the need of it being as popular as js.

The big G dropped the ball on Dart 1.0, which was rescued by the AdWords team.

Right now Flutter/Dart looks like an ongoing political war between ChromeOS, Android and Fuchsia.

By the way, Fuchsia is getting Android suport and a new language agnostic UI composition engine, Scenic, so lets see for how long Flutter stays as the Fuchsia official UI toolkit.

Nice point about fushsia.

But isn't the point of a truly cross platform framework just that? So what if fuschia has a different native toolkit. Maybe they are trying to launch a platform specific api that's more bare metal.

I mean Isn't the whole point of flutter is that you take the same app and run it anywhere?

What do you mean with "Fuchsia is getting Android support"?

Android is being ported to work on Fuchsia as well, just like it happened with ChromeOS.


To be more specific about the value here:

Maintaining parity between two applications running on different GUI platforms is very expensive - much more than twice the effort of maintaining a single codebase.

Not at all. Core logic can be shared. Single-platform frameworks usually have large libraries of well-tested controls. You can often get good performance, OS integration, and accessibility without really trying.

Not to mention a huge pool of talent for JavaScript devs

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.

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

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

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

If he meant that word, he should have used that word. Even if he meant “sucks,” I don’t think he’s right. I use VS Code professionally. It’s far better than Sublime Text or notepad++, despite making different trade offs on the native vs electron UI front. To say something sucks is a wholistic statements that isn’t supported by the evidence he gives. It’s far more accurate to say “it’s unfortunate that electron has these drawbacks.” That’s true but also kind of vacuous.

Good points, but:

A cross-platform UI framework could easily fulfill all your requirements, yet doesn't exist.

I'm not saying that I have requirements, just that there are different considerations when choosing a tech stack other than compile/run speed.

Several cross-platform UI frameworks do exist, all with different pros and cons. I don't think it would be possible for a single UI framework to override all other considerations when choosing a tech stack. It would have to be pretty magical.

Especially compile speed, and especially if the program is composed of libraries that don’t all need to be compiled every time.

There is something super nice about editing JS and being able to see the change immediately, but I’d still trade that off for some type safety in a “compile to JS” language that wastes a second of my time per compile.

The other point about compile speed is it doesn’t affect the end user (if we are talking about source code compilation not JIT)

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:


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.

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

Are your applications of similar size and complexity as these Java and C++ applications? Photoshop is a huge beast.

I ask because I’ve written C++ GUI applications that start up instantly (sub second). I’ve also written Python GUI applications that did not. It depends on what and how much you’re doing on startup. Most GUI applications aren’t as large as PyCharm or Photoshop and start up significantly faster, regardless of implementation language.

> 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’ve not had this problem personally, but I have had Chrome lock up my entire system on Ubuntu (input including mouse clicks simply not doing anything, but if I happen to have another window open I can alt tab to that and then everything is good again, or at least I can kill Chrome).

I've made smaller apps with JavaFX which still take annoyingly long to start up compared w/ similar tkinter apps.

Java was once notoriously slow and still has slower JVM startup time than C++. Maybe JavaFX is slower. I’ve not written any GUI applications in java nor do I use many java applications. However, my experience with C++ has been very different: things can run and start very fast. If they don’t, it’s because either you did something very wrong or because it’s doing a lot of work that would be equally slow elsewhere.

I’ve used Qt, WxWidgets, FLTK, GTK+ and a FOX as my GUI toolkit over the years and, for my small applications, all of those start so fast I don’t notice it. The only slowdown I’ve noticed is with Qt when using QtQuick (I assume because it has to load, parse and then execute QML — essentially JavaScript — as well as the C++ code). It’s still faster starting up than PyCharm and Photoshop for anything that I’ve used it for.

Qt slows down when it processes [large] images. Anything you want to display on screen has to be processed to a QtPixmap structure. When I last used it, with sufficiently large textures and/or splash screen images, this operation could take long enough to cause the rendering thread to skip frames. (In an embedded x86 environment we were talking about some hundreds of milliseconds.)

The other part where Qt can really slow down is when you have to instantiate a 3D driver module. That can block absolutely everything.

Ive always wondered why java starts so slow. A simple hello world takes a second or so. Most interpreted languages do a lot better.

Once it has warmed up, it's close to C however.

A simple hello world takes about 262ms on Windows 10 with Java 11.

Which can be further reduced by making use of AOT compiler, or SubstrateVM.

Additionally, Java always enjoyed the ability to AOT compile to native code, even though it was mostly available via third party commercial JDKs, or gcj for the adventurous ones.

>Once it has warmed up

that's the problem, a lot of workflows even on really complex applns like photoshop are firing up a project for a couple of minutes to get some output or correct something. enough time is wasted warming up that people who can afford it just leave the applications running. i just keep whatever VS project i'm working on running for eg coz the startup times are painful and i have RAM to spare

Interestingly enough, since we have Qt mentioned in this thread...

Somewhere between 4.8 and 5.1 (I can't remember exactly when), QtWebKit introduced a compile-time macro-assembler setup. This was used to generate a "first pass" product of the JIT engine output, to reduce the JavaScript engine warmup time.[ß]

This was at a time when I had already wondered aloud, on several occasions, how long it would take for browser vendors to allow downloading precompiled JIT blobs for speeding up the most expensive parts of whatever they wanted their visitors to run. This never happened. The world hopped over the fledgling JS-AOT craze and came up with WebAssembly instead.

ß: the construction also introduced Ruby as a build requirement, because of course the macro-assembler generation was done with Ruby.

> Are your applications of similar size and complexity as these Java and C++ applications? Photoshop is a huge beast.

It's not really the application size though. It's whether you load/initialise things eagerly at startup, or do you do it as needed/in the background.

If you see a splash screen, you know it's the first option. The slash screen is visible and active after all - the app itself is loaded.

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)

“Programmers” are definitely not the ones making calls on stuff like this. There may well be some generational turnover, but the value of performance for these sorts of tasks is not judged by the folks implementing them. Product owners are the ones who decide on the priorities. And keeping stuff like this snappy is undoubtedly a lot of work that mid range managers are reluctant to stick their neck out over. So yeah you need someone at the top who cares about it. But I’m guessing so few people even use the finder for file management day to day these days that it rarely even comes up.

"Programmers" make some of these decisions, "Management" make some of these decisions. Professional programmers generally don't get to pick what tools they use 100% of the time, but they do get to decide some of the time.

I'd argue that programmers rarely get to make decisions like performance. Esp. in a large corp, where responsibility is diffused.

I’ve noticed iCloud sync is sometimes the issue. If dropping files into/around enabled folders the sync process invokes immediately and uses a lot of CPU similar to Dropbox sync.

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

People are attracted to shiny so companies prioritize making everything shiny as often as possible. The average used had to look for subtle clues to find out whether their machine was windows 95, 98/SE, 2000, ME, or XP with a classic skin.

Now, the average user has to totally relearn every few years how to do less of the things they could do before. There’s an obsession with reinventing the wheel that takes precedence to stability.

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.

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

Do you use google drive? I experience the same file issue on my work laptop where I can’t uninstall the drive daemon.


I’ve noticed this, too. I suspect specter/meltdown mitigations. But that’s purely speculative... (See what I did there?)

Keep in mind that it's not always the developers that dictate when things get released; as companies get bigger these decisions are made less by the creators and more by the management/PM cabals.

Software Date Driven Development is a scourge, but shareholders (or potential purchasers) scream for their instant ROI, and this is what we get.

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

Has the GUI of tkinter apps improved over the past couple of years? I have yet to see an interface built with tk that doesn’t look like it was meant for Win95.

For native looking tkinter, there's ttk (themed tkinter).

I'm always suspicious when people say something can be done. Why isn't it the default then? Because there is some drawback to that choice. But what is it?

haha, well for example there's an issue open since 2012 about how common convenience dialogs don't work with themed tkinter although i don't really understand the comments about IDLE supposedly doing it automatically but not yet?. i think tkinter is a tool you reach for coz you know python only to realize you can't really write bulletproof UI in it coz of some workaround or issue.


I used tkinter a few years ago, since it was available on Raspbian on the Raspberry Pi. It looked bad on Linux, and it seemed tkinter was not in active development or getting a lot of attention. I remember not having found any sane workflow for how to place GUI elements and struggled to place a bunch of text boxes and buttons.

Reasonable or not, I have a hard time accepting workflows worse than what Microsoft Access or VB 6.0 had.

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

So much this!

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.

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

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

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

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.

My favourite text editor is VSCode.

I use sublime as a notepad.

Tixati is my favourite torrent client.

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.

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

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.

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.

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

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.

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

Yeah, so we're experiencing this right now. We're writing more and more of our app in Swift (slowly migrating from Objective C), and compile times are growing as a result. It's extremely frustrating. 90 second compile times seem forever when you are used to incremental builds that take only seconds.

That's fair. If it's 90s and it's part of a developer workflow that is triggered more than a few times a day, it matters. I haven't worked with Swift in particular, but in general you might be able to do incremental compilations to avoid that problem rather than "rebuild the entire project" with every change.

My real point is that I care about everything more than speed until I have a specific reason to care about speed. Then I'll care about speed.

In contrast, many programmers fetishize speed and efficiency as a quasi-religious value, even when they have no practical consequences.

I think Swift has support for incremental builds (it's not always 90 seconds).

The blog post was mainly written about GUI toolkits, if your application was freezing for 78 seconds waiting for a screen redraw you might be willing to settle for uglier syntax.

> if your application was freezing for 78 seconds waiting for a screen redraw

78 seconds was the compile time. The runtimes were almost identical: 0.45 seconds to run the entire test suite in the fastest case vs 1.3 in the slowest.

The slowest is three times slower than the fastest! That’s not almost identical at all, and could easily be the difference between a useable interface and an unbearable one...

It could be. And when I have evidence that user experience is affected, I'll care about the difference. But what if it's 1ms vs 3ms? Or 3ms vs 9ms? And the 9ms time is a much more expressive, productive, high-level language?

I'm not going to care about the difference just because "omg one number is 3x another number!?!"

For an soft realtime application like game that’s the difference between 10fps and 30fps. Or 30 and 90. Basically total failure or success.

I was referring to response time in a GUI app -- 9ms is undetectable.

Again, if you have a reason the speed matters, then it matters. The specific numbers here are not relevant to my argument, which boils down to: being "slow", in and of itself, is meaningless.

0.45 vs 1.3 is mentioned as being almost irrelevant in the article - from article: “Another interesting observation is that it makes no difference what hardware you use to run it. If the solution is fast, it’ll be fast on a notebook as well as on a beefed-up workstation-class desktop. Sure, it might be twice or thrice slower, but it’ll be a difference between 10ms and 30ms.”

All up the article starts with reasonable discussion about how different solutions can have more than 6 orders of magnitude time difference, then it segues irrelevantly to a complaint about electron.

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

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

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.

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.

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

> I'm thinking of writing a browser extension to add latency to some websites to make them less addictive.

Woah, that might be really effective. I love the idea of finding ways to undo the powerful conversion and retention techniques that our industry has developed. Adding latency is likely not frustrating enough that I'd just bypass it (like I do with Screen Time), but maybe it'd work for my brain. So cool. I wonder what other opportunities exist in the "making this less sticky" space.

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

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.

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.

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

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.

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

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?

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.

I'm pretty sure that you use a bunch of Qt apps on Windiws without even knowing it. Hell, even the official Microsoft OneDrive client uses Qt :-)

Yes. Especially for windows or the Core Graphics gtk port.

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

On the other side of the same coin: Drop the web stack and write the application in an appropriate native development environment if your deployment target is desktop or mobile.

Dropping Clojurescript in favor of JavaScript doesn't really solve the problem. Modern JavaScript has compilers, bundlers, minifiers etc that all slow down the build process as well. Almost no one actually just open up a JavaScript file an runs it as-is in the browser these days.

In addition, unlike say GTK vs a native windows app, the only perceptible difference to a user of a Clojurescript app versus some other flavor of JavaScript will be bundle size. Clojurescript embraces the JavaScript VM, unlike languages that attempt to bring their own runtime to JavaScript.

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

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

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.

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

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.

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

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

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.

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

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.

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.

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.

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

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

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

"Win32 however can’t resize the most basic window without flickering"

That's not true

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.

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

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

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

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

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.

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.

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.

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?

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.

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.

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

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.

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

Ad hominem. How intimately familiar are you with the author's situation to comment on it, and why do you feel like a public forum is an appropriate place to do so?

Why and how is it an ad-hominem? What exactly is being critiqued about the person of the original author? The point of the argument is to bring economic trade-offs and external contains into the discussion.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact