5 ms·

> Now that I think of it, the push for more and more Electron apps may be because all devs are living comfortably on 16GB and 32GB devices, where the voracious

> Now that I think of it, the push for more and more Electron apps may be because all devs are living comfortably on 16GB and 32GB devices, where the voracious RAM appetite of Electron does not matter. IMO its generally the JS hype producing these monstrosities. QT and Java have had fast and powerful cross-platform UI for ages. I'm trying to push a new paradigm at work where we write most of the logic in Rust. UI view layer would be JavaFx for desktop and React Native for mobile. Only 2 UI's to target for all platforms, reuse of core code, and good performance all around.

cxr 6y ago
> IMO its generally the JS hype producing these monstrosities. If you use "the JS hype" as a synonym for what are considered best practices by the folks in the NodeJS/NPM ecosystem, then you're right. (I.e., the fault lies in the "hype" half, not in the "JS" half.) It was 10–15 years ago that you could routinely hear one of the most prevalent criticisms in the programming world about the bloat of Java. I think that, where JS is concerned, for some reason we're seeing a regression where it's becoming "conventional wisdom" that JS itself is slow, against the evidence to the contrary. I've seen straightfaced comments here on HN in the last few months, for example, that complain about the slowness of JS as a general rule. But the reality is that the JS runtimes have billions of dollars of engineering from top-tier teams invested in them, and today's JS engines are by-and-large pretty fast. V8, in fact, shares parts of its implementation with Java's HotSpot—specifically the parts that were developed by the folks who made the StrongTalk VM and who were acquired by Sun, thus leading to that work being incorporated into HotSpot in the first place. So what is that reason? There has been a noticeable shift in performance degradation that corresponds to the rise of, for lack of a better term, "the NPM way of programming". As with the case of Enterprise™ Java®, the problem lies in the way people in those circles are writing their programs and what passes for an "idiomatic" coding style. The NPM style used heavily in many Electron apps is relatively recent, with respect to JS's lifetime. Even before JS engines were JITted, Firefox itself had hundreds of thousands (millions?) of lines of JS doing a lot of the work both in what you see on the screen when you're poking at your browser as well as behind the scenes. Notably, the JS in those cases is not of the NPM style. There's nothing in principle that means the "Emacs-like" application architecture (compiled core, dynamic shell) needs to be slow, particularly on today's hardware. As I've mentioned before[1], in the early days of Firefox, I used to use 1.0 and 1.5 on an 800 MHz PIII with 128 MB of RAM. (For folks looking to leap in here with what they'd like to consider a well-timed "well, actually…": yes, I'm acutely aware that even that number is on the order of 100× or more beyond what is necessary to get real work done with a computer—but the point is that it's nothing compared to, say, stock 2015-era Chromebooks with 8GB of RAM, or a comparable quantity in today's phones, for that matter.) Browser extensions are written in JS, and my laptop now is several times over better than the laptop I used 10 years ago—and yet... if I install any arbitrary extension today, there's a good chance that I will encounter perceptible bloat there, too. A recent example (within the last year) that I know of, is the WorldBrain Memex add-on, which upon immediate use has the telltale mark of influence from the world of modern "frontend" webdev, and the performance to match. This wasn't the case when add-ons were authored in the sui generis style of yesteryear, before the NPM practices leaked over and began influencing everything related to JS—and tainting people's perceptions. So I find the attempt to draw a contrast between JS and Java a little misplaced. Even ignoring the common history (in both culture and provenance), there's the fact that Java IDEs themselves have always been the poster children of bloat—second only (or somewhere in the running) along with Visual Studio proper. I know people like to point to VSCode as an example of a "snappy" Electron app, and the inevitable retort about just how lean it really is. (On my system, I don't think it's possible to run VSCode without making sure that there's at least 350 MB of main memory to spare before launching it. Compare to the old joke about Emacs's "bloat": that it was supposed to stand for "Eight Megabytes And Constantly Swapping".) On the other hand, I have to recognize that the folks calling VSCode snappy really are on to something. The previous statements notwithstanding, the fact is that VSCode is still snappier than anything I've ever experienced using one of the mainstream Java IDEs. If I were a naive person, I could point to that and conclude that the problem lies with Java-the-language. And yet every day I used my phone with large parts written in Java—which, to be fair, does impart some impression of bloat and sluggishness, so it's prudent for me to keep in mind earlier versions of Android on older, more limited hardware that did have a fairly snappy feel. And those observations lead us back to the root problem, which is if you judged only by much the code being written today, programmers seem to have forgotten (or simply never learned?) how not to write code that's bloated and slow. 1. https://news.ycombinator.com/item?id=23183770 https://news.ycombinator.com/item?id=23183770
- AnthonyMouse 6y ago
  > I think that, where JS is concerned, for some reason we're seeing a regression where it's becoming "conventional wisdom" that JS itself is slow, against the evidence to the contrary. It's because people have plenty of experience with actual real-world JS code being very slow. Which has nothing to do with the runtime or the ability of someone purposely writing optimized JS to optimize it well. The fact that you can write fast JS doesn't mean that the language itself or popular frameworks encourage you to do so, whereas that is the case for a lot of other languages with a reputation for being faster.
  - zdragnar 6y ago
    I don't think you are actually disagreeing with the author's point- you could easily replace "JS" in your statement with Java, C#, Haskell or a number of other "fast" languages and it would still be an accurate statement. I, at least, have had the displeasure of using slow gui and other programs written in those languages.
  - cxr 6y ago
    This attitude fails to recognize the point I was making in my comment, and so it ends up fundamentally getting something wrong. It happens here in this sentence: > The fact that you can write fast JS doesn't mean that the language itself or popular frameworks encourage you to do so One half of this sentence is bang-on, and the other half is not. That is, it conflates what is encouraged by the language with what is encouraged by the modern JS crowd, and suggests something in that vein—as if they're one tightly interconnected bundle—but in fact, they are two distinct things, and I made several remarks in my original comment alluding to this. To successfully argue the point you're making now, you have to argue that "the NPM way" that is now prevalent is the inevitable result of merely setting out to write a program in JS. But, in fact, it's not. As I mentioned, the JS that made up a huge proportion of Firefox's codebase was written in a style that doesn't resemble the style now popular with NodeJS and NPM, but there was no big, conscious effort to do that by, say, avoiding pitfalls of the language and the things that might make it slow—it was purely a result of the lack of opportunity for being tainted by bad examples from the NodeJS/NPM world, since that world didn't exist then. The main influence on programmers writing JS for Firefox was the influence of Objective-C, C++, and Java. You certainly can "optimize" your JS to make it faster, just like you can with any program, but that's not to say have to—you can leave the optimization to the engine itself most of the time. All that's really needed, on average, to make sure that JS is fast, is to avoid tainting yourself with mindworms that have proliferated in the NodeJS+NPM ecosystem, that is: just don't do the things that you would have never thought of doing were it not for having seen others doing it somewhere else on GitHub or in the packages hosted on npmjs.com. In other words, if you want to write JS that avoids being slow, then you don't have to take any special effort. Generally, you can start by opting for writing the dumbest, most boring code possible. (Indeed, I routinely come across "clever" code by self-styled NodeJS aficionados exhibiting elaborate contortions to fight against the language, when it would be far better to just do the simplest possible thing and then move on. Refactoring to eliminate these contortions can even make the code more performant and more concise.) For example, let's say you have something written in Java, or something with an analogue in C++ or Go, and your team has some motivation to either recreate it in or migrate it to JS. That's perfect—before you ever think about handing the task over to a professional NodeJS programmer, you really should give some heavy consideration to doing your best to copy the architecture from the existing, non-JS implementation, down to class names and code organization, and doing a straightforward, procedure-for-procedure port to JS. (Although, if in the case of migrating from Java, maybe also consider eliminating any unnecessary abstractions along the way—or don't.) There's a good chance that this will have satisfactory results that challenge your assumptions. Even if you're creating something from scratch rather than porting an existing solution, once again, all you have to do is to not worry about being fashionable and trendy, and just do the most straightforward thing possible. There's a recent comment here on HN that's extremely relevant and really hints at what's going on with all these slow, bloated, and messy projects from the world of modern webdev: https://news.ycombinator.com/item?id=23869393 https://news.ycombinator.com/item?id=23869393

