HN user
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)
Are you looking at the base M1, the pro or the max?
Because the M1 Max is not less than half
https://browser.geekbench.com/v5/cpu/compare/11136167?baseli...
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.
You can look at the Allied Military Government of Occupied Territories (originally abbreviated AMGOT, later AMG) for more information. https://en.wikipedia.org/wiki/Allied_Military_Government_of_...
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.
Like you said reactive programming and OO are not exclusive.
And if you look how you do React now with useState, useEffect and all. It's exactly a reproduction of OO, but inside a function that don't behave like a function anymore. And goes HOC for the inheritance/mixins/composition you flush down the drain.
The equivalent is fable [1].
The major difference I would say, is that you are required to use botnet alongside of node. (dotnet to compile to JS, then node to bundle with wepback or anything else)
Also, you can use the same language to build high performance backend with giraffe [2] (better than node). And build performant native application with fabulous [3].
There is an experimental typescript compilation. Which will be great, because it will make using F# less hostile in an environment where the winner takes all.
[1] https://fable.io
It's all political.
If the government fight hard, then lose, the opposing party will blame them for that and most likely make them win the next election. If they just do a marketing campaign telling they did the best possible, winning the next election is more probable.
And Trudeau has nothing to do with that, conservative or liberal, it will be the same strategy.
In order to make Canada more competitive, I think it should be addressed on the provincial level. We definitely need more startup to change the culture and have a place to keep the best talents. High risk funds, change in laws (so anybody can freely invest), etc.
This is a personal conclusion having work in both, some US and some Canadian based companies. What I realized, the reason we are pay less in Canada, is caused by our perceived value from management.
In the American company, the managers want me to succeed because that is directly link to their success. I'm part of the team, I'm accountable, but I had more freedom.
In the Canadian one, managers want all the credit (pay+bonuses+recognition), because they are the incredible one who made the monkey produce the value. I'm part of a pool, managers will decide what programming language I'll program in, he's managing the risk after all. Oh, and by the way, it was a hard year, not all goals where reached, so they need to cap the bonuses, but the company is glad for the all-time profit record.
Of course, it’s a bit of a caricature. It surely applies to US or Canadian company. But our perceived value struck me in all my employers.
On macOs, it's the same shortcuts as Emacs. Except the `ctrl+x+[other]` uses the command key.
IMO its significantly superior for programming.
It's also the reason there is less key on the keyboard, it's simply more efficient. Plus, you have the benefits of having the same bindings in all the apps. Either it's the terminal, your mail client or your IDE. `cmd+s` or `ctrl+x` or `ctrl+q` or name it, always do the same thing. That can't be said for any other desktop.
I know you can configure Gnome to have emacs keybinds, but it's not the same and many apps break the users configured.
I did the switch for my personal laptop when Apple added the touchbar. Telling myself about the same reasons plus the price tag.
I already had a Windows Desktop for game, and for the first time in the Windows history, I really liked what they did with windows 10. They also seem to be more invest in pushing the platform forward. And contrary to the popular opinion, I do believe in convertible devices. Also, I told myself I can also run Linux for development.
I then bought an HP laptop with similar spec than the MBP, for about 500$CAD less. Seem like a real save, but god I was wrong.
The fun with Linux lasted for less than a month before I just gave up.
The consistent (across all apps and terminal), powerful default emacs key bindings on the macs is a gem for programming and productivity. I miss that all day.
The touchpad is mediocre, they are all mediocre, never saw one working as good as the MBP. Even when someone told me that they're working great and let me try it, it was clear they never work with a MBP or don't use it that much.
Native apps in general, like photo, video editing, notes etc. are more polish and perform better on the mac. Web app though is quite different. icloud.com is terrible compare to onedrive.
Resume, battery life, screen, even if the tech specs sheet says it's the same, it's not in real life.
It's hard to put a price on all that, but at the end, I didn't save 500$ in value, I lost way more than that. Moreover, comparable specs, innovative devices like the surface line, are now price about the same.
Adobe will make it happen and docker too. That's just a question of time. As oppose to Microsoft, Apple is taking to switch to arm seriously. Adobe currently has app running natively on the ipad. Between docker and the browser, there is a lot a work you can do, the world is not binary.
As for price, when you build a comparable system, price are similar between companies.
why not go all the way with fable + elmish for the Frontend?
Since Apple is announcing the new Macs with M1 SoC today, I'm wondering if it will support it from day 1 or we will have to wait?!
edit:
I guess I can't read. `We expect that Apple will announce new Apple Silicon-based Mac computers any day now. We already have early builds of .NET 6.0 for Apple Silicon and have been working with Apple engineers to help optimize .NET for that platform. We’ve also had some early community engagement on Apple Silicon (Credit @snickler).`
Still wondering for .net 5 though
You can use f# with fable on the javascript ecosystem. And it's quite nice. Better than TS imo.
and now with .net core, its a better cross platform framework.
also, you can target wasm or native image now, no need to install it on the target env.
I'm not involved with figma in any way, just a user. But from what I understand, it is written in c++ and uses webassembly. Some ui parts are in standard TS+css. [1]
There is absolutely no reason not to be responsive, low on memory and as powerful as a native app.
[1] https://www.figma.com/blog/webassembly-cut-figmas-load-time-...
As a full time web developer, I liked the idea of electron. Even if I dislike electron apps that I need to use at work (like slack memory glutton).
It gave me the impression that I can build desktop app faster by reusing my skills. When it was time to build some side project, I did them in electron.
Recently I decided to learn c#, for unity initially, but I decided to try xamarin. This change all my perceptions. Not only building the core was way more enjoyable that with js/babel/nameit. Prototyping the native interface was faster, and developing the final UI was also more productive. Not to mention the final product looked better.
Comparing developer productivity is hard, but based on my own experience, I would say that it would have taken twice the time on electron the finish the same app in the same time. Compare to my other similar electron project, it load faster, don’t use cpu cycle on idle and consume ¼ of memory.
Maybe there is better idea than xamarin, but at least is seems like a better idea than electron. Now I see more electron as a fast way to have a webapp on the desktop or a fad based excuse to not learn something new.
On the other hand, calling a "cancer" is quite absurd.
what do you find sluggish with this electron app?
I just tested it agains sourceTree, which is native, and I can't see any differences. It loads as fast, navigation and selection take the exact same time to load.
The only difference, github desktop eat 200mb instead of 60mb for sourcetree.
At the end of the day I will still use the command line, except for diff. But for a git gui, I can't really see what you mean by sluggish.
Why not a Surface Book. What is your use case?
Programming, design? Oh is the keyboard as a laptop replacement?
Flash developer can use haxe (http://haxe.org/)
More gear towards games though.