Live data from Hacker News

Electron 7.0

electronjs.org

191–200 of 289 posts

Re: Electron 7.0

#191

Earlier quoted context omitted.

> It's a bit silly every application would follow the same guidelines as applications are intended to do different things. Platform UX/UI conventions place too strict limitations on innovation. They really don’t. Have you taken a look at the thriving ecosystem of native, powerful macOS apps that follow platform conventions?

Most apps that I know people use in MacOS are really not native-controls based - Ableton Live, Max/MSP, VDMX, Resolume, Mathematica, JetBrains IDEs, VSCode, Sublime Text...

I'm pretty sure the parent was talking about macOS exclusive apps. The ones I recognize there are all multi-platform, which have always had the problem of keeping their own conventions between platform or adopting the platforms--most chose to keep their app consistent platform-to-platform.

I also think "professional" apps are a special case (which is a totally subjective classification). Even Apple and Microsoft have done their own thing for professional apps since forever. If I'm going to use that app for 8hrs every day, I'm more accepting of learning something new. I'm still more likely going to pick up an app if it follows existing conventions...I already chose my OS because I've learned and like those conventions.

Re: Electron 7.0

#192

Earlier quoted context omitted.

I release two apps, across 3 OSes, in somewhat of a bimonthly cadence with a low defect rate. That’s 6 different binaries. I’m a solo founder. I know people like to rag on Electron, but without it, I wouldn’t be using something else, my apps just wouldn’t exist . It allows more people to try building more thing and that is a net positive. The speed problems and bloat issues of Electron is just shoddy programming on t…

> I release two apps, across 3 OSes, in somewhat of a bimonthly cadence with a low defect rate. That’s 6 different binaries. I’m a solo founder. I release a Qt app for mac / windows / linux whenever I want by tagging a git commit and letting it be built by CI services. There is a single code base with almost zero platform-specific code. I really don't think that the technology choice is what matters in this.

How is Qt support for mobile platforms?

Re: Electron 7.0

#193

Earlier quoted context omitted.

>The speed problems and bloat issues of Electron is just shoddy programming on the maker’s part - Electron itself isn’t slow. I doubt this is entirely true. VSCode is frequently cited as an example of a good, performant Electron application. Its performance is generally acceptable (I use it as my primary text editor), but it absolutely chugs sometimes. Sublime is light-years ahead in terms of performance.

That is true and as a user of Sublime myself, I agree. However, VSCode is still a JS app that has to do its computation on a single thread, on a largely interpreted language. If you do it the way I do and use Electron as a skin / thin client to a compiled binary within the package, you remove that bottleneck. That way, you get both cross-OS capabilities, a familiar UI toolkit (JavaScript, I use Vue) and native binary…

I really hope this is the sort of thing products like VSCode will start turning to WASM for. Performance is their Achilles heel for the time being even though they’ve done a relatively good job considering.

Re: Electron 7.0

#194
post #191

Earlier quoted context omitted.

Most apps that I know people use in MacOS are really not native-controls based - Ableton Live, Max/MSP, VDMX, Resolume, Mathematica, JetBrains IDEs, VSCode, Sublime Text...

I'm pretty sure the parent was talking about macOS exclusive apps. The ones I recognize there are all multi-platform, which have always had the problem of keeping their own conventions between platform or adopting the platforms--most chose to keep their app consistent platform-to-platform. I also think "professional" apps are a special case (which is a totally subjective classification). Even Apple and Microsoft have…

There are a couple that are cross platform and still native, such as Microsoft Office and the Affinity suite.

Re: Electron 7.0

#195
post #193

Earlier quoted context omitted.

That is true and as a user of Sublime myself, I agree. However, VSCode is still a JS app that has to do its computation on a single thread, on a largely interpreted language. If you do it the way I do and use Electron as a skin / thin client to a compiled binary within the package, you remove that bottleneck. That way, you get both cross-OS capabilities, a familiar UI toolkit (JavaScript, I use Vue) and native binary…

I really hope this is the sort of thing products like VSCode will start turning to WASM for. Performance is their Achilles heel for the time being even though they’ve done a relatively good job considering.

That would be helpful. Go can compile to WASM natively, so if I could just compile it down to that, I wouldn't even have different Go binaries for different platforms.

That said, some things I use (like SQLite, gRPC) will probably forever remain a C dependency, so I'm not sure if WASM would help with that.

Re: Electron 7.0

#196

Earlier quoted context omitted.

So maintain it as a third party set of patches. So I can run proprietary apps (because that's what these self-professed app devs are talking about mostly)? Not gonna happen. Just because upstream wouldn't accept it doesn't mean that it can't exist. No, it just means it's a lot of unnecessary work for a framework that already has an arduous build process. I haven't found that killer Electron app just yet so what that…

> So I can run proprietary apps (because that's what these self-professed app devs are talking about mostly)? Not gonna happen. Well then you don't want it that bad. > I haven't found that killer Electron app just yet so what that means in practical terms is that VS Code goes bye bye when my MacBook Pro finally dies and I move away from Apple (and likely to OpenBSD) on the desktop. You seem to care an awful lot about…

You seem to care an awful lot about an issue that doesn't seem to affect you. Why?

Because it does effect me. Electron is promoting a monoculture of apps that don't behave well (resource usage, accessibility, abysmal native integration) and they're not portable to boot. What that means in real terms is that more and more that quality native apps become less common and hacky Electron apps become more common. Unless you're using an unsupported configuration, then Electron just means that people are being encouraged to standardize on the lowest common denominator and ignore you.

VS Code? Definitely not my first choice, but its rust support is still better than IntelliJ (or nearly anything else for that matter). But that's network effects for you.

Re: Electron 7.0

#197
post #181

Earlier quoted context omitted.

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)

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

Re: Electron 7.0

#198

I'm bullish on Electron. I think it's just a couple of technical advancements away from being the ultimate desktop toolkit. For context, I love and have worked a ton with Qt, and I much prefer Qt UIs as a user. But Electron has brought true cross-platform development to all platforms (Including Linux!). If it weren't for Electron, I wouldn't even have a bunch of the apps I use today. Hell, I wouldn't have a good IDE,…

glad to see someone else who thinks like this. the way people seem to react to electron apps is very close to "they killed my pappy!" kind of anger.

Re: Electron 7.0

#199
post #159

Earlier quoted context omitted.

Personally I'm fine with application specific UI schemes. It's a bit silly every application would follow the same guidelines as applications are intended to do different things. Platform UX/UI conventions place too strict limitations on innovation. The original point - that people would get confused from non-platform UI schemes - has been proven kind of moot since most games have their own domain specific UI schemes…

> It's a bit silly every application would follow the same guidelines as applications are intended to do different things. Platform UX/UI conventions place too strict limitations on innovation. They really don’t. Have you taken a look at the thriving ecosystem of native, powerful macOS apps that follow platform conventions?

My mac's primary purpose is to run bash, firefox, intellij, and docker. they've all got their own UI, and I don't feel wanting for power.

Re: Electron 7.0

#200

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?"

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

1) Log into Slack in Chrome

2) Log into Discord in Chrome

3) Log into in Chrome

Problem solved?

Post reply on HN