by Aaronn on 9/2/21, 11:28 AM with 92 comments
by ryandrake on 9/3/21, 3:42 PM
The solution that has worked well for me in the past, has been:
1. Keep all of your business logic and as much of the rest of your code as possible in platform-neutral C or C++: Something you can call into from all native platforms.
2. Write a very small layer of code using the native language/frameworks to do the UI and interact with platform-specific APIs.
This has a few advantages: You get a single code base, for the most part, to maintain. You have the opportunity to implement as native a look-and-feel as you want, on each platform if you want. Most of your application is C or C++ so you don't need a team with deep expertise in multiple languages. Most of your development should be on the business logic, right? This architecture also lets you easily add a command-line version of your product, for example to help with automated testing of your business logic. And finally, you don't have to ship a huge, memory-devouring browser and JavaScript stack with your application--your users will thank you.
It's not rocket science or anything to be terrified of! I think people too quickly dismiss cross-platform native because they imagine re-writing their application in 3-4 different languages, but it doesn't have to be that way.
by Zababa on 9/3/21, 2:33 PM
I want to apologize to the few people that I talked to about this here on HN. I didn't understood your side.
by jagger27 on 9/3/21, 3:08 PM
Electron has made it possible to use a lot of apps that otherwise wouldn't have been ported to Linux work with no hassle, and for that I'm grateful. I have only recently been able to comfortably run Linux full time. My dev experience on Linux is effectively identical to what I do on macOS: Docker, VSCode, Alacritty, and Discord (to talk to my team). Of course Discord and VSCode are both Electron apps, and Docker just lives on the command line. Alacritty, on the other hand, is an extremely interesting example to me, as it is a true native program that uses cross-platform GPU acceleration through OpenGL. I feel that route is overlooked as a path towards compatibility for a lot of programs outside of games.
by 10x-dev on 9/3/21, 3:48 PM
I suspect that hiring and training cross platform developers, then having them own a feature across all platforms will significantly increase speed of delivery of that feature. These are typically called feature teams and they are most effective when there are backend developers on the team as well.
The trade-off is that now the new feature teams are not communicating between each other and coordinating on the common code between them, which starts affecting productivity.
In the end, regardless of how the new VP of engineering likes to split the teams and get praised for solving the current problem by introducing another one down the road, the trade off for increased size is loss of productivity due to synchronization overhead between the people involved.
by travisgriggs on 9/3/21, 3:25 PM
If this is the case though, why when I follow links to strong web apps like Twitter and reddit and Facebook, do I got plagued with “try the app! It’s better!” prompts?
I developed/maintain 2 apps that both have native variants. So 4 apps total. And I often bemoan the duplicity and wonder if we shouldn’t unify them. But then I see that the web guys are still pushing me to use native apps. I find it very circular/confusing.
by munificent on 9/3/21, 9:12 PM
> “What is it about enterprise companies that make so many of them abandon native apps, when they could surely afford to develop one app for each platform?”
Another way to think about the article's thesis is that organizations never deal directly in simple "costs", like "Can I afford to spend X on Y?" They always evaluate in terms of opportunity cost, "Would I rather spend X on Y or Z?"
Once you frame it like that, you realize that the choice between native versus cross-platform is, as the author states, often a choice between fidelity and velocity. And in today's software environment where hardware and user needs change very quickly, velocity often wins.
by vemv on 9/3/21, 2:38 PM
by pantulis on 9/3/21, 8:40 AM
Counterpoint: multiplatform frameworks are web-based and thus are easier to learn and have more developer mindshare than native frameworks. But native frameworks are not that much more complicated these days and can use proprietary services: would you roll your own sync or use CloudKit?
by api on 9/3/21, 2:31 PM
Look at this heroic effort by a single developer:
https://github.com/andlabs/libui
It's not there, but it's probably too big of a project for one person.
by stkdump on 9/3/21, 2:56 PM
by Ericson2314 on 9/3/21, 2:50 PM
by rkangel on 9/6/21, 10:12 AM
It's continuously astonishing to me that there isn't another workable UI platform that doesn't require bringing a whole browser. Or is the HTML/CSS/JS UI the killer feature because you can share things with the browser implementation (or share skills with a browser frontend team)?
by SavantIdiot on 9/3/21, 4:06 PM
by PaulDavisThe1st on 9/3/21, 4:59 PM
First, I'm not even sure I understand what the author means by "cross-platform". At some point, he mentions Figma and Slack. What platforms are we talking about? Does cross-platform mean "web-based"? Lots of people use Figma's web incarnation ... is that cross-platform? Or is it cross-platform in its "native" Android/iOS apps? More people use Slack in it's app-based incarnation (probably), but those are not implemented with the same tools as the desktop version(s).
I suspect the article suffers from the myopia often on display here at HN, in which essentially all software development involves some datastore, a means of entering data (often by one set of users) and a means of display the data in various ways (often by a different set of users). This used to be called "application development" in the 1980s, and these days there's a lot of writing about s/w development (and a lot of comments about that writing) which seems to be based on the idea that this the ONLY kind of s/w development there is.
This vision excludes most "creative" software, all gaming software, most development tools, a great deal of technical/scientific computation, a large amount of automation software, and all actual computing platforms (kernels & user-space environments).
Those of us who have been doing native desktop application development for decades have an entirely different take on this stuff from people for whom "cross-platform" means "web, android and/or iOS". We're not "more right", but we know about toolkits that work on macOS, windows and linux (gasp!). We've been compiling our software on multiple platforms for a long time, not relying on interpreters and VMs. We've had to grapple with packaging and runtime library questions for longer than web browsers have existed.
Electron has got a group of people excited because it appears to move web-based development approaches onto the desktop, which is a totally different model than the one taken when using a cross-desktop-platform toolkit. It doesn't add to the list of such toolkits, it creates a totally different approach to tackling the problem, with the promise that the result could also be used for a web-based version, somehow.
In my case, having been developing a "creative" application for 20+ years that runs on windows, macOS and linux via a cross-platform GUI toolkit (and C++), switching to a model that included web front ends (e.g. Electron) let alone mobile platforms, would be even more disruptive than just switching to another of the existing desktop cross-platform GUI toolkits, and in that sense, it's essentially a new development process entirely.
by stephc_int13 on 9/3/21, 11:44 PM
It is perfectly possible to do both.
You don't have to use something like Electron or even Qt to make cross platform apps or games.
by d--b on 9/3/21, 2:33 PM
Video games are cross-platform and polished and fast and they have been so for a while now.
When someone comes up with a Unity for desktop applications, that's when this problem is going to go away.
I hope Sciter.Js is going to be it.