
Static Web Apps – A Field Guide - trumbitta2
http://www.staticapps.org/?hn
======
simonw
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.

~~~
jfaucett
I see your point but sorry, its nonsense when talking about "webapps" \- as
opposed to anything largely text based and with very limited user interaction.
You are going to have to rerender the page for every single user action. The
feedback the user gets is going to be ridicously slow for marginally
complicated apps, creepingly slow on low-bandwith devices.

Just deleting an item in a paginated list will require posting data while
maintaining the query parameters in the url, running a possibly very complex
query on the server again, recalculating and rerendering the page and then
shoving that data all back to the user via expensive TCP cycles - huge waste.
A "webapp" on the otherhand makes a post to the server gets a 204, and on the
client side simply removes the corresponding dom element.

As an example, think about implementing MS Paint and the corresponding user
experience - using what you're talking about.

~~~
simonw
I agree that you'd be nuts to build an interactive drawing program like
this... But the vast majority of what people are calling "web apps" today
aren't anything like a drawing program.

I'm also personally a big fan of adding a layer if JavaScript to improve
interactivity, but the "static apps" approach advocated in the OP goes way too
far for most apps in my opinion.

------
skrebbel
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.

~~~
thruflo
I believe the point is to drive traffic to
[http://www.divshot.com](http://www.divshot.com), re-labelling their snake oil
as a uniquely cold-blooded essential along the way.

I quote from their features page:

> Fully featured? Yes. Get pushState with custom routes, clean URLs (goodbye,
> .html), and more. ... Whatever you choose, we support it.

> S'all about you, dev, s'all 'bout you.

~~~
mbleigh
Actually, we built our static hosting service because we were already
developing with a static web architecture and couldn't find an existing
acceptable option for hosting.

I'm building the platform because I believe in the technology, not espousing
the technology because I built the platform. :)

