Static Web Apps – A Field Guide

Allow me to describe a revolutionary way of creating web applications. I call it "Pages and forms".

If you need to display some information, you use an abstraction called a "page" - a full HTML document served from a URL. You can generate the HTML using a variety well understood, easily tested server-side frameworks. You can even just serve static HTML saved in a file.

Pages are easy to scale, easy to link to and work on every device, platform and browser released since IE and Netscape 3 back in 1996 (or earlier if you don't need to rely on the Host header).

How about adding interactivity? That's where "forms" come in. Forms allow your application to request information from users and submit it back to your server using a simple and widely understood key/value mechanism.

By combining pages and forms you can build applications that work everywhere, are easy to link to, easy to maintain and can be scaled to handle anything you can throw at them.

These people call an app "static" when all content is dynamically generated at runtime on the client-side. Everybody else calls these things "single-page web applications". I really don't see the point of defining a new, confusing term for an existing concept.

I used to work at a place that switched to only building apps this way. It was architecturally simple, but for random business apps, there was one major difficulty: The tooling felt like going back on a time machine. You have all this tools out there for download, but almost all of them don't do quite what you want, are not easy to extend without just getting tied to an old version forever, and have trouble interacting with each other.

When you get developers that are wishing they were back using Swing because it was easier, you know you have trouble.

Disagree with a few things, the title 'static is better', is hyperbole, its a different environment. Also the 'the doesnt mean they are any less capable' is pretty much by definition wrong.

That being said I absolutely love the architecture, pretty much every application I build these days starts with switching my github default branch to gh-pages. I work on http://pouchdb.com and use that for storing and syncing data. not having to worry about how my servers are configured / how they are running, how to move an application makes me feel like I can build what I want then when I come back in 2 years it 'just works', with dynamic applications I always feel there is a maintenance burden that I cant shake.

So is this just another way to talk about the now-ubiquitous thick-client app? Or is there something revolutionary I don't see in my cursory look at this site? There is definitely something to be said for building separate services as your API, rather than thinking your static assets have to be married to the data processing backend. But calling that a static app is misleading -- it's still dynamic, and in fact the server is still processing data, it's just distributed.

The elephant in the room is performance. They can't help mentioning "perceived performance" but conveniently haven't gotten around to explaining that in detail. In my experience browser performance is a struggle, and it's always faster to do as much as possible on the server.

I don't think the dichotomy of static vs. dynamic is that useful really. At least not if they are taken to mean pre-compiled vs. generated directly as a response to a http request. The so-called static pages are presumably still assembled by some programmatic pipeline (aka "dynamic").

What does matter, is that pages that are the same for all users, and that change rarely are served with proper caching headers. That way you can drop a http-cache in front of your app and voila, you have all the same benefits that a pre-compiled site would give you, but without the pain of having to use a completely separate process.

The hard part is separating elements that have different frequencies of change from each other. For some reason, this is not something that popular web frameworks (Such as Rails) push very hard, but it's something I find extremely useful when building web apps. A classic trick is putting user-specific information (Such as your name + karma score in the top right corner of this site) in a separate ajax-call, while the main page is served with hard public-cache headers.

I honestly misunderstood the definition when I first read it. I've built a variety of web apps (old php + mysql, actual static content, nodeJS + angular), and I this terminology escaped me. I've never looked at an Angular app and referred to it as static? In fact, what is defined here is the exact opposite of what I'd assume was a static application.

I wonder if people who advocate this as "better" have ever build anything even remotely complex. It's this kind of simplistic tunnel vision why many engineers look down their noses at "web development".

Also, this is nothing but a marketing site for a "static web hosting service", which explains the superficial buzzword bingo.

Isn't this really just advocating clear separation/encapsulation between client-side and server-side? IE. create a "static" web app that can get data from server side through REST API or allow you to plug in other sources of data (pouchdb).

It certainly has its advantages. I would even say if you can get to a point where your app is totally static, you should do it. But if there's even a little server-side state things can get complicated pretty quickly.

For example, say your app uses hash/fragment URLs, and users need to be logged in to access the app. A user hits yourapp.com/#/whatever, but isn't logged in, so you bounce them to the login page. Except, oops, the hash/fragment doesn't get sent to the server, so your login page doesn't know where to redirect the client after logging in.

After looking over the site it seems to be advocating simply serving static content statically and / or create single-page web applications.

I'm not entirely sure 100% static makes sense either. For instance serving debug versus minified versions of a website. Sure you could compile everything and create different outputs but that takes time and testing to setup; I haven't worked on a team that would really have the upfront time to do that. The alternative is loading assets via JavaScript but that's much slower than including the links upfront.

The other issue is serving code that requires higher permissions to execute. I would rather leave chunks out if I know if can't be accessed from the server-side to make it a little more difficult for someone to figure out how to exploit my website. It's certainly not foolproof nor secure but I don't want to make it completely easy for someone to understand how all administrative functions and permissions work either. You could probably compile different versions of the website and control which gets served based upon authentication but that's even more upfront cost.

In other breaking news:

) Earth still exists ) Human's breathe oxygen *) Cow's fart a lot

