Hacker News Reader

Comment by indymike | Hacker News Reader

Unpopular opinion: native GUI app development on most platforms is a shitshow. Huge toolkits, copious amounts of boilerplate, and a huge amount of dev effort thrown at the platform just to get it working.

Meanwhile, say what you will about the web ecosystem, I've given interns/jr devs tickets like: see if you can get this webapp running in electron, and maybe figure out how to do push notifications and save data locally. Two days later the project is done. A week later, the app is ready to install.

I think the real reason I quit doing meaningful amount of native GUI development a decade ago was velocity. The developer experience with iOS is probably about the best of the major GUI platforms, but even that is rife with tarpits of tribal knowledge and gets really complicated to release an app due to the whole App Store experience.

View on HN

I don't think I have ever witnessed a comment on Reddit, prefixed with "Unpopular opinion:", that did not actually contain a VERY popular opinion, and therefore rocket to the top of the thread thanks to reverse psychology upvotes.

It's depressing to watch this trope start to bleed over into HN.

Problems with the prefix aside (I'm not a fan either) Reddit does it's best to show you popular comments. If you go looking in the -10 through 10 range on relevant threads you'll have a decent chance of spotting them. Not "controversial", not "top" (or bottom of "top"), not "hot", just the 95% of comments that aren't driving engagement numbers.

After all it's neither going to be popular because it's a popular sentiment nor is it particularly likely to be something interesting/relevant to get upvotes on merit. It's just going to be an unpopular opinion that gets ignored.

https://en.wikipedia.org/wiki/Survivorship_bias

You are less likely to read the truly unpopular opinions but yes I agree, seems like a cheap way to gain popularity.

Well, it's at least a controversial opinion even if it also maintains popularity. People seem to rag on Electron apps all the time on HN due to their inefficient usage of computing resources. However, they are an optimal use of developer resources, which are far more constrained for the average project.

Also the phrase seems close to breaking the guideline against commenting about the voting on comments, and is a boring meta-comment that just adds noise. It seems like putting up a preemptive umbrella.

You're taking about wrapping a boilerplate ridden platform in another boilerplate ridden platform where someone else wrote either boilerplate. You're talking about a browser without window dressing. That's not making an app nor eliminating any boilerplate.

I'll also add that you lose most of the benefits of a native app and most of the benefits of a web app.

Well.. people around here love to hate on Electron so I can understand thinking it's an unpopular take.

But seriously Electron is so many times better than writing native apps .. or even trying to find the documentation for how to do _one single thing_ in a native app the way you want to.

Getting started in the web ecosystem involves a lot of similarly impenetrable "magic". There just isn't a community built around creating project templates and creation scripts and such for lower-level programming.

I'd say you're right about the GUI shitshow, and the web ecosystem is just a slightly different kind of shitshow.

Absolutely.

There's a huge amount of tiny chores with web development, that if you hadn't learnt how to do them in 1.5 seconds 5 years ago, would take you 2-3 days to figure out.

There are a hundred small chores that must be done to build and launch software on the web that you have to learn before you get it going.

I strongly doubt desktop doesn't have the exact same volume of inane things as webdev.

I second this. Further, the number of times I’ve tried to get into native development is about ten, and every time I’ve done it the APIs are completely different as the OSes have moved on to new ways of doing things. Meanwhile, the DOM APIs have been more or less the same since I learned them 15 years ago, with the oddball world-changing addition of querySelector or enhancements that people rarely use like Shadow DOM and filesystem API.

The APIs for cross-platform native GUI development haven't changed in any significant ways in 20 years or more.

If you insist on using the new hotness being offered for any platform (web, native, whatever), then sure, you're doing to see this. But in the web context, you reference the DOM APIs that are stable ... in the same way that Qt, GTK (or even Cocoa) have been. New APIs for web dev show up monthly, but you apparently manage to not keep switching from one to the other. Why would you do the same thing for native dev?

Qt isn’t a native API. It’s true that there are stable libraries like GTK or WxWidgets which allow you to write native-looking apps (or for Linux, I spose that is native, and granted, Linux probably has the best native dev experience), and those exist in the form of React et. al. for the web world.

But the number of Windows native app APIs is insane, and every year I try to learn how to create an XCode basic app and it’s different. Creating a simple app with HTML and JS however is the same as it’s always been.

I use the term native to mean "an application that runs on the metal and has direct access to system calls, not in a VM of any kind, including a browser".

Qt is native in that sense, just as much as any other toolkit designed for the same purpose.

> every year I try to learn how to create an XCode basic app and it’s different.

https://ardour.org was first ported to then-OSX in 2006. Almost nothing in the codebase that relates specifically to now-macOS has changed in that time.

XCode is a tool, not a platform. Cocoa is the platform, and it changes very little and very infrequently.

This is irrelevant in terms of developer experience. I’m sure it’s possible to maintain an existing app for years and years, but if every blog post in existence is written for a different version of the development environment (which are vastly different from each other) and the OS Vendor (Apple in this case) is deleting or never even producing documentation on these APIs, which definitely happens, the rot is too much to keep up with for people trying to learn the system.

One of the jobs of a software developer is to understand that companies that produce proprietary systems (such as Apple) have their own incentives that do not always align with the desires and needs of those creating software. Put simply, this means that you do not trust those companies to do the right thing for you, and instead you need to identify what level of their technological offerings seem most likely to represent the correct entry point for you/the project.

When we first ported Ardour to OSX/macOS, it was abundantly clear that XCode was a non-starter in terms of technology, partly because it was single platform, and partly because its scope was too large - as Unix-based developers we understood the merits (and occasional pain) of more modular toolsets. So I found a handy guide to writing "nibless applications" that completely removed XCode from the picture (along with some Cocoa boilerplate code that isn't actually required). As a result, we've continued to interact with the stable API core of Cocoa, even as Apple dither around the edges.

Apple (and Microsoft and .... ) are not your friends. They want you to build software for their platforms, but beyond making that possible in some way, their incentives do not align with yours in any substantive way (partly because they make software too, and have their own API goals and needs that may/will conflict with yours). If you don't understand this, you're inevitably going to have the sort of experience you describe above.

I don’t disagree with anything you said. If anything, it just supports my point that native development is needlessly hard. Again, none of this has been true of the browser vendors. They have every incentive to get people to use their stack and make it nice.

By the way, a blog post on how to create Nibless apps would be invaluable.

Not sure about browser vendors and their stack. I almost never hear of anyone who develops on a browser vendor's stack, they use 3rd party tools in JS and CSS and webasm etc ... After Node wrapped up the DOM and put a bow on it, it seems that people move on (up? down? sideways?) from webdev at that level (except the people developing alternatives to Node).

I'm not sure if this is the source I used, because the date is a little late, but it seems very thorough and excellent:

http://lapcatsoftware.com/blog/2007/05/16/working-without-a-...

Cocoa is quite stable, I can vouch for that. So much so that I was able to resurrect an open source Mac app originally written in the early 2000s over the course of a weekend. Some changes were required and there were a bunch of deprecation warnings, but it worked and could’ve been cleaned up pretty easily.

I haven't touched GUI development for many years but 20 years ago I was able to learn Turbo Vision and create a simple TUI app having very little programming experience. A few years later I was using Java AWT and It didn't took too much time to learn it too. I cannot create a WebApp or even an Electron app of similar GUI complexity without spending much more time.

Native GUI is more cplicated nowadays too, but I don't expect it to change too much - controlling layout using CSS+HTML is harder than in most (if not all) native GUI frameworks.

Cannot agree more. I have used like 20 Native UI Toolkits ( MFC,WxWidgets,QT, WinForms, WPF, VCL, Android, Jetpack, SwiftUi, GTK, and the list goes on ) i have even written one myself ( for in game uis )

I still cannot comprehed how we ended up with the shitshow that is CSS/HTML. Even Javascript nowadays is a workable language ( or otherwise typescript ) WebAssembly is great... but the actual UI Layer with the DOM and CSS .... just a nightmare

Every time i have to work on something a bit more complex on the browser, i ponder of writing my own UI Toolkit based on Canvas/WebGL or WebGPU and just draw everything myself

Flutter for Web is doing exactly that. For some webapps, this might be a great way to go.

The performance of flutter on the web is unusable, I would be ashamed to ship an app using it.

What other framework doesn't maintain 60 fps in its hello world?!

Flutter works great on mobile and desktop though, I shipped multiple apps using it and currently writing a desktop app.

I am not sure, Flutter is still using DART ? That's a pretty big no go, last time i looked DART was a haphazard clone of Java/C#/Kotlin with no discerning features of any value.... I rememember when it was supposed to be the new Javascript (transpiling and big dreams of landing a native Dart VM in browsers )

For me its a no go to have a language that's bascially a dead end outside of one specific ui framework.. Seems like a solution in search of a problem.

I don’t have the patience or interest in messing with GUI frameworks anymore.

Any desktop app I make that needs a GUI gets written in Java. Swing is antiquated but doesn’t change every year like everything else keeps doing. I use an XML UI definition language (Swixml) to make it RAD. With a modern look-and-feel package it looks great, runs fast on modern hardware, works the same on Windows/Mac, is easy to deploy, and most importantly: I know it will work basically forever.

> see if you can get this webapp running in electron, and maybe figure out how to do push notifications and save data locally. Two days later the project is done. A week later, the app is ready to install.

So you had an app that was already written, ported it to electron (designed to make the port as painless as possible), and you note that this is easier than writing it from scratch with non-web APIs? This is not exactly suprising, is it?

So true. I don't think it's a surprise for anyone that developers experienced in web technology find it easier to make apps using the thing they're experienced with.

In a parallel universe, a junior dev who only learned Qt would have same amount lot of trouble making websites.

Maybe, but there a lot more web programmers than Qt programmers, so chances are you going to be dealing with someone who knows the web and not Qt.

> So you had an app that was already written, ported it to electron

True, and had we tried to port to native, that intern would have given up. Most of the business functionality was in a REST api, so porting to native was something that was doable, but the level of effort would have been extreme. Oh, and had we wanted native on Mac, Windows, Linux, Android and iOS... well... that's 5x jumbo right there.

As a general remark, I get confused and maybe even a little irritated when people conflate Android & iOS with macOS/linux/windows. I mean, a device that you interact with almost entirely via (multitouch) and generally has extremely limited display real-estate is fundamentally a totally different platform than a desktop computer. The interaction model, the display design... you're never going to want the same thing on both (unless what you want to do is extremely constrained).

You can sort of kind of pull this off with a relatively limited web app, where the interactions are limited to tapping (since there's generally touch interaction on the desktop) and the fluid layout possibilities of modern CSS give you some chance of coming up with a general design that can work sort of kind of OK across all browsers on all platforms.

But try this for a more complex app, the sort that has been traditionally desktop only, and I think it's extremely hard to design the GUI in a way that can work on both mobile and desktop platforms, regardless of the actual toolkits /technology you are willing to use.

> As a general remark, I get confused and maybe even a little irritated when people conflate Android & iOS with macOS/linux/windows.

Android and iOS represent the majority of devices your software can be run on. They are ubiquitous, and also very dependent on a native UI frameworks that are a somewhat better developer experience than their desktop counterparts, but only because the years of accumulated cruft are less. Incidentally, Android actually does have a desktop mode for it's GUI. That said, users rarely use the desktop Android GUI.

> You can sort of kind of pull this off with a relatively limited web app

I've had better luck with electron and PWAs on the desktop than non-native mobile tooling. This is largely because non-native mobile frameworks often don't have access to the same libraries - or the abstraction layer loses fidelity in trying to be cross platform. There's really no QT grade multiplatform tooling on mobile. There's some promising starts.

> I think it's extremely hard to design the GUI in a way that can work on both mobile and desktop platforms

It's hard to get a decent GUI on both Android and iOS that doesn't have a lot of rough edges with cross platform frameworks. They are coming along, but it's still just not quite there yet.

I'll concede that native GUI development is tedious on pretty much every platform in existence. However, there was a golden age of Linux GUI programming that spanned from the mid 2000s to 2019, where you could spin up fantastic GTK interfaces in the span of a weekend afternoon. I still use GTK3 to make simple forms and utilities, and I reckon I will for quite a few more years; the workflow is flexible and straightforward, there's a ton of fantastic desktop widgets that work as well as they do on a touchscreen as they do with a mouse, and it was surprisingly extensible too. GTK4 has seemingly put that behind them to focus on a "write your app in this specific way or don't write it at all" ethos, but frankly I'm happy to stick with the prior toolkits. Maybe it sounds cheesy, but it really was my "ideal" GUI library for a while.

Yep. Getting started on the web platform is honestly still a marvel to me and unmatched after decades. Sure you can use babel/webpack/vite whatever, but you can also still create a text file called app.html, type your little program into it and then double click to run.

I recently switched to Fedora and discovered that it's straightforward to create native GUI apps for Linux these days: just use GTK+ with your choice of official binding (C, JavaScript, or Rust) and you're done. Things are well documented and generally easy to set up, at least in my limited experience.

Flatpaks make distribution a non-issue too.

Not sure this is a very 'unpopular' opinion ...

The size of node_modules and the compile times beg to differ.

Have you tried the Mac?

Reply on news.ycombinator.com