
Create React Apps with No Configuration - vjeux
https://facebook.github.io/react/blog/2016/07/22/create-apps-with-no-configuration.html
======
thereact
This is great since it provides an OFFICIAL opinionated set of tools for
building React apps which is typically the largest barrier of entry for new
developers looking to experiment with this technology.

However, it is missing a lot of core features that typically come standard
with Webpack/React boilerplates. Directly from their Github:

Some features are currently not supported:

    
    
        Server rendering.
        Testing.
        Some experimental syntax extensions (e.g. decorators).
        CSS Modules.
        LESS or Sass.
        Hot reloading of components.
    

So a great first set of features for a simple React starter project, but for
those of you looking to expand the development toolkit from this currently
limited configuration, check out the following link to search React boiler
projects on github based on a number of criteria like the ability to search by
features included such as CSS Modules, Hot Module Replacement, etc.

[http://andrewhfarmer.com/starter-project/](http://andrewhfarmer.com/starter-
project/)

For those looking to learn more about the ecosystem, the following resource
lists might be useful.

More React resources: [https://github.com/enaqx/awesome-
react](https://github.com/enaqx/awesome-react)

React/Redux resource links: [https://github.com/markerikson/react-redux-
links](https://github.com/markerikson/react-redux-links)

~~~
afarrell
Lack of testing is a pretty big oversight given how helpful testing is for
someone getting started. Hopefully it is easy to just add mocha on top of this
with out any mucking around?

~~~
danabramov
It shouldn’t be too hard.

This is not an oversight, we literally developed this project in a single
week. We plan to add testing, just need to decide on the runner and good
defaults: [https://github.com/facebookincubator/create-react-
app/issues...](https://github.com/facebookincubator/create-react-
app/issues/80).

~~~
rattray
I really would love to see all the "features" listed above (and more) as a
part of this tool.

eg; `create-react-app --hot --less`

Including commonly-used defaults first, and adding full community bundling
later, would be much appreciated. There are probably <10 such packages which
would account for a wide range of the first week or so of any React project.

Good luck with this project and thanks a ton for dreaming it up & getting it
out the door!

------
orf
> Having just attended EmberCamp a week ago, I was excited about Ember CLI.
> Ember users have a great “getting started” experience thanks to a curated
> set of tools united under a single command-line interface.

This is one of the best things about Ember. `ember new`, `ember serve`, ember
generate component my-component`, `ember build`, `ember deploy`, `ember
install`. It's opinionated but it lets you get productive right off the bat. I
tried React but after a couple of days I just couldn't get it working, waaay
to many options. So I switched to Ember and haven't looked back.

~~~
ctvo
Kind of interesting to think about the two projects and how they diverge based
on the core developers.

Ember is made by folks who work on / for small and medium companies[1]. They
don't have the build infrastructure Facebook does and are able to create an
anointed solution in Ember-CLI because they'll use it daily. React is stuck in
a place where the environment it's developed in is unique from what any other
user will see. It's difficult to solve a problem when you're not in the space.

EDIT:

This leads to things beyond CLIs too. React is still billed as just a view
library instead of a solution for building an entire app. There's no official
path from view layer -> complete app (no guidance for data flow, how to
communicate with the server, server side rendering, routing on the client).

I think the React team needs to take a little more responsibility for the eco-
system it created. You can't call it just a view library when most use cases
use it to develop entire applications. You have to provide more guidance, you
can't fallback to Facebook not using it that way as the default response. In
my opinion most of the Great Javascript Fatigue of 2015-16 was caused by users
trying to fill in the blanks left by the React team and producing one solution
after another (and quickly abandoning ship as something iteratively better was
released).

1 - Tom, Yehuda at tilde.io

~~~
trentmwillis
The idea that Ember is made by/for small and medium sized companies is a bit
dated. Several Ember and Ember-CLI core contributors have and continue to work
at larger companies like LinkedIn and Yahoo.

In particular, LinkedIn has been using Ember (with Ember-CLI) for over a year
now and has found a lot of benefits from its adoption. Having a build system
and conventions that a community maintains lets us focus on building
applications instead of tooling (though we still have our share of internal
tools). We also can give back to the community for things which matter more
for applications "at scale". LI, for instance, funded a good portion of the
FastBoot work and has been a key driver in the Ember Engines effort recently.

All that to say, Ember (and Ember-CLI) can serve the needs of the whole
spectrum of company/team sizes. While it still has some issues to sort out for
larger applications, to say it isn't being influenced by large companies isn't
really accurate any more.

~~~
iamleppert
Having worked at LinkedIn in the past, and seeing the state (stagnation) of
their products both current and past, that's certainly not a ringing
endorsement.

------
seangrogg
I think one of the best things I've done to date is actually distance myself
from the React community. While I love some of the tooling that has come out
of it (Redux, React-Router) I think the community (as an amorphous entity)
over-emphasizes the need/desire for transpiling, linting, testing, etc.

Since then, I've "reverted" to building things in ES5, working in multiple
files without bundling, etc. and I have to say the enjoyment I get out of
using React has cranked up considerably.

I am happy to see they are converging on some standards - that will definitely
make building new apps much easier from a common starting point. I just hope
they can walk the fine line between "opinionated" and "bloated".

~~~
sotojuan
I was just talking about this with coworkers... I love React but the community
(aside from the actual creators and leaders like Dan) is too much for me and
seem to love bloat and unnecessary features. The cynical side of me thinks a
lot just do it for GitHub stars and blog views, but maybe not.

Of course, we just spent two days trying to decipher a React/Redux project
whose lead dev decided to use every "latest" feature even though it's a good
ol' CRUD app.

~~~
danabramov
We think ES6 is not the problem here. It’s just a language, and arguably a
better one than ES5.

The problem is the low level tooling around it. This is what we’re trying to
fix with this project. Hopefully you’ll give it a go, and maybe it will give
you just as much enjoyment as using <script> tags. If not, please let us know
how we can improve.

It’s not linting/transpilation/bundling that’s bad, it’s that it’s hard to do
them without shooting yourself in the foot.

~~~
Touche
I think the problem is that React is developed as more of a Node/JavaScript
project than as a web project. You see this in stuff like depending on
`process`, a thing that exists in Node but not on the Web. So the Web is a
compilation target; not the platform that React is developed for.

From there it's easy to think about everything in terms of JavaScript, and not
making the Web the intended target for usage.

~~~
enraged_camel
Yeah, along these lines, I also hate how most of the examples/tutorials online
assume your server is Node.js. I'd love to find some _official_ documentation
on the best ways to use it with Asp.net and Rails, for example.

~~~
pests
That's usually because those tutorials are also setting up sever side
rendering. Node.js is only needed for that and for running the various
(optional) build tools.

When doing a SPA I often set up Node.js to serve the index and provide server-
side rendering and then never touch it again. Any actual API/WebSockets/RPC
interfaces the app needs can be serviced by any plain old Ruby, Python, PHP,
etc app backend. Since I usually use PHP from old habits, I use a Symfony API-
only application.

I posted about this in a top level comment, but don't forget React can control
any element in your DOM and not just the entire body like most SPA's are
setup. You can continue using whatever languages/frameworks templating and
view systems and augment views as needed that would be better handled by
React.

------
jfdk
This is actually pretty huge. #1 complaint/barrier/hate with getting started
with React is all the tooling to do it "the right way"

Kudos to React team for bringing a superior pattern and making it actually
practical to use.

~~~
terda12
I'm really hoping to see the React team make React more user friendly. Maybe
an all in one React framework much like Meteor, where you can just do `react
createapp myapp` or something and start coding right away.

~~~
tlrobinson
React is so versatile (raw React, React + Redux, React + Relay, to name a few)
I don't think they should tie it too closely to one framework. I would love to
see a more official/opinionated framework that uses React, but call it
something besides "React".

Ditto for Redux. They're both low-level building blocks that could benefit
from some official "opinions".

------
firasd
This is great. React has this weird dual nature in that on one hand, you can
drop it in as a <script> tag and it 'just works'. On the other hand, if you
want to build using it, you're going to end up needing things like webpack,
babel, etc, not to mention other common libraries, to the extent that it takes
over your front-end stack (also because it takes over any rendered document
nodes, and if you want to build a SPA you eventually use it to render
everything inside <body> if not the whole document). So it's good to resolve
this conflict by providing quicker ways to get started with common tools.

------
andrewstuart
This is the most exciting thing to come out of the ReactJS project since it
started. The very best investment a technology platform can make is onboarding
new developers. ReactJS is recognising that and it's great news that they are
making the hardest bit easier.

I whined a while back on exactly this topic.

"Babel 6 - useless by default - a lesson in how NOT to design software. "

[http://fourlightyears.blogspot.com/2016/03/babel-6-useless-b...](http://fourlightyears.blogspot.com/2016/03/babel-6-useless-
by-default-lesson-in.html)

The last line of the above griping blog post says: "The right amount of
configuration is none."

So it is awesome to see someone who DOES know how to design software.

Dan Abramov's blog post says: "Zero Configuration. It is worth repeating:
there are no configuration files or complicated folder structures. "

Babel gets it precisely wrong, this new ReactJS tools aims to correct the
Babel complexity error.

~~~
danabramov
Babel doesn’t get it wrong, it just wants to be a lower level tool. You can
(and should) build on top IMO.

------
msoad
This is lacking tons of features that other boilerplates already have but I
think this was a great move because we needed a source of truth for doing app
structure in React.

In a different note, I think if you write it yourself from scratch you'll have
more control and knowledge down the road when it comes to nasty bugs but I
won't blame you for choosing this over spending weeks setting up a React app.

~~~
city41
If you work with React a lot, you can setup a React project to your taste in
about 30 minutes. But the catch being if you leave React for a while then come
back, all bets are off.

I think most boilerplates add way too much and are overly opinionated. I like
that this is simple, and "eject" gives power users an even better starting
point.

~~~
happyslobro
Totally. My first React setup took me two days to get right. Now, starting a
new project is a 5 minute exercise in CLI autocomplete that has me wishing
npmjs downloads were faster. It's surreal to think that for any popular
technology, there will always be newcomers, no matter how long that technology
has been around. I would write up my process in a blog post, but I'm sure that
that has already been written several times.

~~~
happyslobro
Going back over my old projects and finding four different flux
implementations, that is a new and interesting kind of suffering. The crazy
thing is, I never even liked flux in any of its forms. What I really want, is
pouchdb / couchdb, but even that is not perfect, and my team has no problem
poking holes in weird ideas.

Right now, I'm going through the Om.next tut series, and it is pretty awesome
so far. I think I'm going to pass on datascript, though. This is total
skunkworks though, if people at work found out that was using clojurescript on
the front end, they would be very concerned about me.

The killer feature for Om.next, imo, is using a reader function to define the
relationship between a component and the one application state atom. Combine
that with an identifying function that associates a component with a field in
the application state, and you enable the framework to make very precise
component updates.

------
amavisca
Under the hood this is Webpack + Babel + ESLint with sane initial
configuration. Love it.

~~~
griffinmichl
This is all I ever want in a React boilerplate, but everyone feels the need to
throw a bunch of random shit into them that others probably do not even want.
Glad they kept it sane and simple.

~~~
seangrogg
In all fairness, I think that flags that provide some basic bootstrapping for
Redux and/or React-Router would be very spiffy - those tools are useful for
many React applications.

~~~
amavisca
I think Redux and React-Router are very opinionated and distract people new to
React from React itself.

My workflow for ramping someone up on React and eventually Redux looked like:

\- A single React component with React.createClass

\- ES6 class React components

\- Add a component hierarchy and treat the top level component's state as the
entire app state - pass down callbacks to update state. Look how this becomes
harder to scale as we get more depth in our component hierarchy!

\- Redux without the redux-react bindings. Also stateless function components.

~~~
seangrogg
I agree. That's why I would put them behind flags. Even though most of my own
projects wind up using them, I tend to start from a clean slate and apply
things only as they become relevant.

------
tlrobinson
I think the best part of this is the "eject" feature. It's great to be able to
spin something up quickly but migrate to a custom solution if you outgrow it.

However, it would be nice to be able to tweak some of the configurations
(Babel, ESLint, Webpack) without completely "ejecting".

~~~
danabramov
If we let you tweak them, any minor update on our part would be a breaking
change. We wouldn’t be able to introduce new features or update the underlying
tools without a lot of risk. This is why we don’t let you change the configs.

If you have a specific pain point, please file an issue. I think we can make
defaults better. It takes more work but is more rewarding in the end because
it benefits everyone.

~~~
cheapsteak
This is super useful for helping beginners overcome initial barriers and
quickly become productive, but do you see this as something that most will
eventually grow out of?

~~~
danabramov
When you grow out of it, you run "eject" and customize everything you want.

We think in the beginning many will "eject" but we will gradually make the
defaults better to cover more and more use cases.

~~~
tlrobinson
That makes sense, but I think there will always be people who want to tweak
ESLint rules or enable new Babel features, but would still like to take
advantage of improvements to this project.

Perhaps exposing a subset of those tools' configuration options would be
sufficient.

Alternatively, you could imagine a pretty simple system that allows you to
pull newer versions of the "ejected" code and handle merge conflicts using
your version control software.

I'd also suggest reducing the amount of non-configuration code that's
generated by "eject". I think basically everything in "scripts" could be put
into a package ("openChrome.applescript" seems like it should be a feature of
opn anyway). That would also reduce the number of devDependencies that need to
be added to your project's package.json (rimraf, chalk, opn, etc)

------
vlunkr
My team has wasted so much time configuring webpack. This is a big win for
React IMO.

~~~
abritinthebay
This right here is why I actively suggest not using webpack. It's Grunt 2.0
all over again and not worth the mess.

IMO it's the worst choice Facebook could have made for this toolkit, as it
breeds some awful habits.

~~~
vlunkr
I actually use browserify for personal projects. It's ultra simple to get
started. My boss insists on using webpack.

~~~
abritinthebay
If you don't care about the stupid arbitrary bundling system for other assets
(like CSS and images) that WebPack has (and you shouldn't: it's an awful code
practice) then yes... Browserify is literally better in every way (other than
tree shaking)

~~~
danabramov
_> If you don't care about the stupid arbitrary bundling system for other
assets (like CSS and images) that WebPack has (and you shouldn't: it's an
awful code practice)_

The “stupid arbitrary” system has a number of benefits. It revs your assets
for production automatically with content hashes. It saves you from filename
typos because all assets (CSS, images) are part of the same build pipeline. It
throws on parse errors in CSS as part of your normal dev flow, not at some
later stage. It allows for fast hot reloading of styles in development.

The only downside I’m aware of is that it doesn’t work with some other tools
without special plugins or configuration. Well, you have to pick your
tradeoffs, right? I’d love to talk about technical tradeoffs of both systems
but your comment reads more like a knee-jerk reaction than a technical
assessment.

~~~
abritinthebay
> The “stupid arbitrary” system has a number of benefits.

Yes, it does. Those features aren't exclusive to webpack though (they're
really, really, really old features of webdev) and can be replaced by much
less silly systems.

I mean literally everything you just listed is _better_ handled by more
mature, developed, tools.

------
vicapow
I'm sucker for self descriptive "boring" names like "create-react-app"

Also, sweet project!!

------
hoodoof
This is a great idea and sorely needed. Too many frameworks rigidly avoid
integration with the ecosystem because they do not want to be seen to bless
any given third party technology.

In the case of reactjs however it is extremely important because the ecosystem
is absolutely necessary and absolutely damn complicated.

This is precisely what needs to be done to help people get started. Well done.

------
stoikerty
I'm fairly close to finishing the conversion of my `dev-toolkit` into an npm-
module. It is almost no-config, has scss, server-side-rendering, hot-reload
and more. I'm a one man band but will get there. It's all on
[https://github.com/stoikerty/universal-dev-
toolkit](https://github.com/stoikerty/universal-dev-toolkit)

The npm-version sits in a feature branch, just look for the corresponding PR
if you're keen.

~~~
stoikerty
I have a release ready. Just pinned it at 5.0.3 It is similar to `create-
react-app` but also has CSS-Modules (with SCSS) and a few other features like
Browsersync and root-relative imports.

Hope anyone reading this finds it useful :)

[https://github.com/stoikerty/dev-toolkit](https://github.com/stoikerty/dev-
toolkit)

------
thegayngler
So I was looking through the modules in react-scripts module and I noticed
postCSS, HMR is activated (I tested this myself). I also installed react-
router with ease and it appears to work just fine. So far so good from where
I'm sitting. I was able to start coding right away while I was half assed
looking through the modules to see what is actually in there and just play
while I talked with my roommates. It took me all of 10 minutes.

------
mohsinr
Loving it! I always wanted to get started with ReactJs but looks like time has
come! I tried the module and I am loving the "Welcome to React" page on my
localhost! Thank you!!!

PS. Already in /src/App.js , and wow live reloading without gulp or browersync
, it is so simple to get started! Thank you!

~~~
robertfw
I thought the live reloading was just for CSS?

~~~
danabramov
Yep. For components we refresh the page now. (Automatically still.)

------
venuzr
As someone new to React, I wonder

a) How is this different from getting a custom starter kit/generator from
Yeoman. Searching in yeoman, I see several for "React" with the top one having
over 9.5k stars [http://yeoman.io/generators/](http://yeoman.io/generators/)

b) Is Facebook planning to maintain and keep this generator current? Why don't
they just contribute/recommend an existing generator

~~~
danabramov
This is not a generator. It is a dependency, which means that we can (and
intend to!) update the underlying tools without any work on your part.

Additionally, unlike a generator, it doesn’t expose you to any configs so you
can focus on your code. However you can “eject” if you really want to.

------
kcorbitt
Sane defaults and pieces made to go together are critical to lowering the
adoption barrier and building a community, so huge props for that. But no
ability to configure anything at all? I think that for most people, at some
point there will be some small change to the default configuration their
environment will require[1], and that means they'll need to jettison the
entire project. It's nice that this is easy to do, but it would be better if
it weren't necessary.

[1]: For example, I run my app from within a Vagrant Virtualbox machine that
doesn't forward filesystem notifications correctly, so I have to configure
Webpack's hot reloader to poll for changes instead of listening for fs events.

~~~
sotojuan
[https://facebook.github.io/react/blog/2016/07/22/create-
apps...](https://facebook.github.io/react/blog/2016/07/22/create-apps-with-no-
configuration.html#no-lock-in)

> “Ejecting” lets you leave the comfort of Create React App setup at any time.
> You run a single command, and all the build dependencies, configs, and
> scripts are moved right into your project. At this point you can customize
> everything you want, but effectively you are forking our configuration and
> going your own way. If you’re experienced with build tooling and prefer to
> fine-tune everything to your taste, this lets you use Create React App as a
> boilerplate generator.

~~~
danabramov
We’ll start with extremes (no config vs all config is yours) and see how
people use it. Perhaps we’ll add some configuration later but if we do it too
early, we might as well become another webpack.

Configuration makes it very hard to move forward or swap underlying tools. So
we’ll stick with no configuration for as long as we can, and try to figure out
a way to solve common problems by other means (e.g. smarter detection,
platform-specific code, etc).

~~~
andrewstuart
Please Dan keep it zero configuration.

If a person knows enough to want to configure, then they have learned enough
to venture out on their own via eject.

The difference in cognitive load between "zero config" and "some config" is
enormous.

"zero configuration" === minimal mental model, no scope for misunderstandings,
misconfigurations, minimal documentation, almost no scope for user errors and
also minimal learning time

"some configuration" \- _even one single switch /option_ === learning the
mental model, understanding, version problems with the old way of configuring,
documentation of configuration, potential for errors, old & out of date blog
posts on the Internt telling how to do it the old way, beginner pain

You will come under constant pressure from people who want to add "just this
one teensy option" and will criticize the project for not having it. Resist
the criticism - beginners need zero config.

The root of all evil in JavaScript development and build systems is
configuration.

------
dustinfarris
Incredible turnaround! I remember seeing Dan Abramov's tweet [1] a while back
saying React could learn from Ember's CLI. Two weeks later, here it is!
Impressive!

[1]:
[https://twitter.com/dan_abramov/status/752863664290553856](https://twitter.com/dan_abramov/status/752863664290553856)

------
griffinmichl
After spending hours yesterday teaching a colleague about webpack, babel,
configuration, etc, this is exactly what the React community needs. Finally
some fucking sanity in the ecosystem.

------
fdim
Finally something that may convince me to switch from
[https://github.com/thardy/generator-
ngbp](https://github.com/thardy/generator-ngbp) \- all I want is to focus on
writing components not figuring out how to link gazillion dependencies

------
marknadal
The day we now see "compiled successfully" in the Command Line as the
necessary "easy" starting point for frontend web devs.

------
joemaller1
This is great and I will be moving my React projects in this direction. At
very least this project represents a de-facto standard and guidance about how
to work with React.

However I do wish the React team would pick between ES6 classes and
`React.createClass`. I think I remember the main React tutorial was rewritten
in ES6 at one point, but then switched back. I've read arguments both ways,
but I suspect they ES6 is still too much of a barrier to entry.

People who aren't up to speed with ES6 will still be shaving a lot of yaks
before actually jumping into React.

~~~
lacker
If you're using create-react-app then you're encouraged to use ES6 classes -
that's how the default App.js is set up.

~~~
danabramov
>However I do wish the React team would pick between ES6 classes and
`React.createClass`

We’re going with ES6 classes. Expect createClass() to go into another package
some time this year.

(Obviously we’ll provide an automated “codemod” utility to convert your
existing code.)

~~~
anthonybullard
Please say it isn't so! Class is terrible syntactic sugar to please old Java
programmers. I'd be really interested in why this decision would be made. Im
just getting going in React and am looking to make a move away from Angular,
because Angular 2 is so hyper focused on classes and decorators. I like React
because it's closer on the purity scale to something like Cycle.js.

But nevermind me, React is a great tool, and this is a very nice and needed
project!

~~~
acemarke
React's lifecycle methods and other similar features require some kind of
"object instance" to exist. Since React was created prior to ES6, the React
team created their own "inheritance"-ish approach, which is something that
every JS library out there was doing as well. One of the main arguments for
classes being included in the ES6 standard is that it's a common approach that
libraries can converge on and use together, rather than every library
inventing their own version of inheritance.

Since ES6+ is now the actual Javascript language standard, it makes sense for
React to move away from their homegrown class definition approach, and build
on top of the approach that is now standardized in the language. The React
community has already eagerly adopted ES6, and while React.createClass() isn't
going to be deleted any time soon, it's time to start encouraging people to
move away from using it.

Either way, though, React's API _does_ depend on having something "class"-like
available.

~~~
danabramov
Exactly.

We don't like classes, but we don't like "pseudo classes" (createClass) even
more. Better the devil that's standardized.

We already offer a way to create stateless components with just functions. We
will keep exploring that space and eventually might have a class-less solution
we like that satisfies all our use cases.

~~~
shados
One thing though, is that the standard classes are just not up to the job
without a lot of stuff tacked on. Eg: the function binding problem pushes
people to use class properties, which aren't yet a standard, and then they hit
walls with tools that don't support them (eg: I dunno if it's still the case,
but for a while class properties caused issues with Flow).

createClass might not have been the answer, but on top of stateless component
functions, things like the good old ES3 module syntax honestly would be more
flexible/powerful (giving you a closure to do things like private members,
etc)

Instead we have people using babel with all sorts of plugins, tacking on 3rd
party decorators and utilities, and a bunch of other cruft just to mimic
features JavaScript have had from the beginning. And then (talking out of my
rear here), it possibly put pressure on the TC39 to waste time discussing
features we seriously don't need.

~~~
hex13
There was not such thing like ES3 module syntax. This is just programming
pattern many people used:
[https://addyosmani.com/resources/essentialjsdesignpatterns/b...](https://addyosmani.com/resources/essentialjsdesignpatterns/book/#modulepatternjavascript)

It was a great idea back then, but that was never syntax. This and similar
patterns rely on the fact JavaScript is very dynamic and flexible language and
enables creating closures and creating objects dynamically.

These are very powerful features of language, but they're dynamic, which is
unfortunate because to know what _exactly_ is happening in this code you have
to run it. for IDEs/editors it's hard to look at your code and guess "well,
it's module pattern, I see! You mean this and that". Tooling operates usually
on static analysis of syntax. They use JS parsers to parse code to
AST(Abstract Syntax Tree).

And here's the thing: ES6 classes are visible in AST, there is something
called ClassDeclaration. This means that every programmer can install some ES6
parser from NPM and analyse ES6 classes. This means that there will be better
linting, better autocompletion etc.

On the other hand - JavaScript parsers don't understand module pattern or
other homegrown idioms. It's harder to analyse them statically. Especially if
they rely on dynamic aspects on language. ES6 parser doesn't run your code.
That's why ES6 classes, because they're static, are better for parsers, and
consequently, enable better tooling, IDE support, autocomplete etc.

Situation maybe were a little bit different if we had tooling for some sort of
dynamic analysis (if tools were running code in sandbox and gathered data in
runtime, not from syntax etc.).

But because currently most of tooling is syntax based I think ES6 classes (and
e.g. ES6 modules) are just better for analysis.

Well... to contradict what I said early I must say that actually it's often
possible to analyse such things like module pattern, createClass etc. But:

1\. not always with 100% certainty of the result

2\. there are too many idioms. If every framework, every team and every
programmer has own way of writing JS, own module syntax, own class syntax etc.
it's very hard to support all the frameworks and provide tooling for all
people...

~~~
ericelliott
Classes don't do anything about the dynamic nature of JavaScript. They spit
out basically the same constructor that everybody was using for pseudo-classes
in ES5. You can still do crazy things like manipulate the prototype outside
the class, tack extra stuff onto instances after they've been instantiated and
so on...

In other words, classes in JavaScript are a poor substitute for static types,
and should not be used that way. That's why a lot of React people are using
flow, and a lot of Angular people are using TypeScript.

~~~
hex13
Yeah. You're right that even classes allow for great amount of dynamics. I've
seen classes with decorator annotation and decorator can change classes as
much as it wants. I've also seen patterns like:

class Foo {... }

// then, after class definition

Foo.A = X;

Foo.B = Y;

etc.

So... it seems that every try to make JS more static is doomed to fail...
Because people will still use it in dynamic way...

Not sure how to solve this problem. Maybe we really need tooling that would
run code in sandbox instead of analysing it via AST (but how to sandbox e.g.
NodeJS code that interacts with file system or MongoDB? Mocking everything? Or
make complete dev environments/virtual machines with NodeJS code running in
it?)

(Maybe I overengineer solution ideas in my head, but I think proper tooling
support is important for modern web development. It hurts me when I have to
learn new large JS codebase and IDE is not helping)

> That's why a lot of React people are using flow, and a lot of Angular people
> are using TypeScript.

I don't like the idea of defining types for everything but maybe it's the
solution (I'm not sure because I have too little experience with TypeScript to
judge).

------
pests
Do not forget React is not equivalent to an SPA.

Almost all SPAs give the entire body over to React but its also possible to
choose a smaller DOM node and add React progressively to any existing website
view that would benefit from the React paradigm. In this setup (at least)
server-side rendering is no longer needed and thus simplifies setting up the
build process.

So its not all or nothing, you can pick and choose where to use React based on
your needs and requirements.

------
hex13
it seems like a solution to the Vjeux's challenge:
[http://blog.vjeux.com/2015/javascript/challenge-best-
javascr...](http://blog.vjeux.com/2015/javascript/challenge-best-javascript-
setup-for-quick-prototyping.html)

(If we don't count _sharable_ requirement).

~~~
vjeux
Integration with now.sh ( [https://zeit.co/now/](https://zeit.co/now/) ) and
uploading to gh-pages is something that was cut for the release but we are
thinking about doing :)

------
matthoiland
> Some features, such as testing, are currently missing. This is an
> intentional limitation, and we recognize it might not work for everybody.

With Ember CLI you get a great testing setup with Qunit. While I prefer Mocha
over Qunit, I'm at least glad that testing is a first class citizen in the
CLI.

~~~
iamstef
and its easily swappable: [https://github.com/switchfly/ember-cli-
mocha](https://github.com/switchfly/ember-cli-mocha) (and fully integrates
with the existing test harness, regardless of the test framework you choose.)

------
Bahamut
This is great! Toolchain pain really sucks, and makes being able to get
started on a project harder for many, when all you want to do is get a setup
running and start creating app code. Having an opinionated CLI start up a
scaffold is great - one can also peel apart this whenever one has to prepare
for modifying the build chain for specific purposes (for example using Rollup
to optimize bundled code, adding new build steps, etc.).

The only thing I disagree with here is not allowing it to be pluggable - IMO
it should be flexible and allow users to tweak the setup as desired. Of
course, it should focus on getting the core experience right, but in the long
term I absolutely think it would be better to have a pluggable CLI.

~~~
andrewstuart
Toolchain pain is closely related to configurability i.e. "having a pluggable
API".

Your choices for this type of tool are zero configuration with no pain, or
configurability with pain.

You can't have it both ways. In the JavaScript world, configuration and pain
are synonyms.

~~~
Bahamut
> In the JavaScript world, configuration and pain are synonyms.

This is outright false. There is some relation, but not all configuration
results in pain.

~~~
andrewstuart
It's a good enough slogan.... if more developers took it to heart then
JavaScript development would not be the torturous process it is today.

Any time anyone thinks about adding a configuration option they should think
again and if humanly possible, take the configuration option out.

Developers love making things configurable - it's a way of avoiding tough
decisions about what software should and should not be able to do.

The best developers are constantly looking for opportunities to remove
configurability without compromising the goals of their software.

~~~
Bahamut
If it's wrong, it's not good enough.

I don't disagree that configuration is awful, especially if it isn't well
thought out, but some configuration is unavoidable & even preferable in some
situations (for example when dealing with differences between production, qa,
and dev environments). Dismissing configuration wholesale though is laziness.
All things should be considered carefully, and blanket statements serve little
good.

------
ola
I created something similar a month ago

[https://github.com/olahol/reactpack](https://github.com/olahol/reactpack)

Doesn't seem like this project differs that much, although this looks to have
the backing of core React developers.

~~~
pbreit
I don't get why they would need to lock down the configuration and then have
to offer the eject thingy.

Couldn't they just offer a "facebook-certified" starter pack/bootstrap?

I guess you could just do an immediate eject?

Edit: looks like they contemplated that in the survey: "Yes, and I will run
`eject` straight away"

~~~
danabramov
Many people (especially beginners) appreciate automatic updates of their
dependencies. If you eject straight away you’ll have to manage them yourself,
which is a big turnoff to many.

~~~
pbreit
Could there be some sort of npm feature that incorporates a remote list of
dependencies & versions?

~~~
danabramov
Yep, it’s called a “package”. ;-)

~~~
pbreit
So could whatever create-react-app is delivering be substantially approximated
with an npm-based solution?

~~~
danabramov
create-react-app _is_ an npm-based solution.

------
koistya
There is an alternative solution that supports CSS Modules, PostCSS and HRM
with React Hot Loader. Give it a try! Create a new folder for your project,
then run:

    
    
        npm install -g react-app-tools
        react-app new
        react-app start
    

[https://hashnode.com/post/react-redux-without-webpack-
ciqylw...](https://hashnode.com/post/react-redux-without-webpack-
ciqylw5ux02a2oh53w5k15cw1)

------
bruth
This is a great start. I too got frustrated with the overwhelming complexity
of the "boilerplate" or "starter kits" that have all the bells and whistles.
Having something very simple that you can exit if necessary is nice. The
approach I took was just to document each tool or plugin that I may want to
add to my project since it is generally very quick to do so:
[https://github.com/bruth/modern-javascript-
starter](https://github.com/bruth/modern-javascript-starter)

------
dack
This is really great! However, I think this speaks to the need for a better
API in general for this sort of stuff.

At the moment it's "all or nothing" in that you can decide to let everything
be configured, or nothing be configured ("ejecting"). This makes perfect
sense, but I think a more ideal solution would be having layers of
configurability that let you more gracefully set your preferences without
completely abandoning this tool's utility.

I'm not saying that's easy, but it's a direction I'd be excited to see.

~~~
danabramov
I’d love that to be possible but “all or nothing” is useful as a forcing
function for us to choose great defaults. We might want to relax it a little
someday, but doing it too early will harm the project.

------
silasb
Very very awesome. This is very much needed. I work with a lot of older Java
people and showing them the ins/outs of webpack/eslint/React is killing
productivity. Thanks FB.

------
robertfw
I've solved my webpack config woes by using HJS-Webpack[0] which describes
itself as "Helpers/presets for setting up webpack with hotloading react and
ES6(2015) using Babel."

It provides you with a base configuration object, which has been setup with
any loaders that it has detected in your node_modules. You can then extend and
customize as needed.

[0] [https://github.com/HenrikJoreteg/hjs-
webpack](https://github.com/HenrikJoreteg/hjs-webpack)

------
thegayngler
This was one of the downsides to us using React at work. I did a presentation
on Webpack and React and my manager who is the VPE said having to figure out
and choose tooling was a concern for him. I responded we should know what the
tooling is doing and introduce pieces into our stack rather than go all the
way in. This allows us more freedom on how and when to upgrade or change
different tools in our front end stack.

------
mfrye0
This is awesome. Learning the whole modern build ecosystem was such a
headache. It's great it see best practices rolled up for new users to
experience.

------
codenamekt
This is great. One of the biggest hurdles is getting started which is why
there are so many react boilerplates. It would be awesome to see projects like
this grow so that it would auto configure based on libraries you would like to
use. Want to use Redux? Just run the `create-react-app -m redux hello-world `
and you would get everything with the addition of redux and it's
configuration.

------
brooklyndude
Is it me, but is not Angular just taking over? Kind of Google vs Facebook
thing. Just think Google won this one.

~~~
Bahamut
Eh, it's not a winner takes all war - it's the quest for continual
experimentation and improvement on the tools available to us for improving how
we build apps. The winners are all of us.

------
andrewstuart
Covered on TechCrunch [https://techcrunch.com/2016/07/22/facebooks-new-open-
source-...](https://techcrunch.com/2016/07/22/facebooks-new-open-source-
project-makes-it-easier-to-get-started-with-react/)

------
platonichvn
Definitely a great way to lower the barrier to entry. The eject feature is
sweet since it removes the risk of lock in. Looking forward to integrated unit
testing libraries in a future release. While you're at it let's add redux. :)

~~~
danabramov
We won’t add runtime dependencies besides React for now. We are focused on
solving build tooling first.

------
JoeCortopassi
This is great for someone who wants to get started to learn React, but is
_missing a ton_ that is needed for a real world production app.

    
    
      * No isomorphic rendering
      * No hot module replacement
      * No generators
      * No dockerization
      * No Sass support
      * No test environment setup
      * No code splitting
    

It would be cool to have a production ready tool from Facebook, but I'll stick
with gluestick for now
[https://github.com/TrueCar/gluestick/blob/develop/README.md#...](https://github.com/TrueCar/gluestick/blob/develop/README.md#why-
your-project-or-boilerplate-isnt-enough)

~~~
ctvo
What an odd and arbitrary list. SASS support over LESS over PostCSS over CSS
in JS? Component boilerplate generation is required for production? Hot module
replacement is required for production? Everyone using React is looking for an
isomorphic solution? Docker support?!

I think the point of the project is to acknowledge that React requiring
transpilation to use is 100% accurate and there needed to be a transpilation /
workflow solution to make it easier to adopt. It wasn't let me solve every
single problem for you, including setting up your production deployment
environment using Docker.

~~~
abritinthebay
> SASS support over LESS over PostCSS over CSS in JS?

Well yes, because any CSS in JS solution (in PostCSS) is just plain bad for a
myriad of reasons.

That would leave you with SASS vs LESS and SASS is massively more popular and
supported.

~~~
atoko
I think parent was suggesting inline styles

------
ralusek
For CLI generation utilities, I haven't found anything that comes close to
this guy:

[http://fountainjs.io/](http://fountainjs.io/)

------
lucaspottersky
Expectation: \- "Hey, look, this can SOLVE ALL THE PROBLEMS"

Reality: \- "Hey, look, this actually BRINGS IN A WHOLE LOT OF OTHER PROBLEMS
too!"

:sad:

~~~
Splendor
Would you mind explaining which new problems this creates?

~~~
abritinthebay
WebPack for one. Using webpack brings in way more problems than it solves.

~~~
Splendor
Again you've suggested the introduction of problems without mentioning a
single one. I'm not saying you're wrong (because I don't know what you're
saying yet), but I don't think you're adding much to the discussion here.

------
arianvanp
This is really neat. especially the fact that I can 'eject' at any time when I
need more power. Love it!

------
deepsun
Is there something like this for React Native? I'm interested in recommended
directory structure.

~~~
ed
This is kind of built in to React Native already, but they use their own
packager (ReactPackager) instead of webpack. Would be neat for ReactJS and
React Native tools to converge at some point!

------
kjhughes
Does this help with React Native too?

~~~
vjeux
React Native already has `react-native init <project-name>` command that works
in a similar fashion.

------
uptownhr
wanted to share
[http://github.com/uptownhr/kube](http://github.com/uptownhr/kube). I also
wanted to tackle this problem but also handling SSR as well.

~~~
uptownhr
but handles SSR as well.

------
crudbug
Having a consistent API with ember-cli will make this more useful.

$ react-cli <>

~~~
erokar
Only for those used to ember-cli. For the huge majority this is irrelevant.

~~~
crudbug
It provides a consistent mental model across frameworks for building front-end
applications via CLI.

~~~
danabramov
This would make people expect us to implement everything it does. We currently
don't plan to.

------
wrong_variable
Just wanted to know, am I the only person who is unhappy with react ?

~~~
mrspeaker
There are 7.4 billion people in the world. It's safe to assume you hold no
unique opinions.

------
smrtinsert
This is not a react problem, this is a nodejs problem.

------
rhinoceraptor
What the heck is that terminal font?

~~~
madjam002
Operator Mono

------
smcgraw
Amazing.

------
Exuma
Looks cool

------
mcs_
Thanks !!!

------
mderazon
In the spirit of zero configuration, it would be nice if it included Standard
JS [https://github.com/feross/standard](https://github.com/feross/standard)

~~~
mrspeaker
Please no! One person's "standard" is another person's "Please no!".

