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.
You must break down the part that led to that reputation.
Electron uses its own renderer (chrome). Meaning it can't share memory with the os browser and make download size way bigger.
It bundles nodejs. Again make download size bigger
Nodejs needs to create multiple processes which each of them can use a lot of memory.
It use a bridge between the UI and backend (to do os stuff)
while JS is nowaday fast, Go/Java/C#/etc are still faster
Wails on the other hand.
Uses the os browser. (Download size is reduce and can share memory)
Go is compiled to native, no runtime needed. (Download size is reduce, lower on memory, run faster)
Same bridge performance bottleneck, but you can perform critical stuff in Go and get an advantage.
HTML renderers are fast. Code your UI with performance in mind, use a library like svelte or solidjs combine with something like wails (or anything that will do the same thing in java/c#/swift) and you won't see a difference between any native apps in most cases.
Also you gain the ability to share your UI code with the web.
To be more accurate, it needs one variable.
- Butt(s) per feature
That includes defects,
It's one of many reasons I like new compiled/vm languages like Go, Swift, Nim F#. You got the productivity of python, but near the performance of C. User wins, dev wins and planet wins.
I didn't read the NY Times articles since it's paywalled.
But your translation is inaccurate. it would be more something like:
"They were decided to occupy France like an enemy territory"
It was not the French who described the liberating force as an enemy, but that the liberating for was acting like an occupying force and didn’t see the French as allied but as enemy.
> Also electron require multiple node backend services which each eat memory like crazy (based on electron app I use).
AFAIK Electron requires 1 Node instance (you can disable it for renderer processes and you can have 0 WebWorkers or only WebWorkers with Node.js disabled) which consumes like ~50MB or something like that, which probably accounts for stuff other than Node.js too, if the app you are using require multiple Node processes that use huge amounts of memory they are just badly written.
> Have one, real Multithreaded +, more efficient backend, will reduce memory and offer better performance.
You can't just share Node.js across multiple apps, Tauri just doesn't bundle it at all, which is a whole different story with mostly downsides from my point of view.
Of those apps I can only say that VS Code is well written and that Spotify is junk.
Is 600mb too much for VS Code? I guess it depends on what you are doing with it and which extensions you have installed etc., if you are running a pretty bare-bones installation and seeing 1GB+ memory usages in VS Code please open an issue in their issue tracker and tag me (same username as in HN).
> Slack is much better than it was.
And that didn't happen by switching to the website approach, I think you'll be disappointed if any of these apps end up switching to Tauri or Wails without significantly improving their code too. Which is why I'd predict no major player will jump ship.
for my work, vscode take between 1.5 to 2.5gb. Nothing has change since start using it 4 years ago, and my experience is consistent with my coworkers. I keep using it because it 'feels' the best overall. No magical issue will fix that, node is memory hungry as is java.
Calling an app junk to justify is argument is unconvincing. Its still a widely used app that works as good as the competition. In the case of slack, their optimisation endeavour seems to cost them quite a lot. But sure I don't have the number. If they would have start the project in Tauri or Wails at the beginning, would that saved them the refactoring? I don't now. But we will need more team using that kind of alternative to gain the knowledge and real benefit.
At this point I rewriting a toy project from electron to wails and its great. But well, it's only a toy project.
That sounds like a lot, you are probably running some heavy extensions or too many of them I guess, could you post a screenshot of the "process explorer" window for your instance of vscode?
> Calling an app junk to justify is argument is unconvincing.
I couldn't care less about what you think about Electron, that's just what I think.
Someone has to come in and make it supported. Adopting nlvm isn't going to magically make it easier.
The reason it's easier in Rust is because someone that's passionate about WASM came along and did the work up front to document everything and make it as simple to compile to WASM as possible, the same is certainly possible in Nim, just need someone to put in some work :)
I really do like Nim, but suggesting it to do WebAssembly out of the box could be deceiving and do no good. The project is currently in the hard spot where it's hard to convince your team of using it, but because its hard they is less contribution.
As for llvm, you might be right, I'm not an expert in that particular field. But it seems there is a lot of already backed in stuff you'll have for free. Like Wasm, debugging, optimization. We'll see how the Crystal project manage to get Wasm and how llvm will help them.
because the 15x programmer that is slowed down to 1.3x because the 50x added 80x of technical debt will leave the company. So the company will only have 50x that leave as soon as there is a need to fix their own code.
To put a real value on the work of a heterogeneous pool of developers is way harder than it looks. One will only value the contribution of what 'he/she' values as important. But the quality of a software come from the strength of many that focus on different things. Even the person who is not really good, but is the only one that bring a 'team spirit/team work' brings value to a team.
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.