Sydjs: static site generators

1,721 views

Published on

Not everything needs to be deployed as an app. Sometimes a static site generator is the right option.

Full transcript/blog post:
http://weblog.200ok.com.au/2013/11/static-is-not-dirty-word.html

Photo sources:
http://www.flickr.com/photos/nuitei/73859782/
http://www.flickr.com/photos/squirmelia/7094409713/

Short talk given at Sydjs, as part of an evening based on topics linked in Axel Rauschmayer's JS Weekly.

Published in: Technology, Business
1 Comment
1 Like
Statistics
Notes
  • See notes for photo credit.

    Full transcript/blog post:
    http://weblog.200ok.com.au/2013/11/static-is-not-dirty-word.html
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
No Downloads
Views
Total views
1,721
On SlideShare
0
From Embeds
0
Number of Embeds
382
Actions
Shares
0
Downloads
3
Comments
1
Likes
1
Embeds 0
No embeds

No notes for slide
  • http://www.flickr.com/photos/nuitei/73859782/
  • 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.
  • 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.
  • 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.
  • 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
  • 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.
  • ...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.
  • 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
  • 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.
  • 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.
  • 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/
  • Sydjs: static site generators

    1. 1. Static is not a dirty word SydJS, 2013.10.23 / Ben Buchanan / @200okpublic weblog.200ok.com.au
    2. 2. That's static websites. You can argue about types (again) later.
    3. 3. "Why are you making a static site?! That's a bit old school isn't it?"
    4. 4. Everything old is new again.
    5. 5. Good use cases ● Small/medium sites ● Blogs ● Version-specific or bundled documentation
    6. 6. Use case: UI library ● 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. 7. Bad use cases ● Anything else :-P ● Things that actually should be an app.
    8. 8. Upsides of static ● Fast ● Less moving parts (in prod) ● Deploy anywhere
    9. 9. Downsides ● Dynamic content means oldschool scripting ● "It just seems too simple."
    10. 10. "It just seems too simple."
    11. 11. ...and anyway, "simple":
    12. 12. A few nodejs options ● Hexo* ● Romulus* ● Blacksmith, CabinJS, DocPad, Wintersmith... ● See modernstatic.com for a list * As seen in JS Weekly ;)
    13. 13. Goes a liddle sumthin like this ● npm install -g name ● name scaffold dirname && cd dirname ● name generate ● name server ● name deploy
    14. 14. Look for... ● Clear setup, dev/test and deploy phases ● Documentation ● Your preference for: ● ● Preprocessors ● ● Templates Deployment options Proof of life (beware abandonware)
    15. 15. Example activity check Blacksmith CabinJS Docpad Hexo Romulus Wintersmith Age 2 years 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. 16. Static sites have their place. Embrace simple.

    ×