The First Web Browser Was a Storage-Neutral App

ONE IMPORTANT NOTE: I’m just toying with this idea, not asserting it at this point. But part of me is very interested in what happens when we view the rise of the app as not a betrayal of the original vision of the web, but as a potential return to it. I don’t see many people pushing that idea, so it seems worth pushing. That’s how I roll. ;)

——-

Apropos of both an earlier post of mine and Jim’s Internet Course. This is a screenshot of the first web browser (red annotations added by me):

tims_editor

 

The first web browser was a storage-neutral editing app. If you pointed it at files you had permission to edit, you could edit them. If you pointed it at files you had permission to read, you could read them. But the server in these days awas a Big Dumb Object which passed your files to a client-side application without any role in interpreting them.

I never used the Berners-Lee browser, but even in the mid-90s when I was hacking my first sites together Netscape had a rudimentary editor (I was using something called HoTMeTaL at the time, but stilll):

Netscape_EDITOR_Window

This is still the case with many HTML files a browser handles, but what’s notable here is that in those days a browser sort of worked much like what a storage neutral app would today.  When I talk about having the editing functions of a markdown-wiki client-side in an app, we’re essentially returning to this model.

And think about that for a minute. Imagine what that wiki would be like — you tool around your wiki in your browser editing these Markdown files directly. When someone hits your site in their browser, it lets them know that they should install the Markdown extension, or download the Markdown app to view these things. Grabbing a file is just grabbing a file.

So what happened to this original vision? So many things, and I only saw my little corner of the world, so I’m biased.

  • Publishers: The first issue hit when the publishers moved in. They wanted sites to look like magazines. This accelerated a browser extension war and pushed website design to people slicing up sites in Adobe and Macromedia tools.
  • Databases + Template-based Design: As layouts got more complex, you wanted to be able to swap out designs and have the content just drop in; so we started putting pages in database tables that required server interpretation (this is how WordPress, Drupal, or alomost any CMS works for example).
  • Browser incompataibility, platform differences: People didn’t update browsers for years, which meant we had to serve version and platform specific HTML to browsers. This pushed us further into storing page contents in databases.
  • E-commerce. You were going to have a database anyway to take orders, so why not generate pages?
  • Viruses and Spyware. Early on, you used to download a number of viewer extensions. But lack of a real store to vet these items led to lots of super nasty browser helper objects and extensions, and the fact that you used your browser for e-commerce as well as looking at Pixies fan sites made hijacking your browser a profitable business.

In addition, there was this whole vision of the web as middleware that would pave the way to a thin-client future free from platform incompatibilities. Companies like Sun were particularly hot to trot on this, since it would make the PC/Mac market less of an issue to them. Scott McNealy of Sun started talking about “Sun Rays” and saying McLuhanesque things like “The Network is the Computer“.

In the corporate environment, thin clients are wired to company servers.

In your home, McNealy envisions Sun Rays replacing PCs.

“There’s no more client software required in the world,” he said. “There’s no need for [Microsoft] Windows.”

Sun Rays fizzled, but the general dynamic acclerated. And part of me wonders is it accelerated for the same reasons that Sun embraced it. In a thin client world, the people who own the servers make the rules. That’s good — for the people who own the servers.

This is really just a stream of conciousness post, but really consider that for a moment. In the first version of the web you downloaded a standard message format with your email client, and web pages were pages that could live anywhere (storage-neutral) and be interpreted by a multitude of software (app-neutral).  In version two, your mail becomes Gmail, and your pages get locked into whatever code is pulling them from your 10 table database.  And yes — your blogging engine becomes WordPress.

OF COURSE there were other reasons, good reasons, why this happened. But it’s amazing to me how much of the software I use on a daily basis (email, wikis, blogs, twitter) would lose almost nothing if it went storage neutral — besides lock-in. And such formats might actually be *more* hackable, not less.

It’s also interesting to see how much other elements of the ecosystem have solved the problems that led us to abandon the initial vision. Apps auto-update now. The HTML spec has stabilized somewhat, and browsers are more capable. The presence of stores for extensions gets rid of the “should I install random extension from unknown site” problem — people install and uninstall apps constantly. Server power is now such that most database-like features can be accomplished in a file-based system — Dokuwiki is file based, but can generate RSS when needed and respond to API calls. And, interestingly, we are finally returning to a design minimalism that reduces the need for pixel-based tweaking.

In any case, this post is a bit of a thought experiment, and I retain the right to walk away from anything I say in it. But what if we imagined the rise of apps as a POTENTIAL RETURN to the roots of the web, a slightly thicker, more directly purposed client that did interpretation on the client-side of the equation? Whether that interpretation is data API calls or loading text files?

I know that’s not where we are being driven, but it seems to me it’s a place that we could go. And it’s a narrative that is more invigorating to me than the “Loss of Eden” narrative that often hear about such things. Just a thought.

About these ads

