
Building static sites with Middleman - cjbell88
http://12devs.co.uk/articles/204/
======
alok-g
>> Middleman is a static site generator using all the shortcuts and tools in
modern web development. __Getting started __.

Most of the websites, including Middleman's home, for some reason jump too
fast from defining what the project is to "getting started". There needs to be
a link to more information about what the project is, tailored to people who
are unfamiliar with the space, followed by more information defining what
distinguishes the project/product from others in the same space. Once the
reader understands what the project is and how it fits what she is trying to
do, and why it is more suited to them than others, then comes the Getting
Started aspect. If the reader needs to go though the "Getting Started" section
and try the product out to figure how it would help them, then the product
pitch has not been done right or at all.

In this blog, we see a mention of Jekyll, followed by no words about why
someone should not just use Jekyll which is also stated to be the at the core
of this movement.

While the answers may be obvious to some people, they are not obvious, and
should always be explicitly stated.

The "hello, world" paradigm itself is often misused in my opinion. In a large
number of cases, "hello, world" is not a demo program but rather a test to
make sure installation went right. I would first like to see a demo of the key
aspects of the product, explained on the website, before getting to the hello
world.

Ah, it's Friday today. No seriously, the intention of my rant is to either
have someone explain to me why product websites are so often like this or try
to influence them to change.

------
CookWithMe
What is the advantage over using $your_favourite_webframework and wget -r?

I've been doing this for a while (deploying to S3) and the most annoying part
is really to upload to S3...

~~~
ratbeard
We mostly use middleman for static sites and it works really well. Recently we
built a "microsite" based off of an existing full rails app we had so we went
the wget route. My experiences are:

\- Middleman dir structure is simpler for frontend devs to learn.

\- Don't need to switch between dev and prod environments to work on the site
vs. build the final version. Switching between the two was pretty painful as
our rails app used jruby and was pretty large so it took a minute or so to
restart the server and re-compile all the assets if in prod. Plus need to
remember to `rm -rf public/assets` after switching back to dev.

\- Wget doesn't run javascript so you might not get all assets. For example,
we used a responsive image swapping technique like <img src=1px.gif data-
desktop-url='xxx' data-mobile-url='yyy'>, which wget wouldn't know how to get
those assets. So I ended up putting all such assets into a single dir and
`mv`ing it into the build dir after the wget.

\- Wget doesn't pull down assets inside IE conditional comments (json2.js,
ie.css). Perhaps it has an option to do that though.

I've used the s3_sync plugin for middleman which makes the upload part a
breeze.

~~~
CookWithMe
I see. I'm not using rails but the Play! framework / Scala, don't have the
pain of switching.

However, I get your point about javascript/conditional comments... I had a
sort of similar problem in that I had a couple of landing pages that don't
have any incoming links from the main page. I just had the framework generate
a sitemap for me and used that as a starting point for wget, but didn't upload
the sitemap itself.

Thx for the tip regarding s3_sync!

------
Brajeshwar
Used Jekyll quite a bit. These days, I'm beginning to like Yeoman -
[http://yeoman.io/](http://yeoman.io/)

------
ehm_may
Good writeup, and I appreciate the section on deploying to heroku. Have used
middleman before and had issues getting it running on Heroku.

