[iandanforth]

There is a fairly important point that is missed by this article. You do not need build tools to write JavaScript and depending on which tools you use there are significant drawbacks to using any them.

Before you dive into the world of build tools and process management I urge you to write unminified, ES5 (aka the JavaScript that runs without transpilation today) until it hurts.

Write unminified JavaScript and watch your page load times.

Write ES5 and time how long it takes you to complete projects of a given size.

Write reactjs code but use the JSXTransformer. Watch page performance. Watch how many times you reload the page in a given sitting.

It's really only when you find yourself with a problem that you can quantify that these tools start to make sense.

Discover for yourself why these tools exist or you'll waste a ton of time learning the newest thing and in the end not have gained much at all.

[sirgawain33]

I highly recommend this road as well.

Three exercises along the lines of the parent that I found particularly valuable:

1. Compare VanillaJS TodoMVC to your framework of choice

http://todomvc.com/

https://github.com/tastejs/todomvc/tree/gh-pages/examples/va...

What does the framework buy you? Is the framework-powered code easier to read? Easier to understand for a newcomer to the code base?

2. Read every line of Effective Javascript (it's short and eminently practical) and write out every code example.

http://www.amazon.com/Effective-JavaScript-Specific-Software...

There are about a dozen small errors in the code in the book, see if you can find them.

3. Read substack's alternative Javascript build flow:

http://substack.net/task_automation_with_npm_run

Think about the possibilities and limitations. (I personally love his approach at the beginning of projects when I could care less about fiddling with gulp and want to get into exploring the guts of a problem)

[temo4ka]

3. b) http://blog.keithcirkel.co.uk/how-to-use-npm-as-a-build-tool...

[jowiar]

There's a definite balance between cargo-culting and reinventing the wheel. Minification is often a premature optimization. A somewhat proper/standardized module system (aka that which comes with ES6), on the other hand, is almost a necessity when it comes to building software.

Standalone JS was meant to add little bits of interactivity to documents. If what you're building is interactive documents, build tools are generally overkill. If you're building applications, the tools exist largely b/c JS-in-the-browser was not designed to build applications.

[oldboyFX]

> Discover for yourself why these tools exist or you'll waste a ton of time learning the newest thing and in the end not have gained much at all.

Exatcly. It's important to clarify these things because so many inexperienced developers get lost in the maze of js tooling for no apparent reason.

Learning how to use these tools takes time which could be spent on learning how to program properly. And in some cases JS tooling isn't necessary at all, even in more complex projects. For example if you end up working in environments such as rails where most of these things are done automatically.

I've also noticed how people seem to look down on GUI tools such as https://incident57.com/codekit/. I think it's a great solution for beginners and people who don't need complex custom tooling.

[pekk]

People get lost not for "no apparent reason" but because the maze of JS tooling is incredibly confusing, full of people telling you "do this, use that!" (without accounting for the other 40 things you want to use together with that) and full of stuff that is underdocumented and misdocumented and outright broken and changes every 6 months. Even if you learn "how to program properly" it doesn't in any way mean that you will be conversant with this confusing world.

Rather than blaming the user we should probably recognize there are quality problems that are the root cause of user confusion.

[sillygeese]

> It's really only when you find yourself with a problem that you can quantify that these tools start to make sense.

Good point. Another reason to be careful is that there are too many half-assed solutions to problems that might not even be real.

[JustSomeNobody]

I wish and hope web developers (and developers in general) read your post. Very well said.