Kickstart Your Project With INIT And Grunt

Advertisement

Whenever you start a project, you have to repeat certain tasks and set up certain structures: create new folders, choose a framework, set up your development tasks. But configuring settings once and reusing them would be simpler. An easy way to achieve this is by using some kind of generator — for example, Yeoman Generator — or tools such as INIT, which can perfectly coexist with and even be used through a generator.

You might already have used Yeoman Generator’s Web app. It kickstarts a project, hooking into HTML5 Boilerplate and adding things like Compass, Sass Bootstrap, a preview server with LiveReload, CoffeeScript, JSLint, Bower and more. While it’s a good starting point to automate your initial configuration of a project, you will likely need to adapt it extensively to your needs.

Keep in mind that it is intended for Web apps, so the lack of a build workflow might trouble you if you try to build a whole Web page architecture with it.

As is customary in the open-source world, you can extend Yeoman any way you like, modifying the available generators to your needs. But what exactly would you put in a custom generator? Have you thought about a good workflow and about which tools provide the most convenience?

Introducing INIT

First, allow me to introduce INIT. Based on the popular HTML5 Boilerplate project, INIT adds modern tools — such as Sass, Grunt, RequireJS and Karma (for automated testing) — and is easy to customize and extend. You no longer have to worry about those few things that you have to do manually — or that you forget to do at all.

init-opt
INIT is a set of tools that provide a sensible workflow and structure on which to base your Web projects.

You no longer have to copy a project’s default files or download dependencies that you use in most projects, such as jQuery, Modernizr and Normalize. INIT works on Mac OS X, Windows and Linux and supports all major browsers, including Internet Explorer 8 and nearly all mobile browsers.

INIT also provides a staging workflow. As you develop a page, you’ll want to refer to unminified CSS; after deployment, however, you’ll want to point to the versioned, minified CSS file; this project takes care of that. It also acts as a static file generator because it supports HTML concatenation out of the box.

For more details on INIT’s workflow philosophy and set of features, see The Nitty Gritty’s “Reducing Boilerplate Code in Front-End Projects.”

INIT has a slightly different set of helpers than Yeoman’s Web app generator, including a workflow structure that is easy to extend and customize.

While Yeoman’s Web apps conduct simple testing, via Mocha and PhantomJS, INIT uses the more capable Jasmine test suite and Karma to run tests. INIT doesn’t expect you to need CoffeeScript, Compass or LiveReload, so it doesn’t install those by default. But should you need them, you can easily add them via plugins.

INIT does require a few dependencies to be installed on your machine:

Git is also recommended as a versioning system. To set up a new instance of INIT, grab the project’s code, extract the archive, and run the following in your command line:

git init
npm install -g grunt-cli
npm install
git add .
git commit -m 'Initial commit'

This will install everything you need to run the Grunt tasks automatically. It will also create a components folder that holds all vendor dependencies managed by Bower.

Animated gif showing a shell with the install process
Installing INIT in the command line

Now that INIT is installed, we can take a closer look at what it brings to the table.

Folders, Files And Build Strategies

We can divide the file structure into four parts: configuration files, development files, tests, and the folder for the ready-to-use distribution files.

Configure Your Editor And Code Settings

INIT sets up some decent guidelines to ensure that your code is consistent. The principal settings for the code editor are configured in the .editorconfig file:


[*]
end_of_line = lf
indent_style = tab
charset = utf-8
trim_trailing_whitespace = true
insert_final_newline = true

[.htaccess]
indent_style = space
indent_size = 4

[*.json]
indent_style = space
indent_size = 2

Choose whether to use tabs or spaces for indentation, the character set, and the end of line style for the various file types. INIT has common defaults but can be easily adapted. If your editor recognizes EditorConfig files, then those configurations will be applied to your project automatically. The EditorConfig file is supported via a plugin in such apps as Sublime Text, WebStorm, Vim, Emacs, TextMate and more; a full list and links can be found on the official website.

INIT configures a few other things, too. For example, the .gitignore file contains all of the directories and files that should be excluded from Git versioning, and the .jshintrc file contains all of the rules that should be applied when JSHint tests your code.

Finally, the .htaccess file includes Apache Server Configs. If you use another server, please check the official repository maintained by H5BP. The server configuration file can reduce bandwidth by sending out Gzip’d files to the client and by setting cache headers so that files are cached in the browser. It also configures security settings to safeguard your website from common attack vectors.

