Blog ProjectsAbout

The Power of Static Web

March 29, 2012 by Ahti Kitsik

Recent web startups often share a common pitch for the integration simplicity : “It only takes 1 line of javascript to integrate with our service!”. Disqus, KISSMetrics, Chartbeat, Google Analytics, Facebook, G+ buttons. When was the last time you had to use SERVER-SIDE code to integrate a new service? It’s gone. Let me share a few thoughts where I think this trend takes us.

Static CDN serving for “dynamic” websites

Static pregenerated websites behind CDN scale massively better than any php+mysql CMS (wordpress, drupal, joomla).

This has boosted a number of site generators like jekyll. But why now? Why not before?

Because most of the sites had a dynamic element that couldn’t be regenerated easily. Comments, mostly.

A few dynamically generated sites have become static by the introduction of Disqus commenting system that sits into browser without any server-side integration. Getting the same level of integration at the server side would bring more complexities – depends on the frameworks, language and version compatibilities.

It does not end with comments. There are “1-liner” shopping carts, chatrooms, customer feedback, customer support, visitor analytics, games. These either complement or integrate with your site and more services appearing rapidly. I hope to see more variety in apps in this field like theming/styling websites dynamically, A/B testing, JavaScript-backed content caching, AWS SimpleDB-like storages for a unified datamodel integration. Turning upside down things that previously had to sit at the server-side.

One step forward with static CDN is javascript-fetched content. This is already happening – browser JavaScript is used to fetch content for the website. But there is a pending problem with this – until about a year ago search engines did not run nor index javascript-fetched content. So the search engines must catch up in order to provide the best search results. The good news is that Google and others are already doing that! They started to run JavaScript with their V8 crawler. But it’s no way guaranteed that your JavaScript is neat enough for the V8-powered crawler. In order to keep search relevant they must keep up and start running more and more JavaScript for indexing. It’s expensive but to a certain degree we can expect JavaScript-enabled indexing crawlers to take over.

Security

By keeping 3rd party components outside of your server walls your internal systems are better protected from being compromised.
On the other hand this risk is passed on to the end-user by being exploited to any code 3rd party chooses to run in her browser.
Thankfully browsers are relatively safe sandboxes and this security threat is close to visiting any regular website. The main difference being that JavaScript provider (3rd party) can potentially tamper your webpage content and has access to your website user info and page content. So you must trust any 3rd party javascript component 100%. From the security perspective it seems favorable for the service provider to keep 3rd party integration at the browser level.

Power of insight

Browser always sees more about your user than your server because it’s closer to the user. Being closer is better.

Browser era MVC

With JavaScript data loading and pushing the widely used server-based Model-View-Controller (MVC) architecture falls apart. At least server is not the Controller it used to be. Browser becomes the new Controller and Server is just one of the Model-providers.

What are other less covered upsides and downsides of moving more action to the browser?

  • http://taivo.net/ Taivo Lints

    From the user side — how does it affect page loading speed (which is very important)? Doesn’t fetching content from n servers take considerably more time than from one server? Also, when fetching content from several servers it is very important to think through how the page should behave if any of those n external servers does not respond well (is overloaded and slow or totally down), and how to still provide the user a good experience. Because as the number of servers that the page depends on increases, the likelihood that the page will have problems also increases (the more servers, the higher probability that at least one of them is slow / down at any moment). And from the user’s perspective if the site is not performing great then it’s an unpleasant site — s/he doesn’t care if the problem was in some third party server…

  • http://ahtik.com Ahti Kitsik

    Taivo, thanks for the great feedback!
    Page loading speed is two-fold: server-side work and client-side work (javascript parse+execute and content rendering).
    Loading speed for javascript is again two-fold: fetching the script and parsing+executing. 

    If coded properly javascript and other resources can be fetched in parallel so CDN and 3rd party services removes your server as a bottleneck. Loading content from more servers can take less time than the single server loading as the work is distributed. 

    If 3rd party is dedicated to offering the service browser-side then it usually puts a lot of effort into ensuring it’s stability, scalability and performance.

    As the service mixing is brought to the client side it’s easier to control the user experience when one of the services fails – for example if comments system is down then comments are just not visible for a short time.

    Compared to the server-based system where your whole page crashes when something happens with the comments system!

    Yes, when designing the site it’s super critical to plan for the 3rd party service failures and not block your site loading. All services should load lazily right after rest of your site is rendered, preferably in the order of importance.

    Feching content from just one server has one good benefit, especially within the next few years – SPDY. As SPDY is now enabled by default in latest Chrome and Firefox we can skip the latency issues that previously came from the TCP stack when requesting multiple resources. But this is just about server architecture. This does not make static sites less favourable – quite the opposite! Doing more work at the client-side becomes faster as the service runs within one host.

    But yes, it’s not that black and white.
    Hosting services yourself has it’s benefits but often 3rd party browser-based services provide way better product with faster integration than the server-side integration.

    By the way, comments of this blog are just a javascript-based service, not wordpress commenting system. In that perspective my whole blog could be just a set of static files as comment is the only dynamic nature here!

Home | ©2006-2010 Ahti Kitsik. All rights reserved.