~~~
thruflo
I also believe in the technology and the general architecture you're
espousing. I found the content on
[http://www.staticapps.org](http://www.staticapps.org) well written and
constructive and the links to [http://www.divshot.com](http://www.divshot.com)
are unobtrusive.

My reaction to [http://www.divshot.com](http://www.divshot.com) is something
else entirely. To solve the "problem" of static file hosting and deployment
with a service that is "compatible with Angular and Firebase" and supports
"pushState with custom routes" is clearly disingenuous.

Not that there's anything wrong with effective marketing. If your target
audience is people who don't know what the words mean, then knock yourself
out.

~~~
mbleigh
We're trying to market to people who want to use static architecture,
regardless of experience. It's a bit of an education issue as people are
familiar with e.g. Angular and Ember but don't necessarily know what it means
to deploy them as a static app.

Can you tell me what you find disingenuous about the claims? What would appeal
to you when describing a static web hosting service?

------
hibikir
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.

~~~
fidotron
Swing is/was verbose for simple stuff, but beyond a fairly low complexity bar
it is enormously preferable to the web stack, at least from a developer
perspective.

While Java got somewhere with the whole deployment thing it was never quite as
slick as the web, and that's the killer aspect of the web really.

What is funny about the web these days is how they're very slowly reinventing
all the things NeXT were doing in the 80s, only using a lot more memory and
CPU in the process. Ironic given it started on a NeXT in the first place.

------
daleharvey
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](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.

~~~
e12e
> Disagree with a few things, the title 'static is better', is hyperbole, its
> a different environment.

This.

I feel I might fall under the hn banhammer soon, but I really wish people
would actually _read_ Fieldings thesis (introducing REST) -- it's a really
good overview of the different architectures one might use for a client-server
system. It' not _just_ REST, REST is a natural conclusion drawn from the
alternatives when the goal is a highly performing system for hypermedia:

[https://www.ics.uci.edu/~fielding/pubs/dissertation/net_arch...](https://www.ics.uci.edu/~fielding/pubs/dissertation/net_arch_styles.htm#sec_3_2)

But it's worth noting that fat-client styles are also in there, and the trade-
offs mentioned are worth keeping in mind (no, there is no silver bullet -- you
actually should choose an architecture that fits your problem domain.
Shocking, isn't it?).

------
rquantz
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.

~~~
badman_ting
The assets served to the client are static, they can be served by a simple
server, cached through CDNs, etc.

~~~
derengel
I don't know how it is static either or are you referring that it is 'static'
only from the web browser(consumer) point of view? for example, in the backend
you could be generating a value from a database.

~~~
badman_ting
It's really not worth sperging out about this. It just means the HTML/JS/CSS
assets delivered by the front-end server do not change.

~~~
mtrimpe
Sperging out? Are you serious?

~~~
abrichr
I had to look this one up:

 _Sperging out: When someone goes on a long, in-depth, overly elaborate
explanation long after everyone already gets the point, but will not fucking
end._

[1]
[http://www.urbandictionary.com/define.php?term=Sperging%20ou...](http://www.urbandictionary.com/define.php?term=Sperging%20out)

~~~
mtrimpe
Just so the original author doesn't accidentally misinterpret my complete and
utter disgust for his statement as ignorance; I pretty much guessed it
instantly.

It might be a new term, but as far as I'm concerned it's as bannable an
offense as calling someone a faggot or something of that kind.

~~~
mantrax4
Gee, aren't you an outraged little fella.

~~~
mtrimpe
Ah well; thank you for your contribution. Enjoy it here; I have feeling you'll
fit right in by now.

I'll just retreat to my old-man cave to contemplate a time when the internets
had this quaint little place where conversation was civil, the news was
enlightening and everyone was striving to break free from the status quo by
going at it alone, forging our own path.

It was fun while it lasted...

~~~
mantrax4
Did those old times include being insulted and outraged at every word your co-
debaters said?

It's quite ironic for you to be sad about the lack of civil discourse, when
you used the opportunity to hijack the original point of the poster and start
discussing a 'bannable offense' on the occasion of a silly colloqual phrase
they used.

You think you're taking the high ground? I for one long for a debate where the
people talking can stay focused on a topic without being constantly insulted
by this or that for the purpose of cheap outrage.

------
foreigner
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.

~~~
couchand
Also indexing by search engines or the like. Expecting a web crawler to
resolve your JavaScript code to produce a complete page is probably a recipe
for pain.

~~~
mbleigh
Search friendliness is probably the biggest problem yet to be completely
solved for static apps. There are workarounds, but they are admittedly less
than perfect.

However, given the general web development trends towards JS-driven interfaces
and upcoming standards like Web Components, I don't think it's going to stay
unsolved for much longer.

------
troels
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.

------
jcolemorr11
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.

------
bowlofpetunias
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.

~~~
mbleigh
Your derision comes with a dearth of actual reasoning as to why "complex"
applications don't work from a static architecture perspective or how you
define complexity.

------
daemonk
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).

------
badman_ting
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.

~~~
ethikal
There are ways around this. With ember it is possible to use browser history
to mask the hash... [http://emberjs.com/guides/routing/specifying-the-
location-ap...](http://emberjs.com/guides/routing/specifying-the-location-
api/)

------
BinaryIdiot
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.

~~~
mbleigh
The great thing about a static app architecture is that for things like
administrative functions you can usually easily build an entirely separate
interface and application utilizing the same back-end resources.

Security through obscurity is never sufficient, and static architecture makes
you think through those concerns more thoroughly before deploy. See
[http://www.staticapps.org/articles/authentication-and-
author...](http://www.staticapps.org/articles/authentication-and-
authorization) for more on that subject.

As to development vs production, minifying etc. that's something we're trying
to solve with multi-environment hosting at Divshot.

~~~
BinaryIdiot
It's not typically cost effective or realistic to build an entirely separate
interface for administrative functionality (in fact, for user experience
purposes, it's typically better to be able to administrator changes in place).
As I mentioned it's doable but requires additional upfront work that I have
never had time to do on any project I get to work on.

Obviously security through obscurity isn't sufficient as I said it wasn't
security :) but I don't see any reason why a static architecture should make
you think about those issues any more or less; you should already be doing so.

------
rubyn00bie
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.

------
dpweb
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.

~~~
snowwrestler
> 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.

Isn't this the exact problem that a reverse proxy cache solves?

~~~
dpweb
it does if you want to setup the 2nd piece, but I like nginx alot

------
AdrianRossouw
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...](http://developmentseed.org/blog/2012/07/27/build-cms-free-websites/)
[2] [http://prose.io](http://prose.io)

~~~
anishkothari
Prose is seriously awesome! Thank you :-)

------
minhajuddin
What a coincidence, I have been building a CMS which spits out static HTML
which uses the same bolt icon :)
[http://getsimplesite.com](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.

~~~
mantrax4
And you also make the same unsubstantiated claims of superiority, without any
explanation.

What is this magical hosted CMS that limits my freedom, exactly?

~~~
minhajuddin
Many CMSes ask you to write your templating code in something which is safe to
run on the server, check
[http://get.harmonyapp.com/](http://get.harmonyapp.com/) for instance it
forces you to use liquid templates. Getsimplesite on the other hand uses plain
javascript to write page templates.

~~~
mantrax4
So then the solution that comes to mind before I drop my entire stack to use
yours, is to simply use the language the CMS itself was written in (Python,
PHP, whatever), instead of the CMS. Sorry. Work on your value proposition.

------
snowwrestler
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.

------
klapinat0r
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?

~~~
mbleigh
Authentication and Authorization are handled via JS calls to back-end services
that know. Did you read [http://www.staticapps.org/articles/authentication-
and-author...](http://www.staticapps.org/articles/authentication-and-
authorization) \-- if so, what doesn't make sense from that perspective?

~~~
klapinat0r
Whether or not this was a new take on static + auth, as it sounded like it was
the standard client-js apps (which you confirmed it is). Not that it's not a
valid approach, I just assumed it was something new.

------
alok-g
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?

~~~
jakejohnson
I recommend checking out some of the examples provided by Firebase. In
particular, something like angularFire-seed
([https://github.com/firebase/angularFire-
seed](https://github.com/firebase/angularFire-seed)) is a great way to get
started. Firebase can handle user authentication and data storage. AngularJS +
Firebase is an amazingly productive combo. Set up Bower and use Bootstrap for
the user interface, you’re all set.

It would be a great idea to set up some boilerplates for StaticApps.org
showing how easy it is to get started.

------
pygy_
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.

~~~
Joeri
The token is returned by the auth service when the user logs in. The initial
page bootstraps in unauthenticated mode and always has to query the auth
service first to figure out if the user is logged in. That's how I've done it
in the past.

~~~
pygy_
How do you tell apart the app loaded in several tabs and and an attacker?

------
ams6110
So we're back to Powerbuilder again.

------
kennethkl
Why take a step back in technology?

~~~
Gracana
I think you're misunderstanding what they mean by "static." The served pages
are static html and javascript, and the javascript loads other resources from
the server. The "static" part just means there is no page rendering occurring
on the server.

~~~
otterley
Out of all the processes that must occur to render a dynamic server-side
response (database queries, computations, etc.), assembling HTML ("page
rendering") is probably one of the least expensive. This seems like a
premature optimization to me.

~~~
reverius42
It's not just a performance optimization. It's a cleaner architecture that's
easier to test.

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

~~~
mbleigh
Redirects don't maintain URL state. If I make a redirect rule that points
everything to /index.html, once I get to /index.html the browser doesn't keep
the old URL in the location bar.

------
mantrax4
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.

~~~
mbleigh
If you're running a mostly-public content site that depends largely on search
engine traffic, static is probably not the way to go (yet).

If your application lives mostly inside of a login, there's little reason to
force yourself to render HTML from the server rather than building reusable
APIs that can be shared across web, mobile, etc.

~~~
mantrax4
False dichotomy.

Building reusable APIs has nothing to do with forcing yourself to consume them
with client-side JS. Maybe that approach works as a training wheels type of
guide for developers who can't stay focused, but a service layer is pretty
much the norm for any competently written web app, whether a particular API
call is materialized with client-side or server-side view rendering.

Few additional points about thinking intranet apps get a pass for being
intranet:

1\. Even on the intranet, it's good for people to be able to bookmark specific
point of their navigation and query type (i.e. page, sorting order, filtering
criteria, via URL query); it matches how they use the web, and improves their
workflows and performance. People don't react well when the web app you
developed just decided to pick up all the limitation of native apps, with none
of the benefits of a native app (native UI, performance, OS integration etc.).
Don't make it a crappy wanna-be-real-app web app, just make it a good web app,
acting like a web app.

Now, sure, if you try really heard, you can emulate it with a big number of
static pages (so it works when you refresh) and manually synching everything
with the browser History API, but whoops, you just blew your budget, deadline
and doubled the number of tests your app needs to pass QA checks since your
app now has complicated history management where it didn't need any (aside
form ideology), instead of letting the browser and server work it out using
the good old school ways of handling page state.

2\. It's pointless waste to develop two set of practices, tools and processes
for creating & maintaining public apps, vs. internal apps. What for? Feeling
good inside that you saved 3% CPU on the server in view rendering? Please.
I've gotten people fired over insisting on using their own pet practices like
these (with no provable real-world benefit) over common sense, and wasting the
business time and money.

3\. In my practical the line between an intranet app and Internet apps is
thing. So if an internal app becomes public (in a limited or full-blown
capacity), it's a good idea you don't have to drop all the UI code and start
over, mkay.

I write intranet apps for a living (they mix server-side and client-side
rendering).

~~~
mbleigh
I wasn't referring to intranet vs. internet apps, but rather apps that
generate public content that can be viewed without authentication (e.g.
Twitter) vs. apps whose information is entirely restricted to authenticated
users (e.g. GMail). Basically: does the app generate stuff that needs to be
crawled by a search engine?

While client-side routing and state preservation used to be a very difficult
thing, these days it's actually pretty straightforward (ngRoute, Backbone
router, Ember router, etc).

