Hacker News Reader

Hacker News

Comment by headcanon | Hacker News Reader

Full thread

headcanon

Every time Electron is mentioned I bust out the popcorn for the inevitable hate spewed towards it:

"Javascript is a terrible language and no one should use it"

"Separate instances of chrome for every app is dumb and consumes too much memory"

"Qt is amazing and elegant and desktop-native. Why isn't everyone just using Qt?"

View on HN

> "Separate instances of chrome for every app is dumb and consumes too much memory"

That one is true though. Different Electron apps could at least share the runtime.

I imagine the different electron versions and different Chrome versions would make this hard without breaking things. Maybe a config option for "allow chromium between versions x and y" would solve this.

Shouldn‘t Chrome be backwards compatible? I would hope so at least.

Most electron projects I've seen have used webpack targeting ES2017 or earlier anyways which makes this unlikely, but if you compile for ESnext (or don't compile at all) and use a new V8 feature, you wouldn't want Chrome 69 running your app and getting stuck on old V8 not being able to use the new feature.

Maybe it should, but it's not always the case. As a front end dev I have to fix issues related to bugs introduced by browser uptades every now and then and usually it's Chrome. On the web it's easy, deploy a fix and it's live. With a desktop app I can't even imagine the logistics involved.

Is that really possible? I feel like it would only work with considerable engineering effort, and even then, probably only if the bundled Chrome instances were all exactly the same version.

This is literally how every gui library on planet earth works. Developers all build against a particular recent released version with all apps in the system expected to build against a small number of recent versions.

If this is hard maybe its because the browser isn't a very good runtime to build against.

Right, but those systems are set up from the get-go with that usage pattern in mind, where you have an expectation of ABI compatibility and the underlying libraries as a shared resource.

The expectation with Electron has always been that you bundle a copy of it with your app, so that you're always targeting exactly that version.

Except they cannot, Chromium (or is it Blink?) changes too frequently to reliably code for one version and expect backward compatibility of future releases. Electron versions could be shared libraries... except again BC breaking releases proliferate.

Websites manage to target different versions, and browsers, and even device classes just fine.

Why can't it be based of Chrome's version number? If you know the version number at the time of release then you can say only use the same runtime if there's only a revision version difference, else you can use it's own run time. That packaged with auto-updates for the app to that developers can push updated builds every month or so should be fine.

Except they chose not to, preferring to allow for frequent breaking changes. This makes it easier for devs to make these rapid changes with all the cost/overhead payed by you.

With their multi-process approach, you'd have separate processes even when sharing the runtime to the point that sharing the DLLs likely has minimal benefit. It's the equivalent of running firing up Chrome twice w/ two different user profile dirs...shared libs, but no obvious perf advantage over two separate Chrome installs.

1) Log into Slack in Chrome

2) Log into Discord in Chrome

3) Log into <insert application here> in Chrome

Problem solved?

Swap Firefox for Chrome and you are golden.

The problem with Qt I have is how incredibly expensive it is. Sure it's free if you want to build something open source, but you know some of us have to also make money to pay for being alive and it's hard to bootstrap an application if you have to pay $5,508 up front, per developer, and then again on an annual basis.

You can use Qt with closed source software, under the LGPL license that you don't have to pay for. Only the binaries that have Qt code need to be open. Don't statically link Qt libs into your closed-source code and you're good.

And put that in an app store?

Yes, even on iOS.

The LGPL requires end users to be able to view and modify the LGPL portion of the derivative work. Does iOS give end users that level of access to apps? (honest question, my outsider's impression of Apple is that they have stuff locked down more than that)

the problem with iOS was that you had to pay 99$ a year to upload apps to your own phone, which prevent use of GPL code since it removes your right to do stuff on your own hardware. Fortunately this restriction was lifted since Xcode 7 a few years ago and it's nowadays not a problem at all - there are plenty of GPL / LGPL apps on the app store. Just put the code and build instructions on github, what matters is that users can patch, rebuild and upload the patched version to their phone.

There was an iOS email client a few years back that used some LGPL components. They complied by providing the object files so you could, in theory, re-link (and re-sign) using your own updated LGPL library.

Ahh, here we go:

https://news.ycombinator.com/item?id=4302517

https://web.archive.org/web/20140325063249/http://sprw.me/lg...

Let me preface by emphasizing that IANAL, but I believe the issue isn't with the software vendor and is instead with the distribution platform (i.e Apple).

The LGPLv3 mandates that users be allowed to modify the parts that are licensed by this license. The TOS of the Apple App Store explicitly disallows its users from modifying software they get from it, thereby running afoul of the LGPL.

So this issue, as I understand it, is that neither the software vendor nor Apple have a license to distribute Qt on a platform that places additional restrictions on what the user may do with LGPL software. I think this is the reason why Apple removed VLC and other GPL software from their stores.

Please correct me if I got this wrong.

Cant edit my post, but here are a few links that you might find interesting:

* FSF's opinion: https://www.fsf.org/news/2010-05-app-store-compliance

* General conscious: https://apple.stackexchange.com/questions/6109/is-it-possibl...

The core of Qt is licensed under LGPL which means you can write and ship proprietary software with it. You just need to dynamically link and provide sources for the Qt libs if a user requests it.

you know some of us have to also make money to pay for being alive and it's hard to bootstrap an application if you have to pay $5,508 up front, per developer, and then again on an annual basis

Are you really surviving on $5,500 annually?

$5.5k annually, even in the US, is still enough money to devote a few hours per week on a paid hobby project. I'm actually working on a side-project app right now, and if it makes >5.5k/year I'd be fairly pleased.

Not enough to survive on, but as a sideline business that isn't terrible money as long as it doesn't consume 40 hours/week.

I can't fathom how do people still don't understand the licensing and keep posting FUD about it.

Every single time. How it's even possible?

No, you don't have to pay anything to build and sell your proprietary software built with Qt.

I see this out of date myth on every HN page discussing Qt. The fact that people still don't know that Qt is LGPL is damaging.

The people complaining are not the customers, they're the product. Electron isn't sold to the users running Slack and Spotify and Atom, it's sold to the developers of those things with the promise of a low-friction path for existing web devs to deploy a native-ish application on multiple platforms.

Only second one is a really valid point;

I would use Uno.platform . C++ is also a terrible language.

Reply on news.ycombinator.com