Because storage is cheap, so it’s not worth optimizing that heavily for, because the optimization creates a huge amount of headaches.
There’s a reason that today you can just download an app, and it just installs, runs, and uninstalls itself cleanly.
There’s no fighting with dependencies, or installing versions of libraries or frameworks before you can install an app, or having apps conflict with other apps, or having bits of app installations lying around conflicting with things.
That’s because we used to spend a lot of time and effort making sure that only a single copy of each dependency was installed on a system. If two apps both relied on the same library, one would install it, and the other would then be dependent on it as well and not install its own copy. If the original is removed you have a problem. If it thinks something else is dependent on its asset still and doesn’t remove it when it should you’ve got a problem. If they were both dependent on different major versions of a library, you could run into conflicts and compatibility issues (hello dll hell). Either the apps would have to manage all that, or the OS would, or eventually the user often would.
Now every app just bundles all its dependencies with it. It means the app comes as a clean bundle, there’s no conflicts, it can install cleanly, and there’s so much less time spend on packaging apps and debugging various system configurations.
Quite frankly this makes way more sense as a model for distributing anything. Yes it costs more in storage, but it pays off massively in resiliency and time savings for everyone.
Also, unless everything is done with vectors, high def image / video assets are not small and can very quickly add up.
Except that it’s not just storage, but also increased memory footprint and CPU usage in a lot of cases. Take something like Slack which is a huge resource hog.
Electron. Many apps nowadays are just headless browsers and browsers are huge and complex. It’s nice from a development perspective, because you can (re)use web tools for desktop apps but it’s very resource hungry.
It’s worth noting that it doesn’t have to be that way. Take Tauri as an example of leveraging the benefits of web stack development, and having an efficient runtime under the hood.
Yes, and now you can’t test your application before shipping it because who knows what browser engine will actually run it.
You could develop it on Windows and have it completely break for every single Mac user when it executes in Safari and have literally no way of knowing or testing that ahead of time.
I mean you would just test on each platform, which you should be doing regarding of what you’re developing with. Also worth noting that web standards are a thing, and vast majority of apps aren’t so complex that they would run into edge cases between browser engine implementations.
However, this isn’t an inherent problem since you could build something like Tauri and package its own lean rendering engine with it. Sciter-js is an example of this approach. Other examples can be seen with React Native and Proton. The main point here is that the bloat the Electron brings to the table is wholly unjustified, and far more efficient approaches are possible.
I mean you would just test on each platform, which you should be doing regarding of what you’re developing with.
Yes, except the platform your developing for with Electron is the browser engine you ship alongside it, so you are constantly testing it and it will always work.
With Tauri the platform your developing for is now whatever the underlying OS chooses to use to render it’s WebView. It is flat out impossible to test for every os and WebView so you have no guarantee that your application will even render once it’s installed.
And again, if you develop on a Windows or Linux machine, there is flat out no way to test on Safari without buying a Mac, but you can reliably expect your Electron app to just work.
Also worth noting that web standards are a thing, and vast majority of apps aren’t so complex that they would run into edge cases between browser engine implementations.
Lmao. Bruh, I’d like to introduce you to this little known WebView called Safari.
The vast majority of web apps will run into compatibility issues between safari, Firefox, and chrome. There is nowhere close to enough standardization for that.
However, this isn’t an inherent problem since you could build something like Tauri and package its own lean rendering engine with it. Sciter-js is an example of this approach. Other examples can be seen with React Native and Proton. The main point here is that the bloat the Electron brings to the table is wholly unjustified, and far more efficient approaches are possible.
Lol, you’ve clearly never installed a React Native app if you think there’s no bloat.
No, the point is that you want it to be unjustified but it’s not. Electron works great, is incredibly easy to setup and ship with extremely little overhead beyond storage. The opportunity cost of solutions that don’t bundle dependencies are almost never worth it.
There’s a reason the most popular IDE used by virtually every software developer these days is built using Electron.
Lmao. Bruh, I’d like to introduce you to this little known WebView called Safari.
Bruh, I’ve been developing web apps for over a decade now. You don’t have to introduce me to anything. The reality is that most apps aren’t that complex and if you’re using something like React, a lot of the details are already handled for you.
The vast majority of web apps will run into compatibility issues between safari, Firefox, and chrome. There is nowhere close to enough standardization for that.
Sounds like skills issue there bud.
Lol, you’ve clearly never installed a React Native app if you think there’s no bloat.
We’re comparing with Electron here lmfao.
No, the point is that you want it to be unjustified but it’s not. Electron works great, is incredibly easy to setup and ship with extremely little overhead beyond storage. The opportunity cost of solutions that don’t bundle dependencies are almost never worth it.
If by works great you mean hogs resources like no tomorrow and is able to bring modern hardware to its knees to render a simple crud app, then sure.
There’s a reason the most popular IDE used by virtually every software developer these days is built using Electron.
Vast majority of apps people make aren’t nearly as complex as an IDE.
Bruh, I’ve been developing web apps for over a decade now. You don’t have to introduce me to anything. The reality is that most apps aren’t that complex and if you’re using something like React, a lot of the details are already handled for you.
XD XD XD
You mean … Webpack? React handles nothing of web compatibility for you.
We’re comparing with Electron here lmfao.
I literally quoted you talking about using react Native instead. Try and remember what you wrote.
If by works great you mean hogs resources like no tomorrow and is able to bring modern hardware to its knees to render a simple crud app, then sure.
Oh yeah, that’s how everyone feels about VS Code. What a horrendous resource hog! No developer would ever use it!
/S
Again, there are opportunity costs to other frameworks. There is a reason Electron is so popular and it’s not because it’s terrible.
It’s also worth noting apps have to ship higher resolution assets now, due to higher resolution displays. This can include video, audio, images, etc. Videos and images may be included at multiple resolutions, to account for different sized displays.
For images, many might assume vectors are the answer, but vectors have to be rendered at runtime, which increases startup time in the best case scenario, and isn’t even always supported on all platforms, meaning they have to be shipped alongside raster assets of a few different sizes, further increasing package bloat. And of course the code grows to add the logic to properly handle all the different asset types and sizes.
All this (packaging dependencies, plus assets/asset handling) to say it isn’t always malware, ads, electron, etc. Sometimes it’s just trying to make something that looks nice and runs well (enough) on any machine.
It’s also because we started doing shit like using JS in places it really shouldn’t belong. Half the programs on my PC are just webapps running in a sandbox environment, instead of using systems languages like C/C++ directly like was the case 15-20 years ago. Abstractions on top of abstractions on top of abstractions. JS was fine for embellishing elements of a web site and facilitating AJAX, it should have never been turned into an app language.
That’d be like if interpreted BASIC was taken seriously in the 80s as more than just a toy and the majority of popular software was written in it. We’d rightfully question WTF society was thinking.
No we wouldn’t, and this is a crazy take when like half of Linux runs on interpreted python.
You’re min/maxing for things that don’t matter. You know what does matter? User facing features. You know what language in unquestionably the fastest to produce user facing features in? JavaScript/HTML/CSS.
If you want to optimize for performance you can do so after by moving things server side, writing them in web assembly, or offloading them onto other threads.
There’s also massive opportunity cost in a) programming in low level languages, and b) having every developer have to learn a low level language. There’s a reason that we don’t all code in assembly any more.
Because storage is cheap, so it’s not worth optimizing that heavily for, because the optimization creates a huge amount of headaches.
There’s a reason that today you can just download an app, and it just installs, runs, and uninstalls itself cleanly.
There’s no fighting with dependencies, or installing versions of libraries or frameworks before you can install an app, or having apps conflict with other apps, or having bits of app installations lying around conflicting with things.
That’s because we used to spend a lot of time and effort making sure that only a single copy of each dependency was installed on a system. If two apps both relied on the same library, one would install it, and the other would then be dependent on it as well and not install its own copy. If the original is removed you have a problem. If it thinks something else is dependent on its asset still and doesn’t remove it when it should you’ve got a problem. If they were both dependent on different major versions of a library, you could run into conflicts and compatibility issues (hello dll hell). Either the apps would have to manage all that, or the OS would, or eventually the user often would.
Now every app just bundles all its dependencies with it. It means the app comes as a clean bundle, there’s no conflicts, it can install cleanly, and there’s so much less time spend on packaging apps and debugging various system configurations.
Quite frankly this makes way more sense as a model for distributing anything. Yes it costs more in storage, but it pays off massively in resiliency and time savings for everyone.
Also, unless everything is done with vectors, high def image / video assets are not small and can very quickly add up.
Except that it’s not just storage, but also increased memory footprint and CPU usage in a lot of cases. Take something like Slack which is a huge resource hog.
Electron. Many apps nowadays are just headless browsers and browsers are huge and complex. It’s nice from a development perspective, because you can (re)use web tools for desktop apps but it’s very resource hungry.
It’s worth noting that it doesn’t have to be that way. Take Tauri as an example of leveraging the benefits of web stack development, and having an efficient runtime under the hood.
Yes, and now you can’t test your application before shipping it because who knows what browser engine will actually run it.
You could develop it on Windows and have it completely break for every single Mac user when it executes in Safari and have literally no way of knowing or testing that ahead of time.
I mean you would just test on each platform, which you should be doing regarding of what you’re developing with. Also worth noting that web standards are a thing, and vast majority of apps aren’t so complex that they would run into edge cases between browser engine implementations.
However, this isn’t an inherent problem since you could build something like Tauri and package its own lean rendering engine with it. Sciter-js is an example of this approach. Other examples can be seen with React Native and Proton. The main point here is that the bloat the Electron brings to the table is wholly unjustified, and far more efficient approaches are possible.
Yes, except the platform your developing for with Electron is the browser engine you ship alongside it, so you are constantly testing it and it will always work.
With Tauri the platform your developing for is now whatever the underlying OS chooses to use to render it’s WebView. It is flat out impossible to test for every os and WebView so you have no guarantee that your application will even render once it’s installed.
And again, if you develop on a Windows or Linux machine, there is flat out no way to test on Safari without buying a Mac, but you can reliably expect your Electron app to just work.
Lmao. Bruh, I’d like to introduce you to this little known WebView called Safari.
The vast majority of web apps will run into compatibility issues between safari, Firefox, and chrome. There is nowhere close to enough standardization for that.
Lol, you’ve clearly never installed a React Native app if you think there’s no bloat.
No, the point is that you want it to be unjustified but it’s not. Electron works great, is incredibly easy to setup and ship with extremely little overhead beyond storage. The opportunity cost of solutions that don’t bundle dependencies are almost never worth it.
There’s a reason the most popular IDE used by virtually every software developer these days is built using Electron.
Bruh, I’ve been developing web apps for over a decade now. You don’t have to introduce me to anything. The reality is that most apps aren’t that complex and if you’re using something like React, a lot of the details are already handled for you.
Sounds like skills issue there bud.
We’re comparing with Electron here lmfao.
If by works great you mean hogs resources like no tomorrow and is able to bring modern hardware to its knees to render a simple crud app, then sure.
Vast majority of apps people make aren’t nearly as complex as an IDE.
XD XD XD
You mean … Webpack? React handles nothing of web compatibility for you.
I literally quoted you talking about using react Native instead. Try and remember what you wrote.
Oh yeah, that’s how everyone feels about VS Code. What a horrendous resource hog! No developer would ever use it!
/S
Again, there are opportunity costs to other frameworks. There is a reason Electron is so popular and it’s not because it’s terrible.
It’s also worth noting apps have to ship higher resolution assets now, due to higher resolution displays. This can include video, audio, images, etc. Videos and images may be included at multiple resolutions, to account for different sized displays.
For images, many might assume vectors are the answer, but vectors have to be rendered at runtime, which increases startup time in the best case scenario, and isn’t even always supported on all platforms, meaning they have to be shipped alongside raster assets of a few different sizes, further increasing package bloat. And of course the code grows to add the logic to properly handle all the different asset types and sizes.
All this (packaging dependencies, plus assets/asset handling) to say it isn’t always malware, ads, electron, etc. Sometimes it’s just trying to make something that looks nice and runs well (enough) on any machine.
It’s also because we started doing shit like using JS in places it really shouldn’t belong. Half the programs on my PC are just webapps running in a sandbox environment, instead of using systems languages like C/C++ directly like was the case 15-20 years ago. Abstractions on top of abstractions on top of abstractions. JS was fine for embellishing elements of a web site and facilitating AJAX, it should have never been turned into an app language.
That’d be like if interpreted BASIC was taken seriously in the 80s as more than just a toy and the majority of popular software was written in it. We’d rightfully question WTF society was thinking.
Bingo!
No we wouldn’t, and this is a crazy take when like half of Linux runs on interpreted python.
You’re min/maxing for things that don’t matter. You know what does matter? User facing features. You know what language in unquestionably the fastest to produce user facing features in? JavaScript/HTML/CSS.
If you want to optimize for performance you can do so after by moving things server side, writing them in web assembly, or offloading them onto other threads.
There’s also massive opportunity cost in a) programming in low level languages, and b) having every developer have to learn a low level language. There’s a reason that we don’t all code in assembly any more.
A good package manager like those commonly used on Linux solves this problem