211–220 of 465 posts
Earlier quoted context omitted.
What do you think would be more in line with what you've seen in the past? There's definitely room to keep optimizing.
<25Mb for the executable. For the use case the web page desribes, probably <15Mb. It usually comes down to dependencies used.
Earlier quoted context omitted.
It's not a new or scary thing, but it's way more expensive (in time or money) than relying on "it looks good on my machine, so it looks good everywhere." I've worked on large consumer-facing web-apps where we had a dedicated QA team (and/or contracting firm) that runs visual regression testing on multiple platforms and browser versions. As a solo developer, I have no interest in being that team for my hobby project.…
It’s an unpopular take I’m sure, but I really have to question shipping binaries for platforms that I can’t or won’t personally test. Between platform intricacies I don’t understand, unaddressed papercuts, and limited ability to debug issues, the end result is very likely to be underwhelming and/or frustrating for users of that platform, and as such if the app is paid those users are disproportionately unlikely to co…
Earlier quoted context omitted.
Especially macOS is built on the assumption that you rarely "quit" apps. When you close all of an app's windows, it remains running. You actually have to hit cmd+q or right click and hit "Quit" in the Dock to really quit an app. In other circumstances too though, it's not great UX to demand your users quit your app once they're done with it because it eats too many resources just being idle in the background. It's an…
Electron doesn't seem to support it (and even if it did, I suspect most electron developers wouldn't pay it any mind) but... NSApplicationDelegate's -(BOOL)applicationShouldTerminateAfterLastWindowClosed:(NSApplication *)sender; method exists so an application can, uhh, automatically terminate after the last window closes. https://developer.apple.com/documentation/appkit/nsapplicati... It's not 100% consistent but if…
I can’t find obvious reference or when Apple started changing this, but it seems related to background app killing that is done now as well. I’m still not sure how I feel about it, but historically that wasn’t common for Mac apps.
Earlier quoted context omitted.
You shall hear also about dark side of Flutter. It reimplements the whole UI rendering layer and UI components, so you lose all the flexibility, accessibility etc. of native components. On the other hand with Tauri or React Native you get browser or native OS components.
dont like the sound of reimplementing the whole UI components....
I do so with Rust also with the package flutter_rust_bridge which works great, I'm working on a mobile app that also simultaneously works on web and desktop when I tested it, even all the Rust parts.
It would be great to see an up-to-date benchmark comparing modern cross-platform frameworks like Tauri, Flutter, Electron, React Native, and others. Key metrics could include: - Target bundle size - Memory usage (RAM) - Startup time - CPU consumption under load - Disk usage - e.t.c. Additionally, for frameworks like Tauri, it would be useful to include a WebView compatibility matrix, since the rendering behavior and…
Electron comes out looking competitive at runtime! IMO people over-fixate on disc space instead of runtime memory usage.
Memory Usage with a single window open (Release builds)
Windows (x64): 1. Electron: ≈93MB 2. NodeGui: ≈116MB 3. NW.JS: ≈131MB 4. Tauri: ≈154MB 5. Wails: ≈163MB 6. Neutralino: ≈282MB
MacOS (arm64): 1. NodeGui: ≈84MB 2. Wails: ≈85MB 3. Tauri: ≈86MB 4. Neutralino: ≈109MB 5. Electron: ≈121MB 6. NW.JS: ≈189MB
Linux (x64): 1. Tauri: ≈16MB 2. Electron: ≈70MB 3. Wails: ≈86MB 4. NodeGui: ≈109MB 5. NW.JS: ≈166MB 6. Neutralino: ≈402MB
It's sad to witness how much suffering developers are ready to endure (and make their users suffer) just not to part ways with HTML/CSS/JS stack. The stack that was never designed properly, let alone for modern UI apps. Flutter would be much better choice for such a desktop app, for example.
Earlier quoted context omitted.
Well, they're right to point out that it removes a lot of inconsistency though. For example, today I was working on an app which used some Unicode characters as icons in buttons, and they look perfectly centered in the button in Firefox but weirdly off-Center in Chrome. I never managed to find a set of CSS properties which made it look good in Chrome tho. And if it was a more serious project I'd probably have used SV…
Sure, the closer your config is from the actual user config the fewer issues you'll get, but I wanted to highlight that even with electron you ought to test on different configurations.
Earlier quoted context omitted.
Electron doesn't seem to support it (and even if it did, I suspect most electron developers wouldn't pay it any mind) but... NSApplicationDelegate's -(BOOL)applicationShouldTerminateAfterLastWindowClosed:(NSApplication *)sender; method exists so an application can, uhh, automatically terminate after the last window closes. https://developer.apple.com/documentation/appkit/nsapplicati... It's not 100% consistent but if…
The function has been available for a while, but auto-closing system apps is a relatively recent change. I can’t find obvious reference or when Apple started changing this, but it seems related to background app killing that is done now as well. I’m still not sure how I feel about it, but historically that wasn’t common for Mac apps.
Nowadays, apps closing themselves or being closed by the OS automatically is reasonable in a lot of cases, but Electron apps tend to hit the cases where it still is valuable to operate with the classic NeXT/OS X document-based app paradigm.
Earlier quoted context omitted.
It’s an unpopular take I’m sure, but I really have to question shipping binaries for platforms that I can’t or won’t personally test. Between platform intricacies I don’t understand, unaddressed papercuts, and limited ability to debug issues, the end result is very likely to be underwhelming and/or frustrating for users of that platform, and as such if the app is paid those users are disproportionately unlikely to co…
There's also the simple fact that shipping an identical UI on multiple operating systems is obviously wrong for a least some of those operating systems (and maybe all of them). You don't have to worry about "platform intricacies" because a web-based cross-platform UI toolkit is going to get really basic UI conventions wrong.