7 ms·

sometimes, you can be sure of the browser / rendering engine ahead of time, and you don't need all that "bloat". For instance, react-native, electron or window

sometimes, you can be sure of the browser / rendering engine ahead of time, and you don't need all that "bloat". For instance, react-native, electron or windows store apps.

Tade0 9y ago
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.
- coldtea 9y ago
  >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.
- jchw 9y ago
  I doubt this? contenteditable is pretty stable in Chrome/WebKit.
  - Tade0 9y ago
    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.
    - jchw 9y ago
      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.
lmm 9y ago
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.
- roryisok 9y ago
  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
  - lmm 9y ago
    > 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.
    - roryisok 9y ago
      > 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.
      - lmm 9y ago
        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.

sometimes, you can be sure of the browser / rendering engine ahead of time, and you don't need all that "bloat". For instance, react-native, electron or windows store apps.

Tade0 9y ago

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.

coldtea 9y ago
>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.
jchw 9y ago
I doubt this? contenteditable is pretty stable in Chrome/WebKit.
- Tade0 9y ago
  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.
  - jchw 9y ago
    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.

lmm 9y ago

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.

roryisok 9y ago
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
- lmm 9y ago
  > 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.
  - roryisok 9y ago
    > 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.
    - lmm 9y ago
      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.