We already have cross-platfrom UI engines called browsers and they're very advanced and reasonably pleasant to work with these days. If you bundle the browser (electron) then you don't have to worry about differences between browsers. So electron makes plenty of sense to developers, even although it's an egregious resource hog.
I get the popularity of electron and other cross-platform tools for small startups, but for Microsoft..
Having done exactly this work it's really not as simple as throwing 5x as many people at it.
Though to be clear, I am an advocate of native apps on each platform and am not a fan of "wrap a webview around it" type fake-apps. That said, we need to be honest about level of complexity here.
The problem with maintaining 5x native apps is not just the cost of hiring 5x as many people - as you scale towards more platforms the inter-team coordination overhead increases exponentially.
The complexity of coordinating 4 teams to ship in lockstep on 4 separate platforms isn't double the complexity of 2 teams on 2 platforms.
There are a bunch of intersecting factors here:
- product management has extreme load - new features need to be designed for every supported platform at the same time, increasing complexity in feature definition. Some features aren't possible on some platforms, so that increases scope and complexity of the features as we include fallbacks or exceptions.
- engineering has to happen (roughly) in lockstep with one another. It's not acceptable to ship a new feature only on Windows and not Android - they don't have to launch on the same day, but neither can they launch a year apart. This means you have multiple engineering teams that basically have to move at roughly the same speed, even though they are developing on completely differently platforms.
- underlying platform changes affect your ability to move in lockstep - iOS and Android both have significant yearly updates that create additional testing needs. Both platforms also introduce more significant OS-level features that you want to add support for than the older/more mature platforms like macOS or Windows. This throws another wrench in having your teams progress in unison.
There are real advantages to cross-platform frameworks, even though I dislike them from a UX perspective. In particular I have beef with the use of web views, which while offering incredible consistency between platforms is probably the least CPU/RAM efficient way to do literally anything. A huge part of why computers feel slower than ever is the pervasive use of web views for everything.
I really, really wish we had a better cross-platform solution than a thing with an ill-defined render cycle, bases literally all rendering on an XML-like structure, and has all processing stuck to a single thread on an interpreted language. Yikes.
For example... Gamestop's market cap did this recently - https://www.macrotrends.net/stocks/charts/GME/gamestop/marke... - the company doesn't suddenly have more money to spend on projects.
Microsoft generates more money than they know what to do with so they return large amounts in dividends and probably stock buybacks (I haven't checked for MSFT specifically, but it's all the rage these days.)
That's essentially the opposite of what GME did.
That aside, they also have lots of products and teams and some have more budget and resources than others.
Saving some memory usage in teams for more than double the development costs, is probably an unattractive position for that team. It also makes it hard to keep features consistent across platforms (as it is, teams struggles with that!)
- DOS 4.0
- Microsoft Bob
- Windows ME
- Windows Vista
- JScript
- MSJVM
- Zune
- Eliminating all/most easter eggs
https://www.infoworld.com/article/2612971/microsoft-s-13-wor...
You can make many, many mistakes as a giant company, so long as they're not fatal. ;-)
The platforms are fragmented and the user pays the costs of that in the end, one way or another.
If you hide it by increasing development costs, the price of the app ( or amount of ads or premium only features) must go up to compensate and the user pays the cost as well.
Edit: downvote all you like, there is still no magical solution.
That's typically the smart choice.
Why are we pretending in this thread that there aren't any cross-platform toolkits?
Using that is an entirely valid trade-off between "putting a webshit in its window" and "you have to develop 10 separate native apps".
Those are pretty sucky by comparison to both web and native and they don't feel native.
The problem is not that cross platform toolkits don't exist, it's that they're aren't any good enough.
Also why are we pretending in this thread that it's impossible to write electron or web apps with more reasonable memory usage? Look at vscode.
Electron, as much as I hate to say it, is one of the best options available.
It must be very hard to write Electron apps with more reasonable memory usage if VS Code is the sole example anyone ever has.
Sublime Text is my reference for reasonable memory usage and performance. VS Code doesn't measure up.
I'm not aware of any cross-platform toolkit that works on windows, mac, linux and the web aside from, well, a browser.
> Using that is an entirely valid trade-off between "putting a webshit in its window" and "you have to develop 10 separate native apps".
People don't want to pay the cost of native apps, they want to be able to use apps everywhere and have new features often.
I just opened a couple of Swing programs on macOS. Other than not having dark mode, I couldn't see any major difference. I can't check it on Windows right now.
So, no, I don't live under a rock.
Someday we compile to WASM and have UI rendering on top of WebGPU?
Mac and iOS are relatively-straightforward, aren't terribly different, and share development resources.
Android (Kotlin) doesn't often lead to suicidal ideation.
Windows is meh.
Linux is so-so.
> So electron makes plenty of sense to developers
To mostly front-end developers who don't know much about the world outside of a browser.
> , even although it's an egregious resource hog.
Violating nonfunctional requirements to be usable, performant, and efficient.
Just for the record I'm a senior backend developer, who sometimes operates at CTO level in startups, and I suck at front-end development. But still electron makes sense to me. Or react native if it's mobile only.
The state of cross platform development is pretty bad.
Cross-platform development will never be improved by N-times duplicated effort of abstraction layers on-top. The best that could happen is for OS developers to agree on common interfaces like UNIX/The Open Group for low-level operations, but for high-level media, UI, and common native development APIs more integrated than a patchwork of libraries like Qt, LibUV, etc.
I've worked on nuclear reactor simulators in F95, embedded industrial GPS equipment, deadline-oriented ad server meta-mediation, Fortune 500 client-facing consulting, compilers, functional programming projects, and now earn a paycheck doing SRE/PE since it's easy money to fund side-hustles.