I like the idea behind using Node.js for webapp development. I really do. The idea of using a consistent language between both client and server, which therefore means that you are able to share code between the two without replication. Who wouldn’t like that?
The latest version of the ECMAScript Language - ES6 - introduces a lot of new features. One of the most interesting of these is the introduction of a module system that is built into the language. The way this works is, unfortunately, very different to how any of the pre-existing ES5 module systems work.
Wait, what? Most of the time when people discuss the new ES6 module system it is talked about as being one of the brand new features of ES6, and not an existing feature that has been fit into the language - such as Promises. However, there are already a number of module systems that are used and very well supported in ES5. The fact that there are different module systems, and that they aren’t trivially compatible, is a big problem. There are ways of making the three major module systems work together, but it’s not great to have to do that just to work around this fact. As such, the fact that there is a language-level module system in ES6 is a good step forwards. It’s just that the new module system isn’t a perfect solution.
I’ve just recently been working on getting my Hexo blog set up, and importantly on getting it automatically deploy to Github Pages every time I do a commit. Given that this is a generated site, there are intermediate steps involved between the source that is committed and the site that is deployed.
The obvious way to achieve the actual Build part of this is to use the fantastic Travis CI, which can be set up to perform a build every time you do a commit to a Github Repository. The challenge involved in this is getting Travis to be able to push the deployed site back to Github for it to be accessed. However, it turns out that Github have a solution that can work for this as well.
From this point on, I’m going to assume that you’ve already got Hexo configured as you want it, and you know how to configure Travis to build a Github repository correctly.
Blogs are not a new thing. However, a re-emerging trend is to use Static Site Generators that take source code stored in a source control system, compile this up into static HTML files and deploy the compiled HTML as the site. There are obvious drawbacks to this style of doing things, but at the same time there are a fair few benefits to it as well - more so for certain type of people who are used to thinking in terms of code that gets compiled into the results (i.e. us developers).
Having decided to use a Static Site Generator, there’s then the question of which one to use. There are plenty to choose from, but the three big ones are:
Octopress is actually just a fork of Jekyll. Both of these are written in Ruby, and have a relatively large number of plugins and themes to select from. Hexo, on the other hand, is written in Node.JS and whilst it has plugins and themes, the selection isn’t quite as much. However, from having played with both Hexo and Jekyll, the architecture of Hexo just feels better. The big problem I had with Jekyll was how the themes were so tightly integrated into the actual configuation. Changing themes in Jekyll is not a trivial thing to do. Because of this, I’ve chosen Hexo as my generator of choice.