
Step-by-step tutorial to build a modern JavaScript stack from scratch - lobo_tuerto
https://github.com/verekia/js-stack-from-scratch
======
nulagrithom
I feel like the people complaining about how many libraries there are in this
stack don't know what these tools do. Most are small tools that do one thing
very well.

Yarn installs packages, much like Gem, NuGet, whatever. Pretty standard.

React is a frontend framework. Not surprising that you'd use one. I suppose
you could opt to write a giant pile of vanilla JavaScript instead (I'm
assuming you're _not_ using this kit for a simple webpage, which would be
silly. We're building a web _app_ , right?)

I'd dare to compare Gulp + Webpack + Babel to your "compiler" in a way. I'm a
little lost at why we're using both Webpack and Gulp though. Babel is a
necessary evil to ensure we're "cross-platform" in a manner of speaking. These
are probably your most "unnecessarily complicated" tools.

ESLint and Flow check your code for obvious mistakes. Reminds me of
IntelliSense and compiler warnings. Again, pretty standard stuff.

Mocha is a test runner and Chai is an "assertion library". Chai isn't a big
deal: expect(foo).to.equal('bar'); Simple stuff.

Feel free to scoff at Redux and Immutable if you'd like. Probably unnecessary.

Am I the only one that likes this ecosystem? I feel like it follows the Unix
philosophy of "Make each program do one thing well". You need almost all these
tools in other environments -- they're just typically chosen for you in
advanced.

~~~
khc
I think the reason most of us dislike the ecosystem isn't because therre are
many libraries and tools in the stack. In the C-world, every time you type
'make' I am probably executing two dozen different programs, so we are very
comfortable with "Make each program do one thing well".

The problem that most of us dislike the javascript/web ecosystem is that those
set of libraries and tools keep changing every couple years. As someone who
doesn't do this as a full time job but once in a while has to poke his head
out to the other side, it's really hard to keep up with even the acronyms. For
example, I know that we are using npm, but now you say we should use yarn?!

~~~
gotofritz
Just google "yarn vs npm" and you'll know the answer...

the tools change because the technology is evolving, despite node the front
end is still the driver, and mobile phones / browsers / etc are constantly
being improved and evolved, and the ecosystem keeps up with it. Would you
rather it all stayed static like in the C world and then you program a 2016
smartphone with a 2006 stack?

~~~
IgorPartola
The answer to your question is yes. I would rather the stack, or at least most
of it, stayed stable for 10 years. The problem seems to be that the JS
community keeps re-discovering the wheel at every step, instead of actually
looking at other ecosystems and learning from them.

How log did it take for a sane build system to show up? Or a sane package
manager (with dependency resolution, upgrades, checksums, signature
verification, etc.)? Why is Grunt/Gulp a thing when we have thinks like
make/CMake?

The technology is not changing, in the sense that the state of the art is not
really changing. In the past 15 years the biggest paradigm shift has really
been towards single page apps, ES6-7, and TDD. The rest has existed as state
of the art in many other ecosystems, but the JS community is notorious for
having a bad case of NIH syndrome, so it's taking forever to get to the state
of the art.

The good news is that it will slow down at some point. The bad news is that it
probably won't be for a few years.

~~~
gotofritz
> Why is Grunt/Gulp a thing when we have thinks like make/CMake?

What a ridiculous statement. It's like asking why .NET doesn't use the JVM or
why Haskell doesn't use the C compiler. Grunt/Gulp solve web dev specific
problems, make is a different kettle of fish.

------
stevoski
From section 1 of the tutorial:

> Since it came out in October 2016, [Yarn] received a very quick adoption and
> is becoming the new package manager of choice of the JavaScript community.
> We are going to use Yarn in this tutorial.

It's October 2016 as I write. Tell me this tutorial is satire. Please.

~~~
gotofritz
Yarn solve some problems that the npm folks were unwilling / unable to solve,
and is backed by Facebook + Google (+ others) so it's likely to be here to
stay. Unless npm wake up and smell the coffee and implement some of it
themselves, but experience shows they are quite opinionated and not in a good
way.

~~~
Klathmon
IIRC the yarn developers worked with NPM to get it out.

It's not a lack of will or ability on the part of NPM that it can't be
"fixed", it's that NPM has just so much baggage. They can't change how things
are installed, because that would mean getting rid of features that many
people rely on. For a while they didn't even have any documentation on how NPM
worked, it was a bit tautological (npm worked in the way that npm worked...).

And rather than add flags or settings to NPM to support yarn's use cases which
would bloat the code, add a pretty sizable increase to maintenance and
support, and would really be a mess, they decided to create their own tool
which is similar enough to make it easy to switch, but without any of the
legacy baggage that NPM needs to support.

It's a perfect example of the unix philosophy at work ("Don't hesitate to
throw away the clumsy parts and rebuild them."), and just about everyone
(including NPM) is happy with the work they are doing.

~~~
oblio
I honestly don't know that part of the Unix philosophy. And it starkly
contrasts with my experience related to Unix, where most of the time we throw
nothing away.

------
Achshar
Ridicule me all you guys want but I still write using just html/css/js and
sublime text (no jquery either). And I have written a 30k line project using
just that and php.

Being a filthy casual has it's upsides. I can do whatever I want insanely
quick. Moving projects from machine to machine is quick as well. Only time I
use command line is for git. I do have the advantage of having all my
customers on a modern browser. But if that were not the case, only thing extra
that I would need is babel. None of what OP mentions is "needed" to create a
"modern" web app. Far from it.

~~~
agnivade
So just curious here -

How did you manage your js files ? Did you put everything in a single file ?
If not, what scheme did you take up on to split the files ?

What about minification and obfuscation of js ? And since you are not using
jquery, did you manually set event handlers (onclick, onchange) in the html ?

From my personal experience, I had once did a pretty big JS project without
using the ES6, webpack flow. And beyond a point of time, it got pretty much
out of control. In hindsight, using classes, require directives would have
made life so much easier to understand.

~~~
Achshar
> How did you manage your js files ? Did you put everything in a single file ?
> If not, what scheme did you take up on to split the files ?

Since I have the benefit of having all my customers' systems on chrome/ff
(evergreen variety) I can use latest js features that are stable. So most of
my main project (a CMS for schools to manage date sheet, exams, result,
attendance, homework, assignments, etc) is divided into features/modules.

There are a few project wide classes (es6) that are all in one file /main.js
(about 1000 line file, nothing outrageous). Then every feature can have any
number of individual pages (mostly two). So for example attendance has two
pages take.php and view.php. Each page with it's own js file, an average of
300-500 lines per page, though a couple js files go as far as 1500.

At the end most pages have about 2 or in some cases 3 js files that are
included in the header. It used to be kind of a mess when I wasn't using
classes but now it's all pretty much as good as it will get at my current
skill level.

> What about minification and obfuscation of js ?

My overall static page load is about 30kb to 50kb on average (excluding
api/json calls) so minification is not something that I had to look into but I
can easily do it with a babel flag. I mentioned babel in my original comment
because some of the site is also exposed to parents that can be from any
device/browser. So I use babel to compile (and if I want, minify/obfuscate)
some of my code as well.

> And since you are not using jquery, did you manually set event handlers
> (onclick, onchange) in the html ?

I think even in jquery you would have to set manual event handlers. But I have
a `Node.prototype.on = (e, f) => this.addEventListener(n, f);` somewhere in
main.js. So setting event handlers is not as verbose but I never needed
anything more than that. Not sure what other advantage jquery provides over
`node.on('click', e => {})`. Inline event handlers are yuck. My html/js/css
are strictly segregated.

I mostly keep my interface simple and focused on one single task so I never
needed frameworks like react either. I keep DOM interaction to minimum. Only
place where I think something is left to be desired in my work flow is
generating DOM nodes from my json api responses. I have it down to as simple
as I can but it's still pretty verbose. But I don't want to include and figure
out an entire framework just to do this one task that I am not completely
satisfied with but isn't that big of a trouble either.

Whew that turned out to be longer than I expected.

------
anon1253
I appreciate the effort, certainly do. But, and this a big but: the amount of
tooling, libraries, complexity and systems needed for a "modern" web app is
almost comical at this point.

~~~
ng12
Are you sure it doesn't seem that way to you because you're less familiar with
the ecosystem? Compare it to a Java backend. You might pick Ant, Ivy, Docker,
Dropwizard, Guice, Jersey, Jackson, Mockito, JUnit, etc. I don't consider that
to be radically less complex than the front-end stack proposed here -- but it
just seems that way because a lot of those are "de facto" tools.

~~~
rootlocus

      > You might pick Ant, Ivy, Docker, Dropwizard, Guice, Jersey, Jackson, Mockito, JUnit, etc.
    

I would pick maven, and add the rest as dependencies inside the pom.xml file
(the only configuration file I need to worry about). It would take me about 5
minutes and then I could import the project into IntelliJ IDEA and hack away.
I can write a tutorial about it in a single blog post, together with the
necessary commands to build, test and deploy the artifact.

With javascript, I need: webpack.conf, package.json, .babelrc and god knows
what else. Seems like every piece of technology around javascript
(transpilers, packers, dependency managers) requires another layer of
configuration, another set of CLI commands, and another waste of time trying
to figure out why it doesn't work.

------
czep
As a back-ender looking to dabble with modern front-end development best
practices, I'm encouraged to find guides like this one. Even if the array of
available packages and tools appears dizzying, and often times faddish, it's
nice to see the many options laid out rather concisely.

I have a decent handle on React and some of its immediately related tools,
which has greatly improved my fluency with contemporary front end work. I may
not ever use all these tools, but again it's helpful to see their setup
illustrated in an easy fashion.

Apart from React, what would be the next most important tool to pickup?

~~~
pault
The good news is that it can all be broken down into view library, state
management, transpiler, build tools, and test framework. Almost all of these
tools fit one or more of these categories. If you pick the one or two most
popular libraries from each of these categories and build a toy app using
them, you'll be 90% of the way there. The stack listed in this article is the
current vogue.

If you're not already using webpack with react, I would recommend putting the
time in to learning that. It's a beast and the documentation leaves a lot to
be desired, so you'll have to supplement your education with a lot of google
searches, but it's quite powerful and flexible.

React has come to dominate the ecosystem so rapidly that for the medium term
you're probably fine just sticking with that, and learning complementary tools
like various flux or relay/graphQL implementations. Angular is the only other
tool I regularly run into as a freelancer, but this is less and less often.
Almost all the clients I've worked for in the last six months have wanted
react. Of course there are many more exotic stacks that some people swear by,
but if your goal is to cover the largest percentage of the job market
possible, react and angular will get you there with a minimum of effort.

------
sospep
define:irony - a state of affairs or an event that seems deliberately contrary
to what one expects and is often amusing as a result.

example: This is a minimalistic and straight to the point guide to assembling
a JavaScript stack.

It teaches you how to set up ES6, Babel, Gulp, ESLint, React, Redux, Webpack,
Immutable, Mocha, Chai, Sinon, and Flow. It

~~~
cyberferret
Exactly. I clicked on the link and when I saw the list of libraries alongside
the word 'simple', I immediately thought it was a parody or satire site. I
kept reading, looking for the joke and wondering why I didn't 'get' it?!?

------
dglass
This is exactly why I don't do frontend development anymore. The number of
tools needed to get an app up and running is ridiculous. Add in cross browser
compatibility and it's all just one big headache.

~~~
20years
You don't need all of these tools to get an app up and running even though
reading the tech blogs may make it seem like you do. Frontend dev isn't really
that difficult if you focus only on what is really needed for your app at
hand.

~~~
ythl
It's just tiring though. I want to make a simple website. But in order to do
it "right" or "optimally" or whatever, I need to flush all the old stuff I
know down the toilet (jQuery, etc.) and learn a mountain of new stuff.

~~~
20years
Who are you trying to make it "right" or "optimally" for? The developer
community or the end user?

Unless your end user is the developer community, I doubt they give a crud if
you are using jQuery or all of this stuff. As long as your app is doing what
they want it to do and doing it well, that is what matters most.

If you want to make a simple website, all of this is way over-kill. That is
one of the downsides with these discussions. People are lead to believe that
all of this is needed to "make a simple website".

I am not at all opposed to learning new stuff especially if it is going to
make your job easier, but don't feel you have to abandon your current toolbox
and buy into a new one every few months just to keep up. That imo is madness
and will only hold you back from getting stuff done.

------
cel1ne
I would give up Immutable because of it's bad performance and often confusing
api.

Also I'd give up Mocha, Chai & Sinon for tape, which is way simpler and more
than enough:

[https://medium.com/javascript-scene/why-i-use-tape-
instead-o...](https://medium.com/javascript-scene/why-i-use-tape-instead-of-
mocha-so-should-you-6aa105d8eaf4#.53b5r8pfe)

~~~
mambodog
I don't think 'bad performance' is a fair characterisation of Immutable.js. If
you're calling .toJS() all over the place it will be doing a lot of redundant
work. However there should be no need to do that, if you just pass the data
structures around and access their fields directly.

That's not to say that you should necessarily use Immutable.js; if you don't
understand the use case where structural sharing in persistent immutable data
structures is useful and require it for your application then you should
probably just leave this tool on the shelf.

However, if, for example, you are maintaining maps containing many items which
are updated frequently, then you may benefit from the time and space
complexity of structurally shared maps (Immutable.js) rather than creating a
full copy on each mutation (plain JS objects).

~~~
cel1ne
> if you don't understand the use case where structural sharing in persistent
> immutable data structures is useful

No need to insinuate that I don't understand. I've used it extensively in
production and I think most code-bases are better off without Immutable.

> However, if, for example, you are maintaining maps containing many items
> which are updated frequently, then you may benefit from the time and space
> complexity of structurally shared maps (Immutable.js) rather than creating a
> full copy on each mutation (plain JS objects).

It was exactly this situation, maintaining maps with thousands of GeoJSON
features and working on these items, where I found Immutable to fall short.
The parsing/building of the data-structure alone took, If I recall correctly,
about 50 times longer than with normal JS-objects.

------
iyn
FYI: if somebody doesn't want to wire everything, there's a pretty good
solution: [https://github.com/facebookincubator/create-react-
app](https://github.com/facebookincubator/create-react-app)

EDIT: just to be clear, I think that the tutorial itself is valuable and I
appreciate it. I just wanted to post the link to CRA before somebody will come
here complaining about "JS fatigue". I use most of the tools that tutorial
describes and will use it to learn more about wiring testing-related tools. So
yeah - thanks for posting the link and for the author(s) for taking the time
to create such resource.

------
blueside
I would suggest to the author to put a "This is not satire" disclaimer at the
top of article to discourage users from leaving.

------
kennell
> It teaches you how to set up ES6, Babel, Gulp, ESLint, React, Redux,
> Webpack, Immutable, Mocha, Chai, Sinon, and Flow.

Stopped reading right here.

------
giancarlostoro
Am I the only one who thought the title meant actually rebuilding some of
these tools from the ground up? Building a stack and using / leveraging a
stack is significantly different.

------
bsou
Alternative stack that gets you much of the same stuff with less:

TypeScript, React, Redux, Webpack, Immutable, Ava

\- TypeScript covers much of the benefit of es6/babel/eslint/flow, Ava covers
chai/mocha, and webpack can cover most of what gulp provides

~~~
k__
There are many alternatives to chai/mocha. Ava, Jest and Tape.

I wouldn't consider Webpack an alternative to Gulp. Gulp is more generic. But
if you use Webpack you can replace to task-runner part with a few scripts.

When using ES6 or TypeScript I'd also consider Immutable to be optional,
because of "const" and "Object.assign()/Spread-Operator".

Also, React & Redux can be replaced with 1 thing, when you use a framework
that bundles view components and state management.

~~~
vmasto
Nit: not sure why you mention const. It does not provide any kind of
immutability assurance.

~~~
k__
I just use const instead of var/let all the time and it prevented me from
overriding the variable later, which forced me to write my code a bit more
functional then before I used it.

I know that I can still change indirect references or override valueOf() etc.

~~~
pault
You probably know this, but for anyone else reading, the problem is that if
you assign an object or array using const, the object/array members are still
mutable. If you have a tree structure, you have to recursively Object.freeze
the entire tree to get immutability, which AFAIK is basically what
immutable.js does for you. I also use const by default, but I find that more
often than not my variables are trees and lists.

------
johnwatson11218
I'm only half kidding but how complex does modern js have to get before it is
easier to code business apps in something like unity3d?

~~~
majewsky
This is exactly why asm.js and WASM exist: to enable frontend code to be
written in something that's not JS.

~~~
johnwatson11218
good to know. I had heard of this stuff before but just assumed it was yet
another framework.

------
codingdave
At one extreme, one can build a modern app from scratch with no libraries. At
the other, you can over-engineer it with far more libraries than you need.
Somewhere in the middle lies the correct answer.

So the key is not necessarily to have a set boilerplate to start from. It is
to understand what each tool offers, and why/when it is better then not having
that tool. So you can look at a project, and make an informed decision of what
stack to build.

------
rhodri
Yarn came out _this month_

~~~
ourmandave
Come Nov 1st, it will be _so last month_.

~~~
LordHeini
Don't forget that next month someone will pull down his trivial package doing
uppercase or something and the whole stack (of cards) will come crashing down.
Lately there was some great post here on hn mocking all that js framework
lunacy. But i guess that joke is old now as well...

But seriously does someone use this to do proper work? And if so does this
person expect this to be maintainable in the near future?

~~~
Matachines
Not only do people do this to do proper work, but the _major_ companies people
look up to do and want to work at or emulate do. Hence the problem.

------
zemo
based on the title, I thought it was going to talk about how to build a modern
front end from scratch. That is, "modern" meaning that it meets the user's
expectations, fits the realities of how they are browsing, and makes use of
the features of current browsers (web sockets, local storage, etc); "from
scratch" meaning using only your own code written in vanilla javascript. I
thought this was going to be about the fact that you can do compelling work on
the front-end without needing to get bogged down in a tangled web of
dependencies. I struggle to see how this qualifies as "minimalist".

------
bikamonki
Are you guys familiar with the term _overengineering_?

~~~
Matachines
I wonder what % of HN would be unemployed if companies moved away from crazy
complex SPAs. Surely how crazy they get is a reason why many here have jobs.

------
tribby
"This is a minimalistic JavaScript stack"

"ES6, Babel, Gulp, ESLint, React, Redux, Webpack, Immutable, Mocha, Chai,
Sinon, and Flow"

brutal.

~~~
bendavis381
Minimalist python backend stack:

Django, gunicorn, Django Rest, Postgres (psycopg2), celery, redis, requests,
nose, factory_boy, freezegun, raven

Building good applications for lots of people requires lots of stuff. Using
vanilla JS to build web apps is as much fun as using vanilla python to build a
backend.

~~~
tribby
I'd opt for flask if I were using python, but that's just me :)

the thing about the above-mentioned JS stack is that it's barely the tip of
the iceberg. most of the dependencies in those python apps are built using
standard libraries that simply don't exist in javascript. glazing over the
whole "you're about to download a bunch of random stuff from npm that may be
unmaintained or malicious" thing doesn't do a service to a junior dev.

it's also not a "modern" stack. gulp? webpack. npm? yarn. react? vue. and in
another month it will be something else. what you would opt for in python, is
well-established, built on libraries that are part of python's core, and maybe
except for the testing stuff has been around for 100 javascript years.

I'm criticizing neither the article nor its author, simply remarking that
javascript in 2016 is, in practice, completely fucking brutal.

------
jfe
so easy, any 10 year old with 30 years' experience can do it.

------
finchisko
Over the years (ok months) I build aversion against JS stacks. I tried to used
many of them when they popped up and I was starting new project. But it was
never a fit to me. However to give them at least some credit, I read sometimes
list of libs they're using for inspiration.

------
disordinary
This whole complicated stack of parts is why I don't really like React, you're
never 100% sure if what you're doing is best practice. I find Ember to be much
better, you only need to install Ember CLI and everything is put together for
you.

~~~
be_erik
Ember still has by far the best out of box experience and guides like this
make that point painfully well. With Ember CLI you start at step 1, skip all
the build steps (babel, webpack, etc...), and move on to learning the
framework and getting some work done.

In the end you'll end up with a framework that already has a story for state
management, api interaction, client side routing, and a complete testing
story.

I've setup the described React stack many times. I like React as a view
management library, but it requires a large amount of duct tape to get working
and even once it is I still have to dedicate a lot of time to tweaking and
maintaining all of these interconnected build steps. There are still tradeoffs
that have made React a great choice some cases (namely its reliance on build
duct tape allows it to be retrofitted into larger mature apps), but for apps I
want to just work out of the box Ember/Ember CLI is an easy choice.

------
captainbenises
You don't need all those tools. I'm a big fan of browserify and the budo
development server.

    
    
      npm init
      npm install -g budo
      npm install --save-dev babelify babel-preset-es2015
      echo "console.log('hello world')" > index.js
      budo index.js --live -- -t [ babelify --presets [ es2015 ] ]
    

Add tape for some tests and you're done.

------
fsloth
The "... from scratch" part made me think of actully implementing a Javascript
based browser environment from first pronciples and not just of a list of
random third party libraries.

------
Raed667
"From scratch" tutorial, that tells you to go learn react elsewhere then come
back...

------
tomcam
An excellent description of the stack and an able "defense". Thank you very
much

------
gagsrg
I don't use testing frameworks, no point to it.

------
manish_gill
This is ridiculous.

------
ge96
subbed

------
Matachines
What's the author's credibility? I know it's free, but why should I give my
time to read this compared to other resources?

I don't know how to say it without sounding like a dick, but the amount of
long "learn web dev" resources by people who can't write well and whose only
ethos is just being a programmer is ridiculous.

~~~
dvdhnt
Well, for what it's worth, he has a Masters in Computer Science, his open
source Initializr project is pretty popular apparently, this tutorial has
3700+ stars on Github, he wrote a book on HTML5, and was a front-end engineer
at Yelp.

You can see his Github here
[https://github.com/verekia](https://github.com/verekia) And his resume here
[http://verekia.com/resume/](http://verekia.com/resume/)

Edit: I find the article to be fairly well written, and I do have a background
in reporting and am a full time dev using most of these tools (although I'm
not particularly bound to them).

