Building static sites with Middleman
12devs.co.uk
12devs.co.uk
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.
I've been doing this for a while (deploying to S3) and the most annoying part is really to upload to S3...
- 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.
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!