> Would this be fast enough for what we experienced back then with early
> websites, however? What with the stats on how people close or click away from
> a tab within N seconds if it hasn't fully loaded yet, I'd think that having
> to compile at all could've been prohibitive to people taking this route vs.
> web forms. Though, I'm not sure how user behaviors or expectations of speed
> were back then for the web.
I have a couple of ideas in this area. If a more guided interface is needed
then when you mount a service you can hook up a console to a file using "con"
command allowing for interactive prompts such as "enter search criteria" and
responses. Still no remote code required.
Another option is to provide a readme.txt file describing the service, relevant
files, etc. Inside that document are examples of shell commands that you can
echo 'search cat pictures' >> ctl
Open the readme in acme, edit the examples, select and middle click on it and
it runs the command. You learn how to use the service and again, there is no
remote command execution other than what you selected and ran.
> I was thinking what may have eventually happened would have been an
> interpreted language would pop up that would be what web applications were
> written in, sort of like java applets, except not embedded in the browser,
> and hopefully in a simpler language. Early web applications were also very
> simple 'put info in textbox and hit enter' forms, if I remember correctly, so
> a small, expandable runtime that would be quickly started up in a sandbox
> might have been on equal footing with html, assuming it was indeed able to
> start up and run quickly (or maybe just fork a running one into a new
> namespace?). Ideally, developers could then write their own libraries (in C
> or whatever they like) that the web language would hook into that could do
> more powerful things - and those libraries might be the time to provide
> source and makefiles, or binaries if they wanted to keep things close to the
That's possible that an interpreted language would have taken off. With OS
level sandboxing, hopefully people run these within the sandboxes, providing
access the minimal set needed for the service.
> Thinking more on the 'writing to a ctl file' idea, which I'm really getting
> into, I was thinking users may have ended up making their own graphical
> interfaces for web services; UIs that abstracted away the actual writing to
> ctl files and put it in a GUI for less advanced users. It'd've been
> interesting to see a competition in UI design among OSS interfaces for web
> services, sort of like what we see today with apps for reddit on phones
> (except hopefully they wouldn't all be awful). Or, maybe everyone would just
> use the service-provider's provided interfaces.
I think that many GUI's were created to hide ugly, inconsistent and large
layers underneath. I have a hypothesis that if you start with a small, well
designed system with a simple interface that people can and will use it of the
alternative is a system that is brittle, complex and allows accidental security
breaches at the click of a button. Textual interfaces can good and usable, with
a bit of learning. Add graphics only when the problem warrants it (eg. CAD) or
it truly simplifies the interface.
> Do you think there would've been fewer large databases if things had gone
> this way? Just thinking on my banking example, it seems like it'd be easiest
> to just have a /bank.com/users/<username> folder with the relevant files in
> it that users could union-mount, since you're not forced to show things
> through a web interface. Though, I suppose a bank could just expose that
> folder as an interface for what's actually a DB running in the background.
The bank may expose files, but it doesn't necessarily mean you can edit them
like simple text files. Plan 9 has some really interesting paradigms with read
only files, updating using control file protocols, append only files, file
descriptors that return errors for invalid writes. I've only scratched the
surface. It could be a really interesting project to write up how different
paradigms work for certain scenarios.