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.
In "creative" applications, the term "business logic" is sometimes hard to use, but accepting it as "stuff unrelated to the actual user-interaction" ... I can say that in Ardour (a cross-platform DAW), the UI is ALWAYS by far the hardest component of everything we do, and takes far more lines of code than anything in the backend (roughly speaking, where the "business logic" lives).
Some native apps on Android/iOS do exactly this, with UI coming from Web API calls.
I think a big limitation to this approach is actually finding (competent) C++ devs who are willing to work on mobile, otherwise it works really well.
But still, it is much enjoyable than using any other framework that adds even more layers to the puzzle.
This to me is the big win of Webassembly: you can compile with gcc/Clang to target it as well. It makes the browser another “native platform”
I actually agree and chose C++ as well, but eluded that part of your quote because it could be a more general choice than just those two.
I want to apologize to the few people that I talked to about this here on HN. I didn't understood your side.
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.
* text entry
* file browsing & selection
* menus
* list/tree views
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.
I would never organize a business like that again.
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.
> “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.
For example foo-2.3.1 when distributed over npm is not guaranteed to match its source over github.
Here's a popular piece explaining various plausible scenarios https://medium.com/hackernoon/im-harvesting-credit-card-numb...
(npm is not different from cocoapods I guess... except that npm dependency trees are famed for its size/depth)
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?
CloudKit is definitely satisfactory, but it's limited to Apple devices.
I don't know much about the space, so I may misunderstand the following technologies, but I wish more apps used P2P protocols like IPFS, Hypercore, etc. to keep my devices in sync with an optional pick-your-own-cloud-backup as well, so I can just use Dropbox, Google Drive, OneDrive, etc. The latter seemed to be pretty popular amongst developers for syncing (i.e. pick your cloud backup service) not too long ago and while there's still apps that do this, like Notability, I don't know why so many developers moved to rolling their own sync.
That was my point, exactly. If you target only specific platform users, easier development (ie, using Electron and web technologies) does not necessarily win over native frameworks because now they are decorated with powerful vendor services.
Obviously if your target is multiple platforms, you are now on Electron land. That's not a bad thing per se, though.
Sync is great for justifying a paid subscription model
Qt, GTK, FLTK, JUCE, NTK, libui are not web-based.
I think that there's more than one definition of "multiplatform" floating around here.
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.
I mean, just take a single subset of functionality like handling multi-touch input. It's probably an hour or two to read through the Pointer Events[1] spec until you get a better idea of why that API was designed the way it was. Now imagine coming up with such a design after at least dozens of hours studying the limitations of prior APIs (but probably more than that). And now, imagine either a) conceiving of and implementing that design (at least dozens of hours, probably way more), or b) cloning that design (still dozens of hours to implement).
Now compare to the minutes it takes to read a tutorial and start using the API in a browser that probably already runs on probably any modern device that has a screen.
That's just one cross-platform API, and probably not in the top ten to implement first.
I am no expert, but my understanding is that it's easy to get to 75%, but extremely hard to get to 100%, or even 95%.
Not to mention that there are some differences between layout and navigation idioms on different platforms. Making an app truly native is not just a matter of using native widgets.
I do wonder if there is mileage in building an abstraction layer at a much higher level than a widget toolkit. Imagine being able to write a very abstract description of your app in some DSL, saying what screens it has, how they are linked, what information is on each one, and then having tools to compile that down to appropriate native code.
I don't think that "success" here is particularly well-defined. There are lots of Qt-based applications running on multiple platforms with a single codebase. That could easily meet a fairly strong definition of "success".
The components are just one part of what makes up a UI. Different platforms have different conventions of how they are used on a higher level, and how everything fits into the rest of the platform UI.
The web is a pretty damn good distribution method for software. The user simply clicks a link and is provided with valuable features. No install process. No IT approval process. No thought at all, really, about how that code runs on their machine and does things that are valuable to them.
Frankly - We're still inching towards the browser being the OS. I don't want a clunky app that needs to be installed on all my devices, and which has a limited feature set compared to the web: I just want the website.
And for the vast majority of "productivity" tools - networking and sharing aren't backseat things, they're literally the most important part of the product (see Figma, for example)
---
Long story short, you're saying this is a "problem to correct". I disagree - I think the problem these tools are correcting is that native distribution methods (up to and including the current mobile walled-garden app-store fuckery) simply suck. They suck SO much compared to simply opening a Url in a browser.
... that can and does run inside a browser. There's a wide-world of software that doesn't run inside a browser right now, and some serious arguments about why it probably never should.
That's where the problem lies, not with yet another app/web-page that provides you with a view of some database columns and rows.
It’s still a great way to deliver certain kinds of application, but we need an alternative.
A huge issue of free software under capitalism is it's really hard to sustain more than one way of doing things. And so we got monster metastasized too-big-to-fail Linux, Chromium, etc.
The goal of any company is to provide a useful service/product, not necessarily a “native” app to satisfy HNers.
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)?
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.
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.
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.
I switch between computers often, and I am happy that my spotify looks the same here and there. I really don't want my spotify app to feel like gimp on Linux and like Excel on Windows...
For desktop applications — especially a password manager whose main use involves switching to it quickly to find something to enter into a different application — there is a lot of that resistance when you go between apps that feel totally different.
(I currently work on an Electron app — but that's because it was already one when I joined the team, and it's in a space where time to market for multiple platforms is definitely more important than a good polished experience, at least at the stage we're at. Sad as that is.)