Bedrock is one year old! We started this project about a year ago, and we’ve been updating and refining Bedrock since.
We use Bedrock for most of our projects at Mono. HTML prototyping is a staple of our workflow; and it’s something we’ve talked about extensively in the past.
We’re at the point where Bedrock’s features have stabilized, and have been in actual use in many projects.
After some recent development work I concluded that Bedrock is feature complete. I’m ready to call this stable and thus a 1.0 is in order. You can download Bedrock 1.0 on Github.
What’s next for Bedrock? Well, at Mono we often use Bootstrap for our projects. We’ve customized Bootstrap 3 with a lot of extra components which we think are worth sharing.
I plan to make a new demo that shows the power of Bedrock combined with Bootstrap. While developing the demo I am going to record my screen and turn it into a session that anyone can watch, to see the process.
Next to this, I want to revise the documentation to make it easier for newcomers to get started. Bedrock is a relatively simple tool to use, but you have to know some details to use it effectively.
P.S. A huge shoutout to Thomas for his coding efforts. If you need a fine React developer, hire him!
In Bedrock, we automatically generate the colors based on the contents of an SCSS file. The visual reference exists to make people aware of colors used in a project to avoid the “50 shades of grey” problem.
It used to be that I thought a website had to be powered by a CMS… there was just no way around it.
Then I discovered the magic of static site generators.
What is a static site generator? Well, basically it is a bunch of code that compiles to a website. But, unlike a CMS powered website, there is no server side language going on. The site is comprised of a bunch of files that you specified.
The first static site generator I fell in love with was Jekyll. It took me a while to understand. I am a user interface designer and not an actual programmer. When you try to work with tools like Jekyll for the first time and your world is mostly HTML, CSS, Sketch and Photoshop, there is a lot to learn.
Eventually I thought I had a good grasp of Jekyll and organized a small meetup called Jekyll Camp. This led to the presentation “An introduction to Jekyll”:
Up to this day is my most viewed video on YouTube, leading me to believe there are plenty of people out there wondering how they should use Jekyll.
But I had a problem with Jekyll: it became too slow. I was not using it to make a small blog or personal site (like most Jekyll website). I was using it to craft the templates for web applications.
Every time you save an HTML file, a static site generator tends to regenerate THE WHOLE SITE. This system works up until the point that your site gets too big and you have to wait too long for your site to recompile.
A co-worker at the time suggested we move to Wintersmith, which used Jade as a templating language (see the previous post). We ported the project I was working at the time to Wintersmith. It was slightly faster but eventually I hit a wall again: render times would take too long again.
At that point, the co-worker in question, Ruben, helped me out own and built his own static site generator that would be faster. He built renderpipe, I started using that, and things were fast again.
Things were fine until my prototype was gigantic enough to hit the same wall of slowness. Again.
After hitting that same “compile” problem in 3 separate environments I was convinced that static site generation was good, but eventually if you are building anything at scale you kind of need a server that gets assets on the fly.
I was prepared to move to some PHP based system using a templating language like Twig; but luckily colleague Thomas found a solution to the problem.
In Bedrock, our static site generator, we use Express to serve our Jade templates on the fly. This makes it much faster in usage when you are coding.
When you use the default gulp command, Express is used to render templates on the fly. When you are ready to make a final build, you can use the gulp build command, and then you have your regular “static site build”.
I worked on a prototype that was so big recently that it took 60 seconds to fully compile. If I would have to wait 60 seconds every time I changed the code, that would be a huge productivity problem. That reminded me of this wonderful comic:
One of the “blocking” factors in learning to use Bedrock is that you have to know how to work with Jade.
Jade is a powerful templating language built on top of node.js.
The first time I encountered Jade I thought it was unnecessary to abstract HTML into something else. But after a few months on a project using Jade, going back to HTML felt tiring. You really have to type double as much code when you are writing HTML.
The main advantage of Jade is that you can’t forget to close HTML tags: the way that Jade works just doesn’t allow for that to happen. This reduces code mistakes significantly.
What I mostly love about Jade is blocks and extending templates. This system is explained here. I make use of this extensively to make sure I never have to write duplicate code in a project.
This home page contains some information about what Bedrock is, along with some screencasts that I made yesterday and a link to a demo application. We are developing Bedrock in the open from now, so you might see some mistakes here and there.