Sydjs: static site generators

Editor's Notes

• #2: http://www.flickr.com/photos/nuitei/73859782/
• #4: It was this reaction from a coworker that inspired my talk tonight. In every web job I've had, at some point deploying a static site was the right option. That was in fact my entire first job. And yet! People react as though it's crazy to be considering it. That it's somehow too old a technique to be used now.
• #5: There are reasons for old patterns to come around again. It has become so easy to build a client side application, it's easy to build something needlessly complex. But if something can be deployed static, why not? "generate dynamic, deploy static" has been a strategy for a very long time. If you look around, you'll find plenty of people deploying static sites, because it makes huge sense.
• #6: Good use cases for a static deployment are primarily about the content. If it doesn't update; if it's about content rather than actions and manipulation, it's probably going to be a good static site. This is also for that client website you want to build with node but when they want their nephew to take over, you don't have to teach their nephew node. This is for documentation that needs to be generated along with other compile-time resources for future reference. Library docs. When you don't want to be running a server for every frickin patch release you've ever done.
• #9: It's not hard to understand why. Fast / performant – the download is it. Done. No runtime dependencies: you don't have to worry about services coming back up after downtime you don't need to mirror your dev environment on the server Deploy anywhere – zip files with your library, deploy to cheap hosting options Some options even deploy via FTP so you dont have to futz about with SSH keys Usually passes the Plane Test
• #11: People often feel static sites are somehow too easy, or they're getting away with something. It's like building a browser extension and feeling bad for not having to suffer at the hands of IE8 – understandable, but time to break free. Fundamentally we need to be comfortable with simple. We should strip things back if we can, remove risks if we can. Keep complexity in the dev's realm. All those little tweaks you can do at compile time have to be totally automated on the server, lest you want to attract the rage fo devops - they're on call. Users don't care regardless.
• #12: ...and anyway, we seem to need quite a lot of dependencies to do simple things these days... (that's the last screen of output of a yeoman "basic" static site scaffold generator) We should be meditating on the concept of simplicity.
• #13: The cool thing is we can use the same dev tools, languages etc that we use in app projects. Nodejs, the relatively new kid on the block, has lots of static site generators! Common stack across projects Faster onboarding Less siloing Good for maintenance Match to your own team's skills If that leads away from node, that's cool
• #14: I'm going to assume you know what an npm install looks like while it downloads the internet. So rather than doing that, I thought I'd run through the key things you should be looking for when you are choosing a tool.
• #16: The only projects with real question marks here are Blacksmith and Romulus. CabinJS is pretty active but is quite new. Hexo and Docpad have the greatest evidence of activity. Activity doesn't equal quality or features, of course. But it's a litmus test.
• #17: My message really is don't feel like static deployments are too simple, or don't make good use of the modern toolset. You can use a great dev stack and still deploy static. Embrace simple. http://www.flickr.com/photos/squirmelia/7094409713/