Electron v5.0 Timeline(electronjs.org)
electronjs.org
Electron v5.0 Timeline
https://electronjs.org/blog/electron-5-0-timeline
100 comments
Does anyone know if the idea of creating a runtime mode for Electron is on the roadmap? (A runtime mode would be allowing multiple apps to share one installed Electron dependency rather than bundling Electron with every Electron app.)
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 work with Runtime 6.12 that is required for newer updates of an app that used to work with Runtime 5.84...
Maybe a better idea would be to make Electron's install specific to each app and only include the bits you actually need so it's a 30MB bundle instead?
Just wondering if calling for a runtime isn't going to make things worse in the long run. It 's already often a pain to install an app that target any framework version in particular that may not be installed or may conflict on some user's target machines. Sometimes it's unavoidable, but I'm wondering if this is really the case here.
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 work with Runtime 6.12 that is required for newer updates of an app that used to work with Runtime 5.84...
Maybe a better idea would be to make Electron's install specific to each app and only include the bits you actually need so it's a 30MB bundle instead?
Just wondering if calling for a runtime isn't going to make things worse in the long run. It 's already often a pain to install an app that target any framework version in particular that may not be installed or may conflict on some user's target machines. Sometimes it's unavoidable, but I'm wondering if this is really the case here.
What ends up happening is that without a shared runtime, now each user is responsible for ensuring he has the latest security fixes in every single of his apps' bundled runtimes, which is much harder to ensure than with a shared runtime.
The users have to track the releases of electron themselves and keep on top of security bugs.
While it may be easier for devs to bundle, it's a major loss and a huge risk to users. Probably much more with non-major apps, where the developer may not care all that much to update bundled runtimes, when he's not adding features to the app itself.
Did you check none of the apps you use are vulnerable to this?[1] Now until every single developer and every single electron app in existence updates their runtimes, they'll be potentially vulnerable to this major privilege escalation bug.
[1] https://electronjs.org/blog/window-open-fix
The users have to track the releases of electron themselves and keep on top of security bugs.
While it may be easier for devs to bundle, it's a major loss and a huge risk to users. Probably much more with non-major apps, where the developer may not care all that much to update bundled runtimes, when he's not adding features to the app itself.
Did you check none of the apps you use are vulnerable to this?[1] Now until every single developer and every single electron app in existence updates their runtimes, they'll be potentially vulnerable to this major privilege escalation bug.
[1] https://electronjs.org/blog/window-open-fix
Fully agree. I've thought about that and the only solution I came up was to only update all your electrons apps at the same time and they would share the minimal electron runtime's version possible. Would also require electron-apps developers to provide all versions of their app (with the runtime version information)
Agree. I think the solution is to make the runtime a lot smaller to the point where download each time becomes a non-issues.
Which isn't really PWA because Electron do offer slightly more capabilities.
Which isn't really PWA because Electron do offer slightly more capabilities.
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.
Yes, that would be very useful to have. Some runtime, or some central application, so that the user just has to download some HTML, CSS and Javascript -- not a complete copy of Electron each time. And if this application could be used to browse the internet when the user enters a URL, that would be useful too! Game changer!
Yes great idea! The different applications (or URLs) could be opened simultaneously and displayed as ‘tabs’ for the user to manage in the central application.
I get the joke, but an Electron "player" daemon seems like a decent idea. It could manage getting the right runtime versions, installing apps, deduping assets and granting permissions.
It'd be a sort of cross-platform Google Play Services.
It'd be a sort of cross-platform Google Play Services.
That would also allow to call one application from another, just assigning some reserved namespace or domain and appending the feature at the end, kind of a path. Exciting times!
How would one remember a collection of these namespaces or the current place within one location? Analogous to physical paper, could we repurpose the concept of a "bookmark"?
To avoid having to update these files on your pc, these could be served by a "server" on the internet. We would have to run cables around the earth so everyone can benefit.
Unfortunately, that would also introduce latency. Plus, I'd like to be able to access these files when I'm not connected to one of these "servers".
First thing we'd have to serve then is some place where stuff like that can be discussed though, maybe some sort of "forum" with "comments" and stuff?
You probably don't need electron to do that, it could be done by any end user. Wondering why it isn't being done!
Oh, you're too brutal to the webdev community. Don't do that. :D
Everyone likes this idea until the HTML, CSS, and JS are given the ability to change application menus and access the file system. Then oh no, we can't have that.
Instead we are encouraging users to download arbitrary binaries bundled with a browser that can be controlled and updated remotely. It’s not clear to me this is any safer.
Java-based GUI applications have been moving from the system's JVM to bundling one due to longstanding and seemingly unfixable reliability and ease of use problems. Why will Electron be different?
The right way to design it would be to allow apps to declare an allowed range of Electron dependency in package.json.
For instance, if my app depends on Electron 5.x, then it will only run if 5.x is installed. If other apps require 4.x, then a system needs to be in place to allow both 4.x and 5.x to be installed on the system simultaneously.
This way if—say—you have five Electron apps running on your system, three of them require Electron 5.x, and two of them require Electron 4.x, then you only need two versions of Electron installed to your system instead of today's approach of bundling one with each app.
Honestly not sure why Java doesn't work this way too. I think .NET does, doesn't it?
For instance, if my app depends on Electron 5.x, then it will only run if 5.x is installed. If other apps require 4.x, then a system needs to be in place to allow both 4.x and 5.x to be installed on the system simultaneously.
This way if—say—you have five Electron apps running on your system, three of them require Electron 5.x, and two of them require Electron 4.x, then you only need two versions of Electron installed to your system instead of today's approach of bundling one with each app.
Honestly not sure why Java doesn't work this way too. I think .NET does, doesn't it?
Java applications can compile to native code and remove needless bloat via linking.
So when is Electron going to support the same features?
So when is Electron going to support the same features?
I have not once seen a Java application that shipped as a native binary. Sure, it can be done, but this is a very rare experience practice.
I have seen plenty on the enterprise, done by companies that actually pay for their tools, or do deployments into embedded targets.
Also Android J++ does AOT compilation, as sidenote.
Now that OpenJDK is starting to offer AOT compilation for free, maybe there will be more adoption among FOSS crowd.
Also Android J++ does AOT compilation, as sidenote.
Now that OpenJDK is starting to offer AOT compilation for free, maybe there will be more adoption among FOSS crowd.
Post: Tries very hard to avoid any use of the word roadmap
First comment: Hey is X on the roadmap?
First comment: Hey is X on the roadmap?
You can use Chrome + NodeJS as the shared runtime instead of Electron, using an approach such as this: https://github.com/GoogleChromeLabs/carlo
You still need to bundle a copy of NodeJS with your app if you're not targeting developers, but that's much smaller.
Of course, this still has many of the issues that a shared copy of Electron will have - you need to make sure that your app stays compatible as Chrome is updated. The HTML/JS side is typically not an issue, but the devtools protocol that you need for this does get breaking changes now and then.
You still need to bundle a copy of NodeJS with your app if you're not targeting developers, but that's much smaller.
Of course, this still has many of the issues that a shared copy of Electron will have - you need to make sure that your app stays compatible as Chrome is updated. The HTML/JS side is typically not an issue, but the devtools protocol that you need for this does get breaking changes now and then.
I think MS fully intends to have something like Electron available for apps to use as a target on Windows. They are desperate to make things easy as possible so devs of consumer apps don't abandon the platform or just make general performance worse by targeting standalone Electron.
macOS is experimenting with UIKit, so we'll see how that plays out. But I wouldn't be completely surprised a few years from now if they announced a Safari-based competitor to Electron that has obvious benefits, like battery life and GPU acceleration everywhere.
macOS is experimenting with UIKit, so we'll see how that plays out. But I wouldn't be completely surprised a few years from now if they announced a Safari-based competitor to Electron that has obvious benefits, like battery life and GPU acceleration everywhere.
I think it would be nice to see this happen, it could be what Adobe's Air platform was supposed to be... I would think that MS could do it relatively easily.
The biggest risk, however are those modules that are compiled to the platform and node version in question. There are now some abstractions that make this easier, but it's still far from perfect. And depending on the application there are more or fewer risks of this being a problem.
As it stands SQLite is specifically one of the most used compiled modules alone and is used in many projects.
The biggest risk, however are those modules that are compiled to the platform and node version in question. There are now some abstractions that make this easier, but it's still far from perfect. And depending on the application there are more or fewer risks of this being a problem.
As it stands SQLite is specifically one of the most used compiled modules alone and is used in many projects.
Currently not on the roadmap – for what it's worth, the majority of apps perform their Electron updates at different times, so you'd still have the same number of binaries and files as you do today.
There's always Carlo[1] as an alternative.
https://github.com/GoogleChromeLabs/carlo
https://github.com/GoogleChromeLabs/carlo
We once had such a thing.
It was called Java. But it's a thing of the past.
I'm unsure if chromium is designed in a way to allow for this safely.
Or just build local permissions into web browsers and download 200KB of HTML and JavaScript instead of 200MB for an electronic install.
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.
Luckily web browsers take care to "never break the web" and remain backwards-compatible, so that should not be that much work.
I didn't see any sarcasm tags on your comment, so I'll take it at face value and disagree. Two quick examples:
Google Chrome went from proposing a new WebAudio method called "start" to deprecating and removing the "noteGrainOn" method it renamed in the span of 12 months. Any sites using the original spec stopped working, some within a year of being released with the latest and greatest spec, one of which was Google's "WebAudio Playground" demonstration site. (There's a fun bug on file where that team had the browser team push back the method deprecation by a release so that they could fix that one website).
Google released Polymer in 2015 or so. Apps written using the latest version of that in late 2015 stopped working at some point in 2017 on Google Chrome.
Web browsers stopped being even a little bit backwards compatible around 10 years ago.
Google Chrome went from proposing a new WebAudio method called "start" to deprecating and removing the "noteGrainOn" method it renamed in the span of 12 months. Any sites using the original spec stopped working, some within a year of being released with the latest and greatest spec, one of which was Google's "WebAudio Playground" demonstration site. (There's a fun bug on file where that team had the browser team push back the method deprecation by a release so that they could fix that one website).
Google released Polymer in 2015 or so. Apps written using the latest version of that in late 2015 stopped working at some point in 2017 on Google Chrome.
Web browsers stopped being even a little bit backwards compatible around 10 years ago.
That's because it was not sarcastic.
You are right, of course: if you use new proposals that have not yet been standardised, you are at risk of them breaking in the future. (I've been bitten by this at a previous employer that insisted on using Polymer as well. Don't get me started on that.)
When you stick to standardised features with multiple implementations, though, I think in the vast majority of cases you would've been fine. (This is also one reason why I was against using Polymer.)
(Obviously this does not cover all Electron features, which is why I don't consider browsers to be a replacement for Electron, at this point. I'm merely stating that it's very much possible to target browsers without having to concern yourself much with their rapid pace of development.)
You are right, of course: if you use new proposals that have not yet been standardised, you are at risk of them breaking in the future. (I've been bitten by this at a previous employer that insisted on using Polymer as well. Don't get me started on that.)
When you stick to standardised features with multiple implementations, though, I think in the vast majority of cases you would've been fine. (This is also one reason why I was against using Polymer.)
(Obviously this does not cover all Electron features, which is why I don't consider browsers to be a replacement for Electron, at this point. I'm merely stating that it's very much possible to target browsers without having to concern yourself much with their rapid pace of development.)
Gah, Polymer. Glad to hear I'm not the only one bitten by that...
(Did a single site with it, worked for a year and then for 6 months only in Safari/Firefox, and then we ported it to sit atop another Google project... ¯\_(ツ)_/¯ )
(Did a single site with it, worked for a year and then for 6 months only in Safari/Firefox, and then we ported it to sit atop another Google project... ¯\_(ツ)_/¯ )
I love your sarcastic response.
Favorite recent example, Chrome's audio blocking solution pretty much broke every HTML5 game in existence. 1000s of sites are still broken. To just name some easy categories, every Pico-8 game exported to HTML5, Every Unity and Unreal game exported to HTML5. Even 100s of Google's own Doodles, examples, promotions, etc ... until they pre-whitelisted every domain they own.
The worst is Apple. Trying to do anything game related in a webpage on iOS Safari is a nightmare and is pretty much guaranteed to break with each new iOS release. "minimal-ui" (nope, took that way), "user-scalable" (worked but they keep changing the conditions so old games break and have to reverse engineer under what conditions it's respected). I recently noticed one of my sites broke for audio. No errors, no mention of what changed that I can fine, worked 6 months ago, stopped working, Safari only. Note it's a site about audio and it doesn't start that audio until the user clicks the "Play" button. It's using the "resume" api but no sound comes out. Still works in Firefox and Chrome (after having to update it last year for Chrome's breaking change)
Favorite recent example, Chrome's audio blocking solution pretty much broke every HTML5 game in existence. 1000s of sites are still broken. To just name some easy categories, every Pico-8 game exported to HTML5, Every Unity and Unreal game exported to HTML5. Even 100s of Google's own Doodles, examples, promotions, etc ... until they pre-whitelisted every domain they own.
The worst is Apple. Trying to do anything game related in a webpage on iOS Safari is a nightmare and is pretty much guaranteed to break with each new iOS release. "minimal-ui" (nope, took that way), "user-scalable" (worked but they keep changing the conditions so old games break and have to reverse engineer under what conditions it's respected). I recently noticed one of my sites broke for audio. No errors, no mention of what changed that I can fine, worked 6 months ago, stopped working, Safari only. Note it's a site about audio and it doesn't start that audio until the user clicks the "Play" button. It's using the "resume" api but no sound comes out. Still works in Firefox and Chrome (after having to update it last year for Chrome's breaking change)
You're right that there's some risk - especially using API's that can also be abused. However, percentage-wise, the vast majority of works targeting browsers continue to work unmodified (at least in terms of interacting with the browser), making it a very stable platform and definitely not breaking as often and as likely as implied by the words "aggressive release cycle".
That said, it's definitely not yet feature-rich enough to fully displace Electron.
That said, it's definitely not yet feature-rich enough to fully displace Electron.
Other than VSCode I don't have any other Electron based on my computers, hardly anything to displace.
Give it a couple of years and Electron would be as common as MSHTML, HTA, XUL apps.
Give it a couple of years and Electron would be as common as MSHTML, HTA, XUL apps.
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.
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.
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.
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.
Do PWAs allow you to do things like modify application menus, access the file system etc?
If you bothered to read the link I posted, you would see that PWAs are native apps in UWP with full access to the same APIs as .NET and C++ have, if distributed via the store.
Same applies to PWAs on ChromeOS (naturally given its nature), and Google is ramping up the same capabilities on Android with their initial release of TWA.
Yep, there are a few OSes currently left out, it is up to their masters to follow Microsoft and Google's footsteps.
Same applies to PWAs on ChromeOS (naturally given its nature), and Google is ramping up the same capabilities on Android with their initial release of TWA.
Yep, there are a few OSes currently left out, it is up to their masters to follow Microsoft and Google's footsteps.
So you're proposing a solution which works on only Windows and ChromeOS (considering desktop OS only), and has to be distributed via a proprietary store (which in all likelihood might take a cut of my revenues), as a replacement for something that works on Win, Linux, and MacOS, and does not require that I lock myself into an unfavorable distribution method?
AFAIK there's no such lock-in in PWAs, even if the app stores are probably going to be the most important venues for their distribution. PWA is a web app that gets more 'app-like' progressively when you need it to. You can use it like any other web application in your browser, but if it's okay to you, it can store data (and cache it's own assets) to your machine, start in it's own window from a launcher, use the filesystem and so on. Many web apps already have this sort of behaviors when you create a home screen launcher for them from your browser.
Per the parent comment I was responding to, PWAs will only have full access to native APIs if they are distributed via the store. And without access to native APIs things like window management, menus etc. become impossible to customize.
I am, because I already have a browser, don't need an additional 300 MB copy per app.
It is only a matter of time until all desktop and mobile OSes that matter fully support it.
Also there is Qt, wxWidgets, JavaFX, ....
It is only a matter of time until all desktop and mobile OSes that matter fully support it.
Also there is Qt, wxWidgets, JavaFX, ....
This won't meet requirements either. Desktop apps require full system access. Either they get that, or it's another API that'll be deprecated sooner than later.
Those poor Electron devs, they will be pushing that Sisyphean boulder up the hill forever. It reminds me of the thesis of Joel Spolsky's essay Fire and Motion.
https://www.joelonsoftware.com/2002/01/06/fire-and-motion/
https://www.joelonsoftware.com/2002/01/06/fire-and-motion/
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.
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.
Great response, thank you!
As someone who has only ever created some basic quick apps in Electron and NW.js why is it Electron sees a much slower release cadence? Is there a different scope of integration with the underlying components?
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.
From the article:
> In the last half of 2018, our top priority was releasing faster and catching up closer to Chromium. We succeeded by sticking to a predetermined timeline. Electron 3.0.0 and 4.0.0 were released in a 2-3 month timeline for each release. We are optimistic about continuing that pace in releasing 5.0.0 and beyond. With a major Electron release approximately every quarter, we're now keeping pace with Chromium's release cadence. Getting ahead of Chromium stable release is always a goal for us and we are taking steps towards that.
> In the last half of 2018, our top priority was releasing faster and catching up closer to Chromium. We succeeded by sticking to a predetermined timeline. Electron 3.0.0 and 4.0.0 were released in a 2-3 month timeline for each release. We are optimistic about continuing that pace in releasing 5.0.0 and beyond. With a major Electron release approximately every quarter, we're now keeping pace with Chromium's release cadence. Getting ahead of Chromium stable release is always a goal for us and we are taking steps towards that.
I'm not sure this answers the question I asked. I'm already aware Electron has been trying to achieve release cadence I was curious as to why they've been having trouble doing so vs e.g. NW.js
Looking over the donors page, I'm pretty amazed at slack's absence. Ditto for Microsoft Teams. Way to give back to the community.
To be fair, Microsoft now pays the bills for the entire company, since electron is Githubs project as I have come to understand it
Which makes me wonder: where do the donations actually go? It looks like the total amount is less than 15k, so everything donated is very easily overshadowed by MSFT's contributions, and I don't see any hints at a payment-for-contributions program on the electron github.
The donations go by paying the salaries of most of the top electron devs since they work for github which is owned by Microsoft.
The donations do not come remotely close to paying even a single person's salary.
Beer money?
Several Slack employees contribute core source code to Electron. I believe they may even have several dedicated employees working on Electron full time. Same goes for MS.
The top donor on that page is Facebook, which has given $9,000 total. Next highest is $745. Just a few commits' worth of development time costs a lot more than that, and both Microsoft and Slack have been major contributors to Electron.
I would say VS Code is pretty good contribution. Since it's open source it can also be seen as a large code example.
Hi, Felix from Slack's Electron team here.
Slack co-maintains Electron together with GitHub, employing multiple core maintainers full-time, contracting those who can't join us full-time. We've also just hosted (and paid for) the first Electron conference. We're also maintaining a fairly large number of electron-userland modules.
tl;dr: That page might be misleading, we're investing heavily in Electron.
Slack co-maintains Electron together with GitHub, employing multiple core maintainers full-time, contracting those who can't join us full-time. We've also just hosted (and paid for) the first Electron conference. We're also maintaining a fairly large number of electron-userland modules.
tl;dr: That page might be misleading, we're investing heavily in Electron.
Any plans on dealing with Slack's/Electron's memory footprint?
Yes, we’re actively working on that.
I’d rather Slack just stop using electron and write a real native app; they can certainly afford it. Meanwhile, Slack remains an incredible resource hog.
It also behaves very erratically on a slower channels. On 3G speeds and lower it becomes basically unusable - messages are not sent or sent in the wrong order.
Why it needs so much resources just to send a few bytes of text?..
Why it needs so much resources just to send a few bytes of text?..
> Why it needs so much resources just to send a few bytes of text?..
Waste. It doesn't cost them much[0], and they don't seem to care on an ethical level about it either, and wastefulness allows them to achieve their business goals faster. Until there's a business pressure for it, things won't improve, and I have no idea what such pressure could be.
--
[0] - How many of their users are captive anyway? I didn't choose to use Slack, some non-tech folks at the company I'm working with chose it. Elsewhere, someone in the community of a technology I use also chose Slack. So now I'm forced to use them in both cases.
Waste. It doesn't cost them much[0], and they don't seem to care on an ethical level about it either, and wastefulness allows them to achieve their business goals faster. Until there's a business pressure for it, things won't improve, and I have no idea what such pressure could be.
--
[0] - How many of their users are captive anyway? I didn't choose to use Slack, some non-tech folks at the company I'm working with chose it. Elsewhere, someone in the community of a technology I use also chose Slack. So now I'm forced to use them in both cases.
Slack takes 5-7 seconds to start up and connect on an ultra low latency 300 Mbit connection. I really wish there were a native app on Mac.
The Slack integration is a bit rough still, but: https://cancel.fm/ripcord/
There is:
https://www.sblack.online
https://www.sblack.online
AFAICT that is not native:
> Sblack works exactly like a browser with small tweaks. We inject the dark mode style at the end of the Slack’s html, and that’s it
I bet it's just embedding a WebView, and the app is small because it uses the system's WebKit2
> Sblack works exactly like a browser with small tweaks. We inject the dark mode style at the end of the Slack’s html, and that’s it
I bet it's just embedding a WebView, and the app is small because it uses the system's WebKit2
That’s not a native app, it’s a app wrapping a web view.
Donations are a voluntary contribution based on "feeling good", and companies especially big publicly funded companies can rarely donate to "feel good". Its hard to justify to financiers why you should pay for open-source updates, if you can get them for free anyway.
It just highlights why donation is a terrible business model for open-source.
Come up with a better support model and people will pay.
It just highlights why donation is a terrible business model for open-source.
Come up with a better support model and people will pay.
are you kidding, GitHub belongs to Microsoft, they would be giving themselves money
mishurov(1)
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.
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.
Surely you could make a more positive contribution than mindlessly bashing the topic and assume anyone has heard of the random drive-by name drop?
People can surely utfg what sciter is in the context of a gui solution ?
Maybe because no one has ever heard of it?