4 ms·

That's what your platform gets when its web engine refuses to be fully compatible with others, especially the major one.

olliej 6y ago
I'm not sure how that applies to electron beyond electron bundling an entire copy of chrome in every app. Electron has plenty of non-web APIs, plenty of non-web permissions, etc. You could do exactly the same thing with webkit's APIs.
- emteycz 6y ago
  The comment I replied to wasn't about bundling webkit instead, it was dynamic linking of what's available in the system. That's not possible because each web engine behaves differently, even if somebody reimplemented the non-web apis as a portable native library (actually, these ARE implemented like that). We're bundling whole chrome because it's a reliable abstraction that works the same on all systems.
  - olliej 6y ago
    Your complaint was about WebKit’s “refusal” to implement standards, where standards generally is whatever chrome announces and then throws onto the web with little to no thought about how the impacts users or user privacy. As a framework, webkit has a stable abi as well which means electron apps would just work with updated system webkit, rather than needing to be rebuilt. Similar for JavaScriptCore vs V8. Unfortunately JSC’s API isn’t nearly complete enough.
    - emteycz 6y ago
      Sure, and then you run your app and find out that the app displays differently in each engine, so not only you need portable system lib, now you also need portable UI code. That's what we avoid with bundling the web engine.
      - olliej 6y ago
        Yes, what you also get is terrible battery life, terrible performance, and terrible UI. It is immediately obvious any time you use an electron app on osx because you immediately hit non-standard UI behavior, and basic errors with hotkeys. So by using electron you've made your life easier, but have produce an app that is much worse for the people actually using it.
        emteycz 6y ago
        VSCode is Electron app, running nonstop on my Macbook, it's very fast and doesn't seem to be much more (or at all) power hungry than Xcode. Thanks to Electron it works everywhere and is the same on all platforms, that's a feature.
        olliej 6y ago
        The first time I used vscode it was obvious that it wasn’t a native app. Basic things like the search hot keys were broken. It’s perf as a text editor compared to native text editors is abysmal, and if you compare to Xcode you have to include the many processes spawned for basic code support. VSCode’s idea of a file that is too large to process is smaller than xcode’s which is itself pretty unresponsive for a while when loading files that textmate and other native editors handle without a problem.
eyelidlessness 6y ago
I’m not sure I follow. There’s no reason Electron can’t use the platform’s ample facilities for shared libraries, and distribute one copy per Electron version rather than per app product. It would possibly be a slightly different startup experience (eg download the components on app launch; even that I think could be solved by detecting their presence with URL protocols, a fairly common practice, to determine which bundle to download).

olliej 6y ago

I'm not sure how that applies to electron beyond electron bundling an entire copy of chrome in every app. Electron has plenty of non-web APIs, plenty of non-web permissions, etc. You could do exactly the same thing with webkit's APIs.

emteycz 6y ago
The comment I replied to wasn't about bundling webkit instead, it was dynamic linking of what's available in the system. That's not possible because each web engine behaves differently, even if somebody reimplemented the non-web apis as a portable native library (actually, these ARE implemented like that). We're bundling whole chrome because it's a reliable abstraction that works the same on all systems.
- olliej 6y ago
  Your complaint was about WebKit’s “refusal” to implement standards, where standards generally is whatever chrome announces and then throws onto the web with little to no thought about how the impacts users or user privacy. As a framework, webkit has a stable abi as well which means electron apps would just work with updated system webkit, rather than needing to be rebuilt. Similar for JavaScriptCore vs V8. Unfortunately JSC’s API isn’t nearly complete enough.
  - emteycz 6y ago
    Sure, and then you run your app and find out that the app displays differently in each engine, so not only you need portable system lib, now you also need portable UI code. That's what we avoid with bundling the web engine.
    - olliej 6y ago
      Yes, what you also get is terrible battery life, terrible performance, and terrible UI. It is immediately obvious any time you use an electron app on osx because you immediately hit non-standard UI behavior, and basic errors with hotkeys. So by using electron you've made your life easier, but have produce an app that is much worse for the people actually using it.
      - emteycz 6y ago
        VSCode is Electron app, running nonstop on my Macbook, it's very fast and doesn't seem to be much more (or at all) power hungry than Xcode. Thanks to Electron it works everywhere and is the same on all platforms, that's a feature.
        olliej 6y ago
        The first time I used vscode it was obvious that it wasn’t a native app. Basic things like the search hot keys were broken. It’s perf as a text editor compared to native text editors is abysmal, and if you compare to Xcode you have to include the many processes spawned for basic code support. VSCode’s idea of a file that is too large to process is smaller than xcode’s which is itself pretty unresponsive for a while when loading files that textmate and other native editors handle without a problem.

eyelidlessness 6y ago

I’m not sure I follow. There’s no reason Electron can’t use the platform’s ample facilities for shared libraries, and distribute one copy per Electron version rather than per app product. It would possibly be a slightly different startup experience (eg download the components on app launch; even that I think could be solved by detecting their presence with URL protocols, a fairly common practice, to determine which bundle to download).