21 Comments on “The First Web Browser Was a Storage-Neutral App”

  1. Your post reminded me of a recent post by John Gruber on the argument about the “death” of the “Mobile Web” http://daringfireball.net/2014/04/rethinking_what_we_mean_by_mobile_web “We shouldn’t think of the “web” as only what renders inside a web browser. The web is HTTP, and the open Internet.” I do like that vision and I also wonder how realistic can we get to “storage neutral”. I suppose we have to define what that means. It’s not raw storage because you’re serving HTML so we need Apache (or Nginx, or Litespeed, or some rendering engine). You mentioned Dokuwiki which you know I love, but all the search, RSS, etc is happening thanks to PHP so now we need that too. So are we just talking about a push away from MySQL or is it something more? I think pieces of the vision are alive and well as you mention with the mobile space. I download an app to access Yelp and think nothing of that interaction. My instinct when accessing Yelp on my laptop though has never been to even wonder if they had a desktop app. If they did I probably wouldn’t use it. It’s interesting how that dynamic changes based on the device I’m on. And I can’t tell which direction we’re heading but the dynamic is certainly there.

    • mikecaulfield says:

      Thanks for that link. That’s an amazing post. I think he is right on, though he actually undersells apps. In the sort of coincidence that’s not a coincidence because it happens all the time, I replied to this comment of yours via the browser, only to get redirected to my login screen because I have a WP account. I promptly botched my password multiple times (not sure why). I had to move onto other things, so screw it, I think, And I move on.

      I’m now typing this into my WP Android app via a keyboard. In the WP app I’m always logged in (because it understands I’m on my phone). It feeds me updates when people comment.

      Etc. Etc. It’s not perfect. Cntrl-z does work, copy/pasting from multiple windows suck, but the truth is as mobile-style hybrid apps move onto standard desktop platforms like Windows 8 and whatever the next Mac OS is, these issues will be ironed out. WIndows 8 is a botched implementation, but it thinks about the web in exactly the right way. If history is any guide Apple will take that botched implementation and make it the approach to the next OS. And it will be elegant. And then, even on the desktop, the browser will go back to being the worlds most awesome document reading app ever, as well as the glue that holds the different desktop apps together.

      I overemphasize the plain text piece in terms of the storage neutral piece. There’s a lot of things that could be done that way, but the most likely route is storage and access focused APIs. APIs that say can I access this document, can I update it, should I put a revision somewhere, can we logged who changed it, can we notify a list of people that it’s been updated. Something like S3, but a bit less atomic, and semi-standard.

      Then you write a hybrid web application as simply as you write a desktop one. The only difference is instead of pointing it to a My Documents folder during install you ask S3, or Azure, or whatever. This is how a good deal of products already work in Windows 8, you just can’t choose the provider. But in the background web resources are first class citizens of the API.

      Given that architecture, it should be pretty simple to write software on top of it, simpler, in fact, than writing web applications, because your OSis going to handle authentication and all the tricky stuff….

      I’ve wandered off track here, but what I’d love to think about is a world where clicking edit on a Dokuwiki page opens up a Markdown editing app that is permanently logged in and talks via APIs to the backend. We get rid of logins, we let people chose their own editor, we integrate with the “Share to” interface of Android, which is incredibly powerful and could form a simple basis of the federation we’ve been talking about (there must be something similar on iOS, right). All this is very blue sky. But I think the first step is what we’re doing — thinking about Dokuwiki as a collection of documents that may or may not be accessed through the browser app. I think we can explore a lot of this just starting with that and hacking stuff together.

      • This is great stuff (the followup post equally so). I will point out that I’m able to comment here in the browser now without logging in again thanks to cookies, but I do get your larger point of how far we’ve strayed with this thing called the internet as compared to other protocols like email and even services like Twitter where we are more than happy to use a variety of apps and tools to interface with them. I never visit Twitter.com. Ever. I’ve jumped around from several different apps but I never go to the website because as you said it’s probably one of the poorest implementations of the service. Truly ironic. I think a real challenge for Edtech is going to be harnessing these new tools. Mobile and Desktop app development is a larger hurdle than firing up a web-based CMS and building something. Hopefully we can find more frameworks that make this stuff dead simple to implement which then leads to a variety of examples pouring out that model this approach.

  2. […] The First Web Browser Was a Storage-Neutral App → […]

  3. explanation says:

    Hi there! Do you know if they make any plugins to protect against
    hackers? I’m kinda paranoid about losing everything I’ve worked hard on. Any suggestions?

  4. Hello There. I found your blog using msn. This is an extreely well written article.
    I will be sure to bookmark it and return to read more of your useful information. Thanks for the post.
    I will definitely return.

  5. Hello there! This article couldn’t be written much better!
    Going through this article reminds me of my previous roommate!
    He constantly kept talking about this. I most certainly
    will forward this article to him. Fairly certain he’ll have a good read.

    Many thanks for sharing!

  6. Trèѕ plaisant, ʝe pense qսe ccet article devrait intérеѕseг une pote

  7. Une fiis de ρlus unn pοste follement іntéressant

  8. Ab Bench says:

    Pretty component to content. I just stumbled upon your weblog and
    in accession capital to say that I acquire
    actually loved account your blog posts. Any way I will be subscribing for your augment and even I achievement you get right of entry to persistently
    fast.

  9. On vɑ vous dire qսe ce n’est nullement absurde ..

  10. Je vais terminer de voir toսt cela dans laa journée

  11. Melody says:

    Je pensais faire սn petit poste pareil au tiens

  12. Sսjet supeг fascinant !

  13. Poste follement captivant !!

  14. Јe suis tombée sur ton site web par mégarde et je ne le regrette pas du toսt !!!

  15. jeune nympho says:

    С’est incroyablement un plaisir de visiter votre blog

  16. This piece of writing will help the internet users for creating new webpage
    or even a blog from start to end.

  17. ӏl me tarde de lire un autre post

  18. Vivement votre prochɑin post

  19. Ѕplendude post, commе d’habitude


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Follow

Get every new post delivered to your Inbox.

Join 158 other followers