I've been trying to get people to realize the power of the browser as a ubiquitous runtime for local software (akin to the way that /usr/bin/python and /bin/bash are situated to run scripts loaded from disk). But there's evidence of an obvious mental block when I try engaging with people. It's as if when you speak about the browser, people immediately start slipping and don't stop until they've arrived mentally at a thin client interacting with an application running on a remote server. No. I'm talking about documents that are meant to be saved to your machine and later opened from a file picker (with e.g. Ctrl+O) or double clicked in your file manager. They also happen to be able to be made interactive, and are self-contained, not unlike a partially baked spreadsheet with macros ready and willing to accept your input.
The author is spot-on with the metaphor to woodworking jigs.
If there's some criticism I have, it's here:
> The goal is not to produce a system that runs forever as has historically been the aim of software for the government and, subsequently, large tech behemoths.
The perverse thing is that this method of development is more likely to produce something that can run "forever", accidentally doing a much better job than any SaaS peddler. The biggest threat to this is the shrinking land area, as one tech behemoth uses its leverage (although all browser vendors are complicit) to force more people to conform to its expectations of fitting into the contemporary webdev mold when it comes to what media a commodity browser will accept.
And then, aside from that, I'm struck that the author may be overly focused on collage. I've said it before: self-contained HTML is (in many cases, at least) an acceptable substitute for office file formats. You can even get your traditional office suite to give you HTML instead of its native format, usually. Here's to hoping that this remains viable as the affordances of file:// space are chipped away.
I've been trending this way as well. Being asked to work on a needlessly complex React project turned me into a luddite. The more complex web development gets, the more I strip out of my own projects, until I'm left with the absolute basics (even opting for the short CSS and JS sections right in the HTML file).
I figure the more vanilla I make it, the longer it will last without needing a re-write. I often find HTML/JS a great way to mock up ideas or to create little utilities, that are also easy for others to use, without having to install anything or pass around executable files.
Although talking about the browser as the ubiquitous runtime makes me think of Windows XP. Wasn't Windows Explorer essentially running on IE? IE was also the default file viewer for a ton of formats. That all probably left a bad taste in people's mouth.
Same. I always start web projects with a single html file with style and script blocks in the document head. Works a treat. If the project is a small demo then it's likely to stay a single file — I only move things to separate files when they get big, or if I start to reuse bits in other projects I might make a common file. I hate using npm, frameworks, build processes etc. for personal projects.
Same here. Usually something starts out a neat way of doing things (say React) and then the solution actually turns out worse than the original problem. Especially as frameworks grow and somehow need to have new versions and functions beyond its original use case.
I have found this concept very useful professionally. Everyone has a browser. You can make self-contained HTML documents that do all kinds of great stuff! I’ll often use it to share an interactive dataset… use a script to pull together a big JSON, in-line an appropriate charting library, and go.
Sometimes performance isn’t amazing, but that’s usually directly related to the essential complexity of the dataset in question.
>I'm struck that the author may be overly focused on collage.
I got here because I'm interested in "Narrative Trails", a concept that was proposed by Bush in "As We May Think" in 1945. The idea of weaving together a set of documents to convey a complex context is quite intriguing to me. It started as a purity thing for me (the underlying documents should be read-only, markup should be separate), and morphed into this view far more sympathetic to collage.
As for saving things locally, I think I'm going to proxy the web locally and save everything in a 2 terabyte ring buffer. Anything that gets referenced with a link gets moved to permanent storage. That way I'll never have to deal with a broken link again.
I've been trying to get people to realize the power of the browser as a ubiquitous runtime for local software (akin to the way that /usr/bin/python and /bin/bash are situated to run scripts loaded from disk). But there's evidence of an obvious mental block when I try engaging with people. It's as if when you speak about the browser, people immediately start slipping and don't stop until they've arrived mentally at a thin client interacting with an application running on a remote server. No. I'm talking about documents that are meant to be saved to your machine and later opened from a file picker (with e.g. Ctrl+O) or double clicked in your file manager. They also happen to be able to be made interactive, and are self-contained, not unlike a partially baked spreadsheet with macros ready and willing to accept your input.
The author is spot-on with the metaphor to woodworking jigs.
If there's some criticism I have, it's here:
> The goal is not to produce a system that runs forever as has historically been the aim of software for the government and, subsequently, large tech behemoths.
The perverse thing is that this method of development is more likely to produce something that can run "forever", accidentally doing a much better job than any SaaS peddler. The biggest threat to this is the shrinking land area, as one tech behemoth uses its leverage (although all browser vendors are complicit) to force more people to conform to its expectations of fitting into the contemporary webdev mold when it comes to what media a commodity browser will accept.
And then, aside from that, I'm struck that the author may be overly focused on collage. I've said it before: self-contained HTML is (in many cases, at least) an acceptable substitute for office file formats. You can even get your traditional office suite to give you HTML instead of its native format, usually. Here's to hoping that this remains viable as the affordances of file:// space are chipped away.