
React-Boilerplate v3: The “JS Fatigue Antivenin” Edition - neuling
https://github.com/mxstbr/react-boilerplate/blob/master/Changelog.md
======
Niksko
Advice please: I tried to wade into the weird and complicated world of web
development a few months ago, but eventually I gave up.

At first I used a boilerplate (in fact I think it was a previous version of
this one), but it felt like I was jumping in the deep end. I didn't know what
anything was, I didn't understand the configuration or the setup, and nothing
was making sense.

So instead I decided "I'll start from scratch, introduce dependencies as I
need them, and I'll actually understand what's happening". But then as I
started to try and introduce dependencies and pieces of the toolchain and
stack (Babel, GraphQL/Relay etc.) and that was a whole different type of
confusing. I found it really hard to follow tutorials unless they were written
for EXACTLY the stack I was using, because small changes seemed to radically
change how I had to go about things.

How do you start? Both situations seem perilous. Bottom up is really difficult
unless you follow a tutorial that exactly matches your stack. Starting with
boilerplate means that if anything breaks you have no idea how to fix it or
how anything works.

~~~
freyr
Modern web development is a bit of a mess. My advice is to start small, and
introduce new technology gradually. You should be familiar the foundation
(HTML, CSS, and vanilla JavaScript) first, if you're not already. Be able to
manipulate elements of a webpage using vanilla JavaScript.

At this point, you might want to get up and running with Babel and the new
language features introduced in ES2015, since more and more tutorials are
written assuming you're using ES2015.

Then pick _one_ library or framework (e.g., React) and get comfortable with
it. Think of a simple project to build, then try building one even simpler
than that. Don't introduce a second technology (e.g., Reflux, Relay, etc.)
until you have a handle on the first. And even then, try to introduce just one
new technology at a time.

You might be thinking that this will be a slow, involved process. That is
correct.

~~~
wrong_variable
As a web developer who is not a 'web bro'

React.

Redux.

Reflux.

Flux.

Relay.

Does anyone else see the madness in this ?

~~~
vectorpush
All these tools exist for a reason, it's not "madness", it's individuals who
wrote some code and open sourced it for the benefit of those who might find
some use in it. _Just because a tool hits the front page of HN doesn 't mean
you need to use it_. I find it ridiculous when people complain about the js
tooling ecosystem (especially beginners), "too many tools" is only a problem
for someone who doesn't have a real problem to solve. If you were tasked with
the job of hanging a window curtain, would you walk into Home Depot and
exclaim "omg, hardware is a mess, why are there like 40 different types of
drills, why can't they just make this simple??". It is simple, _you_ are the
one making it complicated by obsessing over the options instead of focusing on
getting the job done. "but I want to pick the best tool for the job", well if
you don't know what that is, hire an actual professional, _it 's their job to
know_.

~~~
bshimmin
I'm not sure this analogy works. My brother-in-law is a builder and I would
certainly ask him what drill to buy if I needed a new drill, and I'm sure he'd
have an answer. (If I didn't have him to ask, I'd probably be able to
differentiate by "brands I've heard of" and price, with a sprinkling of
research on Amazon.) But if those 40 different drills all had slightly-to-
greatly different characteristics and then had a fundamental paradigm shift
every six to twelve months, rendering previous drills potentially obsolete,
would the professional builder really be able to answer definitively? Can
anyone in web development really answer definitively as to whether you should
use npm by itself, grunt, gulp, or even make?

(Possibly someone who knows a lot about drills is going to tell me I'm an
idiot in a second...)

~~~
vectorpush
> _rendering previous drills potentially obsolete_

This is the flaw in your reasoning. A better drill does not make the older one
incapable of doing the same thing it has always done to meet your needs. For
something to be made obsolete, the alternative must be definitively superior
by definition, so the reason for picking the superior option is clear in such
cases, but even then, _you don 't have to use the superior tool_. If a
traditional drill can meet your needs, _you_ are the one creating a problem by
using a tool that doesn't provide you with clear benefits.

> _My brother-in-law is a builder and I would certainly ask him what drill to
> buy if I needed a new drill, and I 'm sure he'd have an answer._