Lastly, you can set up redirects for your domain, which is incredibly useful for preventing duplicate content from appearing in search engines and for when you change the website’s domain.

Configure the Automated Helper Tasks

When talking about automated tasks earlier, I mentioned Grunt. It automates tasks that you usually run manually during the development phase of a project. The following are some of the tasks built into INIT:

  • JSHint and RequireJS
  • Sass parsing
  • Modernizr custom build
  • Image optimization via ImageMin
  • Concatenation, minification and versioning of files
  • Karma unit tests

Plenty more may be added to a project; INIT just provides the most useful and frequently used tasks to save you time. The official documentation contains a demonstration of how to add LiveReload and SVG-Min as tasks. A couple of other official plugins will save you even more time.

The Build Process

To use all of these tasks and benefit from the tools, you can run a couple of predefined Grunt tasks in the command line. These Grunt commands run several subtasks that we can use to build the page or run unit tests:

  • grunt dev
    This checks your JavaScript code through JSHint, compiles the Sass files and builds your static pages.
  • grunt build
    This optimizes images, creates a custom Modernizr build and runs Karma tests, among other things. This is the task you use to generate the production files.
  • grunt travis
    This runs unit tests via Karma in your continuous integration tool (in our case, Travis CI).
  • grunt watch
    This runs the dev task every time you save a source file, so that you don’t have to constantly switch between browser, editor and command line.

Animated gif showing the development build process running grunt in the Terminal

The terminal will tell you whether something has gone wrong, like whether the JavaScript has a syntax error or Sass couldn’t find a mixin.

Automated Tests: Make Sure You’re Doing It Right

The sooner you find an error, the cheaper it will be to fix. All of us at some point have spent at least half an hour hunting down a missing comma or trying to figure out why that one CSS property doesn’t work. These manual tasks could be done much more quickly by little programs.

JSHint, for instance, complains when we screw up JavaScript syntax by checking against common rules. Jasmine enables us to write unit tests to verify code. Karma runs those tests in the browser.

These automated unit tests ensure that the code works fine. While they don’t replace manual testing by you, they do add a layer of quality assurance and save you time by reporting problems as soon as they are introduced. There are almost no limits to writing unit tests. To learn about writing advanced unit tests, read Guido Kessels’ article “Advanced Unit Testing Techniques in JavaScript”.

By default, INIT uses Jasmine as a test engine and uses Karma to run tests, which are both easier to handle than Mocha. But if you don’t like Jasmine or Karma, you can use any other tool that has a Grunt task.

Static Website Generator

A small static website generator is built into INIT by default that you can use right away.

In pages.json, you can set up the HTML files to generate. The pieces used to construct those files are usually stored in the templates directory. To tell INIT how to assemble things, you would declare a target, name its source pieces and specify a file to save the result to:

{
  "index": {
    "src": [
      "templates/header.html",
      "templates/index.html",
      "templates/footer.html"
    ],
    "dest": "temp/index.html"
  }
}

So that you don’t have to start from scratch, INIT comes with a preconfigured index.html file that you can customize.

This system enables you to work with multiple distinct files, which in the end will make up the HTML that you view in the browser. This is handy if you’re creating multiple files that all use the same header, footer and navigation. You can share content between the “static” pages without having to maintain duplicate files.

Customize!

INIT gives you a solid tool set to start projects more efficiently. It optimizes images and minifies code so that you don’t have to worry about those tasks.

But while it is a solid starting point for new projects, I encourage you to adapt it to your habits and coding workflow. If it’s missing some tools you like, add them; if you don’t need some tools that it does have, remove them. Adapt it to be your ideal framework.

I’ve used INIT for some large projects and use it now for most of my projects, configuring it to what I (and the development team) actually need, which varies from project to project. The static file generator makes it easy for me to work independently of the back-end team, while still being able to show clients my progress right in the browser.

An Outlook

We are working on a number of plugins to extend INIT’s feature set. You can find the plugins on GitHub.

INIT is not meant to replace Yeoman. In fact, you can use INIT via Yeoman. A Yeoman generator is available — generator-init — so you can simply build your own INIT instance using npm install -g yo and npm install -g generator-init.

I’d love to hear feedback, feature requests, ideas and insights on how you use INIT. Please let me know here in the comments, or file a bug in GitHub.

(al, ea, il)

↑ Back to top

