francisl

I working on a project using tauri with htmx. I know a bit uncommon. But the backend part use axum and htmx. No Js/Ts UI. It's fast, reliable and it work well. Plus its easy to share/reuse the lib with the server/web.

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.

swift and kotlin are slowly getting there.

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.

Kotlin -> Jetpack Compose

> Native Android, Native iOS (KMM) and soon Desktop+Web (Compose Multiplatform)

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.

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.

> just badly written.

Ins't the easy answer. Each time a dev want to ignore valid comments.

I have the following electron app running: Spotify, Figma, VS Code, Discord, Slack. They all use more than 1 helper. Consuming between 600mb to 3.5gb.

Slack is much better than it was. But I wish they switch to something like Tauri or Wails in the future.

Also electron require multiple node backend services which each eat memory like crazy (based on electron app I use).

Have one, real Multithreaded +, more efficient backend, will reduce memory and offer better performance.

Wails is also an alternative that does just that. Shared Web UI engine + Go compiled backend.

Yes, you're 100% right and I hear you.

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.

yes but it mostly undocumented, unsupported and trouble assured.

I tried several time and always got stuck somewhere.

Rust that has the reputation to be hard, but is way simpler and faster to get into WebAssembly.

I wish they adopt nlvm as the default compiler, it would make stuff like that way easier and probably boost adoption.

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.

Not sure if you are sarcastic or not. But if you look at how you develop windows app (vb, winforms, wpf, uwp and now maui) or Mac/iOS (from mvc, mvvm, and now mvu) and not forgetting Delphi. I find it far from stagnant.

With React you just switch your complexity. I don't feel more productive with my functional components than with my class component. I even more scared to introduce a memory leak with my useEffect than I was before.

But I do feel more productive with svelte or Blazor. That make me realize that OO vs FP is the the real vector. Reactive programming with good design is.