▲ | dboreham 5 days ago | |
Never understood why these things aren't done by running a local http server and use a regular browser. | ||
▲ | whizzter 5 days ago | parent | next [-] | |
Developing for Electron you usually had a regular webpack server in the background to handle hot-reload cases and technically you could have a regular browser. In production however you don't want a browser for 2 reasons, first should a local app really expose internals to the network(And get mucked up by firewalls)? secondly the deployment is easier the more it's self-contained. Also since there are internal communication channels between "browser" and native/"server" parts (that are far faster than going over the network) you don't want to diverge the production and development environment to avoid having hard to debug things. On top of it, in this case bun is also a bundler so you get the typescript transpilation for free. So to summarize, if your app is really only a plain webapp distributed to desktop then sure you can developer everything with a local webserver and package with whatever is available, but as soon as you involve native off-browser parts you don't want to start exposing everything and using the embedding systems(be it electron or webview2/khtml,etc) built in browser<->native communication is simply the saner choice and the point of these projects is to abstract that from the developer. | ||
▲ | dymk 5 days ago | parent | prev [-] | |
Local file system access is one reason, any other native APIs needed for making a desktop app, etc |