Download to read offline
Uploaded byBen Buchanan
Sydjs: static site generators
The document discusses the merits of static websites and argues they are not outdated. Static sites can be fast, secure, and simple to deploy. They are well-suited for blogs, documentation, and small to medium sites. While dynamic content requires "oldschool scripting," several Node.js tools like Hexo and Romulus make building static sites straightforward. The document provides criteria for evaluating static site generators and an example comparing the activity levels of popular options.
More Related Content
Sydjs: static site generators
- 1. Static is nota dirty word SydJS, 2013.10.23 / Ben Buchanan / @200okpublic weblog.200ok.com.au
- 2. That's static websites. Youcan argue about types (again) later.
- 3. "Why are youmaking a static site?! That's a bit old school isn't it?"
- 4. Everything old isnew again.
- 5. Good use cases ● Small/mediumsites ● Blogs ● Version-specific or bundled documentation
- 6. Use case: UIlibrary ● Build it with its own templates ● ● ● Docs and demos Test pages Include docs in repo ● ● pull requests can include code, tests and docs Versioned docs deployed at release
- 7. Bad use cases ● Anythingelse :-P ● Things that actually should be an app.
- 8. Upsides of static ● Fast ● Lessmoving parts (in prod) ● Deploy anywhere
- 9. Downsides ● Dynamic content meansoldschool scripting ● "It just seems too simple."
- 10. "It just seemstoo simple."
- 11.
- 12. A few nodejsoptions ● Hexo* ● Romulus* ● Blacksmith, CabinJS, DocPad, Wintersmith... ● See modernstatic.com for a list * As seen in JS Weekly ;)
- 13. Goes a liddlesumthin like this ● npm install -g name ● name scaffold dirname && cd dirname ● name generate ● name server ● name deploy
- 14. Look for... ● Clear setup,dev/test and deploy phases ● Documentation ● Your preference for: ● ● Preprocessors ● ● Templates Deployment options Proof of life (beware abandonware)
- 15. Example activity check Blacksmith CabinJS Docpad Hexo Romulus Wintersmith Age 2years 5 months 2 years 1 year 1 year 2 years Version 1.1.3 0.3.1 6.53.4 2.2.1 0.1.1 2.0.7 Active 3 months 1 week 2 weeks 1 week 5 months 2 weeks PRs ~100 ~100 ~700 ~300 2 ~200 Forks 31 14 143 184 4 137 Watchers 49 10 98 86 20 61 Stars 450 115 1619 1145 156 1090 License MIT MIT MIT MIT MIT MIT (collected 2013.10.19)
- 16. Static sites havetheir place. Embrace simple.
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/