|
If you can bundle a static or shared library that have a common api where you can link and build your platform over,
where the dev will know what composition HTML, CSS, JS works without having to resort to a common denominator in contradiction to your point of view, i don't think is the best approach. It will give more burden to the platform developer and to the developer, having to work with less features and unable to follow more experimental technologies. > it shares the system browser engine keeping memory usage down The problem with high memory pressure have nothing to do with sharing a DSO or not, as this is a per process issue, the problem is that with the multi-process architecture, each renderer process have its own WebKit and V8+Node heap instances that need to deal with tons of javascript, resources and the bloat that comes with modern platforms like React, compiling Typescript on the fly or loading big WASM binaries. I mean, the web standard is too complicated now, and theres a need for companies who can afford thousands (expensive) man-hour just to keep up. Which leads to the reality of most browsers engines not being able to follow and becoming outdated in the near future. Which means that shipping a "killer app" in such platform, like Visual Studio, will be harder than platforms like Electron, that giving its direct use of V8 can also have a "batteries included" platform by shipping together with NodeJs. |