Hacker News Reader

... which means you have to write the application at least twice for mobile and at least three times for desktop.

On desktop nobody does it any more, not even big companies. Everyone just uses Electron or something similar. It's a worse experience for the user but it's not bad enough to be a major barrier to adoption in most cases.

On mobile I guess only two platforms is not quite as bad so more people cope with it?

> It's a worse experience for the user but it's not bad enough to be a major barrier to adoption in most cases.

One thing I don't quite get is why giant companies with zillions of dollars of recurring revenue just keep using Electron (other than the obvious reason that it's there and it works already), when they could massively improve the user experience & make themselves significantly less vulnerable to competition by building native applications.

I mean, I get that making native applications is really hard, and trying to keep feature parity between version is a huge challenge (indeed, the the point of TFA). But it's obviously possible & some large organisations do it despite the difficulty (indeed, even some open source projects run by volunteers have it figured out).

I think about this every time I use Slack & feel the janky horribleness every time I click around the interface and have to deal with all the latency of waiting for it to update. I get that average users might not notice this but anyone who grew up with native applications surely can "feel" it and despair.

They do it because coding a large UI project is brutally hard and money doesn't help that much. Building a new UI team is hard, hiring is hard, managing is hard, designing is hard, it's all brutal. Now do that 2-3X in parallel and manage that efficiently and ship new features on time.

Couple that with the fact that web devs are much easier to recruit than devs for any native platform and it's easy to see why they don't bother with native.

The real choice is (1) be single-platform (Mac only, Windows only, etc) or (2) use a cross-platform UI with Electron being the easiest to adopt.

Bang on the money.

I think a big part of what people perceive as being Electron’s fault actually comes down to how the app code is written.

Beyond the regrettable (but hard to avoid) baseline memory usage, startup time, and bundle size, at the end of the day it’s just a browser. Native code might be faster than JS on benchmarks but at the level of clicking a button to perform an action, there’s no technical reason that the latency should be any different, certainly not at the level of 100s of milliseconds. It’s just slow UI code at that point. I daresay the bigger problem is the huge prevalence of slow UI code.

It reminds me of this article on why NetNewsWire (a native Mac RSS reader) is fast - turns out it takes a lot of work beyond just being native! (and a bunch of these strategies have analogs in the JS world too) https://inessential.com/2020/05/18/why_netnewswire_is_fast

I think this is the thing.

Web apps get a bad rap, and justifiably so.

But the blame frequently lies with the bloated frameworks developers choose to use. Developers choose these frameworks because web development is pretty complex.

When done properly, light-weight responsive web apps can be smooth as butter and an amazing user experience.

I do think that it requires a higher degree of technical expertise and more development effort to achieve this on the web vs native, though.

In some cases, depending on the business model and audience, it's worth it.

Just the other day I did an experiment while writing a new Electron app. I created a Hello World -- once using React, and another with just static HTML & Vanilla JS. The React version, literally just the default Hello World page, was already noticeably slower and jankier at startup than the static HTML version.

Tack onto that experience however many NPM packages the average React app imports, maybe some hastily written synchronous calls that play fast and loose with your main thread, and it's not difficult to see why Electron and web apps in general get a bad wrap. It's not unavoidable, it's just lazy practices.

Yeah, and honestly I don't think it's even down to the framework all the time either, but some frameworks make it easier than others.

React, for instance, is famously the opposite of bloated ("it's just the V in MVC") and leaves it up to the user to shape it how they like. I think the trouble is that it's not really fast by default. You end up needing to be pretty careful to avoid excessive rendering, which in practice means thinking about referential equality a lot, and trying to make sure renders only happen when you mean them to. React can be plenty fast though, with care.

I think Svelte does a better job of being fast by default, and part of that is because it's more truly "reactive". Change a variable, and that specific part of the page is updated; if other variables depend on that one, then those parts are re-rendered too. It needs a lot less babysitting to avoid extra CPU cycles.

I've thought about this a bunch because I'm building a video editor with Svelte and Tauri. (Tauri is a Rust-based alternative to Electron that uses the system webview instead of Chromium). Of the things I'd expect to be hampered by being web-based, "video editor" is pretty high on that list! But I've yet to run into a performance problem that came down to the browser being just too slow. It has so far been something under my control, whether that's needing to optimize some canvas drawing, or finding the most efficient way to get video frames on the screen, or minimizing the messages I'm sending between Rust and the UI.

There are certainly inefficiencies that wouldn't be a problem with a native app, but it's been possible to work around them so far. And as the sole developer on the project, it's nice to be able to serve a larger market without having to keep 2 code bases in sync.

I like what I've seen of svelte, but it's going to be hard to drag me away from vanilla web components with lit-html as a renderer.

Super lightweight, blazing fast, and straightforward to develop with. Class property setters that call render() are the reactivity.

In some cases it does take more time to reason about lifecycle and rendering than the equivalent react component, though.

Slack used to feel better than it does now, and from my outside perspective it feels like most of the slowness that's started to happen comes down to lazier caching and slower back-end requests (loading conversations, etc)

From my experience the reason why these kinds of platforms get used as much as they do is that it follows the concept of the fungible developer. It is painful and expensive to find an iOS/Android/Win32 developer because the pool of skilled developers limited.

The promise around much of these frameworks is that any dev with web experience can handle these and become a cross-platform generalist. Faster and less expensive to find more/backfill developers and, most of the time, it won't cost anything in lost sales.

// tangential rant follows

The experience suffers but when you look at the tech landscape as a whole, there is little to no native application niche that is presenting an opportunity. Quite the other way, the prevailing trend is that everything is bring brought down to the limits of the OS's webview components. You even see this in, what used to be, pure native applications like office. One of the latest changes they're doing is replacing the room finder with one backed by a webview2 control. It sucks and is a lot less capable from the native version, but it is following the same path being charted by our industry.

> I tried the new hotness recently - Kotlin Multiplatform. Sharing code was great, debugging sort of worked but not really, and it wasn't long before I was pen pals with an overseas developer - no documentation on the bleeding edge! Ive been developing iOS for 10 years and my all-native workflow never relied on the mercy of a kind Bulgarian...

I honestly can't count the number of times I've been down this road - Alfresco, Hazelcast, Sencha Touch, a bunch of others I can't remember right now. People skills become very important.

Ionic has been a round for a while, good development experience, from what I can tell there are some good Ionic apps out there

Xamarin (MAUI now) is pretty decent and there are good apps out there (Bitwarden for example).