Microsoft is building a new Outlook app for Windows and Mac powered by the web(windowscentral.com)
windowscentral.com
Microsoft is building a new Outlook app for Windows and Mac powered by the web
https://www.windowscentral.com/project-monarch-outlook-web-universal-email-client-microsoft
33 comments
VSCode is one of the snappiest and most responsive apps I use, period. Microsoft knows how to use Electron.
Never used Sublime or Notepad++ I see.
I've used both at different times in the past for quick-edits, when my "main IDE" was Eclipse or Visual Studio (which are truly sluggish, and also native [1]). With VSCode I don't feel like I have to choose between feature set and responsiveness, and as such I haven't used either in several years.
I won't say VSCode is more responsive than Notepad++/Sublime, but I will say any difference is small enough that I don't notice/care
[1] Eclipse is Java, but that's arguably still more "native" than Electron
I won't say VSCode is more responsive than Notepad++/Sublime, but I will say any difference is small enough that I don't notice/care
[1] Eclipse is Java, but that's arguably still more "native" than Electron
Agree to disagree. I switch between VSCode and Sublime regularly, and I see significant differences in input latency as well as memory consumption.
VSCode also doesn't handle large files well, etc.
VSCode also doesn't handle large files well, etc.
In this case I have to disagree. I've been using the web version of outlook for at least 8 months now and it is so much better than the rusty windows application.
At least for the Mac client, I think the native app, as slow as it is (possibly made worse due to corporate spyware), is better than OWA for several use cases:
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...
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 went through a similar change then found the Mac Outlook client and have been using it for months. I had forgotten how great a stand-alone email app is.
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.
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.
I don't question that their web-apps are good. I also didn't imply the native applications were any good.
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.
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.
It's unlikely that they'll be bundling Chromium with the individual apps, at least on Windows:
"In the future, the Evergreen WebView2 Runtime plans to ship with future releases of Windows." https://docs.microsoft.com/en-us/microsoft-edge/webview2/
"In the future, the Evergreen WebView2 Runtime plans to ship with future releases of Windows." https://docs.microsoft.com/en-us/microsoft-edge/webview2/
This is literally the second sentence in the link you cite:
> The WebView2 control uses Microsoft Edge (Chromium) as the rendering engine to display the web content in native applications.
> The WebView2 control uses Microsoft Edge (Chromium) as the rendering engine to display the web content in native applications.
Yes, I know. My point was that it’s not like Electron where they ship Chromium with every app, it’s more like a browser tab in terms of resource consumption.
Totally agree. And also, chances are it won't be Electron, at least on Windows. These guys literally made the OS, they know how to use a native webview.
> they know how to use a native webview.
I have never liked Windows embedded webviews and don’t think they actually know how to use them well. They’ve always seemed like suckier interfaces than their native interfaces. I think their new control panel stuff is web controls and seem clunkier and slower than the old windows control pane widgets.
I have never liked Windows embedded webviews and don’t think they actually know how to use them well. They’ve always seemed like suckier interfaces than their native interfaces. I think their new control panel stuff is web controls and seem clunkier and slower than the old windows control pane widgets.
New Control Panel stuff is C++/XAML/WinUI, definitely not web controls.
The big trouble with Windows' embedded webviews in the past has been that they only updated once or twice a decade with Windows updates, so tied to very specific IE versions and often meaning applications that used them were stuck in specific versions of the web platform. The new "WebView2" from Microsoft is powered by Chromium Edge so it should be a lot closer to Electron in practice (though still, updated at user/system pace [just now on the much faster Chromium Edge cycle rather than the slower Windows cycle], not developer pace which is often the specific draw to Electron).
The big trouble with Windows' embedded webviews in the past has been that they only updated once or twice a decade with Windows updates, so tied to very specific IE versions and often meaning applications that used them were stuck in specific versions of the web platform. The new "WebView2" from Microsoft is powered by Chromium Edge so it should be a lot closer to Electron in practice (though still, updated at user/system pace [just now on the much faster Chromium Edge cycle rather than the slower Windows cycle], not developer pace which is often the specific draw to Electron).
This is a sad day because if the Windows team at Microsoft can't get the Office team to build snazzy native apps then that can only mean there is no hope remaining for native apps in Windows.
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.
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.
Aesthetic differentiation is an interesting consideration, but even aside from that the native UI framework options are currently not practical for applications like Office. Like, their options are:
- 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
- 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
Unfortunately you forgot a dot there, "Wait for WinUI 3.x", with x probably being quite big.
https://github.com/microsoft/microsoft-ui-xaml/blob/master/d...
https://github.com/microsoft/microsoft-ui-xaml/blob/master/d...
Ugh, true. I'm pretty annoyed by how many features are missing from 3.0, I won't be able to use it in my hobby app because I depend on MediaPlayerElement for audio.
The Windows team have themselves to blame for the way this has been handled since Windows 8.
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.
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.
On some level it make sense. Microsoft is not thinking in terms of a Windows-centric workplace anymore, but a Microsoft 365 workplace.
Outlook is probably a pilot. If successful, then I could see the rest of the Office apps going in the same direction eventually.
Outlook is probably a pilot. If successful, then I could see the rest of the Office apps going in the same direction eventually.
I have a bad feeling that the new app won't be as battle-tested on Firefox as it will on Chromium-based browsers like Edge and Chrome.
The existing Outlook works pretty well in FF.
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.
[1] https://news.ycombinator.com/item?id=25589177
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.
[1] https://news.ycombinator.com/item?id=25589177
The optimist in me wonders if it was simply easier to make an Electron alternative run well on Windows, instead of rebuilding their native apps to meet arbitrary internal goals.
Let's just hope it's at least better than Teams. Current Outlook client is already pretty bloated and unintuitive, I wonder how bad will it get after moving to Electron.
In what way is it bloated or unintuitive? It seems fairly easy to use if one has used a Ribbon-based UI in the past, which is ~everybody at this point.
I wonder if they are working on a VBA to WASM compiler because they will need a way to replicate existing functionality or they are going to frustrate power users.
Here's hoping that the native desktop app is alive for a few years. I don't need more Electron apps that have a quarter of the features of a native app.
Weren't there rumors they were rewriting it in React Native Windows? Now going full web, what message shall we read? Is React Native dead on Windows?
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...
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...
Could be the same rumors filtered through differently technically literate pipelines. To a lot of people React Native is still "web stuff", and the article doesn't admit any technical knowledge as to how this rumored project is going to attempt "native integration" other than it will attempt "native integration" so for all we know, could still be (has always been) React Native.
Office was adopting React Native and XBox team did as well.
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 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.
Yeah, great move.