After devoting years to creating applications and websites with UserLand Frontier, culminating in his publication of the excellent 1998 book Frontier: The Definitive Guide, Matt Neuburg did something unusual.
He liked publishing websites with Frontier, which offered a scripting engine, database, and a website framework, but he decided the technology stack was no longer to his liking.
So he created RubyFrontier:
Perhaps, says I to myself says I, it would be possible to clone Frontier’s website-making functionality, using Ruby. …
Now, at first this entire prospect seemed an improbable one. Frontier, after all, is much more than a language. It’s a kind of hierarchical database. All the materials from which a web site is generated, including scripts and texts, are kept inside that database. Objects in the database are referred to as variables through a sort of namespace notation. Furthermore, the database makes use of “tables” whose entries are “scalar” values such as strings and numbers.
True, but then I got to thinking: For web site generation, the database isn’t really necessary. Scripts are just scripts; it doesn’t matter how they are stored, so they can just as well be methods in one or more Ruby script files. Texts can be represented by text files, and the hierarchical arrangement of texts and tables in the Frontier database can be represented by the hierarchical arrangement of files and folders on disk. This, after all, is how most Web site frameworks work these days (e.g. Rails); and there was once even a variant of the Frontier web site framework that worked this way (the so-called “BBSite suite”). In the distant past, repeated reading from files would have been considered “thrashing the disk”, but modern virtual memory and disk usage patterns have outmoded such concerns. Furthermore, thanks to TextMate, viewing and navigating a big hierarchy of files and folders is just as easy as navigating Frontier’s object hierarchy.
And what about Frontier’s “tables” of “scalars”? Well, Ruby has internal “tables” (hashes). In fact, they are a lot more efficient than Frontier’s, plus they have an on-disk human-readable representation — YAML.
So, it was starting to look like the project might be possible after all.
Still I hesitated, worried about one final piece of the puzzle — outlines. Outlining is one of Frontier’s great strengths, and not something I wanted to lose. But then, once more, I got to thinking: Where in the Web site framework are outlines really needed?
RubyFrontier is available on GitHub under the open source MIT license.