PA R A D I G M I I S TA T I C I S T H E N E W D Y N A M I C B Y B U D PA R R I like to think of static site generators more broadly than just a set of tools. For me they represent a new way of thinking about what we do and have changed my entire way of working.
60+ Wordpress sites • 5 Flat-file, no-db sites (Statamic) • 25+ static sites (Jekyll, Metalsmith, Webhook) I've been designing and developing websites for 12 years. I've built more than 70 ExpressionEngine websites and close to that many Wordpress sites, both large and small.
was using. I felt constrained by them; spending too much time maintaining the infrastructure behind my websites and not enough time making them better for users. I hate administering servers!!!!!
for the campaign because we were working on such a short timeline and already bringing in about $15 million a month. After this work was complete we had a very flexible donation API and now it was time to figure out what would consume it. We knew from the very beginning that our new donation platform needed to be as fast as we could reasonably make it. We were very familiar with all the stories from huge companies like Amazon and Google about how only 100 milliseconds of latency can affect conversions by as much as 1%. Needless to say, performance was was one of our very top priorities. After working closely with our Devops team to plan the architecture of the platform we decided to go static. We consumed the newly created donation API using JavaScript on static HTML pages which were served by our CDN (Akamai). We chose to do it this way in no small part because this is the fastest possible way to get the HTML document to the user since Akamai has over 50,000 edge servers and the Somewhere along the line, I stumbled on this article by Kyle Rush where he outlined their move from ExpressionEngine to a static site and what that did for them in terms of performance and stability.
C M S - F R E E W E B S I T E S D E V E L O P M E N T S E E D , J U LY 2 7 , 2 0 1 2 After Development Seed pivoted away from building Drupal-based web applications, we started over completely. We began developing the majority of our projects for clients as simple, single page websites by manually coding the HTML, CSS, and JavaScript files. We pushed the boundaries of what we could do with these standards and avoided building server applications at all costs. As a result, we were able to build some of our best work. We used the money we would have spent on wrestling with Drupal’s codebase to focus on good design and strategy work, making sure we were actually solving our clients’ problems. By developing websites as “client-side” applications that only consist of the files directly usable by a web browser with no extra work done by backend servers, we are able to pass on substantial cost savings to our clients while virtually eliminating risk of the website going “down”. For additional functionality not available to client-side applications, we vet and integrate external services. We can deploy our projects on practically any web server and not worry about whether it has the right software to run our application or the technical resources to handle high traffic. And this Development Seed was a prominent Drupal shop who dumped the complex application stack to get back to basics, and I think this paragraph is the essence of what this move has meant to me and my business.
H E P O S T- C M S W O R L D B E N B A LT E R , O C T O B E R 1 , 2 0 1 2 Although powered by the open-source CMS WordPress, the old site (shared hosting provided by Bluehost) for performance sake, would actually just served flat HTML and Javascript files from disk (generated on a regular basis by an industry-standard plugin known as W3 Total Cache), but fired up WordPress on every request (on top of the already sluggish Apache). Don’t get me wrong. WordPress can be configured to fly given the right setup, and that’s exactly what I set out to do. I got the best of the best. I spun up a shiny new AWS box, got Nginx with microcache up and running, APC for opcode, page, and object cache, and even put everything behind Varnish. But as much as it pains the developer in me, just like fixies, PBR, and Javascript, static sites are back in style. Reduce the complexity, push it to the edge, and let the visitor’s browser call APIs directly to generate any dynamic content you may need. Same functionality, same experience, no headache. The pitch is straightforward. It leads to simple, flexible, and reliable websites that allow for a renewed focus on what actually matters: the content. Dave Cole over at Development Seed (also powered by Jekyll) put it best: And this what actually matters: the content
I T E G E N E R AT O R S D O ? Run through Templates Your Text Output HTML pages Not a very satisfying answer… After the last presentation I gave, I was asked, “how do they work?” In short, they take your text, spin them through a template engine and output HTML pages. Every day on Twitter, someone announces they made a static site generator for fun over the weekend. That gets a lot of hahas, but the truth is making one of these things to use in production is quite involved once you get into the details of how to handle a variety of layouts, url schemes, pagination, categories, structured content and so on.
I T E G E N E R AT O R S D O ? Take your text-based content • Markdown or Textile • HTML • YAML • CSV • JSON so let’s slow down. The starting point is your content. Everything starts out as text, one way or the other.
I C S I T E G E N E R AT O R S D O ? {"layout"=>"default", "title"=>"Atrocity Accountability in Syria: What Criminal Investigations Have Uncovered", "category"=>"News", "excerpt"=>"ABA holds experts closed-door Meeting on results of international atrocity crimes investigations in Syria and discus how these investigations may affect policy in Syria and the region.", "published"=>true, "url"=>"/news/2015/04/14/Syria-CIJA-Closed-Door-PR/", "dir"=>"/ news/2015/04/14", "date"=>2015-04-14 00:00:00 -0400, "id"=>"/news/2015/04/14/Syria- CIJA-Closed-Door-PR", "categories"=>["news"], "next"=>, "previous"=>, "tags"=>[], "path"=>"_posts/2015-04-14-Syria-CIJA-Closed-Door-PR.md", "content"=>"On April 14, 2015, the American Bar Association (ABA) Center for Human Rights and its International Criminal Court Project will host a closed door meeting of experts on Syria entitled “Atrocity Accountability in Syria: What Criminal Investigations Have Uncovered.” The event will discuss the legal implications of a non-governmental organization undertaking high-level criminal investigation of international atrocity crimes in Syria and whether Syria policymakers should utilize this information in addressing this 4 year old conflict. The experts in attendance will come from the US government, international diplomatic corps, policy think tanks, human rights and rule of law organizations, and other members of civil society.\n \nTo view the event recap, please visit the event recap [page](http://www.international-criminal-justice-today.org/ event/2015/04/16/Syria-CIJA-Closed-Door-Event-Recap/).\n\n---\n\nThe American Bar Association’s (ABA) International Criminal Court (ICC) Project is an independent initiative of the ABA Center for Human Rights that advances international criminal justice and US-ICC relations through advocacy, education and practical legal assistance. Please visit the ABA's ICC Project [website](http://www.aba-icc.org/) for more information. \n", "section"=>"post"} which template to use what’s the URL other things the template might need to know This is the heart of the static site generator, but the part you never really see. I’m using Jekyll as example here.
assets and HTML files • Build folder gets moved to a server W H AT D O S TAT I C S I T E G E N E R AT O R S D O ? How? • Could be all done on a server with a script - with a deployment solution • Could be RSYNC or SFTP Next thing is to get that folder onto a server. The how is tricky, but there are a lot of solutions. One reason a lot of people use Jekyll is that this is all automated if you use Github-pages. Every time you change something in your repo, the site gets rebuilt and pushed to their servers, like magic.
When your audience accesses your web page there’s very little for the server to do, because it’s just the basics: HTML, JS, CSS, images. • There is no SQL database for the server to access • No complicated layers of caching needed* W H AT D O S TAT I C S I T E G E N E R AT O R S D O ? *doesn’t mean you can’t cache assets
E D Y N A M I C PA R T S ? My favorite two tools together: List.js for filtering and Tipue for search. More search tools at http://www.thenewdynamic.org/articles/search-options-for-static-websites/
H E F O U R S TA K E H O L D E R S So how do static sites impact users. I wrote a proposal to a government client who needed a discussion platform that could easily be replicated. In my proposal I talked about the four stakeholders of a web property: - the users, - the owner, - the designers/developers, and - the site's content creators.
pictures and nice fonts, apparently… PERFORMANCE IS A FEATURE serving static pages and assets from a CDN eliminates database calls and helps edge performance For users, the case is clear. Performance is a feature. Clients get this: Everyone who has waited for a page to load on their phone understands the importance of performance.
are getting heavier And even though “everyone” seems to be talking about performance, there’s evidence to suggest that other business concerns are winning. Google includes page performance in their ranking calculation, centered around best practices. We also have https on its way to becoming ubiquitous, and that's one more performance battle to fight
now • they never want their site to be down or unresponsive static sites are cheaper to build and quicker to iterate and there’s no database to hack My initial proposal for the discussion platform was to be on ExpressionEngine multi-site with a budget for hosting and server maintenance and labor for creating new sites. I dropped most of that right off the top when we switched to static.
can be replicated in minutes • It’s free to host • It can be abandoned This site was cheaper to produce because I was able to move content and content types around until I found the right balance of how to structure things. It was also faster to iterate on changes, and create multiple versions.
0 50 100 150 200 10k 100k 1m 100m Fictional chart demonstrating the increase in cost and complexity for a static site versus dynamic as traffic increases. traffic Hosting costs are minimal while dynamic sites need ever-increasing resources
G O V: C O D E D E V E L O P E D B Y T H E P E O P L E A N D F O R T H E P E O P L E , R E L E A S E D B A C K T O T H E P E O P L E T H E AT L A N T I C , J U N E 2 8 , 2 0 1 3 That adds up to cost savings. Sites that are heavily trafficked -- as Healthcare.gov can reasonably expected to be - normally have to use a caching layer to serve static content and add more server capacity as demand increases. “When we worked with the World Bank, they chose a plan from Rackspace for 16 servers,” said Gundersen. “That added tens of thousands of dollars, with a huge hosting bill every month.” HHS had similar strategic plans for the new site, at least at first. “They were planning 32 servers, between staging, production and disaster recovery, with application servers for different environments”, said Cole. “You’re just talking about content. There just needs to be one server. We're going to have two, with one for backup. That's a deduction of 30 servers.” Why was Development Seed able to succeed in selling this approach to coding and collaboration with a federal agency and other contractors, in contrast to traditional systems integrators? Or to put it another way, what could a mapping startup teach the world about making government work better? Quite a lot, as it Here’s a real-world example where the healthcare.gov site went from 32 to 2 servers by switching to static, and one of those two is for backup. We may never have to deal with that sort of traffic, but it also means that traffic spikes are never really an issue, and costs are stable.
G O V: C O D E D E V E L O P E D B Y T H E P E O P L E A N D F O R T H E P E O P L E , R E L E A S E D B A C K T O T H E P E O P L E T H E AT L A N T I C , J U N E 2 8 , 2 0 1 3 • The part that worked. • I ran this on my desktop (took 7 minutes to generate though) • Genesis of prose.io For a while, the healhcare.gov site was publicly available on Github. I ran it on my local machine to study the code (particularly for its multi-lingual capabilities).
focus on shipping • freedom to create what I want without the limitations of my CMS or database • To be a hero Use only the systems you need , build what you want I work with a lot of non profits and cultural organizations. I once got an email from a client wondering what the hell she had been paying me for all these years. My bad, I had explained it to her in the beginning, but her budget didn't have much left over after accounting for software updates, monitoring, and server management and hosting. By switching to a static site, her hosting costs now average $1.25 per month, including 0 for server maintenance, and she pays me for ongoing design enhancements, which gives me the freedom to iterate more, do a better job and allow the site to respond to user needs rather than the number of users.
N T S E E D “We used the money we would have spent on wrestling with Drupal’s codebase to focus on good design and strategy work, making sure we were actually solving our clients’ problems.”
to before it’s ever deployed opens the door to building better user experiences But what people don’t talk about when talking about performance is the load on the database for complexity. In our content strategy we don’t think of pages, but aggregated bits of content that need to be put together on the front end, and used in various contexts. By taking the pain of build times before the site is ever developed we can build whatever we want without worrying about what it’s going to do to our page load times.
A simple example where a ton of content is loaded on the page. This is about 700 entries, which would very likely slog on a database driven site. (note that I have compressed HTML and lazy loading images, but you’d do that on a dynamic site as well.)
web has always been difficult, but… • I thought everyone would *LOVE* markdown files. • The didn’t. • Increasingly seeing editor-based systems Uh, oh But there has to be a catch. There is, and it’s for content creators. It’s doable, but not yet a perfect world.
of tools • Use tools that do one thing well. • Use the simplest tool for the job at hand But there’s more to this than just seeking performance and cost-savings. The budding popularity of build tools and static site generators brings us the potential for a new way of looking at the CMS. I think that the future looks a lot more like content in one place and publishing in a variety of worlds completely separate. Much more light-weight tools that are brought together to solve particular problems.
P E METALSMITH Webhook CMS DocPad ROOTS staticsitegenerators.net staticgen.com Jekyll has a great community, is actively developed and has deployment and hosting baked in. Middleman is a favorite for Ruby people and is extremely flexible. I tested Hugo with thousands of pages and my local build took a few seconds. Tarbell can publish your data straight from a Google spreadsheet (middleman can too, but that’s Tarbell’s major purpose). Jekyll can publish CSV. Metalsmith is a gulp-like static site generator and completely embodies the idea of the post-CMS paradigm because it’s 99.9% plugin based. It’s node based and you’re not going to use this one unless you’re pretty handy with javascript.
problem of publishing easy-to-edit spreadsheet data. Metasmith.io created by a startup to publish a variety of different content (books, marketing site, docs) with one tool Harp created to publish from Dropbox folders Webhook CMS Webhook created to solve the problem of editing content in a static environment Each of these has a distinct approach and tries to solve a problem.
P E S O M E E X A M P L E S Ruby: • Jekyll • Middleman PHP: • Sculpin Node: • Harp • Webhook • Metalsmith Go: • Hugo Templating Languages: Swig, Jade, Liquid, ERb, eco, and the list goes on Some people pick the tool for the language they’re comfortable with. I don’t think this is necessary. They all use one or more template-languages (some exceptions, like Hugo)
G L A N D S C A P E thenewdynamic.com Lots of stuff coming on line to edit content and deploy, and to have commerce capabilities, including what I think is where this is going: Content as an API, completely separate from where it will land.
has progressed significantly in the past two years • Likely largest user base (4,000 forks) • Avid maintainers and community • Optionally, Deployment and Hosting Baked-in with Github, and free • Liquid not the most flexible, but easy to use. • Sass built in, so no need to layer in another build tool (though I use Gulp for Sass and JS).
files: CSV, YAML, JSON • Great for one-pagers, prototypes, blogs, low-volume updates, abandon-able sites • Incremental regeneration in 3.0, along with collections, make it okay for larger, more complex sites. • Can use the Github-based editor prose.io (but it’s not the greatest). Cloud Canyon editor? • Getting running the first time can be a pain (Ruby) I’ve done a lot of work with Jekyll. It strikes a nice balance between being opinionated (and thus easy to use) and flexible.
with an Ember SPA for the control panel • Firebase JSON data store • Swig template-language • Simple API capabilities baked in (lots of possibilities here) • Easy to pre-set your working environment
Setting up on server isn’t too hard, *wink* • quite a few dependencies: • Firebase: data store • elastic search: control panel search • emed.ly: for some fields • Mailgun: send new user emails • Google APP Engine (generation) • Google Cloud Storage (hosting) I like using the open source version because I like to control everything. The devs, I think, tried to solve all the problems associated with editing content and generating and deploying a site from the web, so set up certain dependencies for their audience. I get the choices, but would love more flexibility.
1315455780, "_sort_last_updated": 1427502300, "_sort_publish_date": 1315455780, "article_related_person": [ "article -JatT2WACYTM7h7c12eK", "article -JatT2W5DyZz6CdEqU91", "article -JatT2W6gGokyXfq9xoP", "article -JatT2WrHqn-TdAasGEg", "article -JlDsZlftkoJyiFuSOhI" ], "banner_height": 600, "bio": "<p>\n\tLászló Krasznahorkai was born in Gyula, Hungary, in 1954. He worked for some years as an editor until 1984, when he became a freelance writer. He now lives in reclusiveness in the hills of Szentlászló. He has written five novels and won numerous prizes, including the 2013 Best Translated Book Award in Fiction for <a href=\"http://ndbooks.com/book/satantango \"><em>Satantango</em></a>. In 1993, he won the Best Book of the Year Award in Germany for <em><a href=\"http://ndbooks.com/book/the- melancholy-of-resistance\">The Melancholy of Resistance</a>.</em> For more about Krasznahorkai, visit his <a href=\"http:// www.krasznahorkai.hu/\">extensive website. </a></p>", "books_authors": [ "book -JatT2X9P5DzjdRkaq-W", "book -JatT2XJ1bls3Pg6AuUB", "book -JatT2Xaw4xCp37MqhzO", "book -JatT2Xkqs0zfJIEzd-E", "book -JatT2XGj4ytuQMlo5h0" ], "create_date": "2011-09-08T00:23:00-04:00", "featured": 1, "featured_image": { "resize_url": "http://lh5.ggpht.com/8QUjl-_dRIf20DMUetcPbBDe8DVHWF0rrz0dyqYs5-MVkQVKB8ajRe- TAYv_rbcRvggV21mT3vi0tiCN9giAjZVhD2uOfeIo", "size": 104159, "type": "image/jpeg", "url": "/webhook-uploads/1422671300161_c_Olivier_Roller01_cropped.jpg" }, "featured_image_position": "top", "full_name": { "first": "László", "last": "Krasznahorkai" }, "isDraft": false, This is what it looks like in raw form. Makes for very easy manipulation with Regex.
in the chain. • Often creates an implicit dependency on having a developer. • Only basic HTML/CSS/JS+ skills needed, but people still caught up on the tool. A few things to think about. It’s not a perfect world, though an increasing number of people are
platform”, by Kyle Rush • “The Static Web Returns”, by Rob Muhlestein • “How We Build CMS-Free Websites”, by Dave Cole at Development Seed • Why? “The Great Web Slowdown [INFOGRAPHIC]”, by Tammy Everts • “Welcome to the Post-CMS World”, by Ben Balter • Not the app! “Healthcare.gov: Code Developed by the People and for the People, Released Back to the People” by Alex Howard at The Atlantic
budparr
lycorp_recruit_jp
shonansurvivors
linyows
shigashiyama
stajima
rebonire626
ianozsvald
imamura_ko_0314
minorun365
oracle4engineer
ogiwarat
ohbarye
chriscoyier
skipperchong
bkeepers
garrettdimon
kneath
rocio
dougneiner
wjessup
lara
danielanewman
tenderlove
