Yeah, great move.
1) searching mails is much faster locally
2) OWA zoom plugin requires re-auth every time SSO times out
3) most operations take 1-2 more clicks on OWA (marking meetings pub/priv, editing a meeting, etc).
On the other hand I've not had plugins working on my native Outlook for several months...
I had hated Windows outlook for so long, I forgot that client apps can be good.
Here’s what I like: 1) cmd+tab for quick switching between email and other stuff 2) faster search using local storage (although I think this could be done in browser) 3) Persistent login not affected by browser state/cookie/whatnot 4) Keyboard shortcuts not mixed into browser shortcuts 5) speed
I think 4-5 could theoretically be fixed eventually in a browser app. But every single native wrapper over browser has had so much bloat that I suspect it won’t happen.
I also really like the native Mac mail app, but can’t use it with some email accounts due to security settings.
But there is absolutely no reason for a mail client or calendar to use gigabytes of RAM and have significant impact on battery life. Which is bound to happen if you bundle Chromium et al. and run the webapps in it.
VSCode also doesn't handle large files well, etc.
This underlying reason/trigger for this is the Windows team's failure to differentiate native apps in an attractive way. The flat look has been a disaster from a usability point of view, but it also has been a disaster from a differentiation point of view. If native Outlook app looks no different or better than the Web version then there is no longer any reason to maintain the native app.
For native apps to succeed over Web — and Steve Jobs has shown this can be done — it must have a differentiated look & feel, and users must find the look & feel attractive. The Flat look and feel meets neither of these criteria. Microsoft pioneered the Flat look and feel, and it has since been copied by Apple, which "proved" the wisdom of Microsoft's move. But it has been downhill for Windows native apps since then.
- Wait for WinUI 3, hope it’s good+stable enough eventually
- XAML Islands which I hear is super buggy and janky
- WinUI 2.x which constrains them to an AppContainer. Not gonna happen for an app as big+legacy as Office
- WPF which is on life support
https://github.com/microsoft/microsoft-ui-xaml/blob/master/d...
Here are some bullet points, that even I as WinRT believer have to acknowledge, please hold with me starting rant mode:
- Windows 8 broke compatibility with XNA/Silverlight model
- WinRT even though it is definilty a better COM, required 3 implementations on Windows 8.0 (phone, tablet and desktop)
- Windows 8.1 reduced that to 2 (phone/table and desktop) with UAP, and naturally a rewrite was required
- Windows 10, merged all models, renamed UAP into UWP, and naturally a rewrite was required
- Windows team not happy with .NET taking up of the Windows eco-system, botched Longhorn, doubled down on COM eventually leading up to WinRT/UAP/UWP, whatever you want to call it.
- Naturally they couldn't just reuse .NET runtime with added support for AOT, so Windows 8.x adopted AOT compilatio model from Singularity, followed up by .NET Native on Windows 10. In both cases, also incompatible with regular .NET.
- Similarly, C++/CX which was introduced for WinRT, the first time that Microsoft finally had a C++ RAD experience somehow comparable to C++ Builder, was killed by the Windows team pushing C++/WinRT with complete and total disregard for developer tooling, making those of us that depend on mixed code bases (.NET/C++) to feel we are back into the Visual C++ 6.0 days, manually editing IDL files in notepad and doing ATL like template magic. From their point of view, screw us, and we should wait until ISO C++23 for the Visual Studio team to be able to replicate in C++/WinRT the kind of tooling we were able to join in C++/CX.
- Project Reunion just got their 0.1 milestone one (yep not a typo)
- WinUI 3.0, although deeemed as the future native UI, won't be feature parity with UWP, only later the year
- .NET 5 isn't supported in .NET Native, and the roadmap between CoreRT, .NET 6 and .NET Native isn't fully clear
/rant mode off
While this kind of reboots might be daily stuff on Apple and Google's platforms, it didn't land that well among the typical enterprise customers from Microsoft, and most likely not other Microsoft teams that are upper of the SDK food chain.
However, why stay on Microsoft stack then? Because I could write equally long rants for the other eco-systems I develop for, and Microsoft while being this schizophrenic still provides the best developer experience and smallest rant list from my point of view.
Fuck, another UI platform they're killing - at least it's OSS and someone might pick it up. But at this point, we should all just give up and do web shit I guess...
In fact that is how C++/WiRT sells not having the tooling around that C++/CX provides, by using React Native as Microsoft's QML so to speak.
I share the Web sentiment, for anything that isn't games related, it has won, just wait until WebGPU happens and WebAssembly gets more mature.
In fact, I used it there right until I discovered that in new Edge I can have it as a standalone app on my taskbar - exactly the feature FF announced last week that they have no intention of implementing[1].
FF is still my main browser. But for something like Outlook, that is an essential feature. And obviously, any links in emails now open in Edge so FF loses that usage too.
Outlook is probably a pilot. If successful, then I could see the rest of the Office apps going in the same direction eventually.
