[333c]

Does your distaste for native apps extend to the desktop computer? Many HN users (myself included) dislike Electron-type apps because they feel slow and bloated. On my computer, native apps are much nicer, and feel like they fit in much better with the desktop environment.

If you agree that native apps on the desktop are a good thing, than I think you would agree that, for smartphone users, native mobile apps are a good thing as well, for the same reason.

[jsgo]

VSCode, as far as I'm aware, uses Electron and is great.

Twitter's React web application was so good on performance and hitting all of the marks I used the mobile native application for that I was able to delete the native application saving space, and "adding to homescreen" for like, what, a few bytes of storage?

Facebook I just use the mobile web app inside of Safari proper instead of installing the native app. It's a pain that I have to wait until I'm on my iPad or PC to use messages (I don't install Messenger because I don't want a separate application just for a small feature of Facebook proper), but it's serviceable enough. Would be nice if Facebook would follow Twitter's lead and build a native-like web experience, but I guess they don't feel it adds the value and that's their right.

I'm completely game for people using these things and doing it right and if done so, yeah, I think it is better than or at least equivalent to native (PWAs != Electron apps, but can be served in them). It is also crazy to compare a 32GB-128GB device vs my PC with storage measured in TBs. I can afford bloat on my PC that I would prefer to keep away from my phone.

[jacquesm]

A native app to me is something that works independent of a network connection (with the exception of browsers and an email client, those are obviously pretty useless without and a browser is the 'gateway' to the online world), and without an interpreter. Most mobile phone apps aren't native by that definition, but let's stretch the definition and include binaries targeted at virtual machines.

So native apps that I'm happy to use: compiler, editor, whatever stuff I've written myself, cli tools, bash, ssh, openoffice, okular, Firefox and Thunderbird.

Your typical mobile app is just an extension of someone else's server. As such it should be a web app rather than a native app.

[alain94040]

That's a strange definition. Native usually means that the application uses the platform's native APIs. The application could require a network, or not. I grant you that an app that should not need the network fails to work without a network connection probably means it's not a native app, and instead it's trying to execute on some server somewhere else (like a classic web page for instance).

[mschuster91]

> Many HN users (myself included) dislike Electron-type apps because they feel slow and bloated.

How much of this is the fault of the Electron runtime and how much is fault of the developers?

When one looks at the sheer amount of code that popular frameworks (or, as I call them, crapworks) like Angular require the browser to load, compile and run, plus the resources that these apps end up gulping down... it's madness, compared to how far plain old jQuery will get you while running at a quarter of consumed resources.

Sure, using only jQuery requires lots of thinking about your code structure and it will undoubtedly be more complex. But also: orders of magnitude faster.

[scarface74]

How much of this is the fault of the Electron runtime and how much is fault of the developers?

It's completely the fault of the developer for choosing Electron when there are better tools available.

[Heliosmaster]

What would you use? (honest question)

[scarface74]

If you want a native app, use native tools for each platform to create the best user experience.

[evv]

This is effectively asking to double the size of the engineering team, or slow it down dramatically.

If I were a startup or small business, I'd rather ship a slightly slow-feeling app with my existing team of web developers who already know their tools, than to hire a bunch of native developers and somehow get them all on the same page.

[saagarjha]

> If I were a startup or small business, I'd rather ship a slightly slow-feeling app with my existing team of web developers who already know their tools, than to hire a bunch of native developers and somehow get them all on the same page.

That might be the time where you'd want to stand out from your competitors by shipping a fast, native app rather than a web app.

[scarface74]

Yes. I'm asking a business that want to provide a native client to provide a native client.

If it can be done as a web app why not do it as a web app?

Yes I am a developer and for products that are suited to be on the web, I write websites.

[ascorbic]

And asking to drop Linux support.

[notriddle]

Qt?

[jsgo]

ever used VS Code?

[scarface74]

Yes. I went back to Visual Studio. If I were using a Mac, I would buy Rider in a heartbeat.