cxr 6y ago

> IMO its generally the JS hype producing these monstrosities. If you use "the JS hype" as a synonym for what are considered best practices by the folks in the NodeJS/NPM ecosystem, then you're right. (I.e., the fault lies in the "hype" half, not in the "JS" half.) It was 10–15 years ago that you could routinely hear one of the most prevalent criticisms in the programming world about the bloat of Java. I think that, where JS is concerned, for some reason we're seeing a regression where it's becoming "conventional wisdom" that JS itself is slow, against the evidence to the contrary. I've seen straightfaced comments here on HN in the last few months, for example, that complain about the slowness of JS as a general rule. But the reality is that the JS runtimes have billions of dollars of engineering from top-tier teams invested in them, and today's JS engines are by-and-large pretty fast. V8, in fact, shares parts of its implementation with Java's HotSpot—specifically the parts that were developed by the folks who made the StrongTalk VM and who were acquired by Sun, thus leading to that work being incorporated into HotSpot in the first place. So what is that reason? There has been a noticeable shift in performance degradation that corresponds to the rise of, for lack of a better term, "the NPM way of programming". As with the case of Enterprise™ Java®, the problem lies in the way people in those circles are writing their programs and what passes for an "idiomatic" coding style. The NPM style used heavily in many Electron apps is relatively recent, with respect to JS's lifetime. Even before JS engines were JITted, Firefox itself had hundreds of thousands (millions?) of lines of JS doing a lot of the work both in what you see on the screen when you're poking at your browser as well as behind the scenes. Notably, the JS in those cases is not of the NPM style. There's nothing in principle that means the "Emacs-like" application architecture (compiled core, dynamic shell) needs to be slow, particularly on today's hardware. As I've mentioned before[1], in the early days of Firefox, I used to use 1.0 and 1.5 on an 800 MHz PIII with 128 MB of RAM. (For folks looking to leap in here with what they'd like to consider a well-timed "well, actually…": yes, I'm acutely aware that even that number is on the order of 100× or more beyond what is necessary to get real work done with a computer—but the point is that it's nothing compared to, say, stock 2015-era Chromebooks with 8GB of RAM, or a comparable quantity in today's phones, for that matter.) Browser extensions are written in JS, and my laptop now is several times over better than the laptop I used 10 years ago—and yet... if I install any arbitrary extension today, there's a good chance that I will encounter perceptible bloat there, too. A recent example (within the last year) that I know of, is the WorldBrain Memex add-on, which upon immediate use has the telltale mark of influence from the world of modern "frontend" webdev, and the performance to match. This wasn't the case when add-ons were authored in the sui generis style of yesteryear, before the NPM practices leaked over and began influencing everything related to JS—and tainting people's perceptions. So I find the attempt to draw a contrast between JS and Java a little misplaced. Even ignoring the common history (in both culture and provenance), there's the fact that Java IDEs themselves have always been the poster children of bloat—second only (or somewhere in the running) along with Visual Studio proper. I know people like to point to VSCode as an example of a "snappy" Electron app, and the inevitable retort about just how lean it really is. (On my system, I don't think it's possible to run VSCode without making sure that there's at least 350 MB of main memory to spare before launching it. Compare to the old joke about Emacs's "bloat": that it was supposed to stand for "Eight Megabytes And Constantly Swapping".) On the other hand, I have to recognize that the folks calling VSCode snappy really are on to something. The previous statements notwithstanding, the fact is that VSCode is still snappier than anything I've ever experienced using one of the mainstream Java IDEs. If I were a naive person, I could point to that and conclude that the problem lies with Java-the-language. And yet every day I used my phone with large parts written in Java—which, to be fair, does impart some impression of bloat and sluggishness, so it's prudent for me to keep in mind earlier versions of Android on older, more limited hardware that did have a fairly snappy feel. And those observations lead us back to the root problem, which is if you judged only by much the code being written today, programmers seem to have forgotten (or simply never learned?) how not to write code that's bloated and slow. 1. https://news.ycombinator.com/item?id=23183770 https://news.ycombinator.com/item?id=23183770

