[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.

[evv]

Slack was able to stand out from its competitors by providing a reasonably fast web app. Nobody cared (cares?) about the desktop app.

It sure seems like you can compete with a good feature set and fast iteration on your product. Throwing more web developers on the project is often the right call, so you can keep shipping new features quickly on every platform.

I'd love to be proven wrong, but performance seems to be an afterthought to the market.

[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.

[evv]

What if that business wants to provide an "app" icon in the macOS dock, and a "program" in the windows start menu, without hiring a bunch of native developers? What would you advise for them, if not electron?

[ascorbic]

And asking to drop Linux support.

[scarface74]

Is that a bad thing? What does the Slack "native" app do that the website doesn't? The website supports push notifications on the desktop.

[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.