What if JavaScript had persistent globals?

Listening to Brendan Eich's interview about the origins of JavaScript, our languages, UserTalk which is embedded in Frontier and JavaScript, the one he embedded in Netscape, syntactically, were quite close. So much so that when Danny Goodman, author of programming books, first saw JavaScript , he asked me if I had worked with them.

Brendan also talks about the what-if's, what if the timing had been different. Or what if he and I knew each other back then. I wonder what if some of the ideas that were baked into Frontier, at the deepest level, had made it into the browser.

For example, persistent memory. The browser has very little of it, through cookies, and then later through localStorage. But the PCs of the day could do a lot more than cookies. I know because in Frontier, first released in 1992, we made all globals persist between invocations of the the environment. So you didn't need to worry about loading and saving files to and from disk. If you created a global, it was there forever, until you deleted it. We did this with an object database, that was the second component of the environment that I implemented. The first, of course, was the outliner, which was used for editing everything from code to menubars and to browse and edit the object database.

This led to some interesting places, and made bigger projects more easily approached by small teams or individuals. Ones that would have been too complex otherwise. I can really feel that now that I am working in JavaScript, 20-plus years later, and my environment doesn't have persistent globals.

How close did we get? Well, a good-size piece of Frontier was integrated in Netscape, thanks to Aleks Totic, an important feature we called menu sharing, which allowed one app to insert a menu into another. We used this feature to add script-written commands to Netscape's menus. This made content management much more facile, a precursor to the Edit This Page button, in 1999, that was the basic feature of blogging software.