| ▲ | tcfhgj a day ago |
| > All the performance and other arguments are just not true, a well build webapp is often more performant than a native app especially for long scroll lists not even to mention accessibilty, extensions and more. A well built web app will never be more performance than a well built native app.
It's just inherent due to the JavaScript abstraction. |
|
| ▲ | StilesCrisis a day ago | parent | next [-] |
| It's true that JavaScript costs, but the text renderer in Chrome is just wildly optimized and definitely can outperform an OS list view. An article here on HN covered it a while back. |
| |
| ▲ | doodlesdev a day ago | parent | next [-] | | > the text renderer in Chrome is just wildly optimized and definitely can outperform an OS list view.
The question is not whether it can win against GTK/Cocoa/WinUI but whether it's faster than other retained-mode renderers such as the one Discord is using, GPUI.Also, even if just running on a browser tab, each tab has a lot of memory overhead compare to what an actual binary running on the OS has. That's memory that gets wasted from the outset, before the developer even writes a single line of JavaScript. | |
| ▲ | andypants a day ago | parent | prev | next [-] | | Doesn't it use skia? You can use that in your own native app | | |
| ▲ | StilesCrisis a day ago | parent [-] | | It does! And yes, you could, but Skia isn't a widgets library, it's an immediate mode renderer. You would be on the hook to write the entire widget layer yourself. That's in fact what Chrome provides (tied to a very popular widget library known as HTML!) |
| |
| ▲ | SaintRomuald a day ago | parent | prev [-] | | Do you have the link to it or remember what it was called? | | |
|
|
| ▲ | jFriedensreich a day ago | parent | prev | next [-] |
| The question is at what cost and at that level of both being optimal does it even matter to the user or is indistinguishable. There will always be 1% native apps that make sense, i'm talking about 99% of applications. |
| |
| ▲ | sokoloff a day ago | parent [-] | | To be fair, your upthread post does specifically say "all the apps", which could lead readers to assume that you meant that to include 100% rather than 99%. |
|
|
| ▲ | mycall a day ago | parent | prev | next [-] |
| So fix the JavaScript abstraction. I've had more success with dart-wasm lately so I'm waiting for someone to finish the standards. |
|
| ▲ | broken-kebab a day ago | parent | prev [-] |
| Never? We already had this discussion about JVM, and we know for a fact that it's possible for JIT to achieve better performance with that damned bytecode compared to natively compiled equivalent. |
| |
| ▲ | redox99 a day ago | parent | next [-] | | It would be extraordinary to see a real world rust program use more memory than its JVM equivalent. | | |
| ▲ | tetromino_ a day ago | parent | next [-] | | I have seen it happen once in an LLM rewrite from java to rust. The modern JVM gc is actually pretty good. | |
| ▲ | broken-kebab a day ago | parent | prev [-] | | Let's not move the goalposts, the word in question is "performant". Though even with memory it's not as clear as you assume in the context (which is about browser-based apps). Singular C/Zig/Rust program will surely be more economical than a singular in-browser app due to browser itself having a huge footprint. But what if said user has that browser open all the time anyway as probably most users do? What if there are more than one GUI-rich app, and with browser they share most of the overhead? PLs which allow low-level optimizations offer great opportunities, no arguing. But never say "never" until you know what exact problem yiu have to deal with. | | |
| ▲ | tcfhgj a day ago | parent | next [-] | | You cannot separate performance from memory usage.
Usually less memory usage for apps comes at the cost of performance and vice versa. And more memory usage can slow down the whole system, because the system may need to swap and compress memory. | | |
| ▲ | broken-kebab a day ago | parent [-] | | To be direct: this is utter nonsence. Memory usage and performance are different targets of optimization, which often at odds with each other. | | |
| |
| ▲ | redox99 a day ago | parent | prev | next [-] | | > Let's not move the goalposts, the word in question is "performant". Even though the word performance was used by a parent comment, I think they used it as an umbrella term. The article and most of the talk around rust discord is primarily about the memory. And JVM is probably the worst runtime you could pick if you care about memory usage. | | |
| ▲ | broken-kebab a day ago | parent [-] | | Assuming this would make this comment less reasonable though. Optimization for memory usage is distinct from optimization for performance in our craft. And it's pretty basic thing. | | |
| ▲ | doodlesdev a day ago | parent [-] | | Rust-based Discord achieves both, though... You can absolutely get an application to run faster while using less memory, given there's enough low-hanging fruit (and with today's software, there certainly is...). If you're optimizing sorting algorithms, video decoding or compression software, then that's another story, because using more memory can trade time complexity for space complexity in your algorithm (i.e. Merge Sort vs Insertion Sort). | | |
| ▲ | broken-kebab 18 hours ago | parent [-] | | Good, finally! Yet this branch started with the claim which isn't about Discord at all. | | |
| ▲ | doodlesdev 16 hours ago | parent [-] | | This is a thread on the post about Discord and we're discussing the original statement below: > All the performance and other arguments are just not true, a well build webapp is often more performant than a native app especially for long scroll lists not even to mention accessibilty, extensions and more.
To which I think Discord's Rust rewrite is actually a great counter example. Epic Games's new launcher could've been too, but it's just vibe slop, unfortunately, not real engineering work.The announced performance and memory usage also shows that using a browser tab (reducing overhead for separate browser processes) is still not enough to save memory compared to a native application, as this new Discord rewrite, with multiple accounts logged in, uses about the same memory as an empty new Chromium tab. | | |
| ▲ | broken-kebab 3 hours ago | parent [-] | | For starters, logic doesn't work this way at all. Counterexample doesn't make a valid argument against non-absolute statement. And the claim is that in-browser code can be as performant as natively compiled (as you conveniently quoted). So apparently building the case on Discord misses the point twice. Also for the sake of correctness: Discord CTO said the Rust-based app with 2 accounts uses around 290 MB which is significantly more than even the first empty tab uses (and each of the next will use smaller amount due to sharing). |
|
|
|
|
| |
| ▲ | CyberDildonics 19 hours ago | parent | prev [-] | | more economical Not sure what this means. What if there are more than one GUI-rich app, and with browser they share most of the overhead? Those are called web pages. I don't know what the rest of this comment is trying to say. When a chat room program takes 4GB of memory, there will be optimizations literally everywhere. Everything will work from looking the current javascript to switching languages. | | |
| ▲ | broken-kebab 18 hours ago | parent [-] | | Your "4GB of memory" for "chat room program" is obvious reference to Discord in its Electron-based incarnation. Which certainly proves you sincerely don't understand what that means, and what the rest of my comment is about. It could be my fault, but may I suggest you first read the comment to which mine is answering, just to get the whole picture, so to speak? Missing context may be the root of misunderstanding here because I didn't write it about Discord actually. And even about Electron. | | |
| ▲ | CyberDildonics 16 hours ago | parent [-] | | If you're just talking about being on of the 'java can be faster than native programs' people, then show me a java program and I will show you how to make a faster, more consistent, lower memory native program. | | |
| ▲ | broken-kebab 2 hours ago | parent [-] | | Am I? Let me quote myself verbatim: It's possible for JIT to achieve better performance with that damned bytecode compared to natively compiled equivalent.EOQ Good JIT is able to dynamically re-optimize code according to present conditions/load which is what can give bytecoded program in certain conditions (which aren't that rare) edge over static native code. Is it possible to make your own dynamic optimization with natively compiled PL which would beat Java, or JS on a relevant case? As a sport, sure, you would just have to make your own bytecode with JIT. Or hand-optimize in every possible way staticly, and just chose the best path when running. You can even gain more by going with assembler. Is it worth extra time, increased attack surface, and higher probability of bugs? Will you even have a good chance to succeed? It is genuinely impossible to answer without full requirements which bind you. Independently, it's fair to say that on RAM side, natively compiled code wins most of the time. Is it something users care about is again a question to think each time anew. To quote me again: But never say "never" until you know what exact problem you have to deal with. EOQ |
|
|
|
|
| |
| ▲ | tcfhgj a day ago | parent | prev [-] | | Yes never |
|
