Tiny Websites Have No Server

A big trend in web services right now is the so-called serverless computing, such as Amazon’s Lambda service. The idea is you don’t have a dedicated server waiting for requests for a specific purpose. Instead, you have one server (such as Amazon’s) listening for lots of requests and on demand, you spin up an environment to process that request. Conceptually, it lets you run a bit of Javascript or some other language “in the cloud” with no dedicated server.  https://itty.bitty.site takes this one step farther. The site creates self-contained websites where the content is encoded in the URL itself.

Probably the best example is to simply go to the site and click on “About itty bitty.” That page is itself encoded in its own URL. If you then click on the App link, you’ll see a calculator, showing that this isn’t just for snippets of text. While this does depend on the itty.bitty.site web host to provide the decoding framework, the decoding is done totally in your browser and the code is open source. What that means is you could host it on your own server, if you wanted to.

At first, this seems like a novelty until you start thinking about it. A small computer with an Internet connection could easily formulate these URLs to create web pages. A bigger computer could even host the itty.bitty server. Then there’s the privacy issue. At first, we were thinking that a page like this would be hard to censor since there is no centralized server with the content. But you still need the decoding framework. However, that wouldn’t stop a sophisticated user from “redirecting” to another — maybe private — decoding website and reading the page regardless of anyone’s disapproval of the content.

That might be the most compelling case of all. You can encode something in a URL and then anyone with that URL could read your content even if someone shuts down your servers (or the itty bitty servers). The itty bitty server just hands out some generic JavaScript. The website data is stored as a fragment which — interestingly enough — doesn’t get sent to the server.

That means the server doesn’t even get a look at what you are trying to decode. It just provides the decoding framework and your browser does all the rest of the work locally. We’d love to see someone fork the project and add simple encryption, too. Currently, the text is compressed and base 64 encoded, but anyone with the URL can decode what it says. An encryption key would allow you to send URLs in the clear that only some people could decode and would be very hard to suppress.

The itty bitty code itself is an app since you can edit most pages with an edit link at the top right corner. If you don’t like editing in place, the site explains how you can use a generic HTML file or use an online HTML editor, if you prefer.

There are limitations. You probably can’t host graphics internally — you’d need an external place to point to pictures. You also can make really long URLs — which means some services like Twitter will cut them off. We figure you could use a URL shortener if you needed to. There’s also a way to make a QR code baked right in.

We could see this replacing a server on a Raspberry Pi project. While this isn’t technically serverless computing, it did remind us of how to write code for assistants.

(Editor’s Note: We’ve actually seen this before. Code is data, data is code.)