If you told your brother-in-law you needed a new drill, he'd likely ask "what
are you going to be using it for", and then you'd explain your requirements
and he'd give you an answer based on that. If you said "I really want to get
into building stuff, but I'm not sure which magnetic drill press is the best
option for a beginner", he'd probably say "whoa whoa whoa, that's a
specialized tool for a specific kind of job, just stick with a regular drill
and if that doesn't do what you need come back and ask me again".

> _Can anyone in web development really answer definitively as to whether you
> should use npm by itself, grunt, gulp, or even make?_

The crux of my point is that this isn't a useful question to ask. The question
should be more along the lines of

Q. "I need a way to run some custodial tasks related to the operation of my
application, what should I use to accomplish this?"

A. "Well, you could write some shell scripts and run those directly or with
npm's script running capabilities, or if you prefer to use JavaScript to
define these tasks since you're already using that for your application you
can try gulp or grunt; grunt takes a more declarative 'config file' approach
while gulp takes a more imperative 'streams' approach but they basically do
the same thing, though, you've been a C programmer for 10 years so you might
already feel comfortable with make, so you could use that I suppose, but you
won't be able to easily import js code from your application into make so if
that's something you want to do then you probably want gulp or grunt...." etc.

These tools didn't just emerge from the ether, they were created in response
to specific issues. The existence of some arbitrary library or framework has
absolutely zero impact on whether or not your existing solutions are adequate
for the problem at hand.

~~~
bshimmin
Thank you for your thoughtful and considered response. I'll just leave out the
bit about drills, because debating analogies is always unwise, especially if
the analogous subject is outside of one's area of expertise!

> _The crux of my point is that this isn 't a useful question to ask. The
> question should be more along the lines of Q. "I need a way to run some
> custodial tasks related to the operation of my application, what should I
> use to accomplish this?"_

I think you've just rephrased the question, no? We all know that "run[ning]
some custodial tasks" is what a task runner does; but many wise people have
expended many words telling you which of these increasingly fancy task runners
you absolutely must use, ecosystems have built up around them, and the waxing
of one and the waning of another does have a significant impact on the
decision-making process.

> _These tools didn 't just emerge from the ether, they were created in
> response to specific issues._

I'm not sure people were really desperate to move from "configuration to code"
or thought they really needed streams in their task runner before they were
told they did, so for me I struggle a little to see what the "specific issue"
was that gulp solved over grunt. The movement away from grunt and gulp to npm
scripts and even crusty old make(1) is, of course, at least partly in reaction
to the added complexity of these task runners - so in a way that's almost like
_unsolving_ a "specific issue".

------
mxstbr
Thanks for sharing this here neuling!

We've been working on this complete overhaul of react-boilerplate for several
months. Based on the combined experiences of tons of collaborators, we've
created the strongest foundation to build your next React.js application with.

The biggest changes are:

\- Revamped architecture: Following a bunch of incredible discussions (thanks
everybody for sharing your thoughts!), we now have a weapons-grade, domain-
driven application architecture.

\- Scaffolding: Generate components, routes and more parts of your application
directly from the command line, skipping all the boilerplate writing!

