| ▲ | jFriedensreich a day ago |
| I am at the opposite extreme. We should ditch electron and use browsers good enough integrated they can run all the apps with native feel and reusing the same engine (not a lacklustre OS webview but a complete one) This solves the memory overhead, solves unpatched or misconfigured chromium in each electron app as well as portability and reusing web dev skills. Also this would allow permissions and security to be managed by a layer that can focus on that and I don't have to worry about what a native app can do. (OS permissions and sandboxing are just not made for vibecoded infinite software and likely never will catch up) 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. I will never trust discord or Spotify to run something natively on my machine and so should no one else. |
|
| ▲ | tcfhgj a day ago | parent | next [-] |
| > 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 19 hours ago | parent [-] | | Good, finally! Yet this branch started with the claim which isn't about Discord at all. | | |
| ▲ | doodlesdev 17 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 4 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 20 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 19 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 17 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 3 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 |
|
|
|
| ▲ | arka2147483647 a day ago | parent | prev | next [-] |
| The security boundary here is difficult, if you intend to integrate with native workflows. Also difficult to manage fake websites duplicating the look and feel. Scamming people into giving access or passwords. A native app which is installed once from a good source is more secure, i feel. |
| |
|
| ▲ | andai a day ago | parent | prev | next [-] |
| I just run discord in the browser. The native one reads the titles of open windows on your desktop, and God knows what else. (Well, I don't use discord at all anymore, but I very intentionally never used the desktop app.) |
| |
| ▲ | jlund-molfese a day ago | parent [-] | | It’s gotta be to enable screen sharing, so the use can see the title of windows within the app, right? Although the OS should sandbox that away | | |
| ▲ | andai a day ago | parent [-] | | It's so it can put what you're doing in your status, from what I gathered. |
|
|
|
| ▲ | neya a day ago | parent | prev | next [-] |
| You can optimize all you want, but if your foundation is a pack of cards, you're not going very far. JavaScript is not a solid foundation to build anything on. It's a language that should have been extinct long ago along with internet explorer. But, people kept trying to save it - adding abstraction on top of abstraction, even languages on top of it (coffeescript, typescript) just to get it to work at the baseline of a decent language. It's the only language that is forced upon us. If browsers gave us options to use other languages, it would and should've been long been dead. |
| |
| ▲ | gloosx a day ago | parent | next [-] | | If javascript is not a solid foundation to build anything on, then how come everything is built on top of it? It's the language powering the whole web, and people went really really far with it. Besides that, almost every major programming language can now run in the browser via webassemly, which solves problems in the areas where javascript is lacking raw performace. | | |
| ▲ | pdimitar a day ago | parent | next [-] | | Your parent comment already answered that. You're mistaking "JS is forced on people and they have no choice but to make it work" with "it's everywhere so it must be good". | | |
| ▲ | gloosx a day ago | parent [-] | | JavaScript wasnt forced on people any more than HTML or CSS were. Browsers standartised on a common scripting language so that websites could work consistently across implementations. You can build websites without JavaScript, modern HTML and CSS can accomplish quite a lot on their own. And there is absolutely nothing stopping anyone from developing a browser that natively supports another scripting language. Your arms are untied to end the javascript tyranny once and for all. | | |
| ▲ | pdimitar a day ago | parent [-] | | Finding it hard to take such wildly idealistic comments seriously. There's a ton of stuff that will stop you from making your own browser. The distinction here is that nobody is stopping you to BEGIN making your own browser, but dozens of factors will stop you from making it WIDELY VIABLE later -- which you need if you want anybody else but you to use it. I think you got hung up on "forced". Obviously nobody is saying that pistols put at somebody's forehead were involved. But IE6 and "This browser is not supported" was a thing back then, and that made people compromise a lot and appeal to early JS stupidities. Then it snowballed and the rest is history. Speaking of which, it took CSS ages until its devs finally woke up and started adding native animations and transitions for which JS was required. So you were "forced" using JS for those for quite a long time as well. Don't argue linguistics, please. I'm very sure you knew exactly what I was talking about. |
|
| |
| ▲ | katbyte a day ago | parent | prev | next [-] | | > how come everything is built on top of it Everything is not built on top of it. > It's the language powering the whole web It’s also not powering the whole web, just a significant part of the client frontend inside browsers. | |
| ▲ | Rumple22Stilk a day ago | parent | prev | next [-] | | Because you have no choice? | | |
| ▲ | gloosx a day ago | parent [-] | | What would that choice look like in practice? Should every browser vendor implement and maintain a dozen different language runtimes with all the associated compat and security implications? Standartising on a common scripting language seems like a pretty reasonable engineering decision, and abadoning that standard after decades of widespread adoption seems like a pretty shitty engineering decision. | | |
| ▲ | xigoi 19 hours ago | parent [-] | | > What would that choice look like in practice? Allow WebAssembly to directly access the DOM, so you can write whatever language you want and compile it to WebAssembly. | | |
| ▲ | gloosx 11 hours ago | parent [-] | | This implies the massive complexity of restructuring how browser engines work, plus working around security and memory safety issues. And this work is actually being done right now, see wasm GC and Component Model |
|
|
| |
| ▲ | neya a day ago | parent | prev [-] | | > how come everything is built on top of it Can you share something else they could've built everything else on top of, instead? Yeah, that's what I thought. Do you really think a normal junior dev is going to be/should be writing web assembly code to build a basic portfolio website? | | |
| ▲ | gloosx a day ago | parent [-] | | You have made an extraordinary claim, considering an enormous amount of complex, reliable software written in JS. Perhaps first you could explain what exactly makes it an unsuitable foundation for building software? Im also curious what language do you think would be suitable instead? And whats your plan to move all the browsers and websites in the world to this new language? | | |
| ▲ | neya a day ago | parent [-] | | > Perhaps first you could explain what exactly makes it an unsuitable foundation for building software? https://i.redd.it/rz3o1yibnc511.png > And whats your plan to move all the browsers and websites in the world to this new language? I'm not proposing this, I am saying there should have been options to begin with. | | |
| ▲ | leptons a day ago | parent [-] | | Sorry but tired old JS "gotchas" that no developer worth a damn would ever use, is not a valid reason to shit on Jacascript. Every language has stupid footguns. | | |
| ▲ | neya a day ago | parent [-] | | > no developer worth a damn would ever use There are a lot of junior developers across the world in different economic situations who might. To think otherwise is just arrogance. Think students, freshers, job-seekers switching industries. In other words, if your programming language makes it easy for you to shoot yourself in the foot, then it isn't a good programming language to begin with. | | |
| ▲ | leptons 10 hours ago | parent [-] | | Sorry but there is no perfect programming language, there isn't even one that doesn't confuse "students, freshers, job-seekers switching industries". This magical perfect programming language you seem to think exists simply doesn't exist. In fact, Javascript is far easier than most languages for people new to programming to learn. It was designed that way, and it works well in that role. Invariably, it's only people trying to be gatekeepers are the ones who try to shit on javascript, especially by citing "gotchas" which aren't even really "gotchas". People new to javascript and programming sure aren't the ones who try to shit on it. |
|
|
|
|
|
| |
| ▲ | com2kid a day ago | parent | prev [-] | | Modern JS is fine. It suffers from a lack of integer types and every method being dynamic dispatch is something runtimes have to optimize around, but the base language is quite nice. Culturally JS doesn't have a tradition of libraries with deep inheritance hierarchies so you aren't wasting a bunch of memory, and cpu, constructing layer upon layer of useless base classes. This is an improvement over both Java and some C++. This also means the GC doesn't have to work as hard. | | |
| ▲ | neya a day ago | parent | next [-] | | > Culturally JS doesn't have a tradition of libraries with deep inheritance hierarchies so you aren't wasting a bunch of memory, and cpu, constructing layer upon layer of useless base classes. This is an improvement over both Java and some C++. This also means the GC doesn't have to work as hard. No it doesn't, but instead it has normalized using a ton of third party packages even for as silly as left-pad [1] that might take your whole application down, put the security of your users in jeopardy or even take bulk of JS built websites down [1]. Even if the left pad incident is excluded, everyday, JS developers rely on unaudited third party libraries from the shitstorm that NPM is. So, you just offset the library problem, not really solved it. [1] https://en.wikipedia.org/wiki/Npm_left-pad_incident | | |
| ▲ | com2kid 15 hours ago | parent [-] | | > No it doesn't, but instead it has normalized using a ton of third party packages even for as silly as left-pad [1] that might take your whole application down, put the security of your users in jeopardy or even take bulk of JS built websites down [1]. JS solved the package reuse problem. Turns out the ideals of the 1980s had security problems in the 2020s. Better than C++ where getting third party source building is such a PITA that I got used to seeing decade+ old sources of security critical packages laying around in repos because no one was going to bother trying to get a newer version building. |
| |
| ▲ | dataflow a day ago | parent | prev [-] | | Those are hardly the only two issues modern JS suffers from. |
|
|
|
| ▲ | mulhoon a day ago | parent | prev | next [-] |
| I agree with this. And even further, I think we wasted a decade or so, forcing web and native apart - especially on mobile. Partly due to Apple building a native moat when we could have put resources into building a more performant and powerful internet. |
| |
| ▲ | evilduck a day ago | parent [-] | | Apple did displace Flash though, and Flash was much worse for a performant and powerful (and secure, and mobile) internet than Apple. |
|
|
| ▲ | prmph a day ago | parent | prev | next [-] |
| I'm with you. I created my own declarative react-like UI library that is small, efficient, and does things just the way I want. I have absolutely no desire to go back to the days where for every platform I want to develop for, I need to learn whole new UI paradigm, with all its quirks and gaps and inefficiencies. Past a certain age, having to do this every year or two get old fast. And, it is not necessary for good performance. The only holding back good performance and capabilities from web apps are the platform vendors. |
| |
| ▲ | skybrian a day ago | parent [-] | | Is this library open source? I’m curious about how it works. |
|
|
| ▲ | hobo123 a day ago | parent | prev | next [-] |
| In a way yes, but things like keyboard shortcut, file pickers and similar are major convenience issues and not as easy if the only thing that runs on the metal is a server process, and the UI is limited to the browser. A webview UI like Tauri might solve that (I'm not familiar with it, so I can't say if it does). I think that's also the main reason software like VS Code is electron based and not browser based. |
| |
| ▲ | bagacrap a day ago | parent [-] | | What keyboard shortcut issue? What file picker issue? Both shortcuts and file pickers are available on the web. Now some particularly powerful and dangerous stuff like global hotkeys are not available or heavily restricted on the web, which is probably a good thing for most users. |
|
|
| ▲ | giancarlostoro a day ago | parent | prev | next [-] |
| I rather we bring back Delphi and VB6 which if you dim’d your types could run faster than most people realize. |
|
| ▲ | josephcsible a day ago | parent | prev | next [-] |
| I think either end is good. Web apps that I can use in my existing browser session are fine, and so are native apps. It's specifically the worst-of-both-worlds middle ground that is Electron that I want to see go away. |
|
| ▲ | eptcyka a day ago | parent | prev | next [-] |
| > well build webapp is often more performant than a native app especially for long scroll lists A well built anything is better than most software. I would argue that a well built rust app will probably a higher quality piece of software than typescript slop produced by Microsoft. |
|
| ▲ | tw04 a day ago | parent | prev | next [-] |
| What? No, absolutely not. Did you not learn your lesson when google decided to actively try to kill ad blocking? Why on EARTH would I want all of my desktop apps at the mercy of google and chromium? You can tell me until you're blue in the face that you also think these apps should be cross-browser but we all know that will never happen. |
| |
| ▲ | bagacrap a day ago | parent | next [-] | | They will at least be usable on Safari because the apple userbase is way too lucrative to give up. But given how badly Safari lags in capabilities and how little Apple wants to invest in the Web, that is probably greater reason the web will not win, rather than consolation that you can pick your megacap poison. | |
| ▲ | jFriedensreich a day ago | parent | prev [-] | | This is whataboutism. There is still firefox as possible second engine impl and you are arguing its better to not have a layer at all than accepting the possibility google might take it away. Plus most people are on macs or windows where there are at least as bad actors playing against them. |
|
|
| ▲ | m00dy a day ago | parent | prev [-] |
| Not sure who's still using electron...Rust + Tauri is pretty much standard these days. |
| |
| ▲ | ezst a day ago | parent | next [-] | | How's that different? You are still shipping a web browser and rendering through the inefficiency of the DOM event/rendering model. Sure it helps that the business logic is written in a native language, but modern, JIT-ed JS isn't a sloth either, and I don't think that's what people have gripes with and what causes abnormally large runtimes. | | |
| ▲ | m00dy a day ago | parent [-] | | there's a lot of difference, please just look it up in any AI. Essentially, you do not ship a browser in Tauri. | | |
| ▲ | ezst a day ago | parent [-] | | > Essentially. you do not ship a browser in Tauri. I mean, essentially you are? It just so happens that this web browser that your application very much runs on top of may link (to a more or less large extent) with the host OS "WebView"/built-in browser (assuming there's one to begin with). My point still stands: if you are lucky, you may save some on the binary size download, once, but the run time is a web app with all the quirks and inefficiencies of the web as a platform. | | |
| ▲ | andrewaylett a day ago | parent [-] | | You run on a browser, but that's very different from shipping a browser. And you save more than merely the download size: there's the equivalent disk size savings but also not having to load n browser engines into RAM at the same time. There's definitely stuff I don't like about Tauri — the way the UI is quite so separate from the native logic, for example — but there are still definite advantages over Electron. | | |
| ▲ | ezst 3 hours ago | parent [-] | | > but also not having to load n browser engines into RAM at the same time. have you noticed the amount of sandboxing required by (the lack of a) modern web's security model? Each app/tab needs its own JS/WASM interpreter in a dedicated process (for memory isolation), common assets (images, JS, CSS, …) must be duplicated in memory as to defuse timing attacks (since spectre/meltdown), rendering/WebGL contexts are a similar story. You may be over-estimating the savings there. More to the point, I never said that the above is pointless (the argument was never about the pros and cons of tauri's using the system WebView), the argument was that it is mostly irrelevant: tauri apps, just like electron apps, are inherently web-based. They have more in common than e.g. a tauri app and a native C++/Qt app. The gripes people have with electron apps (lacking integration, wasting resources, …) apply almost equally to both to the point it barely matter from the end-user's perspective. |
|
|
|
| |
| ▲ | resonious a day ago | parent | prev [-] | | I wish I could agree but Tauri performance is insanely bad on Linux. I think it'll be fixed soon but it drives me nuts. Flutter is under appreciated for desktop. | | |
|