5 ms·

I see projects like this pop up every once in a while and get abandoned. A simpler approach may be to just publish a basic web server as your app (express on t

I see projects like this pop up every once in a while and get abandoned. A simpler approach may be to just publish a basic web server as your app (express on top of node would do) that runs on the local machine on some random port and have users just go to that URL with their regular installed browser. Bonus points for no leakage of security / CORS / etc. issues from the UI side of things, every unsafe thing needs to be node-side where it can be better controlled. Also enforces asynchronous and efficient communication between the UI and the "local backend".

martin-adams 7y ago
i see this approach with DB admin tools which makes it great to run in docker along side the db itself.
throwlaplace 7y ago
Does the browser really have access to all the same apis as electron? Doesn't electron have broader access to the file system (e.g. all the stuff that vscode does).
- tlavoie 7y ago
  What the parent posted is stating is that the local web server has that system-level access, which the browser doesn't need in order to access the app. The "back end" web server can be running on whatever language stack you like, be it Go, Rust, Haskell, Common Lisp or whatever. Syncthing is one example, where it's nominally headless, but there is a local web server that can be pulled up to set preferences, monitor status and so on. Works great.
  - throwlaplace 7y ago
    oh yes you're right. i got confused for a moment. thanks!
- bobblywobbles 7y ago
  Electron does, but you need to consider security. Malicious apps or ill-designed architectures can leak openings where a bad actor can attack your OS. I'm the author of secure-electron-template, a template with secure practices baked-in. Security is very important and I don't feel people think of that from the get-go.
troxwalt 7y ago
Love the idea of shipping something smaller. In your proposed idea, would a user still need to make sure node and express were installed? Or can you have a user download a project folder and initiate the same way they would a typical executable?
- gigel82 7y ago
  When distributed to end-users it could be an executable with node DLL/SO bundled that has no UI (or maybe a simple tray/menu bar icon with an Exit to terminate and a Show to open a local browser to /localhost:1337). When developing locally I presume it would be very similar to an Electron project, with npm dependencies for express / fastify on the "backend" side and React or whatever you need for the "frontend" side. During build, you'd produce 2 bundles (frontend and backend) that tree-shake, etc. such that all js dependencies are optimized together. The frontend bundle should load in any browser (it'd be just a normal website with the only difference being that all REST calls go to /localhost). The backend bundle + any native modules will be loaded in the embedded node runtime so they can be distributed as loose files or packaged in something like Electron's asar. There, I designed the whole thing, now someone go build it :)

martin-adams 7y ago

i see this approach with DB admin tools which makes it great to run in docker along side the db itself.

throwlaplace 7y ago

Does the browser really have access to all the same apis as electron? Doesn't electron have broader access to the file system (e.g. all the stuff that vscode does).

tlavoie 7y ago
What the parent posted is stating is that the local web server has that system-level access, which the browser doesn't need in order to access the app. The "back end" web server can be running on whatever language stack you like, be it Go, Rust, Haskell, Common Lisp or whatever. Syncthing is one example, where it's nominally headless, but there is a local web server that can be pulled up to set preferences, monitor status and so on. Works great.
- throwlaplace 7y ago
  oh yes you're right. i got confused for a moment. thanks!
bobblywobbles 7y ago
Electron does, but you need to consider security. Malicious apps or ill-designed architectures can leak openings where a bad actor can attack your OS. I'm the author of secure-electron-template, a template with secure practices baked-in. Security is very important and I don't feel people think of that from the get-go.

troxwalt 7y ago

Love the idea of shipping something smaller. In your proposed idea, would a user still need to make sure node and express were installed? Or can you have a user download a project folder and initiate the same way they would a typical executable?

gigel82 7y ago
When distributed to end-users it could be an executable with node DLL/SO bundled that has no UI (or maybe a simple tray/menu bar icon with an Exit to terminate and a Show to open a local browser to /localhost:1337). When developing locally I presume it would be very similar to an Electron project, with npm dependencies for express / fastify on the "backend" side and React or whatever you need for the "frontend" side. During build, you'd produce 2 bundles (frontend and backend) that tree-shake, etc. such that all js dependencies are optimized together. The frontend bundle should load in any browser (it'd be just a normal website with the only difference being that all REST calls go to /localhost). The backend bundle + any native modules will be loaded in the embedded node runtime so they can be distributed as loose files or packaged in something like Electron's asar. There, I designed the whole thing, now someone go build it :)