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.
Yeah, I’m aware. I pointed out why your example was dumb.
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.
No, badly written apps are badly written, and perennially online nerds coalesce around hating the same things for validation, which in this case is Electron.
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.
You keep ignoring the point that VSCode, amongst many other great apps, is written with Electron.
Youre bitching about the fact the fact that Electron lowers the barrier of entry, and confusing that for Electron being fundamentally bad.
i.e. Discord doesn’t suck because it’s written with Electron, it sucks because it’s developers / product managers never prioritized making it not suck.
Yeah, I’m aware. I pointed out why your example was dumb.
All you’ve pointed out is that you’re incapable of understanding the point being made. The point again, is that you don’t need a full blown browser engine to get the benefits of having a consistent platform that’s easy to develop against. If people cared about performance, it would be possible to make a lean engine that does much of what Electron does without the bloat.
No, badly written apps are badly written, and perennially online nerds coalesce around hating the same things for validation, which in this case is Electron.
The fact that you can’t even acknowledge that Electron is bloated compared to a native app is incredible.
You keep ignoring the point that VSCode, amongst many other great apps, is written with Electron.
I’m not ignoring anything. I’m pointing out the cost here. Compare with Emacs as an example.
Youre removed about the fact the fact that Electron lowers the barrier of entry, and confusing that for Electron being fundamentally bad.
I’m not doing anything of the sort. I’m pointing out that Electron as it exists today is bloated. I’m not against the concept in the slightest, and this whole discussion was me trying to explain to you how similar benefits can be achieved without the overhead. Clearly that’s just a little too hard for you to wrap your head around though.
No, because you haven’t. You’ve brought up examples that all bring their own overhead, complications, and testing issues.
Once again, at a fundamental level, if I develop an Electron app on Linux or Windows, I can generate an installer and am basically guaranteed that it will work on MacOS because the Electron rendering stack works on MacOS and I am shipping my full rendering stack alongside my app.
A WebView solution that uses the system’s WebView cannot possibly provide that.
A specifically versioned runtime like Java can potentially provide that, though if you were to expand Java to support the out of the box high level rendering of html / CSS then you’re basically turning the JRE into the size of a full browser engine anyways, especially if you were to expand it to support a pleasant and flexible language like JavaScript.
And again, you’re refusing to acknowledge that VSCode is built in Electron, and is not a resource hog, despite being possibly the most powerful Electron program most people will run, once again, showing that Electron is not that much of a resource hog, badly coded web apps are.
I fully acknowledge that Election apps use more storage and slightly more ram than equivalents written in Native Languages, but if you’re experiencing actual slow downs due to them, then it’s probably because they’re badly written.
And I reject the idea that the opportunity cost of slowing down software development is worth it. App distribution used to be over optimized for efficiency rather than resiliency.
No, because you haven’t. You’ve brought up examples that all bring their own overhead, complications, and testing issues.
Every approach has its trade offs. I’ve explained to you repeatedly and in detail how what Electron does can be improved. It’s clear at this point that I’m not going to get through here.
Once again, at a fundamental level, if I develop an Electron app on Linux or Windows, I can generate an installer and am basically guaranteed that it will work on MacOS because the Electron rendering stack works on MacOS and I am shipping my full rendering stack alongside my app.
You absolutely do have to test Electron apps on each platform. However, the point once again, is that as long as you package the rendering engine with the app it’s going to have the same benefits.
A specifically versioned runtime like Java can potentially provide that, though if you were to expand Java to support the out of the box high level rendering of html / CSS then you’re basically turning the JRE into the size of a full browser engine anyways, especially if you were to expand it to support a pleasant and flexible language like JavaScript.
You don’t have to extend the JVM for anything and there are plenty of very nice toolkits available such as https://github.com/HumbleUI/Skija/
The JVM supports far better languages than Js as well. I work with Clojure and it’s straight up better experience in every single way. Not to mention that your development process is fully interactive where you connect the editor to a running instance of the application and you can evaluate any code you want as you write it within the context of the app you’re building. The tooling around Js is incredibly primitive in comparison.
However, there are lean alternatives to Electron available for JS as well. Scriter-js is one example which provides a far leaner runtime.
And again, you’re refusing to acknowledge that VSCode is built in Electron, and is not a resource hog, despite being possibly the most powerful Electron program most people will run, once again, showing that Electron is not that much of a resource hog, badly coded web apps are.
It absolutely is a resource hog compared to something like Emacs, and it’s not even comparable.
I fully acknowledge that Election apps use more storage and slightly more ram than equivalents written in Native Languages, but if you’re experiencing actual slow downs due to them, then it’s probably because they’re badly written.
LMFAO understatement of the century there.
And I reject the idea that the opportunity cost of slowing down software development is worth it. App distribution used to be over optimized for efficiency rather than resiliency.
That’s just an inane straw man you’re using. What I’m actually saying is that you CAN have the benefits of Electron and an efficient runtime. These things are in no way at odds with each other. The fact that you can’t understand that is incredible.
Ok, I see what you’re saying ,but from what I can see, if you were to scale a sciter app to the level of VSCode, it is not going to use any less resources.
Yes sciter is smaller for a simple calc app, but once you have multiple ui panes running in different threads, plus a backend server, it looks like it would scale it exactly the same resource usage as Electron.
It would would use less resources because it’s a more optimized runtime. In fact, the more UI panels and other elements you have in the app, the more savings you’d be making proportionally. Even when faced with a concrete example of being wrong, you’re still digging. 🤦
The fact that you’re faced with an example of a much more optimized runtime and still can’t understand that you’re wrong is frankly hilarious. Maybe once you get a bit of programming experience under your belt you’ll be able to hold a meaningful discussion on the subject.
Yeah, I’m aware. I pointed out why your example was dumb.
No, badly written apps are badly written, and perennially online nerds coalesce around hating the same things for validation, which in this case is Electron.
You keep ignoring the point that VSCode, amongst many other great apps, is written with Electron.
Youre bitching about the fact the fact that Electron lowers the barrier of entry, and confusing that for Electron being fundamentally bad.
i.e. Discord doesn’t suck because it’s written with Electron, it sucks because it’s developers / product managers never prioritized making it not suck.
All you’ve pointed out is that you’re incapable of understanding the point being made. The point again, is that you don’t need a full blown browser engine to get the benefits of having a consistent platform that’s easy to develop against. If people cared about performance, it would be possible to make a lean engine that does much of what Electron does without the bloat.
The fact that you can’t even acknowledge that Electron is bloated compared to a native app is incredible.
I’m not ignoring anything. I’m pointing out the cost here. Compare with Emacs as an example.
I’m not doing anything of the sort. I’m pointing out that Electron as it exists today is bloated. I’m not against the concept in the slightest, and this whole discussion was me trying to explain to you how similar benefits can be achieved without the overhead. Clearly that’s just a little too hard for you to wrap your head around though.
No, because you haven’t. You’ve brought up examples that all bring their own overhead, complications, and testing issues.
Once again, at a fundamental level, if I develop an Electron app on Linux or Windows, I can generate an installer and am basically guaranteed that it will work on MacOS because the Electron rendering stack works on MacOS and I am shipping my full rendering stack alongside my app.
A WebView solution that uses the system’s WebView cannot possibly provide that.
A specifically versioned runtime like Java can potentially provide that, though if you were to expand Java to support the out of the box high level rendering of html / CSS then you’re basically turning the JRE into the size of a full browser engine anyways, especially if you were to expand it to support a pleasant and flexible language like JavaScript.
And again, you’re refusing to acknowledge that VSCode is built in Electron, and is not a resource hog, despite being possibly the most powerful Electron program most people will run, once again, showing that Electron is not that much of a resource hog, badly coded web apps are.
I fully acknowledge that Election apps use more storage and slightly more ram than equivalents written in Native Languages, but if you’re experiencing actual slow downs due to them, then it’s probably because they’re badly written.
And I reject the idea that the opportunity cost of slowing down software development is worth it. App distribution used to be over optimized for efficiency rather than resiliency.
Every approach has its trade offs. I’ve explained to you repeatedly and in detail how what Electron does can be improved. It’s clear at this point that I’m not going to get through here.
You absolutely do have to test Electron apps on each platform. However, the point once again, is that as long as you package the rendering engine with the app it’s going to have the same benefits.
You don’t have to extend the JVM for anything and there are plenty of very nice toolkits available such as https://github.com/HumbleUI/Skija/
The JVM supports far better languages than Js as well. I work with Clojure and it’s straight up better experience in every single way. Not to mention that your development process is fully interactive where you connect the editor to a running instance of the application and you can evaluate any code you want as you write it within the context of the app you’re building. The tooling around Js is incredibly primitive in comparison.
However, there are lean alternatives to Electron available for JS as well. Scriter-js is one example which provides a far leaner runtime.
It absolutely is a resource hog compared to something like Emacs, and it’s not even comparable.
LMFAO understatement of the century there.
That’s just an inane straw man you’re using. What I’m actually saying is that you CAN have the benefits of Electron and an efficient runtime. These things are in no way at odds with each other. The fact that you can’t understand that is incredible.
Ok, I see what you’re saying ,but from what I can see, if you were to scale a sciter app to the level of VSCode, it is not going to use any less resources.
Yes sciter is smaller for a simple calc app, but once you have multiple ui panes running in different threads, plus a backend server, it looks like it would scale it exactly the same resource usage as Electron.
Multiple UI panes and a backend server? You mean lke emacs?
It would would use less resources because it’s a more optimized runtime. In fact, the more UI panels and other elements you have in the app, the more savings you’d be making proportionally. Even when faced with a concrete example of being wrong, you’re still digging. 🤦
🤡
No, you just can’t recognize when you’re wrong and someone is kindly trying to meet you half way anyways.
The fact that you’re faced with an example of a much more optimized runtime and still can’t understand that you’re wrong is frankly hilarious. Maybe once you get a bit of programming experience under your belt you’ll be able to hold a meaningful discussion on the subject.