In these cases you'd have to freeze the version of every layer beneath the editor(browser/env, OS and so on), otherwise any regression in these layers is going to break your app.

But if you decide to freeze you run the risk of exposing your users to security issues.

>In these cases you'd have to freeze the version of every layer beneath the editor(browser/env, OS and so on), otherwise any regression in these layers is going to break your app.

You only need to check periodically whether new updates are ok. Same way you don't freeze all your non-editor dependencies for eternity.

And I doubt you need to care for layers below the browser ("OS and so on") changing when it comes to your WYSYWIG component in your Electron app.

I doubt this? contenteditable is pretty stable in Chrome/WebKit.

I don't know - you tell me.

Anyway we had our share of trouble with a customer due to an exotic rendering issue that occurred in two consecutive versions of Chrome and then disappeared, so yeah.

Sure, but that happens. We hit an insane performance problem related to Chrome and some weird combination of CSS that disappeared in a similar number of versions.

I'd say it's the exception and not the rule, though.

Which means you end up shipping a huge chunk of "bloat" to your end users - it may be a library or "runtime" rather than your own code, but it adds up to the same thing.

so in that case isn't it a good idea to try and reduce your overheads wherever possible? And in the case of windows store apps, the runtime is already on the users systems and they're just downloading the packaged JS/HTML

> so in that case isn't it a good idea to try and reduce your overheads wherever possible?

I think it's the opposite: if you're using react-native or electron you might as well give up on optimizing the size of your own code, because it's not going to make a dent in your overall level of bloat. Enabling your codebase to be used from the user's own browser would have a much better return in bloat-reduction, even if it meant writing more of your own code.

> And in the case of windows store apps, the runtime is already on the users systems and they're just downloading the packaged JS/HTML

Sure, but making your site windows-store-only is morally the same thing as making it single-browser (possibly even single-version-of-that-browser). The flip side of "all that "bloat" is there so that you'll get consistent results across browsers" is that you can cut a lot of bloat if you're willing to sacrifice crossplatform support.

> Enabling your codebase to be used from the user's own browser would have a much better return in bloat-reduction, even if it meant writing more of your own code.

Not every app can be ported to the browser. For instance, if I wanted to make a local file manager (like fman) I couldn't do that in the browser. This is why native apps exist.

Sure, but even for that kind of app, if you were looking to reduce the bloat then I'd look to try to cut down the runtime you were shipping (i.e. maybe you can build some stripped-down version of electron that contains only the parts you need) before trying to cut your own code, because the runtime is where most of the bloat is.

> maybe you can build some stripped-down version of electron that contains only the parts you need

if you're using electron in the first place, I think its safe to assume that re-inventing electron is not within your skillset.

Build in the sense of "compile" more than in the sense of "write"; I'm not advocating reinventing it from scratch, just customizing it a little.

That would be a neat option, but I don't think its possible at the moment. you have to take all or nothing.

You raise a good point though. If they could make electron more modular it would save on a lot of that bloat everyone always complains about. I bet half the apps could make do without audio, image processing etc