Not to be a total arsehole, but I mean... uhh, what's the point of this?

If anything, it sounds like, from the copy, they want you to make websites but instead of calling it a "website" because that's un-cool? I don't get it.

// Start of semi-related rant

I would also like to call this statement in their opening paragraph complete non-sense and almost simple minded:

"Static web architecture eases common web development headaches without introducing additional complexity"

After many years of doing web development, I can see programming in Java, Obj-C, or .NET is worlds easier for application development. Instead of 27 different platforms (IE, Firefox, Chrome, Safari on different platforms) I have one-- the god damn operating system. Was this always the case? Nope, but it is now.

Is it easier to write a single screen on the web using JS, HTML, and CSS? Sure, but the return is marginally decreasing as the application grows. More screens, more complexity, the more HTML/CSS/JS start to show their age.

Web development becomes actually more complicated than writing a native application.

The static thing - I think its a reaction to the obvious inefficiency of dynamic pages, server processing for data that is only changed occasionally.

Consider a blog which gets posted to once a week. Do you really need dynamic processing for every page render 24/7/365? Well, that's the way it works.

But you have to have something additional for changing data/separate API. You can do the static site, but you still gotta have the XHR or JSONP calls to fetch dynamic data. You get a nice separation of UI/data, easier to tweak the UI - independent of the data (hand it off to a designer), and your separate data server can feed multiple apps or you open it up for the world to use.

I try and keep things static unless I have really good reason to do dynamically generated markup. There are still very good reasons for having a backend sometimes.

There is a middle ground if you are primarily replacing a CMS though, which is using a static site generator like jekyll.

This is something I learnt while working at [1] DevelopmentSeed. They also built a wonderful editor for github pages called [2] Prose.

[1] http://developmentseed.org/blog/2012/07/27/build-cms-free-we... [2] http://prose.io

What a coincidence, I have been building a CMS which spits out static HTML which uses the same bolt icon :) http://getsimplesite.com

I think static apps are best suited for very simple apps which don't have a lot of business rules, simple CRUD apps are the best candidates for this kind of a setup. Once you go beyond a simple app doing things on the server is much easier.

A reverse proxy cache in front of a dynamic application can approach the best of both worlds. If the page requested is static, you get a fully rendered set of HTML etc. from the cache. If the page requested needs to be customized somehow, the request passes through the cache and hits the application, which custom-renders a new page to send back.

Having skimmed the available articles, I'm still left asking: How does authorization work here? As in, do you use it to 200 or 401 an url (example.com/static/klapinat0r/feed).

Or are they simply advocating serving HTML as templates and updating with js? If so, that's hardly news is it?

By their definition that'd be Hybrid though, right?

Web development newbie here. Is there a starter template available on these lines that has the guts built-in, including both client and server code, user authentication, server-side database access, a default theme, etc., where the developer can start by defining the application-specific data models and business logic?

What's their plan for dealing with CSRF?

For this type of app, the usual solution is to embed a token in the first response, shared between the page and the server, and use it for authenticated communication through the data channel (be it AJAX or a WebSocket).

Consequently, the first page can't be static.

So we're back to Powerbuilder again.

Why take a step back in technology?

you can totally use s3 with pushState sites. They allow you to set custom redirection rules

Congratulations. With this arbitrary limitation you just eliminated the cheapest, most scalable and most simple part of the entire web application - HTML template rendering, to replace it with fragile and invisible to search engines JavaScript logic.

I believe people in firm grasp of their common sense would take the practical hybrid approach and do what makes sense for each specific scenario, rather than rely on ideology to architect their app for them.