3 ms·

I just want to add that running in the browser does not mean running in the cloud or web. I actually once worked on enterprise software that used a browser as G

• cxr 5y ago
  By a reasonable guess your app was distributed as a binary that spun up a local web server and automatically pointed the user's browser to it. That's a perfectly fine approach for some use cases, but for many others, even the server binary isn't needed. An extremely underappreciated approach for development and distribution is targeting the browser as a sandbox for fully local applications (embodied in static files—or better: as a single file). I see lots of people making apps and throwing them up on GitHub Pages, but rarely do the developers package them up into a form that you can download from the Releases tab from the associated repo and then double click to run. At best, they'll point at the repo with instructions in the README about running npm or yarn. (Then again, if their build processes would also target the browser's JS engine and standard browser APIs instead of NodeJS and its proprietary ones, then the entire exercise of setting up an NPM-based development environment need not exist, either. Oddly enough, people who think of themselves as JS developers and spend their days writing web apps seem to either really dislike the thought of actually using the browser, or they're so afflicted with tunnel vision that they've missed the obviousness of using the browser runtime in this way.)