Hacker Newsnew | past | comments | ask | show | jobs | submit | sillyboi's commentslogin

Looks great, but it lags a bit on my phone with a Snapdragon 855 and 12 GB of RAM. I really like the vehicle controls.

It would be a good idea to put some eye-catching example of a hotel room in the article headline, like an image of a shower without a door, just for visual impact. As for me, I’ve come across hotels where the shower is visible from the bedroom, separated only by a glass wall. Lol, that’s probably the next level.


The one I stayed at in France had this shit. Annoyed me to no end and plus I got sick on the trip.


I suppose it's just a click bait title, so nothing special


I'd say nothing kills the web more than hiding the “reject all cookies” button and covering the whole page with a popup until you accept. So I think we’re safe for now.


Honestly, this approach feels like it adds a lot of unnecessary complexity. It introduces a custom serialization structure that can easily lead to subtle UI bugs and a nightmare of component state tracking. The author seems to be solving two issues at once: large payloads and stream-structured delivery. But the latter only really arises because of the former.

For small to medium JSON responses, this won't improve performance meaningfully. It’s hard to imagine this being faster or more reliable than simply redesigning the backend to separate out the heavy parts (like article bodies or large comment trees) and fetch them independently. Or better yet, just use a proper streaming response (like chunked HTTP or GraphQL @defer/@stream).

In practice, trying to progressively hydrate JSON this way may solve a niche problem while creating broader engineering headaches.


Sorry, but it would be great to adapt it for the mobile layout.


Do you mean the website or are you talking about the book PDF?


I meant the website.


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 performance can vary significantly depending on the WebView version used on each platform (e.g., macOS WKWebView vs. Windows WebView2, or Linux GTK WebKit). This divergence can affect both UI fidelity and performance, so capturing those differences in a visual format or table could help developers make more informed choices.


Here's a great comparison, updated two weeks ago. https://github.com/Elanis/web-to-desktop-framework-compariso...

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


The benchmark also says Tauri takes 25s to launch on Linux and build of empty app takes over 4 minutes on Windows. Not sure if those numbers are really correct.


A few months ago, I experimented with Wails and Tauri on Windows. The builds did indeed take unreasonably long with the Rust option and were way faster with Go, no idea why but I ditched Tauri because of that since Wails did more or less the same thing.


Did you manage to publish/ship your WAILS app? What was your biggest hurdle with it?


It was an internal app, a GUI to configure a CLI tool in a user friendly manner. For that use case, I essentially built a local SPA with Vue that can also call some endpoints on server side software that we also host. There, the rendering differences between the web views didn't really matter but the small distribution size was a major boon, plus being able to interface with Go code was really pleasant (as is that whole toolchain). No complaints so far, then again, not a use case where polish would matter that much.

I'd say that the biggest hurdle for that sort of thing is just the documentation or examples of how to do things online - because Electron is the one everyone seems to use and has the most collective knowledge out there.


That seems like a perfect use case for a WAILS app, nicely done!


This. Reminds me of Casey Muratori warning people to not trust benchmarks made by random people on the internet.

There’s absolutely no way Tauri apps take 25s to launch. Source: I’ve played with Tauri on Linux. This is an order of magnitude off.


I wonder the reason Tauri does great in Linux and Electron is at its worst is because of Optimization or lack thereof respectively.


I've compared block editors (Notion - Electron, Appflowy - Flutter , etc) to my Qt C++ & QML block editor I've built in my blog post[1] using similar parameters. You might find it a good read.

[1] https://rubymamistvalove.com/block-editor


I'd love to see a comparison like this.


Cool! Are you planning to add support for a mobile layout?


As they say, "With great power comes great responsibility." Or in this case, with great printer access comes great pranking potential!


At least three detections on VirusTotal, but I'm not sure if it's significant.

ClamAV: Js.Trojan.Obfus-48

Cylance: Unsafe

Google: Detected


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: