The main problem is that Microsoft is trying to use a WebView. If they really want a single cross-platform app, they should develop a native framework that will work everywhere instead of shoving everything into a web engine.
back
8 comments
The web browser is a native cross-platform GUI framework that works everywhere -- including on the web. It's the best and most used cross-platform GUI framework that has ever existed. Why should Microsoft roll their own solution? Nobody has ever been able to make this work outside of the web browser.
>It's the best and most used cross-platform GUI framework that has ever existed.
Just because it's the best on that has ever existed, doesn't make it good. It's just the least bad.
>Nobody has ever been able to make this work outside of the web browser.
Sure would be nice if everyone would give up then and we could go back to having nice, native apps using native controls, file operations, encoding, hardware access, performance, UI/UX patterns, and security features, instead of letting all that rot on the vine while we reinvent the wheel on the browser.
We are absolutely reinventing the wheel on the browser but in the end up we have single broadly compatible platform across devices both small and large, with multiple implementations, and mostly all open source. It runs completely untrusted sandboxed applications. The browser is the ultimate OS for anything that doesn't require raw performance or deep integration.
People have been trying to make that since the dawn of computers. But designing something like that top-down has proven virtually impossible to get right. Building it bottom-up like we have with HTML, CSS, JavaScript, and now even WASM ensures that what gets built is actually secure and practical. It might not be pretty but it works.
Even performance, which is the number one criticism of electron apps, is something that can be solved. When you Microsoft looking at making the webview a common reuable component again, what is native between something like WPF/XAML and DOM/HTML is merely a matter of perspective.
> Just because it's the best on that has ever existed, doesn't make it good. It's just the least bad.
The web browser features a set of technologies that are standardized across a wide array of different implementations. Except for a few minor differences, you can view a website in Safari, Chrome, FireFox, Edge, Brave, the list goes on.
It's a technological wonder. I'm still amazed people hate on it.
There are three implementations you’ve listed for actual rendering: WebKit, Blink, Gecko. And it’s unlikely we will ever see another due to how complicated they are to build. It’s been becoming less diverse for almost two decades now.
And you’ve ignored the fact that every web view we have had on desktop so far is kinda crappy and sluggish when at least well built native apps generally feel snappy.
Webviews are one step about shitty Java apps (you know the ones) in terms of UI.
Beyond that there’s the RAM usage.
Be no longer amazed that people can have these problems which no web app they have used has overcome on three or four different computing platforms.
Wrong - I can use Qt and QML to make an app that compiles and runs, unmodified, on Windows, macOS, Linux, Android, iOS, and others. It can even run on web with WASM. And I wouldn't call web apps "native" or "the best".
> I can use Qt and QML to make an app that compiles and runs, unmodified, on Windows, macOS, Linux, Android, iOS, and others.
As someone who is currently working on several QT apps that also work on mobile: That's an absolute lie. You need a lot of extra work to get it to work on both the desktop and mobile. Realistically you have to build the UI twice, QML is nowhere near as "responsive" as html/css. It's also prone to sluggishness.
I stick with Qt because I enjoy working in C++, it's just simpler to have the whole app in one language. My users also told me they dislike electron like you. But it's very disingenuous to tell people that Qt is "just as easy" to build desktop/mobile hybrid apps, they'll be sorely disappointed if they take your word.
That may be your experience, but for the right kind of app (e.g. simpler apps) I can confirm from experience that apart from setting up the Android app manifest, Qt apps don't need modifications to port, especially if you design convergence in from the get-go.
Developers want to take their web applications and turn them into desktop applications, not the other way around. The web is the master platform.
Qt has had decades to win over this space and failed. Github slapped Chromium together with Nodejs and took over the entire market of cross platform GUI development overnight.
I might not like it but I understand it completely.
>Why should Microsoft roll their own solution?
Because they're fucking Microsoft. Mutilated websites posing as apps are for hobby projects. They're in charge of the vast majority of desktop operating system interaction, if my pitiful 17 dev company can write all-native programs, so can they.
What I don’t understand is why the Electron-based desktop application is so bad, but the web client isn’t. Somehow they can make a usable web app but their all-webview client is trash.
PowerBI's UI runs off of WebView and it's the most frustrating thing. That whole software feels like someone mashed together different colors of play-doh and called it a new one. There are multiple ways to do the same thing within the software, but they have differing levels of efficiency. It's a Frankenstein's Monster of technologies bundled up into this lacking visualization software.
Don’t most Microsoft products feel that way? I’m occasionally forced to use a windows machine the office gave me. Windows 11 is a new kind of janky and it also packs all the fun stuff from earlier versions.
Anyway, they don’t care. Nadella has us all by the monthly subscripted balls.
>Don't most Microsoft products feel that way?
They really do. A lot of their products feel like a "too many cooks" situation where there's too many things being packed into a UI that can't exactly handle it. To make matters worse, the errors you get when something fails aren't too helpful and they are used across various Microsoft platforms. You have to always ensure you're looking for help on PowerBI vs PowerBI developer or PowerQuery.
They already have MAUI. I don't have direct professional experience with it, but the message I'm getting from those who have used it, is that it's cumbersome. With people instead just sticking with XF/Uno/Avalonia (Avalonia being closer to Flutter in how it doesn't actually tap into the platform's native frameworks).
Even if its cumbersome, it's still a win-win for them to use it.
The outlook app will be native desktop and mobile (except linux for now).
Plus it will give the maui project more credibility, help grow its userbase. Make the framework better by providing a real world project for the maui team to benchmark, highlighting pain point, provide in-house feedback, feature request.
I would be interested to know from anyone at the Office/Outlook team why they went with what they did, and if they had any awareness of MAUI happening at all. Fully agree with the noted benefits, so any non-MAUI team insight would be really interesting
Has the Office team ever paid that much attention to what Windows was actually recommending?
All the releases that I can think of shunned the standard UI toolkits for their own homegrown UI. Presumably to show the Windows folks that the Office team is it's own little empire.
My guess would be that they're looking for parity with web apps. I have teams installed on my corporate desktop but I just use the web application any other time and it's... identical.
If you want an identical experience with identical code across the Web, iOS, Android, Windows, Mac, Linux then there is only one solution.
Biggest issue with MAUI imo is the lack of a Linux desktop option, wether a wrapper over GTK, QT or whatever. There's been some effort, but MS is pretty much willfully ignoring it. Not that Linux desktop is huge, but it's approaching half of where OSX is and given the early adopter focus is for Developer, it's IMO a massive miss.
Cross-platform desktop apps, should at least cover Windows, OSX and Linux (appImage/Flatpak) as a baseline. Avalonia works well enough, but MAUI just muddied the waters. With the massive efforts towards web-ui in general, it's really not surprising that many devs/shops are just shrinkwrapping with Electron. Even if there are far lighter options for embedded browser usage of the system's browser engine. In the end, the state of desktop apps sucks all around.
it's one thing when third parties do this, and quite another when it's the operating system manufacturer. it's as though Microsoft doesn't want Microsoft Windows users to feel good about being Microsoft Windows users when they use their Microsoft software from within Microsoft Windows.
Microsoft appears to have stopped caring about how Windows users feel about using Windows quite a long time ago.
vscode is an Electron app and is great and more responsive than its "native" competitor apps from JetBrains.
Until you install the enough addons to VSCode to give it the same functionality JetBrains products have out of the box, then it gets slower.
JetBrains' IDEs are very heavyweight, it's apples to oranges. And while there is some native code in them, they're still driven by the JVM mostly. There is fleet, but it's not an improvement to vscode at all IMO.
How about vscode vs sublime, neovim, or any other native text editor with LSP support? vscode is slow comparatively.
VS Code is primarily an editor, while JetBrains's products are IDEs. You can add extensions to make VS Code more an IDE. And I'd like to see benchmarks proving your point. If you're using VS Code as an editor, others like Sublime Text, Notepad++, Kate and TextMate make it seem very slow.
If your definition of IDE is that everything has to be done using menus and that it needs to be super slow, you are right. If you look at actual functionality then VSCode is as much of an IDE as Eclipse.
I mean, it’s faster than Emacs on my Mac m1.
In fairness, the core of VS Code is really well-crafted highly performant code. It was designed to be fast and to work for a web integrated code editor from the start. After trying Atom and Brackets, I almost didn't touch VS Code when it came out, I'm glad I did decide to try it as I really do like it.
Of course most Electron apps don't have near the same level of effort or foresight when it comes to performance. Discord probably the second most common electron app, and Teams being third. Both of which, at the very least, have issues. Some could be overcome, or at least be more consistent with WASM built controllers, but that whole space needs some maturing and improved tooling. I've played with Tauri and Yew and think it's pretty nifty, but there's a lot of work to getting parity with say React+MUI.
React+MUI itself is pretty good. But even then, on a relatively large team with some relatively inexperienced devs, you can wind up with dependency trees that are insane, huge and slow. Taking that and going through the extra hurdles that the likes of Electron, Tauri or others add is burdonsome to say the least. It can be very nice, but usually isn't.
And while I empathize with the teams using Electron, I can even support the ideas. In the end, it's the outcome that matters. I'm not one of the never-electron types. But I also recognize the issues. I use Tabby for my terminal, which is fast enough, but still takes 3-4 seconds to load. I use VS Code which is usually a couple seconds as well. It drops off dramatically from there.
There are massive advantages a browser renderer offers... it gets all taken away by importing whatever library comes up in your npm search for any given thing.
> the core of VS Code is really well-crafted highly performant code. It was designed to be fast and to work for a web integrated code editor from the start.
Seems to me this is kinda the core of the matter. VSCode written by developers, for developers, working in the domain of...development. It's almost a labor of love at that point.
That's damning with faint praise, though, isn't it?
Is it? I'm pretty happy with vscode. I realize that if you actually measure responsiveness there are better options, but subjectively I'm happy while other "IDEs" are completely unusable for me (Visual Studio, JetBrains IDEs, Eclipse, ...).
There is simply no comparison between the two. Its like comparing MS Notepad with MS Visual Studio. Jetbrains IDEs are so much ahead of even Visual Studio.
All Microsoft needed to do is look to the Apple Music app to know how bad an idea building it on WebView is.
But, yeah, I wholeheartedly agree that they should either develop or use a native framework (Flutter perhaps?) rather than trying to shoehorn a technology that has never been very good for application development.
> All Microsoft needed to do is look to the Apple Music app to know how bad an idea building it on WebView is.
Teams.
Teams is just a horrible product overall. It wouldn't be better with a completely native app.
Coming back to this a week late but, MY GOD YES!
Name a native UI framework that enables seamless cross-platform deployment without extensive testing on each platform.
Go ahead, I'll wait.
Sure. Electron or similar tech are doing a very simple thing: they're externalizing development costs by transferring them to the individual users in the form of storage costs, performance costs, and user experience costs, to name a few.
Meanwhile, Microsoft is a behemoth. Your argument makes total sense for a small shop with limited bandwidth to test. Companies like Microsoft don't get that excuse. They're simply padding their bottom line at our collective expense, and they can do it because they have extremely sticky services in a lot of areas (in this case, corporate email infra).
There's two platforms. Two. Windows and MacOS. Let's not pretend there's dozens. Why does one have to jump through hoops for two simple platforms? Just write the UI code twice. It's not rocket science really.
Same goes for Android/iOS.
There are 5 platforms Microsoft wants to support: Windows, MacOS, Android, iOS, and Web.
These new Microsoft applications run on all these platforms identically across all these platforms and mostly with the same code.
Presumably that would at least double the cost. Additionally, you have to find native Windows and MacOS developers, which are harder to find than web devs. Given that, it's not surprising that companies are moving toward web tech like Electron.
you just mentioned 4. that's not 2, that's 4. And you forgot chromeOS.
Tauri is quasi-native in that it uses native WebViews. It ought to be the best of both worlds once we accept that web-based UI is the only way now
Does webui not require testing on each platform+browser combo? Or are we just accepting that sometimes it is going to break and not allowing the same consideration for native GUI frameworks?
One would expect Microsoft puts Windows before cross-platform.
Microsoft no longer seems to be in the business of putting Windows first. Since they're completely out of the mobile market, they're always going to have be a cross-platform software company now. They want to sell software subscriptions and that requires going to where the users are.
I’ll try, Flutter?
Flutter doesn't use native UI. It recreates similar UI.