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.
I literally quoted you talking about using react Native instead. Try and remember what you wrote.
I gave React Native as an example of an alternative approach to using a browser engine for rendering. Try to work on that reading comprehension of yours.
Oh yeah, that’s how everyone feels about VS Code. What a horrendous resource hog! No developer would ever use it!
A lot of people do feel that it’s a resource hog because well it is a resource hog. The fact that you don’t understand that is truly incredible.
Again, there are opportunity costs to other frameworks. There is a reason Electron is so popular and it’s not because it’s terrible.
Yes, there are opportunity costs. I understand perfectly well why Electron is popular. It makes it easier to crap out something that sort of works. There’s a huge benefit to the developer and a huge cost to the user.
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.
I gave React Native as an example of an alternative approach to using a browser engine for rendering. Try to work on that reading comprehension of yours.
A lot of people do feel that it’s a resource hog because well it is a resource hog. The fact that you don’t understand that is truly incredible.
Yes, there are opportunity costs. I understand perfectly well why Electron is popular. It makes it easier to crap out something that sort of works. There’s a huge benefit to the developer and a huge cost to the user.