AnthonyMouse 6y ago
> I think that, where JS is concerned, for some reason we're seeing a regression where it's becoming "conventional wisdom" that JS itself is slow, against the evidence to the contrary. It's because people have plenty of experience with actual real-world JS code being very slow. Which has nothing to do with the runtime or the ability of someone purposely writing optimized JS to optimize it well. The fact that you can write fast JS doesn't mean that the language itself or popular frameworks encourage you to do so, whereas that is the case for a lot of other languages with a reputation for being faster.
- zdragnar 6y ago
  I don't think you are actually disagreeing with the author's point- you could easily replace "JS" in your statement with Java, C#, Haskell or a number of other "fast" languages and it would still be an accurate statement. I, at least, have had the displeasure of using slow gui and other programs written in those languages.
- cxr 6y ago
  This attitude fails to recognize the point I was making in my comment, and so it ends up fundamentally getting something wrong. It happens here in this sentence: > The fact that you can write fast JS doesn't mean that the language itself or popular frameworks encourage you to do so One half of this sentence is bang-on, and the other half is not. That is, it conflates what is encouraged by the language with what is encouraged by the modern JS crowd, and suggests something in that vein—as if they're one tightly interconnected bundle—but in fact, they are two distinct things, and I made several remarks in my original comment alluding to this. To successfully argue the point you're making now, you have to argue that "the NPM way" that is now prevalent is the inevitable result of merely setting out to write a program in JS. But, in fact, it's not. As I mentioned, the JS that made up a huge proportion of Firefox's codebase was written in a style that doesn't resemble the style now popular with NodeJS and NPM, but there was no big, conscious effort to do that by, say, avoiding pitfalls of the language and the things that might make it slow—it was purely a result of the lack of opportunity for being tainted by bad examples from the NodeJS/NPM world, since that world didn't exist then. The main influence on programmers writing JS for Firefox was the influence of Objective-C, C++, and Java. You certainly can "optimize" your JS to make it faster, just like you can with any program, but that's not to say have to—you can leave the optimization to the engine itself most of the time. All that's really needed, on average, to make sure that JS is fast, is to avoid tainting yourself with mindworms that have proliferated in the NodeJS+NPM ecosystem, that is: just don't do the things that you would have never thought of doing were it not for having seen others doing it somewhere else on GitHub or in the packages hosted on npmjs.com. In other words, if you want to write JS that avoids being slow, then you don't have to take any special effort. Generally, you can start by opting for writing the dumbest, most boring code possible. (Indeed, I routinely come across "clever" code by self-styled NodeJS aficionados exhibiting elaborate contortions to fight against the language, when it would be far better to just do the simplest possible thing and then move on. Refactoring to eliminate these contortions can even make the code more performant and more concise.) For example, let's say you have something written in Java, or something with an analogue in C++ or Go, and your team has some motivation to either recreate it in or migrate it to JS. That's perfect—before you ever think about handing the task over to a professional NodeJS programmer, you really should give some heavy consideration to doing your best to copy the architecture from the existing, non-JS implementation, down to class names and code organization, and doing a straightforward, procedure-for-procedure port to JS. (Although, if in the case of migrating from Java, maybe also consider eliminating any unnecessary abstractions along the way—or don't.) There's a good chance that this will have satisfactory results that challenge your assumptions. Even if you're creating something from scratch rather than porting an existing solution, once again, all you have to do is to not worry about being fashionable and trendy, and just do the most straightforward thing possible. There's a recent comment here on HN that's extremely relevant and really hints at what's going on with all these slow, bloated, and messy projects from the world of modern webdev: https://news.ycombinator.com/item?id=23869393 https://news.ycombinator.com/item?id=23869393