Menu Search
Jump to the content X X
Smashing Conf Barcelona

You know, we use ad-blockers as well. We gotta keep those servers running though. Did you know that we publish useful books and run friendly conferences — crafted for pros like yourself? E.g. our upcoming SmashingConf Barcelona, dedicated to smart front-end techniques and design patterns.

Kickstart Your Project With INIT And Grunt

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 app1. It kickstarts a project, hooking into HTML5 Boilerplate2 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.

Further Reading on SmashingMag:

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 Link

First, allow me to introduce INIT7. 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 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 plugins9.

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

Git is also recommended13 as a versioning system. To set up a new instance of INIT, grab the project’s code14, 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 Bower1511.

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 Link

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 Link

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

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

indent_style = space
indent_size = 4

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 website17.

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 Configs18. If you use another server, please check the official repository maintained by H5BP19. 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 Link

When talking about automated tasks earlier, I mentioned Grunt20. 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-Min21 as tasks. A couple of other official plugins22 will save you even more time.

The Build Process Link

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 CI23).
  • 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 Link

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. Karma24 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 JavaScript25”.

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 tool26 that has a Grunt task.

Static Website Generator Link

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": [
    "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! Link

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 Link

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

INIT is not meant to replace Yeoman. In fact, you can use INIT via Yeoman. A Yeoman generator28 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 GitHub29.

(al, ea, il)

Footnotes Link

  1. 1
  2. 2
  3. 3
  4. 4
  5. 5
  6. 6
  7. 7
  8. 8
  9. 9
  10. 10
  11. 11
  12. 12
  13. 13
  14. 14
  15. 15
  16. 16
  17. 17
  18. 18
  19. 19
  20. 20
  21. 21
  22. 22
  23. 23
  24. 24
  25. 25
  26. 26
  27. 27
  28. 28
  29. 29

↑ Back to top Tweet itShare on Facebook

is a freelance front-end developer who cares about sustainable front-end experiences and ethical choices in life. He writes the WDRL, and is co-founder of the event platform Colloq.

  1. 1

    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?

    • 2

      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.

      • 3

        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.

        • 4

          Anselm Hannemann

          February 20, 2014 9:40 am

          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.

        • 5

          @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.

      • 6

        “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.

      • 7

        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.

        • 8

          Anselm Hannemann

          February 27, 2014 12:01 pm

          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.

    • 9

      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.

    • 10

      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.

      • 11

        Anselm Hannemann

        February 27, 2014 12:03 pm

        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! :))

  2. 12

    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

    • 13

      Anselm Hannemann

      February 20, 2014 9:30 am

      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.

      • 14

        would an error.log help

        • 15

          Anselm Hannemann

          February 21, 2014 6:26 am

          Yes :)

          • 16

            Michael Warren

            February 28, 2014 1:30 pm

            I’d love an ELI5 for this article. I would love to get into this kind of thing, but I think this is just a bit too advanced for someone like me that is just starting to get used to terminal, git, and command line installs.

            Where would you recommend starting?

  3. 17

    Have you tried Gulp? It is much more intuitive than Grunt —

  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.

  5. 23

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

    • 24

      Anselm Hannemann

      February 20, 2014 9:36 am

      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.

      • 25

        Could be my next weekend project!

      • 26

        I am already working on this since I need this at work (Foundation init, I will most likely have to do it for Laravel, WordPress and CodeIgniter as well(=)

  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.

    • 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.

  7. 29

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

    • 30

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

    • 31

      Anselm Hannemann

      February 20, 2014 11:04 am

      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… :)

    • 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.

      • 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.

        • 34

          Anselm Hannemann

          February 27, 2014 12:05 pm

          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.

  8. 35

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

    • 36

      Anselm Hannemann

      February 21, 2014 6:28 am

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

  9. 37

    Real developers use Make !
    The rest is for wimps.

  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:

  11. 39

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

    • 40

      Anselm Hannemann

      February 25, 2014 5:41 am

      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.

      • 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://”

        so then type

        “bower install jqueryui –save-dev”

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


        “bower uninstall jqueryui –save-dev”

        will remove it

      • 42

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

        • 43

          Anselm Hannemann

          February 27, 2014 12:07 pm

          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.).

  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.

    • 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.

  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.

  14. 47

    I have just tested it with generator-init. Init generated 15.310 Objects (133,1 MB) on my disk, with default installation and settings. For just a single project. Can this be normal?

  15. 48

    Not specific to this tool/article but I feel sorry for modern webdevs who have to try to keep up with all these “solutions” (or have to pretend to anyway). A billion ways to do everything with a billion opinions on which is best, no chance to ever master anything – fragmentation rules. Looks like a recipe for burn out from what used to be a fun and creative job.


↑ Back to top