\- Performance: We've got the best code splitting setup currently available,
giving you the leanest, meanest payload. (The fastest code is the one you
don't load!)

\- JS utilities: We now include redux-saga, ImmutableJS, reselect and react-
router-redux to make sure your application scales to the size it needs.

\- CSS improvements: We use CSS modules for truly modular and reusable styles,
code split your styling based on the page the user is on and make sure your
code style is in order automatically!

I think this is by far the best boilerplate currently available, both for
starting your next project and for simply getting inspiration into what's
possible.

Let me know what you think everybody, I'm beyond excited to finally share this
with the world!

~~~
ClayM
Does this provide universal/isomorphic rendering?

~~~
mxstbr
Not yet, but it's the next big feature on our roadmap!

We've actively been working towards it, we realise it's a really important one
too, so it won't be long.

Chime into the discussion here if you have thoughts about it:
[https://github.com/mxstbr/react-
boilerplate/issues/174](https://github.com/mxstbr/react-
boilerplate/issues/174)

------
msy
The adoption of the approach ember-cli took over a year ago by both React &
Angular (angular-cli) is to me the strongest validation of the relative
architectural maturity of Ember over its competitors.

Ember has demonstrated singular organisational maturity - stable and
consistent release process, standardised build tools, high quality
documentation, excellent deprecation warnings & clear upgrade paths. It allows
teams to focus on delivering value without prevaricating about build pipelines
and trust that the whims of the maintainers won't result in months of
rewriting at arbitrary intervals.

Equally it's been pressure and progress from React on render speed that's
helped push along Ember's Glimmer engine, long may the ecosystem and healthy
competition drive innovation!

------
diggan
I've never understand what these kind of boilerplates are for. Well, kinda
understand if you're doing projects that takes just a few weeks to complete.
Otherwise, you're just better off starting with your own boilerplate.

I mean, how does updating work? If you improve the scaffolding, people need to
merge in their changes? Why is this not a CLI tool that would be effortless to
update?

Although I must say it's impressive work made on this, and that it's cool to
be able to generate many things, I fail to see any big value in using these
kind of boilerplates.

~~~
bryanlarsen
Boilerplates are used on large projects:

\- so you can postpone learning some of the more esoteric stuff until you
actually need it, rather than guessing at the beginning

\- Spending a day setting up boilerplate at the beginning of a 6 month project
doesn't seem like a big deal vs spending a day tweaking the boilerplate
throughout the project, but early time on a project is important, it let's you
get feedback earlier.

~~~
andybak
> so you can postpone learning some of the more esoteric stuff until you
> actually need it,

This is the main appeal for me. I want to get something off the ground quickly
and start learning the core concepts - not get sidetracked into understanding
a peripheral tool.

~~~
8note
it also lets me learn by example, with a clear ipicture of how a tool or
library or whatever fits into the puzzle.

------
atonse
Not to beat a dead horse but this boilerplate issue is one of the biggest
values of ember-cli, and the main reason I advocate for it over most of the
other frameworks.

I don't want to spend days figuring out my asset pipeline, build scripts, and
implementation of flux/gulp/grunt/webpack/broccoli blah blah.

It's good those choices exist, but I don't care about the differences enough
anymore, I just want to build my app. Plus, you lose the sense of common
solutions when there's this much variance.

angular has adopted ember-cli into angular-cli – any plans by the react
community to do this?

~~~
insin
> angular has adopted ember-cli into angular-cli – any plans by the react
> community to do this?

First, you would need to define what a React framework looks like, which
libraries it needs and which conventions it should use while wiring them
together, then build tools around that.

Version 3 of React Boilerplate takes steps towards that by deciding on a set
of tools, libraries and conventions and providing code generators for adding
to them in a compatible way, but the initial wiring is still done as
boilerplate (like it says on the tin).

react-project [1] was heading towards something more like managing this wiring
behind the scenes as a dependency rather than a boilerplate, but it's not
being actively developed any more at the time of writing.

\---

I think React and view libraries like it also necessitate a slightly different
approach in that there's no overarching _thing_ to hook into behind the scenes
- you just write a bunch of JavaScript and what it returns (plus side effects)
is exactly what you get.

For example, to use Font Awesome icons with Ember via ember-cli, you install
ember-font-awesome and the next time you run ember-cli it does... something...
such that an fa-icon component is now magically available in your templates.
[2]

In React, you install react-fa, import it into module scope where you need it
and use it as part of what a render() function returns - your build tools
handle it the same as any other JavaScript and CSS you've imported. [3]

[1] [https://github.com/ryanflorence/react-
project](https://github.com/ryanflorence/react-project)

[2] [https://github.com/wycats/github-issues-
demo/commit/a3358026...](https://github.com/wycats/github-issues-
demo/commit/a3358026a42b3438227cff9a3aabb620ce3c09a0)

[3] [https://github.com/insin/react-nwb-github-
issues/commit/cad3...](https://github.com/insin/react-nwb-github-
issues/commit/cad3abd4ec47f78bf50194ec1bd7cbfb1068e733)

------
riebschlager
I want to understand the appeal of React, I really do. But I open a project
like this in my editor and my linter starts going nuts from all the markup in
the JS. And my built-in biological linter starts getting queasy just looking
at it.

Ugh. I just don't get it. Am I just old and curmudgeonly? And what's with the
200+ line package.json. That's a helluva lot of tooling for a simple web app.
GET OFF MY LAWN!

~~~
epmatsw
What linter are you using? ESLint handles JSX fine as far as I know. And with
eslint-plugin-react it actually does some pretty neat validation on it as
well.

I will say that I initially disliked the inline markup as well, but it
honestly just makes practical sense. When we used Handlebars still, I always
had the template open in a split when I was editing a view anyway, why not
just keep it all as one contained unit?

~~~
riebschlager
I'm using JSHint. I know it's just complaining because of the way I have my
.jshintrc set up, but this markup-in-scripts thing is a big mental shift for
me. But hey, I'll try anything once.

~~~
aidos
It's definitely a big mental shift, but it's worth giving it a proper go.

For those of us who have been coding since before there was even JS, it's hard
to let go of the Html / JS split but honestly, it's so much nicer when you
just grab the React approach and run with it.

------
fauria
This is an excellent tool to compare different React starter kits: _Find your
perfect React starter project_ [http://andrewhfarmer.com/starter-
project/](http://andrewhfarmer.com/starter-project/)

~~~
pbreit
I don't want 60-odd random repos. I'd like to see 3-7 well-chosen options with
a few pithy sentences about each.

------
aidos
I've been reading through / trying redux etc over the last couple of days.
This has come at the right time where I know what all the components they're
talking about do and I'm interested in seeing more of how redux apps are
architected.

For people coming to this area fresh it's really daunting. There's a new
library for every little thing you can think of and it's almost impossible to
know where to start. Fortunately Redux itself is such a simple model that it's
easy to build on your understanding of it (vs, say, Angular that has a huge
surface area - I know, they're different things, but people are probably going
to start with one or the other).

Will try this out now to see how I get on. Great timing, thanks!

------
kimar
Thanks for this Max! We used it recently to migrate a Backbone/Marionette
app[1] to React/Redux and it saved us a great deal of time. We hope to write a
full writeup on the migration itself soon but meanwhile we've released the
code here:
[https://github.com/thebakeryio/openmic](https://github.com/thebakeryio/openmic)

[1]: [https://openmic.io](https://openmic.io), a MediaRecorderAPI experiment

------
todd3834
We have been working on solving similar problems. Isomorphic rendering was
very important to our needs, as was rails like generators. What started as an
experiment has actually turned into a really amazing tool. If anyone is
interested, in a more full stack solution, check out
[https://github.com/TrueCar/gluestick](https://github.com/TrueCar/gluestick)

~~~
jeremy_k
If anyone is interested in seeing a small project built with Gluestick, I have
one here
[https://github.com/jer-k/phoenix_gluestick_example](https://github.com/jer-k/phoenix_gluestick_example).
The Gluestick portion is under the _web/ directory.

As a note, Gluestick has been iterating and this project is obviously a few
months old, but it does show the basic structure of a Gluestick built
application.

Disclaimer: I work for TrueCar.

------
drinchev
Where's the boundary between boilerplate and framework?

I think people have hard times pronouncing framework these days, because it
sounds offending in terms of learning curve. Why would you spend X amount of
days to learn a framework, when you can spend that time learning about the
core technologies and make yourself no-dead-code code base? That's why I
dislike frameworks.

With React-boilerplate, having a CLI tool that helps you modify the
"boilerplate" I think we are getting more or less to the framework definition.

In any case I've never used a boilerplate without having to use `rm` command
after installing it. That's why I dislike boilerplates and avoid them.

------
leshow
This boilerplate will have to be rewritten again in a few weeks when react-
hot-loader 3 comes out and makes the hmre babel plugin obsolete

------
mintplant
If this is under the MIT license, doesn't every project that uses it for
initial scaffolding have to keep its license around?

~~~
dvcc
You can basically do anything at all with it, including include it in a more
restrictive licensing setup. The only constraint is that you must include the
original license/copyright notices.

[https://tldrlegal.com/license/mit-license](https://tldrlegal.com/license/mit-
license)

~~~
mintplant
> The only constraint is that you must include the original license/copyright
> notices.

Right, that's exactly what I mean.

------
rapind
But... It doesn't have horizon.io

------
RichH
Just F __ng use clojurescript its 1000 times simpler.