49 thoughts on “Tiny Websites Have No Server

  1. Why isn’t the link just “data:text/html;base64,….”? No server necessary at all. Or even skip the base64 and you can read the content with a text editor.

    One unlisted and huge limitation is that you can’t link to other “tiny sites” from one tiny webpage.

      1. That worked! You can also encode graphics into URLs, a few sites do that. Must speed up loading of common images, or make them available offline or something.

        This webpage-as-URL thing is a bright idea! And we don’t need ANY websites to “decode” it.

        A prize for the best “site” someone posts in this thread…

        [actually I haven’t got a prize, but I’ll applaud here in my chair]

    1. Well, you could link if the total length was short enough or if you cheat and use a URL shortener (which, again, makes you dependent on a host, though).

      Also, the base 64 data is not compressed so where you have URL limits (Twitter) you can’t fit as much.

          1. I noticed something about this at least on Chrome. If you click that link the title is “Be Careful”. If you then click on the Palindrome link, the title will change to “Palindromes.” But if you hit back, you’ll get the first page but the title will not change!

      1. The good old days quickly switched to broadcasting Commodore 64 data tapes over AM radio because typing is slow. You still needed the magazine to fix up the corrupted bytes but it saved a lit of typing.

    1. I like the idea of putting these into QR codes for simple informational signs and such. It would be much more useful if the “web server” was embedded in the url too. Something like:

      <a href="javascript:{document.write('testHello world.’);}”>Tiny site

      1. Also works fine if you cut off the server part, up to the “d” of “data”, then keep the rest. Firefox doesn’t mind data: as a URL type. That means you don’t connect to any server.

  2. Were the itty.bitty server taken down or compromized, a sophisticated user might redirect to a separate website — or create a browser extension. Intercept requests to the itty.bitty site and serve a clean decoding script from local machine instead.

    Maybe one can iframe the itty.bitty page, adding some JS trinket to a page that would otherwise not allow one (say, a hosted blog platform).

    It’s an interesting concept. I just can’t shake the feeling that someone is going to use it to handle some sensitive data, creating a mess, as the different itty.bitty apps would have limited protection from each other. (that is, if this concept were to become popular — if it doesn’t really get used in first place, that’s a moot point)

  3. I’m not quite sure I even see the point of this. If it is to host small, basic web pages, just gzip compress the html and use Content-encoding: x-gzip, which can be done with a couple changes to the default Apache2 mime config. For example see:
    It happens to be a served from a Google compute instance, but it could just as easily be an ESP8266 in my basement. No 2K or 4K content size limit, and it only depends on one server.
    I agree it’s an interesting hack using the #offset in a different way than it’s design intent of an index position in a web page, but I don’t see how it has any practical application.

    1. Like I said, I think the real interesting thing is if you wanted to post something you were afraid someone would try to take down. if the URL exists, it is readable. The encryption I suggested would make that even more real.

      1. I’m no sure that’s much more difficult to take down than something hosted. Twitter, google, etc often remove “objectionable” links.
        The best way I know of to post something that is very difficult to purge from the internet is to post it to a newsgroup. Granted, newsgroups aren’t as active as they once were, but they are still easily accessible through google groups, and there are still lots of groups with many daily posts.

        1. Yes, that’s true although for many people less obvious. So I’m thinking this. I’m a political dissident in Upper Volvenia. I want to warn the world about the latest atrocities (Help! Help! I’m being repressed!). I go to an Internet cafe and I make a page up using this tool on a public PC. I post to Twitter, Reddit, Facebook, etc. I also print out the QR code 100 times. I log off and disappear after putting the QR code under all the windshields in the parking lot.

          So yeah, you could get Twitter et al to pull my post. But what if dozens of people who sympathize with Upper Volvenia pick it up? They spread it even further. You can block itty.bitty.site, but anyone who understands how to decode it still can. And you can’t block it globally. So everyone outside Upper Volvenia that has seen my posts can read it. There’s no server account for me to have to create. No server for the secret police to hack or DDOS without ticking off a lot of other people.

  4. The use that jumped out to me is QR codes. Instead of just being a rather useless shortcut to typing in URL, the QR code would become a tiny little two-dimensional server.

  5. Self-contained webserver? As in a text document? Want styles, then pdf. Or a .zip of a website. Or a .png or .jpg. This reminds me of the explosion of OO patterns a couple of decades ago, with lots of fancy names for things we had been doing for a long time. It’s not a web server, it’s just a damn web page you’re sending an offline copy of to someone.

  6. So a few bytes (or a few thousand) of self-contained, portable data, that can be decoded to show content on the screeen? That should have its own name. How about a “document”? (I’m still impressed, and it is very cool; time will tell how useful it is; but *new* it is not.)

  7. It’s like they reinvented files! This is a wonderful idea, all except for the part where it’s not an actual file. If you can send someone this URL, you can send them an HTML file.

    You could achieve a similar effect by just making a site that still makes sense when downloaded as HTML, and telling people to download and email it.

    Although it may be useful for QR codes as per commenter suggested.

    But really, we need better offline tools in general. The fact that this exists, and has use cases, is exactly why I hope web bundles succeed.

Leave a Reply

Please be kind and respectful to help make the comments section excellent. (Comment Policy)

This site uses Akismet to reduce spam. Learn how your comment data is processed.