Anselm Hannemann is freelance frontend webdeveloper and digital magazine creator. He helps implementing Responsive Images as a W3C standard, helped building opendevicelab.com and organizes a publishing conference.

  1. 1

    Looks promising, was looking to dig into Yeoman, I am already using Grunt.

    On windows I get a weird : node’ is not recognized as an internal or external command after node_modules/.bin/bower install

    0
    • 2

      Hi, could you log a bug on GitHub for this issue please? I guess Windows has a problem with the relative path to the bower instance. If you find a fix, I’d be happy to integrate it.

      0
  2. 6

    Awesome. More tools to automate workflows of working with the tools we need to work with other tools.

    What is web development coming to these days? Installing tools and automating workflows for things that were dead simple to begin with?

    0
    • 7

      It depends what your building, Paul.

      If it’s a very complicated web application, or perhaps a complex extranet or intranet that will require months of development by multiple developers – and constant upkeep thereafter – investing the time to automate the tedious parts of workflow is time well spent.

      If anything, you ensure all the developers are working to the same set of rules and standards at the base ‘grunt work’ level.

      It may be that your company develops a great deal of very similar web projects and every time you develop a new one, you go through the same tasks. The ‘old’ way of doing this, would be to have a big chunk of bootstrapped code, or clone an existing project, then weed out all the stuff you don’t need.

      Wouldn’t it be so much easier, if you could edit 20 lines of a text file, hit ‘Go’ and watch as your project magically bootstraps itself, running tests, ensuring you have exactly what you need to get going?

      If, on the other hand, your a casual web developer, building and maintaining just a few small brochure style websites, it may be that automating the grunt work isn’t worth the effort involved … unless you love tinkering and learning new stuff.

      Bottom line, this is the way web development is moving, you either embrace it, or get left behind.

      0
      • 8

        Matthew, there are two schools of thought. You can easily spend more time weeding out the junk than you do just constructing something from scratch.

        We have a whole generation of webdevelopers who are convinced that automated processes that generate THOUSANDS of dependency files are great because “it takes like 3 commands to stand up a project”.

        Much like you have a whole generation of people who equate jquery with javascript, the more automation tools, and ridiculous tools on tools on tools for tools by tools we have, the fewer people have any understanding of whats going under the hood.

        For example: There was a time, when people got so fed up with bloatware, they looked for a new operating system that was faster, more configurable, and more reliable. We got linux. But that quickly became “too hard”. Soon we got more and more tools to automate the process, and more and more default kernels with tons of drivers to support every single hardware variation there was, and now, fast forward, and we have Redhat, and Apt-get, ports collections, NPM, etc, etc. (Not to mention rootkits, etc)

        And people complain about developers who only know how to google for answers. Well why wouldn’t you? Very few people have questions about actual FUNCTION any more, most all of the questions out there are how to get XYZ plug in to do something.

        I cast sideways glances at the people who consider themselves “programmers” and “system administrators” nowadays.

        0
        • 9

          I guess we can discuss this over and over again and it’s likely this discussion never ends. In fact, I am not biased on that but for bigger projects I prefer the tooling workflow. That’s why INIT exists.
          If you need it, use it but if you feel like you don’t feel free to ignore this project. ;-)
          And speaking of dependencies: It’s true that there are a lot (for development, never for production) of files but don’t worry, they’re really small altogether.

          0
        • 10

          @Lucidz – I agree that it’s important to understand what you are doing before relying on tools such as INIT or Grunt.

          You are completely correct when you say there’s many developers who just rely on setting up a config file, without really knowing what the output will be.
          But you can’t blame the tool for that.

          For those of us who have honed our craft over decades, anything that has the potential to take out the grunt work, allowing us more time to concentrate on high level tasks, the better.

          There is a point where you end up becoming *too* purist – how far do you want to go back? Start coding your projects with Machine code or binary?

          There’s also so many different skill sets in modern web development which make it near impossible to be a master of all of them. You many be a Javascript hero, but your CSS sucks. You could be a OOP master, but haven’t got a clue how to build an HTML page.

          I’m not saying these tools are the answers to those solutions, however, they *do* enable other members of the team, such as UX folk, to bootstrap projects quickly for programmers – reusable init files for any project – and visa versa – programmers can bootstrap dependencies so front-end devs can run a command, get a working project and start doing what they are best at.

          0
      • 11

        “Bottom line, this is the way web development is moving, you either embrace it, or get left behind.”

        That is a pretty bold statement that doesn’t leave much room for discussion, basically rendering the rest of your post obsolete.

        It suffices to say I do not agree with the statement. Working with large projects that span multiple companies and technologies (from Ruby to .NET), we found that adding too much clutter to the process actually reduces transparency.

        I tend to move the other way, saying that these kind of tools are mostly interesting for smaller, single-company-built web apps. Or larger, but still single team or company.

        0
      • 12

        I actually agree with both statements. We live in a wonderful tool era that can automate a lot of repetitive tasks. We should use them, experiment with them, and grab the advantages where we can.

        That said, I do believe a lot of these advantages are not grabbed by many people in the community simply because it is so overwhelming. It seems every week there is a new tool, a better way to do things. By the time a tool is understood and embraced, it is outdated, as there is a better way now. It’s hard to even keep track of the names of tools and what they do exactly.

        Knowledge is an issue as well, because there is such an abundance of tools and frameworks, the knowledge is spread thin. If you’d start a new project with a new team, the odds are high that several people will not know the tools proposed, thus there is time required to invest. This is even becoming a problem in job applications.

        And finally, I am hoping for all of these tools to be better packaged and made more accessible. I’m not against the command-line per se, but again it can be dizzying to know or remember all these commands and config files. I’m secretly hoping for a GUI to manage it all. Not because I don’t understand the command line, just because most people don’t have much time to learn all of this, which is a common web developers issue.

        I don’t want to complain about having powerful, flexible tools, I’m just pointing out some real-world issues.

        0
        • 13

          I agree with what you say, Ferdy. It should be clear that using tools like Grunt and Git involves some more knowledge than just HTML, CSS and JavaScript. It means people who use it know how to use Git in teams, know how to use Grunt, how to deal with automated processes. I think the web today is not only HTML, CSS and JavaScript anymore, it is more…. You decide how far you want to go but the tools are out there and you should choose the right one for you or your team.

          And people can learn how to use these tools, it’s a matter of time. I also think teaching people how to use the tools still can save more money than don’t using the tools in bigger projects but that, of course, is only my opinion.

          0
    • 14

      I find it takes up too much of my time and interrupts my flow of thought too much if I have to do some of these things manually. If it’s a small project, whatever, but on larger projects or when there’s many similar, small projects (such as I usually work on), setting up some automation makes life so much easier. It also makes me more organized from the start, so I forget less at the end.

      0
    • 15

      I agree. I don’t use any tools developing frontend code except my editor Eclipse. What i will look into after reading this article, is unit testing (Karma and JSLint for example). But i’m not at a point yet, where i want tools to create all the stuff for me.

      0
      • 16

        Thanks for this reply. At least, the article could convince you to try a new thing (unit testing) and this means a success for me. I want to give you the opportunity to get to know new things. If you only choose to explore one new thing, that is great! :))

        0
  3. 17

    Have you tried Gulp? It is much more intuitive than Grunt — http://gulpjs.com/

    0
  4. 21

    This is certainly an interesting project and I’m pretty excited to use it. I’ve actually been researching Yeoman lately and trying to find the right generator to work into my workflow.

    Unfortunately I’m struggling to get INIT up and running. It might be that I just don’t have libsass setup on default (Which I am trying to do now) but the way the documentation is laid out I was under the impression that libsass would be part of the installation process.

    I am hopeful to get everything sorted out as it really does look promising, I just wish I could get things up and running.

    0
  5. 23

    is it possible to customize INIT to get Zurb Foundation istead H5BP?

    0
    • 24

      For sure. This should be doable as the INIT markup is not tied to a specific framework. Change your markup in the templates folder to that provided by Foundation and adapt the RequireJS configuration to Foundation’s JS files. Also the scss files can be replaced by your own structure.
      Let me know if you have a fork of INIT with Foundation included to share so we can reference in our project.

      0
  6. 27

    Who ever said “karma is more capable”? I’m pretty sure most developers will agree that mocha is just as powerful as Jasmine or karma, if not more powerful.

    0
    • 28

      Hans Christian Reinl

      February 23, 2014 4:33 am

      This is true. I think you have to understand it as it is meant for INIT project. The INIT project combined RequireJS, Jasmine and Karma to work more powerful than other tools might do by default.

      0
  7. 29

    Not everyone is comfortable with the command line. Why isn’t this stuff bundled as an installer?

    0
    • 30

      Yes, maybe a button that says “MAKE A WEBSITE!” would be nice

      0
    • 31

      It wouldn’t be done with a simple installer, the need for a whole GUI application would be necessary then. This is too much in my opinion and also limits the capabilities and extensibility of the tool a lot. But would the Yeoman generator (which kind of provides an installer in your command line) an option? Try it out, I think it might be a start to get to know the command line a bit better… :)

      0
    • 32

      The command line knowledge required for most front-end tooling is extremely minimal. I’m not familiar with Init yet but, for an example of yeoman:

      1. Go to the directory you want to install to in the command line (differs between OS’s, but extremely simple like “cd /home/kevin/myproject”.
      2. Type “npm install -g yo”. This only has to be done once per workstation.
      3. Type “yo webapp”. Done once per project.
      4. When done editing something type “grunt” to run all of your tasks, which can include testing as well as everything else.

      Of course, it can get more complex than that but not by much unless you need to do something outside the scope of grunt.

      0
      • 33

        am i the only one using Windows? And i hate this whole command line trend in frontend tools as well. I had so much trouble setting up Phonegap. It’s not easy no matter what they will tell you. Node wasn’t that easy either. Especially on Windows with all the errors you get and environment pahts you have to set up and whatnot. Just a mess.

        0
        • 34

          Once you have node and npm running it shouldn’t be that hard anymore. You’re definitely not the only one and I completely agree with you that it’s not easy to set up node and ruby on Windows but otherwise projects like this wouldn’t exist. I have no clue about App development for OS X, Linux or Windows but can create a tool that works through cross-OS command lines.

          0
  8. 35

    So everytime I changed “header.html”, I need to run “grunt dev” to assemble partials html files?

    0
    • 36

      No, you can run a grunt watch in background to get this changes automatically. `grunt watch` runs grunt dev over changed files automatically.

      0
  9. 37

    Real developers use Make !
    The rest is for wimps.

    https://gist.github.com/toolmantim/6200029

    0
  10. 38

    Sebastian Fitzner

    February 21, 2014 1:10 pm

    Nice article. Don’t know about INIT.
    But I have build my own generator on top of yeoman and use it for my daily work. It provides a few grunt modules and assemble as template engine.

    Check it out: https://www.npmjs.org/package/generator-prototype

    0
  11. 39

    What happens if I decide I need let’s say jquery UI while developing my website

    0
    • 40

      Simply add this to your bower.json file, run `bower install` and `grunt` again. Of course you also need to register this in the RequireJS config but it is no problem to extend your workflow during work—I do this all the time.

      0
      • 41

        you don’t need to edit the bower.json file manually

        do a “bower search jqueryui”

        that’s your list of available packages. I see

        “jqueryui git://github.com/components/jqueryui.git”

        so then type

        “bower install jqueryui –save-dev”

        the –save-dev will add it to your bower.json file for you.

        similarly

        “bower uninstall jqueryui –save-dev”

        will remove it

        0
      • 42

        downloading and including it in my index seems a lot easier…

        0
        • 43

          Hi Sumit, this might seem true but it also would break your performance goal, would re-introduce a manual step which will come back to you when you need to update it and limits your possibilities in general (like concatenating it with other files, compressing it automatically, etc.).

          0
  12. 44

    Surely I’m missing the point, but what’s the advantage to run INIT if you have to install Grunt and it alteady has a lot of plugs to do the sames things?? I repeat, maybe I missed the point but for me it looks to be a more complex way instead to improve the tools that exists.

    0
    • 45

      Anselm Hannemann

      March 3, 2014 10:56 pm

      It does differ in the features, functionality and workflow from other tools. While there might be some tools that offer *exactly the same*, they probably do this in an other way or in another surrounding. As said a couple of times, I just want to encourage you to use the tools, not necessarily INIT. If INIT fits to your purpose, use it, if you find something that fits better to how you work, use this. But tools like Grunt, Bower, and others can improve your workflow massively.
      Installing Grunt, etc is btw super easy and some tool will be required by all the tools you find out there. It might be in a app cascade but tools need tools to run in this case.

      0
  13. 46

    Hi I am Jagadish,

    I am new this INIT front end frame work.

    I am trying to install the INIT in my windows8 machine but i am unable to do that.

    It would be helpful, provide the step by step procedure to install the INIT in my machine.

    0

Leave a Comment

Yay! You've decided to leave a comment. That's fantastic! Please keep in mind that comments are moderated and rel="nofollow" is in use. So, please do not use a spammy keyword or a domain as your name, or else it will be deleted. Let's have a personal and meaningful conversation instead. Thanks for dropping by!

↑ Back to top