Static Web Apps – A Field Guide

http://www.staticapps.org/?hn

by trumbitta2 • 12 years ago

80 92 12 years ago

daleharvey• 12 years ago

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.

e12e• 12 years ago

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

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

bowlofpetunias• 12 years ago

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.

mbleigh13• 12 years ago

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.

rquantz2• 12 years ago

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_ting6• 12 years ago

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

derengel3• 12 years ago

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.

rquantz2• 12 years ago

Yeah, part of the application works that way, but then you still have to write an API, it just lives on a different server.

foreigner• 12 years ago

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.

badman_ting6• 12 years ago

I think performance is slightly more complicated than that. For just a document, like a blog post, I totally agree -- and find it irritating that Blogger has a "static app" now just to serve a damn page with a blog post. But for an application, doing it this way can front-load things, so that the startup time for the app is long, but transitioning between states can be faster.

jakejohnson2• 12 years ago

A great example of this in action is Apostle.io. There's a short delay to front-load things and then the app becomes blazing fast when transitioning between states. Internally, it's only making JSON requests to an API that it needs for the view/state. Only parts of the DOM are updated instead of re-rendering the entire page.

couchand• 12 years ago

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.

mbleigh13• 12 years ago

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.

mbleigh13• 12 years ago

This largely depends on application structure. If your application relies heavily on being "linked into" i.e. a user is likely to follow a link to a single resource within the app and is unlikely to continue browsing or accessing other content on the app, doing it on the server is (at least marginally) faster.

If, however, your application use pattern involves users performing numerous actions or navigating around within the application once they land there, a request/response style app only has the overhead of re-sending various bits of layout HTML and re-requesting all of the JS, CSS, and images associated with the site.

kennethkl• 12 years ago

Why take a step back in technology?

Gracana• 12 years ago

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• 12 years ago

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.

badman_ting6• 12 years ago

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• 12 years ago

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

hibikir• 12 years ago

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.

jonny_eh• 12 years ago

Got any specific examples?

fidotron• 12 years ago

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.

ludicast• 12 years ago

The tooling is now awesome (imho). I am the furthest thing from a node.js fanboy, but as a build pipeline it is awesome.

Being able to have a gulpfile take care of compiling jade, coffeescript and sass, triggering live reloads, etc., immediately makes me smile. As a former-Flex developer who dealt with some heinous build-times because the tooling was worth it, I now have a better front-end alternative with sub-quarter-second build times.

And if you have a json-serving backend (rails, spray.io, whatever) you can set up easy double tests of your front-end logic, where you mock out the backend, and then run slower "integration" tests where you include it. Might sound wacky but I've found this to be a way to quickly develop robust systems. For me, angular's dependency-injection makes it even easier.

So this static-koolaid took a while for me to drink, but I'm liking it more all the time.

valisystem• 12 years ago

I once did a website exactly like this. Nothing required a web application server to run, and I was building the (quite simple) thing from the ground up.

Once my build environment was set up, the dev cycle and experience was stellar. Fast, on change, builds, lighting fast local page reloads.

Deployment was just pushing static files on the http server, that served only statics files, like the good old days.

Once that was done, a problem remained: since it was a one shot experiment, with something quite simple, I had only one dev environment for that thing, and I did not document how I did it.

My conclusion was : part of apps that serves dynamic page are kind of build environment that can't pre-built the artifact. But the build environment is part of the code, just like a Makefile would.

It's probably possible to build and serve static page with a good experience as a whole, but your tool quality (easy to deploy and reliable) for building must be great.

daemonk• 12 years ago

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

dickeytk• 12 years ago

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

mbleigh13• 12 years ago

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.

simonw2• 12 years ago

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.

tonyedgecombe• 12 years ago

It won't catch on :)

oneeyedpigeon• 12 years ago

Add a thin-layer of javascript for immediate feedback on certain UI operations, and I'm sold.

mkr-hn• 12 years ago

It needs a catchy name. How about asynchronous javascript?

Rusky• 12 years ago

