Hacker News Reader

Comment by socialdemocrat | Hacker News Reader

Build native for every platform. The amount of work supposedly saved by using cross platform solutions is grossly exaggerated and frequently negative.

Most development time isn’t typing code but actually architecting the solution. You will go through multiple iterations to get your UX right. Lots of things like graphics, GUI mock-ups, database design, file formats can be reused.

In cross platform development one too often ends up wasting time on problems introduced by buggy layers on top of the native frameworks.

Every time I have compare my development speed using native tools vs a lot of the cross platform web stuff, native wins hands down.

But it depends on where your skills are. If you are more skilled with web technologies then your experience will likely be different.

View on HN

(Cofounder here) This is close to our thinking. Comes from seeing how at Dropbox we started with a cross-platform approach on desktop. While it meant that we could quickly achieve consistency, it also meant that we couldn’t use platform-specific tooling on any given platform, like debuggers, without a bunch of custom tooling to fight through the intermediate layers.

We want to try running small teams using the best stack for each platform.

As a user, I greatly prefer the "best stack for each platform" approach.

In fact, I'll usually take reduced overall functionality for a better platform-native experience.

I think many companies have a chicken-and-egg problem when it comes to cross-platform development. They already engineers for iOS/Android/Mac/Windows and there's established workflows for creating native apps for each platform, so cross-platform experiments are at an inherent disadvantage.

> You will go through multiple iterations to get your UX right.

For high-level UX flows, this is where cross-platform frameworks could have an advantage, because you can iterate without redoing the work for each platform. It might even make sense to use a web framework for the initial prototype and early user trials, and then reimplement in native for performance/details once it's finalized. As a bonus, if you're willing to maintain the web version you could use it as your browser-accessible version.

Good points. I think there are two reasonable options:

A/ use cross platform to iterate effectively

B/ choose to iterate on only one platform, then build out other platforms as your ux stabilizes.

We chose B but acknowledge it’s an unusual option, and there a 30% chance in our minds that we’re wrong /shrug

If operating system vendors wanted to, they could deliver APIs that resemble Electron, but with better OS integration capabilities without the performance problems.

HN loves blaming companies like Slack for shipping “crappy bloated electron apps”, but what we should be doing is demanding more from Apple, Microsoft, and Google to ship a sane APIs to make this work. Blaming vendors is essentially victim shaming.

Sadly I know that’s a naive optimistic pipe-dream because these corps would lose power over their user base.

I assume most people use React on Electron. Apple has SwiftUI and Google has Flutter.

Great, now make it so one code base can produce a working GUI on all platforms. Use any tricks you want — COM style binary interfaces, linking against platform libs with common headers, protocols like X11 or Wayland, a common “high level” API that can be transpiled to platform specific code and then natively compiled.

The “one code base” is allowed to have platform ifdefs, doesn’t have to be magically perfect and handle all edge cases.

Because this is table stakes for Electron, cross platform libs, and game engines. Getting Apple, Google, and Microsoft (because honestly if the others can agree Linux will just follow) to agree on something anything would be a huge milestone but I’m sure they would all see it as erasing their moat.

Reply on news.ycombinator.com