Using Electron is a travesty. Why not something like "sciter" ?
Because it costs at least $1000 for year?
Electron v5.0 Timeline
91–100 of 101 posts
Re: Electron v5.0 Timeline
#92Using Electron is a travesty. Why not something like "sciter" ?
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
#93What 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?
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
#94What 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…
Re: Electron v5.0 Timeline
#95Earlier 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.
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
#96Earlier 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".
Re: Electron v5.0 Timeline
#97Using Electron is a travesty. Why not something like "sciter" ?
Re: Electron v5.0 Timeline
#98Earlier 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…
Re: Electron v5.0 Timeline
#99Re: Electron v5.0 Timeline
#100Earlier 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?