Because those applications are bloated and do use a lot of memory. All the electron-based apps running on my system right now consume at least 300 MB of memory each.
I don't think that's entirely the fault of the end developers though because Electron itself is the issue, namely every app spinning up its own Chromium instance.
Does a rendering engine and an HTML, CSS, and a JS interpreter/JIT compiler use 300 MB of memory? I highly doubt it. If by chance they do, then I think it's high time to supersede these old standards.
I know you are not a web developer but I'll be blunt:
300mb of memory is a lot, sure, but guess what: I don't care.
The
average smartphone has 4GB of ram. This means if the operating system takes up *half* of the RAM at any given moment, the user can run
6 apps simultaneously.And that's on the average phone! No one is running these apps all at once!
Like I said previously, the ease of use and rapid deployment Annoying Oranges being able to multitask 1304 apps locally, which no one does. I wouldn't be suprised if in the future we saw a native OS/browser sandbox environment so apps don't have to ship with a web browser.
Idk one of the things keeping me far away from web development is the constant cyclical fad of new frameworks to solve the never-ending issues of web development - largely caused by the shortcomings of Javascript.
This is an outdated stereotype from a time where ECMA standards didn't exist and the entire industry wasn't behind React. Web standards are very well documented and set in stone, a lot of the really annoying stuff is deprecated and Javascript is no longer the only language people develop with on the web. (I'll expand on this in my next point)
I'm gonna play devil's advocate and say that if I was working as a web developer in an environment where the only thing that my manager/boss/employer cares about is getting a product to launch as quick as possible (especially with how cutthroat it is now) I probably wouldn't care much about performance either.
I think the only way around this is to change the tools and standards that can perform better in that kind of industry.
If even the best JS interpreters and HTML+CSS renderers are too slow then it's probably an issue with the languages themselves and we should start looking for a new replacement.
Maybe a scripting and a markup language that are quicker to parse and interpret? What about having them be compiled to bytecode and binary formats? Who knows.
Your idea that JS interpreters and HTML+CSS rendering is slow comes from another era, this is no longer the case. Web browsers have literally become one of the most optimized pieces of software ever made. I remember looking at the stats for how quickly JS has become in every engine available and being blown away by how far we've come. Your statement that "we should be looking for new replacements" is fairly ignorant because people have been pouring blood sweat and tears in optimizing the web. And guess what? You can run bytecode! You can run binaries!
Every major browser supports
WebAssembly! You can precompile any language and run it in a sandbox on the client-side just like JS.
This further proves my point that, as a standard for creating cross-platform reactive UIs, the web platform is a no-brainer. You can literally do anything you want with it, and make it as fast as you want. In fact, many websites and high-performant web-based tools use webassembly to make their stuff fast. For example:
the design tool Figma is a web application built entirely in C++. It was so good that it was the main rival to Photoshop, in fact,
Adobe almost bought it.The reason apps are slow, is because companies prioritize profits and quick delivery over making good things. This is not unique to web development. It's just a lot more visible because people use the web a lot.
Recent Posts
