
The Hitchhiker's Guide to Modern JavaScript Tooling - voter101
http://reactkungfu.com/2015/07/the-hitchhikers-guide-to-modern-javascript-tooling/
======
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/](http://todomvc.com/)

[https://github.com/tastejs/todomvc/tree/gh-
pages/examples/va...](https://github.com/tastejs/todomvc/tree/gh-
pages/examples/vanillajs)

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...](http://www.amazon.com/Effective-JavaScript-Specific-Software-
Development/dp/0321812182/)

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](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...](http://blog.keithcirkel.co.uk/how-to-use-npm-as-a-build-tool/)

------
joesmo
"The biggest weakness of such small tools approach is that it is hard to learn
what to use and how to configure it."

No. By far the biggest weakness of such a small tools approach is a
Balkanization of development tools that generally refuse to work with one
another and often don't work very well by themselves. One library I really
wanted to try was using Browserify but I wanted to use brunch/bower because my
workflow was already in brunch. Even with the brunch-browserify plugin this
wasn't possible. After wasting two days on it, I gave up and just used
Browserify by itself. Another couple of hours it was actually working. This is
typical. On another app, I use gulp. Another piece of garbage that claims that
when you run a command 'gulp watch' it will automatically rebuild your assets.
It won't.

These are only three small projects, each using a different build tool:
browserify, gulp, and brunch + bower. None of them are compatible with each
other and it's unlikely they will ever work together in one project without
hours or days of trial and error. If there was one monolithic (or not)
dependency / build tool that actually worked, I'd much rather use that, __and
it would be a much better approach than having a whole bunch of small crappy
tools that don 't work together. __

tl;dr: Not only is having multiple tools doing the same thing in this area not
appealing, it just leads to developers wasting massive amounts of time and
"what the fucks?" working with half a dozen tools that do the same thing and
do it poorly.

~~~
SonicSoul
yes there is this overhead, but it also reduces dependency on any specific
framework, avoids using big one-size-fits-all monoliths, let's you choose the
best tool for the job, makes your team a lot more well rounded by
understanding pros and cons of each of those libraries.

~~~
edwinnathaniel
What if they _are not_ the best tool for the job largely because these tools
just _get started_ (e.g.: v 0.1/0.2) and less mature?

Let's compare it with the evolution of Maven. Yes, I heard hatred and
grumbling whenever Maven is mentioned but darn, that's a solid software. Old
Maven, version 1 was OK, version 2 was solid, version 3 (or 4?) is when they
address polishing issues and perhaps making a leap joining the new kids on the
block (Gradle) by listening to the community and figure out a roadmap (I heard
something about programmatically do stuff with Groovy... in Maven).

Sometimes one need to let the tools maturing and evolving before dropping
judgement and roll yet-another-too-simple-tool and call it solving problems
that the other tools did not do well (and for ego, of course, name a developer
that has none..)

------
hex13
We talk about "modern JavaScript tooling" but year after year, the list
essentially stays the same.

Maybe few new players have appeared (Gulp, WebPack, Babeljs) but they do
exactly the same thing that the tools we had before (e.g. Grunt, Browserify,
Traceur).

It occurs to me that "modern JavaScript tooling" is growing only vertically
(better tools to build, better tools to modularize, better tools to
transpilation), but not horizontally. If we see some "brave new tool" on the
scene, this tool will do exactly what previous tools did, only better.

I would like to have some decent tools for:

* analysing of project structure (e.g. dependencies between modules, graphs, trees etc.)

* code visualising (not toy! Gource is beautiful, but pretty useless. JSCity... I also don't see much use of it. I would see something that would allow me to draw some useful information from code visualisation. Something that would allow to understand better. But I see only beautiful animations and abstract 3D scenes)

* maintaining code (something that would allow me to conduct massive scale refactoring, or automatically convert code from one framework to another etc.)

* better editors for HTML/CSS, maybe even some decent WYSIWYG

Okay. Plain build systems and transpilers also are super useful. I think that
Gulp, Babel.js, Browserify etc. are greeeat. But I think we need more.
Something different. There is still room for innovation. Projects grow bigger
and I think that we need something that helps us

* to understand easily new codebase

* to navigate codebase, conduct semantic search etc.

* to maintaining, refactoring etc.

I feel that some important tools are missing, not created yet.

~~~
the8472
> * better editors for HTML/CSS, maybe even some decent WYSIWYG

Editors? How about an IDE.

In the java environment I can manage an application container, profiler,
debugger, compiler, packager, test suite all from one application.

Also included: near-omniscient auto-complete, hot-code replace, incremental
building, dependency fetching, visual version control, automatic refactoring,
deployment and many other conveniences I'm taking for granted. Hell, I could
even file tickets from my IDE if I wanted to.

~~~
joesmo
WebStorm
([https://www.jetbrains.com/webstorm/](https://www.jetbrains.com/webstorm/)).
Or if you use other languages as well, check out any of Jetbrains' IDEs:
[https://www.jetbrains.com/](https://www.jetbrains.com/)

I haven't found a better IDE for any language yet.

~~~
hex13
I think that WebStorm is decent _JavaScript_ IDE but if we 're talking about
editing HTML/CSS/Sass, WebStorm is not any better than plethora of other text
editors.

IMO basic problem lies in fact that we're still trying to edit hierarchical
tree structures of HTML and CSS/SCSS as a plain text instead of editing
underlying tree structure.

I think that good HTML/CSS editor should operate on tree and every CSS rule
and every property should be object rather than plain text. That would allow
to more natural editing and faster code modification/refactoring (I am
frontend developer but I hate writing CSS/HTML by hand. It feels like using
punch cards... Better editor could allow to do things faster and more
effective).

I was looking for structural (and projectional) editor for HTML/CSS and didn't
find any. So I started making my own (here is prototype:
[https://www.youtube.com/watch?v=yRwx09bAT08](https://www.youtube.com/watch?v=yRwx09bAT08)
)

~~~
Zombieball
I agree with edwinnathaniel, IntelliJ with its browser JavaScript debugging
plugins is pretty awesome and I find it a fantastic JavaScript IDE.

I am curious what use cases you have for editing in the fashion of your demo
video? I don't find myself frequently wanting to view just fonts in a css
file. I either have specific rules I want to edit, or I pull up reused fonts
and colours into re-used classes (or less variables) and just edit that one
spot.

Why would you want to view just colours? Or just fonts? BTW, I am not trying
to put down your idea, infact I think it's very interesting concept to work
more closely with the tree structures.

Edit: as I think about the idea, it would be awesome if I could click on any
html element in a file and it would be able to statically analyze and show all
applicable css selectors. Although I frequently use angular and dynamically
applied css classes.

~~~
hex13
> or I pull up reused fonts and colours into re-used classes (or less >
> variables) and just edit that one spot.

good editor could pull up reused fonts and colours automatically (detecting if
they the same in various nodes).

> I either have specific rules I want to edit

Yes, I'm also making possibility of filtering by specific rules and finding by
CSS selector (in HTML also)

And different filters are just a part of the editor. Actually, my first idea
was creating something that would allow to make quick changes that are super
easy when operating on tree, but you must do them by hand in text editors
(e.g. operations like "move to parent", "wrap this HTML element in new `div`
element etc.).

I also want editor to be operable without keyboard/mouse switching. And
because when I make websites I often use mouse to test in browser all
functions, I want good mouse support and be able to change e.g. top from 0px
to 10px using only mouse. This is possible in e.g. DevTools, why not to put
this feature in editor?

> Edit: as I think about the idea, it would be awesome if I could click on

> any html element in a file and it would be able to statically analyze and

> show all applicable css selectors.

Yes. It would be nice, although I didn't solve this from technical perspective
yet.

But for now I think about something like in Brackets - you edit HTML and could
edit styles in place without switching to the other file.

~~~
Zombieball
These are some great ideas. There are little features in DevTools that I wish
my IDE had (or I am not aware of the features if they do).

Be sure to post anything awesome you create to HN!

~~~
hex13
I'll do :) As soon as my editor is advanced enough to show.

------
mbrock
I think it's good to note that you don't actually need a single one of these
tools to make functioning software. You can pack your scripts with cat and
download libraries with wget and use regular old JavaScript without
transpilers. When you have a problem with this, you can use tools... But you
don't have to top-load every project with a whole suite of complex tools just
for the sake of it.

~~~
cozuya
No one needs anything. You can write code in notepad. No one wants that, and
no one wants to have a million globals on the browser or hit F5 every single
save any more. While there is a learning curve to something like gulp, you
really only need to set it up once and you can use it on every project as
simply as typing "npm i".

~~~
mbrock
I wrote code in Notepad for years. Often now I use cat instead. Sometimes even
ed, which is surprisingly useful for many editing tasks. Knowing how to do
things in the most basic, fundamental way is nourishing. And I've heard from
many people that the JavaScript ecosystem—by which they seem to mean all the
stuff they hear that everyone else is using—makes them feel overwhelmed. So
it's good to have this clear explanation of the "modern" tools. But it's also
good to know that it's all optional and that you can start without them. It is
entirely possible to make a modern web application with just a few plain JS
files included with script tags. Yet people think the first step is to learn
about half a dozen sophisticated tools that they don't even know why they
need. So I say start with Notepad. Be aware that there are popular tools to
improve your workflow... But also that sometimes the best workflow is the one
you fully understand.

~~~
this_user
Of course you can write code using cat but there is no good reason to do so.
That would be like being a carpenter who refuses to use powertools and instead
relies on manually operated ones. If you don't understand how to use the tools
of the trade that will greatly improve your productivity, then you simply are
not a professional.

~~~
mbrock
You don't know that there's no good reason to do what I do. I use many
different tools. Try ed sometime, it might improve your productivity.
Professional? I deliver and get paid.

~~~
EC1
How about some specific examples instead of "I use `cat` and I'm right"?

>You don't know that there's no good reason to do what I do.

Exactly. Show us.

~~~
mbrock
What does it matter if I'm "right" about using a fundamental Unix command to
enter text once in a while? What do you think I'm arguing, that cat is the
best text editor and everything else sucks? Some guy said I'm not a
professional even before I had a chance to give an example, which is rude and
ignorant.

------
heidar
If you want to get started with this stuff but you're feeling lost or
overwhelmed then the free SurviveJS - Webpack and React book is a nice place
to start! It covers many of these tools.
[http://survivejs.com](http://survivejs.com)

------
tete
Gulp is really great and better, than Grunt, but sometimes make seems to be a
good choice that people forget about.

~~~
hyperhopper
Make doesn't work on windows. Its not cross platform, while Node, and all
technologies built on top of it, are.

~~~
zaphar
What?

[http://gnuwin32.sourceforge.net/packages/make.htm](http://gnuwin32.sourceforge.net/packages/make.htm)

~~~
edwinjm
It's still not cross platform. Changes made to the Makefile under one OS might
break easily under the other OS's.

~~~
voidr
In that case Node isn't cross platform either, I can easily write valid NodeJS
code that doesn't work on Windows.

------
applecore
The very good thing about module bundlers versus transpilers and task runners
is that changing a single file doesn't result in a complete rebuild of the
project; since the bundler maintains a model of the dependencies between
files, it only needs to recompile the files that matter.

~~~
guntars
The downside is that now you have a whole other ecosystem of tool wrappers
that tends to lag behind the tools themselves. They also tend to be JS
specific, so if you have any other assets, you'll still need a regular task
runner.

~~~
applecore
That's why I keep everything in JavaScript, including HTML and inline styles.

------
k__
With NPM and Webpack you can get pretty far. With all it's plugins an loaders
you're pretty much set.

~~~
dominotw
I've never had the need to use gulp/grunt or any such thing after webpack.

------
deckar01
Another tool that becomes useful as your npm dependency list grows is npm-
shrinkwrap. It is too easy to get large projects into a state that the
existing developers can build and test, but break in production builds and for
new developers. Being able to strictly version dependencies and control minor
package updates can save you from debugging bad builds and losing new
contributors. It's not a silver bullet, but can save you some frustration when
packages deviate from proper versioning practices.

------
devNoise
This a good overview of some popular tools for JavaScript development.

The thing that gets me about modern JavaScript development is the amount of
modules you download to build your code. Currently I'm going through a
PluralSights course for Gulp.js. Just to help me build and test my code, over
240MB of modules were downloaded. I'm starting to understand the benefits of
all those modules. The thing that gets me is that the process makes you
download all those modules again for the next project.

------
reycharles
> This process is called transpilation and there are tools called transpilers
> which takes care of it for you.

The process is called compilation, and the tools are called compilers!

~~~
TeMPOraL
Web scene likes inventing new words for old concepts.

------
eibrahim
In my opinion Ember JS is the best framework out there. It's instantly
productivity and everything just works out of the box. No worry about tooling
and such. If you are coming from Ruby on Rails or similar platforms, ember JS
is your best bet.

------
kriro
Very useful. This will be required reading for all our students :)

I created a react/grunt/browserify/babelify (+bootstrap) starter repo to clone
from github for them but think it's still confusing. This provides much needed
background information in one bundled place (even though the stack is slightly
different and only mentions grunt).

~~~
aaronem
That repo sounds like a good candidate for replacement with a Yeoman
generator!

~~~
kriro
Yep pretty much a planned project but for now I'm keeping everything as sort
of a learning exercise. master is ES5 and I have an es6 branch. The idea is to
have students look at the ES5 version first to appreciate the ES6 changes.
[actually a basic git primer is the first step :D]

The more practical solution would indeed be yeoman (imo)

------
talles
Does webpack started to be more popular than browserify?

I'm starting to see people talking more about webpack than the former...

~~~
joemaller1
The React world embraced WebPack after a modularity-kerfuffle back in
January[1]. Pete Hunt followed that with his webpack-howto repo [2] which kind
of turned the tide.

I really like Gulp/Browserify/Watchify/BrowserSync, but I'm starting to feel
left behind and need to give WebPack an honest try.

[1]: [http://blog.namangoel.com/browserify-vs-webpack-js-
drama](http://blog.namangoel.com/browserify-vs-webpack-js-drama)

[2]: [https://github.com/petehunt/webpack-
howto](https://github.com/petehunt/webpack-howto)

------
jebblue
Reading the page then the comments, even as a senior developer who only
touches JavaScript when necessary; I don't see much unification in the
JavaScript world today compared to 12 to 15 years ago.

React seems to be a theme, if I want to develop a modern (is Web 2.0 still the
term) single-page site (is that still a phrase?) using
HTML5/CSS3/JavaScript...what environment exists that is cohesive and complete
as either Eclipse for Java or Visual Studio for .NET?

Here's my answer, as an outsider, Java dude who only suffers brief interludes
with JavaScript...I'd pick jQuery Mobile or DART.

The thing is...whenever these JavaScript tooling articles comes up I don't see
those listed. I see names like React, Meteor, Gulp, Grunt, Webpack and maybe 3
dozen more.

------
erokar
Lost in the Bazar...

------
if_by_whisky
A popular opinion seems to be that none of these tools are necessary-- if you
don't use any tools then how do you write unit tests?

------
fiatjaf
Bad. Please don't use any of these tools except if it is necessary. And it is
not.