[jsgo]

Eh, I like it. It loads quickly and doesn't tap resources. I typically use Visual Studio as well, but I do it when I need to do a quick edit of a file or quickly see syntax highlighting on something to review. Basically, Electron isn't bad. It is most likely the fault of the implementer if it goes that direction.

I think Brackets is served in Electron as well and that seems to be a lesser quality implementation. I like Brackets, but the performance is somewhere between VS Code and a full fledged IDE.

[matthewmacleod]

Sure, using only jQuery requires lots of thinking about your code structure and it will undoubtedly be more complex. But also: orders of magnitude faster.

It’s really, really not. You might be able to pull together some specific targeted DOM manipulation that is faster in jQuery than in React, for example, but the difference is going to be minimal and the development impact substantial.

[mschuster91]

> You might be able to pull together some specific targeted DOM manipulation that is faster in jQuery than in React, for example, but the difference is going to be minimal and the development impact substantial.

The usage difference in RAM and CPU usage will always be massive, because with jQuery (or if you're in for really high performance code, plain JS) you cut all the framework cruft and black magic away.

In addition, I would not be so sure about the development impact. JS frameworks come up every two or three years and vanish in about the same timeframe, yet the good old KISS-based dog jQuery happily barks along. jQuery devs are a dime a dozen, good luck finding someone today who does emberjs (if you want to maintain a legacy project) or knows the innards of the latest compatibility-breaking version of Webpack (if you ditch your legacy project and "relaunch" it).

[matthewmacleod]

I just don’t agree with this from any perspective.

First, the impact is minimal. React or a similar framework is not that big. In fact, React + ReactDOM is roughly the same code size as jQuery - 100k vs 85k minified.

Second, your custom DOM manipulation code is probably going to be a bit less optimised than a widely used library.

Third, you are overstating the difficulty. I would expect any competent front-end engineer to be able to pick up whichever of these frameworks is required. The different skills are a matter of a little on boarding and studying. Of course, there are many unskilled JS developers out there, but I don’t think that’s an excuse.

[Silhouette]

If you agree that native apps on the desktop are a good thing, than I think you would agree that, for smartphone users, native mobile apps are a good thing as well, for the same reason.

That doesn't necessarily follow. The average mobile app is so simple in terms of both the data it's working with and the complexity of its UI that reasonably efficient code is unlikely to challenge a modern mobile device, whether it's native or running within a browser.

[saagarjha]

> The average mobile app is so simple in terms of both the data it's working with and the complexity of its UI that reasonably efficient code is unlikely to challenge a modern mobile device, whether it's native or running within a browser.

Unfortunately, it has been shown time and time again that this isn't the case. Somehow, it seems that web apps just never get the performance that native apps do.

[Silhouette]

Unfortunately, it has been shown time and time again that this isn't the case.

Has it? Web apps might be positively correlated with poor performance, but I don't see any causal relationship there for the kind of apps we're talking about here.

From direct personal experience, some of the UIs I've worked on have been relatively complicated by web app standards, yet typically there's been no perceptible lag in any rendering or interactions. We could achieve that kind of responsiveness at least a decade ago, on much less powerful hardware than sits in your pocket today. Obviously there is an inherent delay in any communication required with the server, which is one of the main areas where PWAs and some of the other modern APIs can help to minimise the effect. Other than that, modern JS runtime environments running on just about any smartphone, tablet or laptop from the past few years are plenty fast enough for the kinds of software most of us are trying to run within them.

Of course, that's not to say there aren't many poorly performing web apps out there. It's just that I've yet to see one where the poor performance was demonstrably attributable to the fundamental web technologies involved, as opposed to simpler explanations like developers who had no idea what they were doing and relied on inefficient designs, bloated frameworks, and so on. You get that with native desktop software as well, but no-one's saying a modern PC can't do things quickly just because someone managed to write yet another text editor that had a noticeable delay just opening a file with a few thousand lines in it.