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.
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.
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.
Someday we compile to WASM and have UI rendering on top of WebGPU?
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.
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.
> Not a subscription—never expires
> Includes 1 year of free version upgrades
Are you telling me that a third-party slack client will keep working forever without updates? The "not a subscription" message here is effectively moot: this thing will stop working and you will need to pay for "another year of version upgrades".
It's not promising you to work forever without updates, but also it doesn't force you to pay if you're happy and everything still works.
Contrast this with something like sublime text: years from now you can still expect it to work normally.
What I expect is that if your app will not continue working for a long time then you should not make "lifetime license" one of your selling points unless you are prepared to offer lifetime upgrades too.
And it maddens me that their whole team, including ops and backend is like 50 people.
At the same time, they used some pretty unconventional ways to find brilliant people. For example, for iOS and Mac and android apps, they simply held a contest for the best open source app fitting succinct and reasonable requirements. The winner got sizable prize and place on the dev team.
Then they released that app as a Telegram X and then gradually sunset the older app.
Pretty neat on multiple fronts.
But that's how they get so much accomplished. Fred Brooks was correct in 1975 and is still right in 2021. Throwing headcount at a problem only delays it.
That's a huge understatement. When development tools improve and people get more productive, that observation gets more and more correct.
Thus, he is much more correct now than he was in 1975. And he was pretty much right by that time.
Don't get me wrong, I loathe Teams and its laggish bullshit nature as much as the rest of the pitchfork wielding people in this thread, it's just that it's not apples-to-apples comparison with a pure chat/call client and the headcount needed to develop it because of how much extra junk is hiding in Teams.
would call it more than just an "improvement", only using 1/2 memory is pretty freakin great when you're already known for hogging mem
But why?
'Native' is a tool, not a goal, surely?
What's the underlying goal you want to achieve, and do you really need native to achieve that?
Performance, small bundle sizes and native UI widgets. And judging by all of the Electron apps failing in these departments, I guess you really do need native apps.
Space are not precious anymore. Nor is bandwidth.
I get 60 Mbps down and an upgrade would be $50k. Bandwidth is relatively precious to me.
I would suggest that people are likely not attempting to use enterprise-grade collaboration software on these machines, so that's not a problem.
https://www.theverge.com/2021/5/17/22439924/microsoft-teams-...
Also, an application that runs constantly in the background, is under a greater obligation to make efficient use of system resources.
> judging by all of the Electron apps failing in these departments, I guess you really do need native apps.
I'd put that differently: solutions heavily based on web technologies seem to consistently fail to be anywhere near as efficient as solutions that use conventional toolkits. (Sometimes someone will suggest this isn't true if the web-based solution is well implemented, but they are never able to give an example of such an application.) On most platforms, Qt doesn't count as being truly native, but it's still far more efficient than Electron.
I don't know what Slack or Teams would look like with native UI components, but I am pretty sure I would consider it inferior to what we have at the moment. The possibly improved performance and memory footprint would be nice but not enough for me to care about.
People don't expect Google to look 'like Windows' just because they're on a Windows OS, they expect Google to look like Material apps across all platforms. There's not 'windows spotify' or 'android spotify' but they expect the app to look the feel the same everywhere, and in that way companies actually benefit from using Electron.
"Native" is the implication that a certain level of comformity is present: the user generally gets an experience that is similar to other native applications.
As you develop with native APIs, and when you follow the best practices for the platform, you end up with a product where the UX is much easier to grasp for the user. Non-native solutions very often have different UI/UX patterns, which leads to users having to learn these patterns before the application becomes understood by them.
This sounds like the goal you want to achieve using native as a tool.
But anyone who struggles to grasp non-native UI and UX is going to struggle to interact with the modern IT environment as there is no standard for web-apps.
Theoretically, there might exist a cup of coffee that achieves this goal. But I've never seen one, and if you serve me coffee it's almost certainly not going to achieve my goal.
Responds to user input quickly enough to not be frustrating.
It matters to sysadmins. Some people need to also work on the computer and when Teams uses all memory they will close it.
It's basically having a third-party forcing programmed obsolescence at your device.