Static web apps are excellent for things like webmail, Google Docs, etc. that aren't going to be crawled. It's simpler there, and is probably how things should work in a hypothetical non-web-based but still deployed-web-style app ecosystem.

For a blog, or a forum system, or twitter, or anything that should be crawled and linked to and shared, it doesn't really make sense, and "pages and forms" makes much more sense.

jfaucett• 12 years ago

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.

derengel3• 12 years ago

I agree with you but isn't paint program a bit extreme as an example? surely much less interactive webapps can also benefit lots from programming all the logic/UI on the client? (newbie)

simonw2• 12 years ago

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.

ams6110• 12 years ago

So we're back to Powerbuilder again.

minhajuddin2• 12 years ago

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.

mantrax47• 12 years ago

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

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

minhajuddin2• 12 years ago

Many CMSes ask you to write your templating code in something which is safe to run on the server, check 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.

jcolemorr11• 12 years ago

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.

rubyn00bie• 12 years ago

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.

AdrianRossouw• 12 years ago

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

anishkothari• 12 years ago

Prose is seriously awesome! Thank you :-)

klapinat0r2• 12 years ago

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?

mbleigh13• 12 years ago

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... -- if so, what doesn't make sense from that perspective?

klapinat0r2• 12 years ago

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.

skrebbel• 12 years ago

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.

mbleigh13• 12 years ago

Because it's describing two different (but related) things. Jekyll blogs are static sites, but not Single-Page Apps, as an example.

thruflo2• 12 years ago

I believe the point is to drive traffic to 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.

mbleigh13• 12 years ago

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

pygy_3• 12 years ago

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.

camus2• 12 years ago

cant the first page just request a token through ajax?

reverius422• 12 years ago

yes.

Joeri2• 12 years ago

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_3• 12 years ago

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

mbleigh13• 12 years ago

CSRF is more or less impossible in a static site architecture. Since everything is just static HTML there are generally no form submission endpoints to attack.

XSS can be very dangerous, as can session hijacking, but CSRF is pretty much moot on static apps.

pygy_3• 12 years ago

Everything is _not_ static: there's a data channel.

If you need to support browsers that do not support localStorage, indexedDB or another kind of local, private storage, you must either restrict authentication to a single tab or provide a token on page load, and not later (one token per page load).

This is less of a concern now, but it used to be the case.

dpweb2• 12 years ago

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.

snowwrestler2• 12 years ago

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?

dpweb2• 12 years ago

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

snowwrestler2• 12 years ago

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.

BinaryIdiot2• 12 years ago

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.

mbleigh13• 12 years ago

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

BinaryIdiot2• 12 years ago

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.

mantrax47• 12 years ago

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.

mbleigh13• 12 years ago

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.

mantrax47• 12 years ago

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

Joeri2• 12 years ago

The most scalable way of rendering templates is doing it on the client, since that means users get a dedicated machine for rendering the templates.

mantrax47• 12 years ago

You're confusing server CPU usage with scalability and performance.

HTML template rendering on either the server or client is embarassingly parallel, as it just takes a viewmodel (basically) and populates a template of HTML with its variables, with zero other calls and dependencies.

You can scale this particular step to infinite number of servers, without any bottleneck appearing (hence, it's horizontally scalable).

And HTML template rendering on the server can be faster, because for client-side rendering you need at least two roundtrips to the server (fetch template, one; fetch content via JS, two), and for complex apps this becomes tens of HTTP requests (side panels, user context, footers, menus etc.), versus just one roundtrip for a server-based approach.

Request/response lag is critical in the way an app is perceived.

Also when it comes to CPU, as I already said in my previous response, view rendering is the cheapest step computationally you have in an app. Any other service takes more time and resources than that. So view rendering is never the bottleneck, and "optimizing" it away with complicated client-side shenanigans is the very definition of premature optimization.

troels• 12 years ago

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.

alok-g• 12 years ago

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?

jakejohnson2• 12 years ago

I recommend checking out some of the examples provided by Firebase. In particular, something like 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.

Static Web Apps – A Field Guide

Related Stories