what I call the "Post-CMS" paradigm. The site, like the Meetup, is called "The New Dynamic," and is meant to be a resource for developers and designers to incorporate static sites into their tool-set.
media, and human rights organizations. • The common thread: they are typically strapped for resources. • So why spend money on servers and maintenance, monitoring and software updates? I do client work, primarily for cultural media, and human rights organizations. The common thread between my clients, other than a sense of purpose, is that they are typically strapped for resources, a fact which informs my technology choices.
60+ Wordpress sites • 5 Flat-file, no-db sites (Statamic) • 30+ static sites Bud Parr - front-end dev and design for 13 years I started working with static site generators in 2013. I had been increasingly frustrated by the time that I had to devote to setting up, maintaining, and monitoring servers and updating software. This translated to expenses my clients had to pay, which they often found frustrating when their ongoing budget was eaten up by maintenance.
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 At about the time of my peak frustration, I ran across Kyle Rush's article where he outlined their move from ExpressionEngine to a static site for the the Obama campaign website, and then
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 Dave Cole's "seminal" "How We Build CMS-Free Websites" discussing his firm's experience building the website for healthcare.gov. His firm, by the way, had previously been a prominent Drupal shop. And this article brought about the idea to me of the "Post-CMS" paradigm.
of tools • Use tools that do one thing well. • Use the simplest tool for the job at hand The "Post-CMS" paradigm, which I think Ben Balter at Github coined, is about breaking up the monolithic, take-it-or-leave-it CMS systems, and using only what you need to get the job done, applying to the CMS world something like the modularized build tools we're all used to using today.
+ can serve entire site from cloud storage/CDN • Scalability with minimal cost. • Security • Flexibility in development, easy to setup, change, test. • “Complexity without Guilt” My aim today is not so much to dwell on why you would use a static site generator, but how to use them in production environments. The benefits are likely clear to most in the room. As developers we want performance gains without the need for heavy layers of caching and we want to build and test quickly.
the same theme in static and Drupal with a very basic setup, and the differences are dramatic. That's a bit unfair, of course, because we know that dynamic sites can be made to go fast, but at what cost? What sort of infrastructure does that take and why would we want to if we don't have to.
going down, and they really love the savings: They spend their money for site enhancements instead of maintenance, and their hosting bill maxes out at a few dollars or so per month, in most cases.
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." Dave Cole said of the healthcare.gov site, that before they decided upon static they were expecting to use 32 servers to handle the load. That number went to two with static, and one of those was just for backups.
(author, translator) • Related Events • Related Articles • Related Books • Related editors, add’l authors, translators. Designers should love static too: I call this "Complexity without Guilt" - meaning that I can put together a content strategy using atomic bits of data, marrying them on the front-end with whatever complexity I need to create a great user experience, without worrying about how that's going to effect my page load time.
Also, I don't have to paginate every damn thing. 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.)
ago, and paying close attention to what people say on twitter, etc; the opinion I see most is that static sites are for simple brochureware or documentation. Those are great and obvious use-cases, and a few years ago that would have been it, but what we've seen is the rise of a lot of tools and services that have broadened the landscape dramatically.
G L A N D S C A P E thenewdynamic.com There's a rising tide of editing interfaces that make it easy for non-technical users to update sites, opening the world of static to client work and more complex sites. For instance. When I started building static websites one of my concerns was the integrity of data references between each other. When everything is text, it's quite easy for a user to input THEATER, "ER", as a reference, for instance, and another to use THEATRE, "RE". But this issue is virtually eliminated when that reference is confined to a drop-down field. The Cloudcannon editor, which I'll come back to can create drop-down references between collections of content.
Netlify CloudCannon Aerobatic Surge Amazon S3/Cloudfront Google Cloud Storage static hosting options https://github.com/smartergiving/free-nonprofit-starter-website Fork and go… So here's a simple scenario. In the past, every bit of functionality and environment was dictated by the CMS I chose, and good luck changing CMSs. Now, I pick and choose only the functionality I want and, increasingly from a variety of tools. This is the static web at its most basic. Conceivably, you could fork a repo and be up and running in about 30 seconds.
less Simple, but not really so Bad Markdown Files CSV or YAML Google Spreadsheets (?) Other editors Netlify CMS Siteleaf prose.io Github Repo Travis CI for testing (e.g. HTML-Proofer) and Deployment Google Cloud Storage Cloudflare for DNS + (.htaccess, like) rules Website Everything Here Can Be Replaced Gulp (assets) A somewhat less simple scenario introduces a web-based editor into the mix. There are quite a few, though many only have the most basic functionality at this point. Right now I'm using Cloudcannon, a commercial product that is very well conceived and impressively solid. The rest of this looks, I suppose, more like an app than a typical website. I'm using Surge to push out staging versions of a site with a quick command. I use very specific versioned domain names with my clients and destroy them when we're done. I'm using Travis to run HTML proofer on my built site, to keep me honest, and push the built site out to Google Cloud Storage to serve the sites. Travis has great documentation, and I had no problems setting this up.
the editor, you'll see that they have editable regions where a user can update content right on the site. I haven't used this yet, but it seems compelling. Cloudcannon, by the way, charges by the user, but client access to their sites (one user) is included. So as long as you don't need to authenticate each client user, they're part of the plan.
matter. Front matter in a static site is super important because it often includes the bits that bind content together and metadata for a page or item.
additional content. • Can include data that binds one piece to another. • Think of a markdown document as a piece of content rather than a page. A markdown "page" is the basic data item, and is a bit limiting itself, particularly if you don't think of your content just as a bunch of pages. I tend to think of a "document" representing a discrete item instead. I've found that end users actually adapt pretty well to markdown and front matter—I've tested this in the real-world—, but it does create opportunities for error, so the editor is definitely the way to go. I've been putting Cloudcannon's editor through the paces and have yet to break it (and I'm good at breaking stuff) and have gotten positive feedback from clients. Importantly, it has pretty good error handling. That's always a gap in any most systems I've seen.
You can also use other data types. You’re not limited to documents in many static site generators. Tarbell is a static site generator created by the Chicago Tribune specifically to use Google Spreadsheets as a data store. I believe that Middleman, Hugo, and Jekyll, among others, are capable of taking in varying data types.
but solid image upload functionality. That's another piece, getting images on to the site, that tends to be a hurdle with static site generators when users aren't working locally.
deploy, etc. Siteleaf Editor Jekyll (coming soon) Markdown Website Siteleaf Platform Netlify Editor Hugo, etc. Website Netlify Hosting Markdown Prose.io Editor Jekyll Website Github Pages Markdown Client Friendly Free So, there are lots of other ways to accomplish the same functionality. These are, to some degree, commercially dominated at some point in the chain, though Netlify has open sourced its editor.
"free zone", you can use the open source prose.io and publish for free to Github Pages. I think this scenario works best for users with some technical knowledge, as there's no real error handling and there are some bugs.
is fairly new and still has a bit to go, but seems promising to me, particularly since it's open source, and Netlify is very committed to the static space. It uses Github authentication, which is great, but could be limiting. Right now, I believe you need to use it through Netlify, which is a very fast and easy-to-use static host, but I don't think that will always be the case. **The important thing to me, is not that I'm using a commercial editor or platform, it's that I'm not tied to using any one of them.**
It's been around for a while, but it's Jekyll-like system has always been closed. I understand they're moving to an open source system, based directly on Jekyll, where the editor is tied to its platform. The Siteleaf editor is very page-oriented and “feels” like it’s meant for really small sites. I have no idea what the new version will look like as I'm not in the beta.
Content APIs that are Saas-based where you roll-your-own front- end. The editor is very accomplished, particularly its media manager and editing suite, which integrates with Adobe Cloud. There are several static site generators that integrate with Contenful. It's a commercial product with a free level, though I'd imagine the typical user is not going to be a free user. The advantage here is that you can also use the content in your mobile app, etc. I think we're going to see more of these in the future. There are three that I currently know, Contenful, Prismic and Osmek. I've not used them, because it does seem to me there is a certain amount of vendor-lock-in with them, but I do think it's interesting and where things are headed.
use combined with Cloudfront CDN. Google Cloud Storage • Easy to use, CDN included, essentially. • Have to declare ownership of domains; a pain,at first. • No Apex domains, use wwwizer.com/ naked-domain-redirect, or Cloudflare. Netlify • Great performance, easy to use. • Integrated editor, on the horizon • Automated builds, feature rich • Can use with any SSG Cloudcannon • Easy to use. • Integrated editor • Jekyll or HTML only. • No Jekyll plugins, yet, but can easily host elsewhere. Deployment is pretty easy and integrated with some hosts Deployment is pretty easy. Depending on your budget and how much trouble you want to go through, there are plenty of options for any scenario. You can spin up a server at Digital Ocean and dump your files via FTP or Rsync in a matter of minutes. There are deployment scripts and tools for Amazon S3, and as I mentioned I use the free level of Travis to deploy to Google Cloud Storage. With Google Cloud Storage, as with Netlify you can also drag and drop your files to create a site, and as I also mentioned Surge, is similarly easy to use.
• Super easy if you’re using Jekyll… • but, Can’t use Jekyll Plugins (unless pushing build folder to a submodule) • Jekyll version used sometimes behind the current, particularly for major releases. • Can use with other static site generators, but not as cleanly. • No SSL (though Cloudflare has a lite solution) Github pages is a bit of a special case because it's integrated with Github, and it's free. The performance is great, and if you're using Jekyll, it's practically a no-brainer. I use it a lot with simple sites. However, if want to use plugins or use another static site generator, you have to do a bit more work.
included with some hosts, like Netlify Calendars Roll your own with Jquery/Underscore (I made a Jekyll plugin) So the last piece of the puzzle, is front-end interaction. These tools are multiplying and really part of making static a viable alternative. I particularly think that the performance benefits of static are a great marriage with the needs of commerce. I haven't used Moltin, but Snipcart is dead-simple, and they have a lot of static-site oriented tutorials on their website. Forms and comments are pretty standard. Search solutions vary. I've had success using list.js, which is a script for filtering content, along with Tipue. Swiftype is a commercial product and get expensive quickly. It's licensing at the free level is for
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 www.thenewdynamic.org @thenewdynamic I should note that I don't have any financial or other interest in the commercial tools I mention here, and I don't try to be comprehensive; I just pay close attention to the universe and try to highlight the most interesting solutions. I intend to take some time in December and write more about the things I brought up today. They'll be posted on thenewdynamic.org So, now we'll have a look at how the U.S. GSA is incorporating static into their workflow and for U.S. Agency sites.
budparr
oracle4engineer
niwatakeru
minorun365
lycorp_recruit_jp
trishagee
smt7174
tsumita
yoshidashingo
tacck
tubone24
nikkei_engineer_recruiting
panda_program
sonatard
paulrobertlloyd
nonsquared
davidbonilla
akosma
lynnandtonic
honnibal
philhawksworth
jlugia
andyhume
quramy
