The name of the post should be "We need a better alternative to Web(& Electron) apps". As the article doesn't talk about the current title at all, and only encourage flame war discussions
There is a need for native apps, however that need is shrinking and, in my opinion, will continue to do so. I also happen to think that's a good thing.
The issue is that developing for a particular OS is, generally, more difficult than developing for the web. The app delivery mechanism is also more convoluted (for native apps) than simply entering a web address in the browser. The web also seems to have more ubiquitous standards that abstract away the differences between OSs - you can, with a high degree of certainty, ensure that your app is usable by 99% of computer users, given the current software they have on their device - with native apps, there is no such guarantee, especially if you're relying on shared libraries.
Browsers are also becoming more feature rich. This has had a negative impact on their memory consumption, but given it's 2020, some may retort "memory is cheap" (I totally disagree with this way of thinking personally). And while some browsers (Chrome, looking especially at you) do a very poor job of memory management, I believe the competitive nature of the browser market will force a reawakening soon, where a lot of the inefficiencies in memory management will have to be eradicated (or vendors risk losing market share). Think back to 2014/15 when Node.js was really becoming established - the PHP team suddenly felt a need to re-optimise their engine for PHP7 (and with dramatic results)... Point is, only after ~20 years at the top did something spur PHP's team on enough to do something about their inefficiencies.
Finally, I can see a future where the line between web and native apps is even more blurred. WebAssembly is the first step, however things could get even more elaborate. Perhaps we could end up with the ability to start docker-like containers from within web apps (given the right permissions, of course) to spin up servers for audio/video/image processing on the client itself, and interact with them via a web page. If we get to this point, native apps may feel even more obsolete.
I know this post relates primarily to the current state, but I felt the need to talk about the future to highlight the marked difference in the rate of innovation in the web ecosystem (fast) vs the native ecosystem (slower). It would not surprise me if the web ecosystem ends up winning in the end. If I was building an app today, and it only requires features I can deliver via the browser, I would almost certainly go the web app route.
Now, if I was building a video processing app today, I'd almost certainly go native, but in a couple of years, my answer may be very different.
I'd say the "need" is shrinking because the number of viable options are shrinking. I'd throw out every single Electron app and replace them with native if it was possible. They're almost always either frustratingly slow or poorly designed. Oftentimes they're both.
I don't disagree, but I think there may be better alternatives to Electron in the not so distant future. I don't think the concept of Electron is bad (i.e. one API regardless of the target platform), but the execution of that concept is.
I strongly believe we will see some major improvements in the performance of Web apps/Electron, since (a) there is a lot of incentive (b) there are many easy wins to be had in terms of performance.
You could even have the browser allocate a volume or two for the container to use (with the user's permission, of course) to store data locally. And users could be allowed to adjust how much space the volume may use (from some default minimum to unlimited).
And with containers, the client should be reasonably safe even if executing malicious software.
I really don't like the lack of responsiveness that some Web apps have. I remember coming from Teradata SQL Assistant to Cloudera's Hue and being so frustrated by the latency of editing code (pushing the keyboard and seeing the letters appear). It would often result in me inserting random characters.
JavaScript is not slow. Python is slower than JavaScript, but if you compare a native desktop app written in PyGTK against an app written in Electron, you will see JavaScript being slow is not the problem.
Electron apps aren't made because the end result is superior but because of budgets and schedules.
Not even a company like Slack wants to get into the headache of maintaining a couple of native desktop apps, even if they probably have the money to do so.
Slack is API calls. I have a hard time believing a few thin client interfaces - win, darwin, ios, android, gtk, qt - would be that hard with a company size of slack.
The question is not whether they are hard, but whether they are harder and whether that harder is worth it. Has Slack lost a single paying customer of this? I doubt it.
I've never really understood this way of thinking. In my experience, it is trivial to maintain cross-platform applications if you encourage code-reuse in the logic layer and tailor the UI/UX experiences for the platform you are targeting. In practice this usually means writing the client business logic in a high-performant language that can target multiple platforms (I've only used Rust for this, but there are other languages out there that would work well with this approach as well), and using FFI when interacting with the UI layer. Combine this with good message passing practices (to homogenise serialisation/deserialisation and avoid the complexity of having hundreds of different FFI functions with various parameters) and you've got something that is easily integrated in platforms with little headache.
I've seen great success with this approach for most platforms including mobile as it provides the end-user with a great user experience (you can use all the native UI APIs which provides an experience that the user is already familiar with) as well as extremely high performance with a high degree of code reuse.
> In my experience, it is trivial to maintain cross-platform applications
Even if setting up the code reuse among platforms was trivial, now you have to develop and maintain a new UI project for each platform with different languages, SDKs, dev environments, and other peculiarities.
With a web UI you can target 6 platforms at once with the same UI project: Android, iOS, ChromeOS, macOS, Windows, and web.
> Electron apps aren't made because the end result is superior but because of budgets and schedules.
I'd add one thing, it's also used because it leverages existing web development skills.
I've made a couple of Electron applications because it simply lets me make a "desktop" app that is basically a web app that can use some local resources such as the file system, notifications, etc. Is it the best way to make a desktop app? Nope. Do I like the fact that Electron, when not optimized, is a pig? Nope.
But me choosing between Electron and a more native platform it is literally the difference between me shipping something or nothing at all.
You might be able to make the point that it's both a budget and a schedule problem, but that involves some reading between the lines. Different people are going to interpret "budget" and "schedule" differently.
Also, every situation is different, as some individuals/organizations have the existing skills to do a native app without learning/retooling and assume the situation is the same everywhere else.
Companies like slack are externalizing costs to the customer. Instead of them spending money on developing a proper app, they let the customer provide them a runtime for their prototype which needs 1gigabytes and gigahertz for a chat app! What a waste. While this seems ok in the individual case - obviously people are buying it, it’s madness globally.
It's always been. But the web stack is the most widely supported, low development effort target we know and even though it's bad, there's value in integrating and expanding it.
A good alternative that is coming to fruition is a modern alternative to Qt called libui [1]. Description from the project page: "Simple and portable (but not inflexible) GUI library in C that uses the native GUI technologies of each platform it supports."
There are bindings for it in many languages, like Node.js, Rust, Swift, Kotlin and more.
Seems like the only argument here is: “web apps are slow and use a lot of resources”
This isn’t a great argument by itself. There are many reasons that web apps are superior and more convenient than desktop apps. If this wasn’t the case, then why are web apps winning?
I don’t want to download and execute a binary just to read my email, make a video call, or read the news. Web apps are also cross platform. You can pretty much guarantee that gmail will work the same on windows, Mac, Linux, Chrome OS, and even iOS and android (with some idiosyncrasies). Web apps also update themselves, they take up no space on your computer, and can be customized using browser plugins.
I’d take these advantages over saving a few gigs of ram, which I have plenty of.
Objectively, web apps seem to be winning as they let the companies keep control over application and data. With a bonus that they can monitor/track usage.
That is, few, if any, technical advantages for users. Just fewer choices, as well.
> If this wasn’t the case, then why are web apps winning?
Because that’s usually all that’s being provided? I don’t think it’s valid to say web apps are “winning” when in many cases they’re the only 1st party option.
I don’t have any figures to back it up but I would not be surprised if the native app versions of Twitter, Facebook, Instagram etc. see far more use than their equivalent web app versions.
> I’d take these advantages over saving a few gigs of ram, which I have plenty of.
That’s all well and fine until everyone decides to make the same decision, and suddenly every application needs its own instance of Chromium to run.
Don't forget that most users do not get to choose what software they have to use (think internal software in a big company, or you have to use whatever company x gives you to deal with their cloud, etc). And most software designers do not use their own products (outside perhaps of software development products). So there is a "good enough for the dog" element in these designs.
Sure, everyone loves hand-crafted, beautiful, native apps. But I will tell you this: it is possible to build a great app using any technology. It’s just a matter of taste & effort. My favorite tool that helps me get my day job done is VSCode. Do I care whether or not the damn thing is native or not? NO! Do I care that it gobbles some meager gigs? NO! Memory not being used is memory being wasted. Use my RAM, dammit. I can buy more. Use whatever you have to do to keep making this lovely thing that saves me so much time everyday and practically reads my mind as a JS developer! It has a elegant, raw beauty to it that totally fits my needs.
If it uses some hybrid web technology stack, what do I care? Is it great? To me, yes!
if you have been using computers and applications that come with them for a while you have an intuitive sense how how big, how fast, and how much resources some of them should take.
that's what is happening here.
most people who are disagreeing with you know intuitively that it is not right, for a chat app -- going for an easy target here -- to grab all your available resources.
> When apps are built for mobile, battery usage is a major area to optimize on.
I worked on some heavy duty mobile apps like music streaming and unfortunately battery usage is the last thing we optimize for.
The platform even provides us with some ways to measure it, but it is just so remote from the metrics we do optimize for that except for major problems, we don't focus on it in the slightest.
>Mobile apps run at 60fps out of the box without much effort.
Technically fps is not the best way to measure this (we tend to focus on dropped frames instead, unlike most video games engines; mobile will not recompose your UI if nothing moves, saving cycles and heat)
Lots of efforts have actually been made to optimize mobile apps. We are starting to reach a point where we do have a top to bottom approach for reasonable performances (try to scroll any app insanely fast .. you will drop frames, but in regular usage; dropped frame are not too noticeable on recent top of the line phones).
Agreed on the article though. Nothing more irritating than running a legitimately demanding application, seeing that it does not have enough resources and realize that a small web app in the background is using 37 cores and 50% of your cpu while you are not even using it (that was whatsapp just now).
As someone who agrees that every electron app appears bloated, but wants a minimal fuss, feature rich, attractive, cross platform UI, what are my other options?
Browsers and things like Electron are just run-times. The browser's main advantage is cross-platform compatibility. But only kinda-sorta as any web developer can tell you. Your code is usually targeting 3 different run-times at a minimum and there are always problems with anything non-trivial.
It is easy to imagine something much better, where your code runs on a nice tidy runtime native to the OS, with relatively easy layout tools and a language that is better than JavaScript (and really, what language isn't?). It'd be nice and fast, and rewarding to develop in.
If we are starting anew, with fresh eyes, and we were handed browsers, with JavaScript, CSS, and the DOM, we'd be like, "This is complete BS. Visual VB for DOS has this beat."
But because it grew organically, with instantly built in lock-in, and we're now thoroughly indoctrinated, the Stockholm Syndrome lives on.
If you can just take 3 steps back it's fairly obvious. But people would rather just keep making the next React or Bootstrap and digging the hole deeper than make something better.
Someday, make my words, there will be a cross-platform runtime that doesn't suck, that doesn't use JavaScript, and won't the stupid mistakes of the JRE, and developers will abandon web browsers as a platform in droves. I mean, can you really see this as the state of affairs in 2030? 2040? That'd just be sad.
The biggest reason is probably that you don't need the user to explicitly download and install your app. Also, a web app works on all the major OSes with a single GUI environment. And then of course the fact that webapps run in a more secure sandbox. A standard cross API and sandbox could potentially solve the second two. But I'm not sure how to solve the first outside of a browser.
A big part of this browser creep was simply that there was friction and danger in native apps, but our demand for more kinds of apps was insatiable and the browser was able to soak up that demand. When you ran Windows 95, a misbehaved, even well-intentioned app could wreck your hard drive with relative ease. Most did not, but there are horror stories. And when you went to download it, well, nobody wanted all the clicks of downloading and installing. As ever, the average computer user is undisciplined and impatient. The market provided for this by pushing the browser as far as it could go, because it did text, forms and images and when you have those and a CGI script, you have an app.
But now we have gone full circle to the browser being the operating system, and unsurprisingly, it's really bad, being in the position of being a "terrarium" for sandboxing all kinds of software behind an API of some sort.
Nowadays we have the alternative models of the curated package manager/app store and more extensive virtualization techniques available. Last night I wanted to try an old Windows 3.1 game. It took a few hours to gather and configure everything but I eventually got DOSBox and Windows 3.11 for Workgroups installed and configured with all the drivers, and the game worked. But the experience of installing this antiquated software reminded me of how Windows itself was a solution to a related kind of compatibility problem: Every program on MS-DOS had ended up in the position of shipping drivers for everything - printer drivers, sound card drivers, SVGA drivers. The solution of Windows was to build a ton of APIs to hide the hardware, just like the browser hides the native APIs. And this solution is a kludge, but a productive one for the near term. It's premised on I/O being bespoken enough that it doesn't have a standard, but not so much so that it can't be addressed in some standardized form. And emulators take that thought in the other direction, adapting new, more capable I/O to old.
But I don't think more terrariums (new runtimes) are necessarily the productive way forward. This always comes down to basic theories in and around CS - digital signal processing, Turing completeness, structured programming, relational data. The runtime is a certain endpoint of data that formats to an I/O medium, but it develops the terrarium structure when we start accommodating all forms of media and saying "well, you can set it up in any configuration".
I think Flutter is an attempt to answer that question. Whether it succeeds is not yet clear, but what is clear is that it is trying to answer the right question.
Look, I get it, "less web apps" is an easy post to write these days, but all I ask is that we tone down the FUD. Let me just pick off the inaccuracies that will likely stick the most:
> But building for the web(and electron) forces you to HTML/Javascript(and derivates).
This is incorrect. Electron supports Objective-C, C++, Rust, and obviously WASM (amongst others). If you want to build native code (and native UI) in any of these languages, go for it. Countless Electron apps have native components.
> It has no type safety, memory leaks are common and it’s slow due to its dynamic nature.
TypeScript has been a thing for a while now. [Citation needed] for the statement that memory leaks are more common than in, say, C++. Slow: Yes, it's slower, but probably by _a lot_ less than you think[1].
> And it’s laughable how weak the browser platform itself is. SQLite is available on raspberry pi, embeddable systems, mobile platforms and just about every other platform on the planet.
I agree, SQLite is fantastic. We don't really have to argue whether IndexDB will get thee job done, because native bindings to use SQLite with Electron exist. Just... use it.
And lastly...
> These days to send a text message over Slack I need over 1GB of RAM. [...] Even basic apps with all of their trackers, external javascript scripts and doms take up 100s of MBs in memory.
We're always working on performance and we're quite far from the place I'd like us to be at, but it'll send your message just fine if you have less than one GB of memory installed in your whole machine. Even if you're a heavy user, your memory _should_ be below one GB. To be clear, I'll say it again: Yes, things should be better and we'll keep working on performance. The post mentioned Instagram earlier, which I'd say goes a bit beyond the most basic app, and it's using a humble 40MB on my machine.
Disclaimer: I'm one of the maintainers of Electron and an engineer at Slack. I'm not here to argue opinions or which tool is better for which job, but we should get the basic facts right.
Yes, and typescript is great. But you do need a rigorous approach with it to get type safety on parr with languages like java and c++. And since that type information is lost by the time it gets to the interpretor, it provide any benefit to performance. For example, the js interpretor has to check the types if operands at runtime to perform addition. JIT compilation helps a lot, but if the interpreted language had stronger typing, the JIT compilation could probably do an even better job, since it could make more assumptions.
WASM cannot touch the DOM so C or any other HLL (besides JS) in Electron is strictly limited to the backend. That's not useless but it's certainly a limitation. For the amount of energy one would have to expend to make an Electron app reasonably performant and less of a resource pig, you might as well just write a native app. After all isn't the whole point of Electron to get to MVP the quickest? Electron is a great prototyping tool, but it's a lousy delivery platform.
I just like to add that I never understood how when I just try to edit one of my Slack message (Windows client) it literally takes 100 % of 4@4ghz i5 cores and freeze my system for 2 seconds.
I mean, come on, I'm not asking the impossible here, just editing a single line of text.
I hope one day you go native like Telegram for example which is blazing fast, ultra light and also has clients on Android, Mac, etc.
When there's a major thread on a topic, like https://news.ycombinator.com/item?id=23211851 which is currently at #9, it's better to post follow-up links in the thread rather than as separate submissions. Otherwise the front page gets repetitive.
Author of the article here and the one who made this post. I did post this as a comment on the post you mentioned, but given that I'm already late I haven't seen any upvotes to it. So I decided to make a submission. Sorry about adding to the clutter.
Sorry if the title now appears to be more baity, I was actually intending this to be a response to the Ask HN post on the front page. I figured it would be okay for post Authors to change the title since I can always change it in my original post. EDIT: I have changed the title of my original post.
Very little matters for most pieces of software besides time to ship.
If the average user isn’t technical/is forced to use it, there is no business reason to care about user battery life. There is no business reason to care about user cpu usage.
Any reduction in user resource use would require greater business resource use (i.e one of their engineers needing to learn native). Are users willing to pay more for software that saves their battery life? Generally not, as most don’t even know why their battery is draining or their computer is slow.
They just blame it on viruses, Windows, or general belief that their computer is getting old.
65 comments
[ 2.3 ms ] story [ 121 ms ] threadThere is a need for native apps, however that need is shrinking and, in my opinion, will continue to do so. I also happen to think that's a good thing.
The issue is that developing for a particular OS is, generally, more difficult than developing for the web. The app delivery mechanism is also more convoluted (for native apps) than simply entering a web address in the browser. The web also seems to have more ubiquitous standards that abstract away the differences between OSs - you can, with a high degree of certainty, ensure that your app is usable by 99% of computer users, given the current software they have on their device - with native apps, there is no such guarantee, especially if you're relying on shared libraries.
Browsers are also becoming more feature rich. This has had a negative impact on their memory consumption, but given it's 2020, some may retort "memory is cheap" (I totally disagree with this way of thinking personally). And while some browsers (Chrome, looking especially at you) do a very poor job of memory management, I believe the competitive nature of the browser market will force a reawakening soon, where a lot of the inefficiencies in memory management will have to be eradicated (or vendors risk losing market share). Think back to 2014/15 when Node.js was really becoming established - the PHP team suddenly felt a need to re-optimise their engine for PHP7 (and with dramatic results)... Point is, only after ~20 years at the top did something spur PHP's team on enough to do something about their inefficiencies.
Finally, I can see a future where the line between web and native apps is even more blurred. WebAssembly is the first step, however things could get even more elaborate. Perhaps we could end up with the ability to start docker-like containers from within web apps (given the right permissions, of course) to spin up servers for audio/video/image processing on the client itself, and interact with them via a web page. If we get to this point, native apps may feel even more obsolete.
I know this post relates primarily to the current state, but I felt the need to talk about the future to highlight the marked difference in the rate of innovation in the web ecosystem (fast) vs the native ecosystem (slower). It would not surprise me if the web ecosystem ends up winning in the end. If I was building an app today, and it only requires features I can deliver via the browser, I would almost certainly go the web app route.
Now, if I was building a video processing app today, I'd almost certainly go native, but in a couple of years, my answer may be very different.
I'd say the "need" is shrinking because the number of viable options are shrinking. I'd throw out every single Electron app and replace them with native if it was possible. They're almost always either frustratingly slow or poorly designed. Oftentimes they're both.
I strongly believe we will see some major improvements in the performance of Web apps/Electron, since (a) there is a lot of incentive (b) there are many easy wins to be had in terms of performance.
You could even have the browser allocate a volume or two for the container to use (with the user's permission, of course) to store data locally. And users could be allowed to adjust how much space the volume may use (from some default minimum to unlimited).
And with containers, the client should be reasonably safe even if executing malicious software.
Not even a company like Slack wants to get into the headache of maintaining a couple of native desktop apps, even if they probably have the money to do so.
I've seen great success with this approach for most platforms including mobile as it provides the end-user with a great user experience (you can use all the native UI APIs which provides an experience that the user is already familiar with) as well as extremely high performance with a high degree of code reuse.
Even that part makes it already more work than Electron and I can't think of any meaningful business benefit to not using Electron.
Because everyone optimized for "meaningful business impact" I have no space on my SSD to install your app.
(and even if I install it, it would cause my laptop fans go wild and I go for an alternative / use your app less.)
Even if setting up the code reuse among platforms was trivial, now you have to develop and maintain a new UI project for each platform with different languages, SDKs, dev environments, and other peculiarities.
With a web UI you can target 6 platforms at once with the same UI project: Android, iOS, ChromeOS, macOS, Windows, and web.
I'd add one thing, it's also used because it leverages existing web development skills.
I've made a couple of Electron applications because it simply lets me make a "desktop" app that is basically a web app that can use some local resources such as the file system, notifications, etc. Is it the best way to make a desktop app? Nope. Do I like the fact that Electron, when not optimized, is a pig? Nope.
But me choosing between Electron and a more native platform it is literally the difference between me shipping something or nothing at all.
Also, every situation is different, as some individuals/organizations have the existing skills to do a native app without learning/retooling and assume the situation is the same everywhere else.
Nope, it is because some bullshit MBA can't see beyond quarterly profits.
There are bindings for it in many languages, like Node.js, Rust, Swift, Kotlin and more.
[1] https://github.com/andlabs/libui
This isn’t a great argument by itself. There are many reasons that web apps are superior and more convenient than desktop apps. If this wasn’t the case, then why are web apps winning?
I don’t want to download and execute a binary just to read my email, make a video call, or read the news. Web apps are also cross platform. You can pretty much guarantee that gmail will work the same on windows, Mac, Linux, Chrome OS, and even iOS and android (with some idiosyncrasies). Web apps also update themselves, they take up no space on your computer, and can be customized using browser plugins.
I’d take these advantages over saving a few gigs of ram, which I have plenty of.
That is, few, if any, technical advantages for users. Just fewer choices, as well.
Nope. This is the Java Virtual Machine promise all over again. It didn't work. It doesn't work the same in Safari or Firefox as it does in Chrome.
Because that’s usually all that’s being provided? I don’t think it’s valid to say web apps are “winning” when in many cases they’re the only 1st party option.
I don’t have any figures to back it up but I would not be surprised if the native app versions of Twitter, Facebook, Instagram etc. see far more use than their equivalent web app versions.
> I’d take these advantages over saving a few gigs of ram, which I have plenty of.
That’s all well and fine until everyone decides to make the same decision, and suddenly every application needs its own instance of Chromium to run.
Sure, everyone loves hand-crafted, beautiful, native apps. But I will tell you this: it is possible to build a great app using any technology. It’s just a matter of taste & effort. My favorite tool that helps me get my day job done is VSCode. Do I care whether or not the damn thing is native or not? NO! Do I care that it gobbles some meager gigs? NO! Memory not being used is memory being wasted. Use my RAM, dammit. I can buy more. Use whatever you have to do to keep making this lovely thing that saves me so much time everyday and practically reads my mind as a JS developer! It has a elegant, raw beauty to it that totally fits my needs.
If it uses some hybrid web technology stack, what do I care? Is it great? To me, yes!
Make great apps. I don’t care how you do it.
if you have been using computers and applications that come with them for a while you have an intuitive sense how how big, how fast, and how much resources some of them should take.
that's what is happening here.
most people who are disagreeing with you know intuitively that it is not right, for a chat app -- going for an easy target here -- to grab all your available resources.
I worked on some heavy duty mobile apps like music streaming and unfortunately battery usage is the last thing we optimize for.
The platform even provides us with some ways to measure it, but it is just so remote from the metrics we do optimize for that except for major problems, we don't focus on it in the slightest.
>Mobile apps run at 60fps out of the box without much effort.
Technically fps is not the best way to measure this (we tend to focus on dropped frames instead, unlike most video games engines; mobile will not recompose your UI if nothing moves, saving cycles and heat) Lots of efforts have actually been made to optimize mobile apps. We are starting to reach a point where we do have a top to bottom approach for reasonable performances (try to scroll any app insanely fast .. you will drop frames, but in regular usage; dropped frame are not too noticeable on recent top of the line phones).
Agreed on the article though. Nothing more irritating than running a legitimately demanding application, seeing that it does not have enough resources and realize that a small web app in the background is using 37 cores and 50% of your cpu while you are not even using it (that was whatsapp just now).
Sure, Ableton Live and Final Cut Pro are pretty rad, but how much percent of the population uses such tools?
I even switched from Photoshop to Photopea and from Sketch to Gravit Designer, because they are good enough and much less hassle.
I also like that PWA and Electron made more tools on Ubuntu available. Postman and Gravit Designer are great examples.
Memory consumption and performance are problematic though for a lot of them - Electron apps especially.
Browsers and things like Electron are just run-times. The browser's main advantage is cross-platform compatibility. But only kinda-sorta as any web developer can tell you. Your code is usually targeting 3 different run-times at a minimum and there are always problems with anything non-trivial.
It is easy to imagine something much better, where your code runs on a nice tidy runtime native to the OS, with relatively easy layout tools and a language that is better than JavaScript (and really, what language isn't?). It'd be nice and fast, and rewarding to develop in.
If we are starting anew, with fresh eyes, and we were handed browsers, with JavaScript, CSS, and the DOM, we'd be like, "This is complete BS. Visual VB for DOS has this beat."
But because it grew organically, with instantly built in lock-in, and we're now thoroughly indoctrinated, the Stockholm Syndrome lives on.
If you can just take 3 steps back it's fairly obvious. But people would rather just keep making the next React or Bootstrap and digging the hole deeper than make something better.
Someday, make my words, there will be a cross-platform runtime that doesn't suck, that doesn't use JavaScript, and won't the stupid mistakes of the JRE, and developers will abandon web browsers as a platform in droves. I mean, can you really see this as the state of affairs in 2030? 2040? That'd just be sad.
Edit: typo
Yeah, cause that's how every native platform has been since the begining. Yet the web still needed to be invented. Why?
But now we have gone full circle to the browser being the operating system, and unsurprisingly, it's really bad, being in the position of being a "terrarium" for sandboxing all kinds of software behind an API of some sort.
Nowadays we have the alternative models of the curated package manager/app store and more extensive virtualization techniques available. Last night I wanted to try an old Windows 3.1 game. It took a few hours to gather and configure everything but I eventually got DOSBox and Windows 3.11 for Workgroups installed and configured with all the drivers, and the game worked. But the experience of installing this antiquated software reminded me of how Windows itself was a solution to a related kind of compatibility problem: Every program on MS-DOS had ended up in the position of shipping drivers for everything - printer drivers, sound card drivers, SVGA drivers. The solution of Windows was to build a ton of APIs to hide the hardware, just like the browser hides the native APIs. And this solution is a kludge, but a productive one for the near term. It's premised on I/O being bespoken enough that it doesn't have a standard, but not so much so that it can't be addressed in some standardized form. And emulators take that thought in the other direction, adapting new, more capable I/O to old.
But I don't think more terrariums (new runtimes) are necessarily the productive way forward. This always comes down to basic theories in and around CS - digital signal processing, Turing completeness, structured programming, relational data. The runtime is a certain endpoint of data that formats to an I/O medium, but it develops the terrarium structure when we start accommodating all forms of media and saying "well, you can set it up in any configuration".
“And it’s laughable how weak the browser platform itself is.”
Which begs the question of why then do developers use web/electron?
Ubuiqity, cross-platform, distribution, updates... and, yes, some developers also prefer web api.
Perhaps the question is how do we bring a web/election experience to native apps?
> But building for the web(and electron) forces you to HTML/Javascript(and derivates).
This is incorrect. Electron supports Objective-C, C++, Rust, and obviously WASM (amongst others). If you want to build native code (and native UI) in any of these languages, go for it. Countless Electron apps have native components.
> It has no type safety, memory leaks are common and it’s slow due to its dynamic nature.
TypeScript has been a thing for a while now. [Citation needed] for the statement that memory leaks are more common than in, say, C++. Slow: Yes, it's slower, but probably by _a lot_ less than you think[1].
> And it’s laughable how weak the browser platform itself is. SQLite is available on raspberry pi, embeddable systems, mobile platforms and just about every other platform on the planet.
I agree, SQLite is fantastic. We don't really have to argue whether IndexDB will get thee job done, because native bindings to use SQLite with Electron exist. Just... use it.
And lastly...
> These days to send a text message over Slack I need over 1GB of RAM. [...] Even basic apps with all of their trackers, external javascript scripts and doms take up 100s of MBs in memory.
We're always working on performance and we're quite far from the place I'd like us to be at, but it'll send your message just fine if you have less than one GB of memory installed in your whole machine. Even if you're a heavy user, your memory _should_ be below one GB. To be clear, I'll say it again: Yes, things should be better and we'll keep working on performance. The post mentioned Instagram earlier, which I'd say goes a bit beyond the most basic app, and it's using a humble 40MB on my machine.
Disclaimer: I'm one of the maintainers of Electron and an engineer at Slack. I'm not here to argue opinions or which tool is better for which job, but we should get the basic facts right.
[1]: https://www.youtube.com/watch?v=81CECdKCJNc
Yes, and typescript is great. But you do need a rigorous approach with it to get type safety on parr with languages like java and c++. And since that type information is lost by the time it gets to the interpretor, it provide any benefit to performance. For example, the js interpretor has to check the types if operands at runtime to perform addition. JIT compilation helps a lot, but if the interpreted language had stronger typing, the JIT compilation could probably do an even better job, since it could make more assumptions.
I just like to add that I never understood how when I just try to edit one of my Slack message (Windows client) it literally takes 100 % of 4@4ghz i5 cores and freeze my system for 2 seconds.
I mean, come on, I'm not asking the impossible here, just editing a single line of text.
I hope one day you go native like Telegram for example which is blazing fast, ultra light and also has clients on Android, Mac, etc.
Bests,
https://hn.algolia.com/?dateRange=all&page=0&prefix=true&que...
Also, please don't rewrite titles to make them more baity - this is in the site guidelines: https://news.ycombinator.com/newsguidelines.html.
Sorry if the title now appears to be more baity, I was actually intending this to be a response to the Ask HN post on the front page. I figured it would be okay for post Authors to change the title since I can always change it in my original post. EDIT: I have changed the title of my original post.
Fixed your title!!
This is the replacement for Electron/Web.
Built on top of ReasonML which offers a JavaScript like syntax (and supports your favorite libraries too)
Revery UI can successfully target web, native desktop for Mac, windows & Linux with mobile coming soon. The case studies are great!
If the average user isn’t technical/is forced to use it, there is no business reason to care about user battery life. There is no business reason to care about user cpu usage.
Any reduction in user resource use would require greater business resource use (i.e one of their engineers needing to learn native). Are users willing to pay more for software that saves their battery life? Generally not, as most don’t even know why their battery is draining or their computer is slow.
They just blame it on viruses, Windows, or general belief that their computer is getting old.