{"id":13,"date":"2022-12-11T11:36:20","date_gmt":"2022-12-11T16:36:20","guid":{"rendered":"http:\/\/blogs.harvard.edu\/technology\/?p=13"},"modified":"2022-12-11T11:52:27","modified_gmt":"2022-12-11T16:52:27","slug":"matt-neuburgs-improbable-path-to-rubyfrontier","status":"publish","type":"post","link":"https:\/\/archive.blogs.harvard.edu\/technology\/13\/matt-neuburgs-improbable-path-to-rubyfrontier\/","title":{"rendered":"Matt Neuburg’s Improbable Path to RubyFrontier"},"content":{"rendered":"

After devoting years to creating applications and websites with UserLand Frontier, culminating in his publication of the excellent 1998 book Frontier: The Definitive Guide<\/em>, Matt Neuburg did something unusual.<\/p>\n

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.<\/p>\n

So he created RubyFrontier:<\/a><\/p>\n

Perhaps, says I to myself says I, it would be possible to clone Frontier\u2019s website-making functionality, using Ruby. …<\/p>\n

Now, at first this entire prospect seemed an improbable one. Frontier, after all, is much more than a language. It\u2019s 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 \u201ctables\u201d whose entries are \u201cscalar\u201d values such as strings and numbers.<\/p>\n

True, but then I got to thinking: For web site generation, the database isn\u2019t really necessary. Scripts are just scripts; it doesn\u2019t 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.\u00a0Rails); and there was once even a variant of the Frontier web site framework that worked this way (the so-called \u201cBBSite suite\u201d). In the distant past, repeated reading from files would have been considered \u201cthrashing the disk\u201d, but modern virtual memory and disk usage patterns have outmoded such concerns. Furthermore, thanks to\u00a0TextMate, viewing and navigating a big hierarchy of files and folders is just as easy as navigating Frontier\u2019s object hierarchy.<\/p>\n

And what about Frontier\u2019s \u201ctables\u201d of \u201cscalars\u201d? Well, Ruby has internal \u201ctables\u201d (hashes). In fact, they are a lot more efficient than Frontier\u2019s, plus they have an on-disk human-readable representation \u2014\u00a0YAML.<\/p>\n

So, it was starting to look like the project might be possible after all.<\/p>\n

Still I hesitated, worried about one final piece of the puzzle \u2014 outlines.\u00a0Outlining\u00a0is one of Frontier\u2019s 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\u00a0really<\/em>\u00a0needed?<\/p><\/blockquote>\n

RubyFrontier is available on GitHub<\/a> under the open source MIT license.<\/p>\n","protected":false},"excerpt":{"rendered":"

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, … Continue reading →<\/span><\/a><\/p>\n","protected":false},"author":9693,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[82],"tags":[],"class_list":["post-13","post","type-post","status-publish","format-standard","hentry","category-news"],"jetpack_featured_media_url":"","_links":{"self":[{"href":"https:\/\/archive.blogs.harvard.edu\/technology\/wp-json\/wp\/v2\/posts\/13","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/archive.blogs.harvard.edu\/technology\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/archive.blogs.harvard.edu\/technology\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/archive.blogs.harvard.edu\/technology\/wp-json\/wp\/v2\/users\/9693"}],"replies":[{"embeddable":true,"href":"https:\/\/archive.blogs.harvard.edu\/technology\/wp-json\/wp\/v2\/comments?post=13"}],"version-history":[{"count":3,"href":"https:\/\/archive.blogs.harvard.edu\/technology\/wp-json\/wp\/v2\/posts\/13\/revisions"}],"predecessor-version":[{"id":22,"href":"https:\/\/archive.blogs.harvard.edu\/technology\/wp-json\/wp\/v2\/posts\/13\/revisions\/22"}],"wp:attachment":[{"href":"https:\/\/archive.blogs.harvard.edu\/technology\/wp-json\/wp\/v2\/media?parent=13"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/archive.blogs.harvard.edu\/technology\/wp-json\/wp\/v2\/categories?post=13"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/archive.blogs.harvard.edu\/technology\/wp-json\/wp\/v2\/tags?post=13"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}