Live data from Hacker News

Electron v5.0 Timeline

electronjs.org

91–100 of 101 posts

Re: Electron v5.0 Timeline

#92

Using Electron is a travesty. Why not something like "sciter" ?

I've seen sciter come up in discussion on quite a few threads related to Electron and other web browser embedding systems, but I've never seen a good answer for "why not sciter", so I'll try to put some points out here:

1. Electron is open source, sciter is free as in beer only. 2. Electron implements the exact same javascript as the web, sciter implements its own js-like language. Harder to find developers with experience, and harder move your app from sciter to some other engine down the line. 3. Electron implements the exact same html/css as the web, sciter implements html/css from a few years back plus its own proprietary bolt-ons. Same problems as #2.

Re: Electron v5.0 Timeline

#93

What is the upgrade process like for existing applications built on the Electron framework? Is it well documented and a first consideration or are you thrown to the wind? Will 4 be able to move to 5 or are we talking about rewrites?

It's pretty well documented.

If you are just using Electron "off the shelf" to host your web app it's generally `npm install` the updated binary, test, and deploy.

Sometimes an Electron-only API changes, but that's pretty rare and most of them aren't "mission critical" if they break. That's always documented well in the release notes and the API and Electron for the most part seems to follow a "deprecate for a version ahead" pattern that you should have plenty of warning.

If you are using native libraries is where things get complicated. At that point you are likely building your own Electron binary, and need to find updated versions of your libraries that support the upgrade NodeJS and/or Chromium versions. Most of that is the same documentation whether or not Electron was in the project, check the related documentation for the appropriate NodeJS and/or Chromium versions, rebuild as needed using the usual tools.

Re: Electron v5.0 Timeline

#94

What is the upgrade process like for existing applications built on the Electron framework? Is it well documented and a first consideration or are you thrown to the wind? Will 4 be able to move to 5 or are we talking about rewrites?

It's pretty well documented. If you are just using Electron "off the shelf" to host your web app it's generally `npm install` the updated binary, test, and deploy. Sometimes an Electron-only API changes, but that's pretty rare and most of them aren't "mission critical" if they break. That's always documented well in the release notes and the API and Electron for the most part seems to follow a "deprecate for a versio…

Great response, thank you!

Re: Electron v5.0 Timeline

#95
post #29
post #18

Earlier quoted context omitted.

Probably OK for some uses, like when you publish as a web app anyway, but for others it burdens you with keeping up with the aggressive release cycle of browsers.

Agree, but it isn't like OSes also don't change their API space or behaviors. Unless one only cares about fossilized UNIX and Win32.

> Agree, but it isn't like OSes also don't change their API space or behaviors.

They change, but more slowly with better backward compatibility, but more important is when they change. In a corporate environment they might update the OS once a decade and on a schedule you control which is much more manageable than relying on a layer that updates itself every 6 weeks.

> Unless one only cares about fossilized UNIX and Win32.

You say that like stability is a bad thing.

Re: Electron v5.0 Timeline

#96
post #43

Earlier quoted context omitted.

Then you get into the issue of keeping apps and runtime in sync so you don't get issues with older apps not working well with a new version of the runtime required by newer apps... You end-up having to keep multiple runtimes and hoping they don't step on each-other's toes... After a while you're still downloading 200+MB runtimes to run your particular app that still requires Runtime 5.05 and hasn't been updated to wo…

easy. you just add sth like elsched.exe that keeps checking for updates in the runtime, then opens a popup saying "Electron Update Available".

Then the Electron Runtime is updated but breaking the particular App that was relying on a feature that has changed since its publication. The problem is not updating the Runtime, it's ensuring that the apps relying on the runtime still work properly after feature updates in the runtime.

Re: Electron v5.0 Timeline

#98
post #95
post #29

Earlier quoted context omitted.

Agree, but it isn't like OSes also don't change their API space or behaviors. Unless one only cares about fossilized UNIX and Win32.

> Agree, but it isn't like OSes also don't change their API space or behaviors. They change, but more slowly with better backward compatibility, but more important is when they change. In a corporate environment they might update the OS once a decade and on a schedule you control which is much more manageable than relying on a layer that updates itself every 6 weeks. > Unless one only cares about fossilized UNIX and…

Stability is good, but not when it becomes an obstacle for advancing the state of art in OS development, as many cling to the ways of yore and we get CLI apps with coloured terminals as improvement or WinForms database frontends in bigger screens.

Re: Electron v5.0 Timeline

#99
post #59

Earlier quoted context omitted.

Chromium changes a lot. One of my teams tried integrating it directly and couldn't keep up with the API change. We went with a 3rd party library that wraps it to shield us from it.

Which 3rd party library ? :)

jxbrowser. It's worked well for us.

Re: Electron v5.0 Timeline

#100
post #63

Earlier quoted context omitted.

Chromium changes a lot. One of my teams tried integrating it directly and couldn't keep up with the API change. We went with a 3rd party library that wraps it to shield us from it.

I'm very curious, which library did you end up using?

JxBrowser. Went from a native c implementation and wrapper to java based. Application size went up (by a lot) but it's far easier to get things done when you don't have to find someone who knows objective C in a java shop.
Post reply on HN