
React Tutorial: Cloning Yelp - jashmenn
https://www.fullstackreact.com/articles/react-tutorial-cloning-yelp/
======
swanson
I'm no Javascript Boilerplate Fatigue apologist, but there are many comments
in here that are treating this as a "Learn how to use React" tutorial. This is
not what is advertised nor the stated reason this article was written.

From the first sentence: "we get a lot of questions about how to build large
applications with React and how to integrate external APIs" Large application
strucutre, external integrations...not "Hello World"

Of course there is no need for multiple environments, or a robust testing
setup, or an icon font, or 6 different webpack loaders to learn the basics of
React. This is not a tutorial on the basics of React -- this is written from
the perspective of a large production level application. And that "overhead"
and "insanity" are helpful for real projects that are staffed by more than one
person and need to last more than a week.

It seems absurd that it might take you 2 hours to setup the environment before
you get to hello world. But if you are planning to use this as the foundation
of a 6 month long project, 2 hours to get everything setup in a sane way is
not an issue.

There is absolutely churn in the JS world and some of it does seem
unbelievable because things haven't contracted and settled into a steady-
state. But don't just levy a blanket "lol fuck javascript tooling" every time
you see a complicated setup process; you are doing yourself a disservice by
not critically evaluating the choices the author of this post made and
determining for yourself if they will benefit your project and/or learning
efforts.

~~~
jimmytucson
Sorry, but even the “Getting Started” guide on React's website requires that
you have a "CommonJS module system" installed which, if you don't, means you
have to make an intelligent choice between Browserify and webpack, which means
you have to do some minimal research into what those are (and probably
research "babel-js", while you're at it), install one of them using npm, which
may require that you install or upgrade node.js which, if you're on a Mac, may
require that you install homebrew, which can sometimes open another, deeper
can of worms...

And that's just to get your tool chain in place. When you actually get into
the tutorial, it starts with "Running a server". Running a server?

I submit that writing even basic, toy applications in React requires a trip to
dependency hell and back, unless you already use these tools on a regular
basis and keep up with the ever-rapidly-changing debate around build scripts,
dependency managers, language preprocessors, etcetera, etcetera.

~~~
tracker1
By the same note, you likely won't be writing a complex desktop application
without some tooling installed, with similar pre-requisites. I don't know why
people get so irritated at "JS tooling is hard". Try writing an (INSERT
FRAMEWORK HERE) app outside the browser.

People assume that writing an APPLICATION for a browser is _easy_ , which is
why people get stuck maintaining monstrosities that are disorganized, not
composed and tens of thousands of lines of spaghetti. Writing an application
in the browser deserves just as much respect as one would give towards setting
up the database & schema or creating a service layer.

That lack of respect for front end code is a big reason as to why front end
projects have crappy code. React is a real break from this on so many
levels... Yes, you'll need (webpack|jspm|browserify) with (babel|typescript),
and likely (postcss|less|scss) in place closer to the start than the end. Much
like if you're writing code for a desktop application you'll likely need at
least an IDE installed, and potentially several libraries close to the start.

My current tooling of choice is webpack + babel, depending on the project I
may bring in scss or less, and react tooling as needed. Using CSJ or ES6 style
module syntax means cleaner code that's easier to restructure. Using webpack
means being able to bundle resources in a logical flow. Working on a project
without webpack + babel is just painful by comparison... I'm working on an ng1
app at work that's less than 6 months old, and feels like it was written in
2011... having to add .js files to some common point, and not being able to
easily refactor services/controllers/directives/components into discrete
modules is pretty painful in general.

What does it take to get a Java application going? Maven, some build system,
some other tooling, and understanding the component/class hierarchies? It's
not any easier than working with any new tooling.

Is there some churn, yes... is it that bad, not really... going to browserify
mainly means that you can have references from a starting point into your
application's code... each piece requires in its' dependencies. From there
going to webpack adds in other dependencies and custom loaders. Babel is a
translation layer... these tools generally build on or are supersets of the
tools that came before.

~~~
intrasight
There is much less tooling and much less churn even for a very complex Java
application

~~~
Chyzwar
When I see people in other teams fighting with Maven, Jenkins builds for weeks
somehow I cannot believe this.

~~~
intrasight
I didn't say that Maven wasn't complex. I said there are fewer tools and less
churn. The advantage of Java dev is that you can justify the intellectual
investment in the tools because there are fewer of them and they are going to
be around for a long time. The same cannot be said about client-side
development at this time.

~~~
tracker1
Grunt still exists, npm has been a common point for close to half a decade
now... it's pretty solid... everything else builds from there. If you've
gotten used to npm and cjs modules, that's been very consistent for a number
of years now.

~~~
Drdrdrq
Would you use Grunt for new projects? Maven is still being _actively_ used.

~~~
rapind
I thought Gradle was the new Maven. Before Maven it was Ant. There's even
Buildr (though not as popular).

------
eterm
To me this epitomizes what I feel as I'm trying to explore options for
different front-end frameworks. In this article I'm 30 screens down (literally
30 page down presses) and it's not even finished setting up the environment
and dependencies.

Sure, this is something that you only do once, so if it then leads to much
better development workflow it makes sense to have a solid investment upfront,
but it makes it very hard to compare technologies and make informed decisions
given how much up-front "glue" is needed to get a demo application up and
running.

I'm not blaming react, everything else in the javascript space is just as bad
right now. There's at least 4 different ways of loading modules (UMD, AMD,
commonJS, es (babel) modules), 2 of which (require(), import .. from) are used
within this example.

In fact the whole process is so complex part of the process is "clone this
package which has pre-configured parts of the process".

And all of this to glue together a couple of APIs.

~~~
swanson
I've shared your frustration. The Hello World experience is a huge spectrum
ranging from the 30 screens of setup you describe to the one-click Visual
Studio installer.

The other thing to consider is what you assume from a reader in a tutorial. If
you assume they have a full environment setup (or will be following another
tutorial), you can put together a much more concise article.

Imagine the now-classic Rails Blog in 15 minutes screencast. For those at home
-- even if you assume a unix-y environment -- you might have tutorial setup
that looks like this:

* Install homebrew/update package manager

* Install ruby-build

* Install rbenv

* Install ruby-2.3

* Install git

* Create a git repository

* Install bundler

* Create a Gemfile that includes rails

* bundle install

* Install rails

* Install postgres via homebrew

* Setup postgres database

* Install javascript runtime (nodejs or ruby-racer)

* finally run `rails s` to see the blank hello world page

Sometimes there are a lot of steps involved in a full end-to-end guide. And
sometimes we forget all the baked in knowledge and setup we had to do for our
preferred tools/stacks that we are having to go through again as part of
learning a new technology.

~~~
010a
I really feel like this isn't a general problem, but rather a problem with a
subset of development environments.

Node (backend) definitely doesn't have a similar problem. Want an express app?
Install node -> npm i express --save -> node app.js.

Go doesn't have it either, whether you're using the base tool or GVM. Python
requires a minuscule setup in virtualenv, but beyond that its straightforward.
Elixir and Rust are straight-forward.

In fact, the only environments where I've ever thought "wow this is a
configuration nightmare" are front-end web dev, Ruby, and in really complex
python apps, obviously notwithstanding less common app environments like
C/C++.

~~~
csallen
To be fair, the parent to your comment included lots of steps that assumed the
user was starting from scratch. If we assume the same for the user making an
Express app, the steps are much more complex:

* Install a C++ compiler (XCode or libssl-dev packages)

* Run the NVM install script

* Use NVM to install Node.js

* npm install express-generator -g

* express myapp

* cd myapp; npm install

* Install or update Homebrew

* Install git

* git init

* Install Mongo (or your db of choice)

* Install Mongo packages via npm

* npm start

~~~
wale
Really? This steps you just listed are similarly complex to what's in that
React article? No No bruh.... 30 screens -- down-button-presses down and we're
still seting up for a frontend sample app. This is so so an issue,
Node(backend), Go and Rails and Py aint got.

~~~
csallen
I'm not comparing my steps to the React article. I'm comparing them to the
steps in the comment I was responding to.

Anyway, measuring steps in terms of "screens" is woefully inaccurate. For
example, the author of the post uses more than one screen on simply running
`npm init`, because he includes unnecessary paragraphs and screenshots. Many
other parts of his post are even more verbose.

I could rewrite the first 30 "screens" of his post in 1-2 "screens". Would
that mean that the process is suddenly 30x easier?

------
pjs_
This genuinely made me feel ill. The author has done a tremendous service to
others - clearly and patiently listing the thousands of steps required to get
a basic modern web app up and running. I agree with others that it is often
difficult to find all the steps for a process like this in one place. At the
same time, this is completely, totally fucking insane.

~~~
ryanSrich
React was built by Facebook. Facebook has 1 billion users. If you're looking
to build a fast, simple, web app look at rails or Phoenix, not React.

~~~
zxcvcxz
What's wrong with react? If it's good enough for facebook and good enough for
the hundreds of other high traffic sites, then it's good enough for me.

Of course I also like to stay employed and react is the most in demand
framework right now.

~~~
ryanSrich
Sorry, I should have been more clear. What I meant was that your web app will
never be as complex and resource demanding as Facebook. The reason why React
is so complex is because it's intended for complex systems. If you want to
quickly build a one off web app you shouldn't be using React imo. The length
and complexity of this tutorial is a testament to that.

~~~
lopatin
React is simple, not complex. Simplicity is like the main benefit of using
React if your intention is to build a single page app. If that's not what you
need, then yeah, use Rails.

~~~
ryanSrich
React in a vacuum might be. React in the context of building a real
application is not.

~~~
lopatin
Vacuum React is all you need for a small scale, real world app.

Ok, granted at some point you might want to pass your build through Browserify
and Babel. No worries, both of those things are one liners in bash.

On the other hand, if you spend most of your time trying to make your build
process the holy grail of hot-reloading webpack ES2020 isomorphic madness then
you're not going to get much real work done. No one told you to do that
though, and you can't blame React either. But even that isn't complexity. It's
just annoying setup stuff. Real complexity grows with the scope of your app.

------
qudat
I've built a multitude of websites/applications in my lifetime spanning many
different programming languages, build systems, tools, etc. From PHP, to
python, to golang, to java, and JS. It seems painfully obvious to me that the
people complaining about this setup/build system do not fully grasp the power
and beauty of the JS ecosystem, more specifically react, redux, time
traveling, and hot module reloading. It is without competition, the best
development experience I have ever had been apart of. There is no lag time
between when I make a change in JS or CSS to when those changes get applied to
the application. There's no compiling (even tho there is a compile step), no
refreshing the page, no stepping through all your previous steps to get to
that part of the application, your changes are patched in real time and
available to you automatically.

I guess the saying is true, that haters are going to hate, but there really is
no competition in terms of development experience _once you grok the
ecosystem_.

------
eagsalazar2
The criticism here is really baffling in how it blames the js ecosystem for
the complexity in building large production apps..

I wouldn't find fault with a similar tutorial for "how to set up a production,
at scale, rails app with only sever side rendering and zero javascript".
Between hosting, cacheing, deployment, worker queues, database provisioning,
etc, LOL that tut would be gigantic and that makes sense!

If people are mad that making production client side applications isn't
trivially easy, well that just isn't going to happen and that isn't because
the js ecosystem is screwed up.

~~~
zxcvcxz
There are two types of web developers:

1\. Those who know javascript and some major framework

2\. Those who are unemployed

Yes we can build apps with just HTML and CSS and put it all in one file and
serve it with a one line command, but if we want to be employed and have a
website that actually scales we need to follow in the foot steps of the people
who have done it.

------
keyle
I've dealt with many technology stacks. If this is the future, we're F#$$%.

Seriously, how can people be blasting older technology like Flash and Flex
(which was GREAT), out of the water for not using web standards and then this
Frankenstein of a "stack" is going so mainstream.

Sure, there is the VM problem, but the language was good and so was the
framework. This looks horrendous and scary. Imagine maintaining this for the
next 10 years when "the standards" will have moved on to you "next gen"
javascript "framework".

My only way to write web apps has been using micro frameworks, jquery, and
small libs that do one thing and one thing only. I can handle serving pages
with Go thanks, and I don't need a routing system that looks like a vintage
joke. Sorry if I sound jaded, I've been doing this for 15 years.

~~~
zxcvcxz
Can you post one of your projects?

~~~
keyle
I currently work for large company (in Fortune 100) and behind NDA, I can't
really show my stuff. But it's good work. I wrote my own data binding library,
beyond that, it's all micro libs. What's your point?

------
Cyph0n
Great work on the tutorial. I'm sure it took a lot of time to setup, and it
seems well written.

However I simply won't believe that setting up a simple React app requires so
much overhead. Granted, I have no experience with React, and only marginal
experience with frontend web dev.

As I read the tutorial, this is the list of questions I had:

1\. Why do we need so many Babel presets? What do they do?

2\. Why do we need Webpack exactly? Why not use a traditional build system
like Gulp?

3\. Why is Webpack so difficult to setup? Are there no pre-configured setups
for React?

4\. What the hell is postcss? Are Less and Sass out of fashion now?

5\. And why all this added complexity to setup CSS? They are only stylesheets
for God's sake!

6\. Oh, so now we need to configure Webpack to support postcss? The definition
of reinventing the wheel. Is there no plugin system for Webpack?

7\. Why is it so complicated to setup multiple environments using Node and
Webpack?

Phew, looks like we're done -- nope, we're not.

8\. _So many libraries_ just to setup a testing environment? I wouldn't be
surprised if frontend apps aren't well tested...

9\. Ah, we also need a "JSON loader", whatever the hell that is.

10\. Great, another CLI tool for testing. And more configuration of course.

11\. Webpack once more needs to be configured to support our new testing app.

12\. We need a better spec reporter? Why? More configuration...

13\. More Webpack configuration.. I'm already sick of it.

So many things to keep in mind, so many dependencies, so very many points of
failure. If just one of these libraries is abandoned, or has a breaking
change, your _entire development environment_ is dead. Is this the current
state of frontend web dev, or are these guys just overdoing it for the sake of
the tutorial?

I find this all weird because I have the habit of thinking very carefully
about every single dependency when I'm writing software. Do I _really_ need it
i.e. can the same task be achieved using the standard library? If not, how
active is the development of the library (recent activity, issue response
time, number of contributors)? How many libraries does it depend on - the
fewer, the better? And even with all this, it's still not guaranteed that
things will go smoothly!

~~~
sdnguyen90
This is how I start off a React app:

    
    
      $ npm install --save react react-dom
      $ npm install --save-dev webpack webpack-dev-server babel-core babel-preset-es2015 babel-preset-react react-addons-test-utils
    

/webpack.config.js

    
    
      module.exports = {
        entry: 'src/index.js',
        output: 'dist/bundle.js',
        module: {
          loaders: [{
            test: /\.jsx?$/,
            exclude: /node_modules/,
            loader: 'babel',
            query: {
              presets: ['es2015', 'react']
            }
          }]
        }
      }
    
    

/src/index.js

    
    
      import React from 'react';
      import ReactDOM from 'react-dom';
      
      const MyRootComponent = (props) => {
        return <div>Hello World</div>
      };
      
      ReactDOM.render(MyRootComponent, document.getElementById('react-app'));
    
    

/static/index.html

    
    
      ...
      <body>
        <div id="react-app"></div>
        <script src="bundle.js"></script>
      <body>
      ...
    

start the web server

    
    
      $ webpack-dev-server --content-base static/
    

There is nothing forcing you to use all the extra dependencies. You can build
a full app without them.

~~~
zeemonkee3
> There is nothing forcing you to use all the extra dependencies

This right here is a major problem with a ton of apologists. "You don't need
to use X and Y, just start with barebones Z".

If you're doing your own side project, sure. Or if you're lucky to be
developer #1 in a greenfield project. I can count on one hand the number of
times in my career that's happened.

Most of the time, you're going to be maintaining someone else's work. They'll
have a ton of dependencies and glue and workarounds, and you're really, really
lucky if they've written tests or documentation. So all the complexity
mentioned in the article? You get to deal with that, only not so neatly put
together. More likely they'll have an out-of-date version of react-router
that's incompatible with the library you're trying to install, upgrading
react-router means rewriting a ton of code because they love to change their
API every other release....

Now I like React, and I've built things with it. But there is a huge and
growing PR problem with it right now, that for all its promise there is too
much incidental complexity, too many ways to do it, a lack of standardization
around things like build tools. Companies aren't overjoyed at having codebases
that become impossible to maintain 6 months out, when the frontend devs jump
ship. Whether the answer is a more structured framework like Ember or Angular,
I don't know, but there is a lot of fatigue and frustration around trying to
build and _maintain_ a project out of lots of tiny pieces, and it's showing in
this thread.

~~~
RobertKerans
The extreme modularization is a huge, huge issue. There is a slight settling:
the recommendation for state management shifting almost exclusively to Redux
is IMO a very good thing, if only for the fact of how brutally simple it is,
with almost zero chance there will be any API changes. Packages such as react-
router, with constant API changes, are a nightmare though. Standardisation
this year would be good: state management (Redux), a router (a settled react-
router), immutability (Immutable), a method of dealing with
asynchrony/promises that's well documented and easy for people to just pick up
and use, a drop in test framework (personal bugbear is setting up the
multifarious bits of test/coverage/complexity tools - Ava + NYC + Plato seems
a very good build so far for this, but it's very young). But it's the
configuration of build tools which is the killer

React itself is very simple, but then so is jQuery, and having to pick apart
the twenty or thirty jQuery plugins + associated spaghetti the last dev
dropped into a project is even less fun than the current situation, it just
took a lot less of a deep understanding of JS; one of the issues I'm starting
to get a lot more of is devs dropping in prebuilt components, which is just
jQuery all over again, but in extremis.

------
rvanmil
I've been on the fence for quite a while, but a couple of weeks ago I finally
bit the bullet and taught myself webpack, ES6, React, CSS modules, Redux, and
everything else that comes along with these tools. It definitely felt like
relearning my job (coming from working with Grunt, Backbone and jQuery) and it
took a lot of time and effort to really get to understand everything (still
learning many new things each day), but man was it worth it. I enjoy working
with these tools very, very much and I am able to build apps significantly
faster than I could before.

~~~
duderific
> a couple of weeks ago I finally bit the bullet and taught myself webpack,
> ES6, React, CSS modules, Redux, and everything else that comes along with
> these tools

Can you share how you did that? Was it a number of different resources you
consulted, or is there some all-in-one resource you found?

~~~
rvanmil
These resources have been very helpful to me:

[http://survivejs.com](http://survivejs.com)
[https://github.com/markerikson/react-redux-
links](https://github.com/markerikson/react-redux-links)
[https://github.com/HenrikJoreteg/hjs-
webpack](https://github.com/HenrikJoreteg/hjs-webpack)

~~~
acemarke
Yay! Very glad to hear that my React/Redux links list has been helpful.
Currently working on trying to add in some more intermediate-ish topic
articles, beyond the typical "getting started" tutorials.

------
showerst
This is a really great tutorial, it's rare to find pieces that step you
through the whole process with dev/prod and tests without assuming you already
understand the arcane setup.

It also shows what an arcane dependency-hell react is... how much boilerplate
does it take to get up a map with a valid route? I hope this is something that
becomes a bit more standardized/easier as the ecosystem evolves.

------
blueside
The setup required just to get a production-ready idiomatic `hello world` app
in React is downright insane. Without the Facebook name behind it, I don't see
how React could have ever made it this far.

Foolish of me to keep underestimating the pains that JS developers willingly
tolerate.

~~~
zxcvcxz
Your comment is wildly uninformed.

[https://gist.github.com/danawoodman/9cfddb1a0c934a35f31a](https://gist.github.com/danawoodman/9cfddb1a0c934a35f31a)

~~~
claar
I don't think it's fair to call his comment uninformed based on that link.

From your gist:

    
    
        For ease of use, we are including the React, ReactDOM and Babel CDN
        builds to make getting started as fast as possible.
        
        In production, you'll want to instead look at using something 
        like Gulp, Grunt or WebPack (my personal recommendation) 
        to compile JSX into JavaScript. Also, check out:
        http://facebook.github.io/react/docs/tooling-integration.html
    

He did specify "production-ready", after all.

------
rvdm
First off. Great tutorial! I wish more frameworks their native documentation
would come with more real world examples. Redux's fantastic documentation is a
step in the right direction but still makes real world solutions a bit too
much of a side note.

Regarding Javascript fatigue, I want to share something that greatly helped
me.

I have written enterprise applications for Fortune 500s using PHP, Rails,
Backbone, Angular, React, Node, Express, Grunt, Gulp, Webpack, Yeoman, Bower,
Redux, jQuery, Coffescript, Prototype.js ( remember them!? ), LESS, SASS...
Basically whatever was hot at the moment.

Long I've enjoyed learning new things, but after having made a solid
investment in Angular only to find out none of it's SEO solutions were really
commercially viable the fatigue hit me hard and I gave up on trying to learn
new things for a while. I simply stopped caring.

Then I got approached by SpaceX for a JS full stack position. All they told me
about the interview beforehand was that it would be very JS heavy, yet no
details on what stack or framework they were working with.

To prep I brushed up hard on my basic JS skills. Codeschool.com their JS road
trip was very useful. So were "Eloquent JavaScript" and "JavaScript: The Good
Parts".

After making that tough but very rewarding investment, learning React, Flux,
Redux, Elm etc. all became a breeze. I no longer have any attachment to any
framework. They're all just different ways of using JS to me. And no matter
what the future brings, no matter how many frameworks and build tools get
thrown our way, I don't think ( hope? ) my heavy investment in Javascript will
soon disappoint.

So for those of you out there trying to figure out what to invest in next,
React, Elm, RxJS.. My advice would be to get a deep understating of pure
Javascript first. Ideally, try to build your very own framework using vanilla
JS. Once you do that you'll find each new framework is just a different
opinion on how JS should be used.

Many frameworks have come and gone. But after more than a decade of investing
in the Javascript language, it keeps rewarding.

------
hammeiam
I also got frustrated by the setup time for a simple react app, so I make a
starter repo that I just clone for all my new projects. It's made to be as
simple, light, and understandable as possible while still being useful. Check
it out and let me know if you have any questions!
[https://github.com/hammeiam/react-webpack-
starter](https://github.com/hammeiam/react-webpack-starter)

~~~
missing_cipher
I like it. Thanks!

------
hathawsh
The complexity of this tutorial reflects the current state of web app
development more than the complexity of React. React by itself is actually
rather simple on the surface.

Even though I don't need this tutorial to be productive, I think I'm going to
go through it anyway to fill in holes in my knowledge. It looks well written.

------
zeemonkee3
The anger in this thread does not bode well for the future of React.

I predict big, complex, arcane React stacks will be a punchline in a few
years, much like J2EE/EJB is today.

And yes, I know React itself is a small library - Java servlets were a small,
simple API that formed the foundation for a ton of over-engineered abstraction
on top.

------
arenaninja
I haven't finished reading, but so far this is an excellent walkthrough. This
goes far far FAR beyond the 'Hello World' and 'TodoApp' tutorials and demos
the amount of tooling you have to dedicate to keep things as seamless as
possible.

I recently wrote that in a side project it does not appear to be worth the
effort, but that applies to my side project and nothing else. Your next
project may well look a LOT like this.

------
ErikAugust
We (Stream) are releasing a React/Redux tutorial series - you build a photo
sharing app (Instagram clone), for those you might be interested:

[http://blog.getstream.io/react-redux-example-app-
tutorials-p...](http://blog.getstream.io/react-redux-example-app-tutorials-
preview/)

~~~
bdcravens
This link has no content - looks to be like a "coming soon, give us your email
for updates!" page

~~~
ErikAugust
Fair enough - but we're releasing 4 posts next week. We have a total of ten
completed and in the pipeline.

~~~
bdcravens
Probably worth a separate submission at that time. I guess you'd don't want to
miss all the eyeballs talking about this React tutorial however, right? :-)

~~~
ErikAugust
Yeah, agreed. But yeah, after all the writing we were eager to get something
out, haha.

------
morgante
People should stop complaining about how "hard" it is to get started or how
"complicated" React is.

React is simple. Its core abstraction is trivial (making views into pure
functions).

If you want to, you can get started with React today without installing any
software at all. Just include it from the CDN:
[https://cdnjs.com/libraries/react/](https://cdnjs.com/libraries/react/)

The rest is there because things like live-reloading are genuinely helpful.
But you don't need to roll them yourself. There are dozens of great
boilerplates you can base a new project off of.

Also, I've never had as much difficulty setting up a React environment as the
constant struggle it is to get even a basic Java app to build from source.

~~~
gedy
The React ecosystem for developing non-trivial apps is not at all easy and
rather complex. Both for new developers and experienced web folks to relearn
"the React way".

------
bdcravens
I know there's a lot of dog-piling on this tutorial, but having gone through
fullstack.io's Angular 2 book, if I wanted to learn React, I'd probably (and
probably will) go with their title.

------
pacomerh
Cool tutorial, but first check if React is what you really need for your next
thing. Facebook creates React to solve the problem of dealing with large
applications with data that changes overtime. React became very popular to the
point where the word gets spread saying this is the newest and coolest thing
to learn. At this point the core idea and key aspects of why React is cool get
misunderstood and we start assuming that React is the best choice for
everything! and Virtual DOM is so cool and done!. So now apps that could be
done in 1/3 of the time if you just used a simpler library or even vanilla
Javascript are being written with all these complex flows, dispatching actions
and thunking async operations when all you really needed was display a list of
things with ajax...... I'm not saying React is not cool. I'm just saying,
understand why React is relevant today and decide if its the right thing for
you project. Of course these tutorials are gonna be using simple examples that
are unrealistic. They're meant to help you understand how things connect with
each other, but are you building a project that is worthy of all this setup?.

~~~
zxcvcxz
The cool thing about react is that it doesn't try to do everything. Compared
to Angular react is minimalist. So that's why react is used so much: because
it doesn't try to do everything, it's basically just javascript and doesn't
require you to re-learn web dev, and if you want to extend it you can easily
do that. React can be made to fit most needs.

If all you're doing is serving a static web page then any framework is over
kill, but then again, if all you're doing is serving static web pages you
probably aren't a paid professional web developer.

To be a web dev professionally you need to know some framework, and react is
really the best one. Angular tries to do too much but still makes you
implement everything "the angular way" and meteor isn't a good framework for
companies that want mix and match different technologies on their stack.

Then there are other alternatives that are non-javascript based, but in the
end you still end up having to use javascript somewhere most of the time. Why
take all the nastiness from the web-dev world and add even more convolution to
it?

React isn't perfect but it's the best we have. And this is coming from someone
who hates facebook and was once an angular dev.

~~~
marknutter
But React does actually try to do everything. React components can only
compose other React components, and so you have React components all the way
down. And if passing data all the way down that tree gets tedious you need to
start looking into some sort of Flux/Redux type of data handling solution.
Pretty soon you're in-lining your CSS because half the tutorials and 3rd party
React components are doing that and nothing you've written plays well with any
of your existing code, not to mention the vast sea of code written using other
libraries. React is a trap. It works best when you use it everywhere, as
Facebook does, but it's not a friendly and open framework when it comes to
compatibility with others, especially with coming standards like Web
Components.

------
drumttocs8
I think most everyone agrees that the amount of work to get all these pieces
glued together before you can even start is ridiculous- a problem that Meteor
set out to fix years ago. It faltered, of course, by being too opinionated.
Now that Meteor fully supports React and npm, though, is there any reason not
to use it? Sure does remove some pain points.

~~~
sergiotapia
No real reason as of now, you can choose to not use MongoDB if you want and
use Meteor as just the front end.

When Apollo comes out, RIP all these React boilerplate projects, you're going
to be able to pick and choose the data stack you want with Meteor making it
nice to use.

------
kelvin0
Is it me, or does the JS tool ecosystem have the same problems encountered in
some functional language frameworks (LISP for example)? I'm not comparing the
languages here (I'm not a fan of JS), but how they are lacking the 'Batteries'
and toolsets other languages have grown up with. Since you can do practically
anything with JS (or LISP), if something is lacking simply write your own
solution ... repeated 1,000 times. This is why there seems to be a gazillion
tools/solutions/framework each doing something similar but different enough to
cause massive confusion to newcomers. This is one of the reasons DART had
appealed to me, the language came with a framework and tools that helped you
get started right away, instead of getting bogged down trying to figure if you
should used Webpack or it's numerous alternatives.

------
sergiotapia
Meanwhile here's how you work with React in a Meteor application.

[https://github.com/nanote-io/nanote-web](https://github.com/nanote-io/nanote-
web)

No need to mess around with plumbing because honestly, who cares about that
stuff.

~~~
Scarbutt
But who cares about meteor? It failed, let it go.

~~~
sergiotapia
Failed how? A lot of startups and enterprise companies are using it now, with
more to follow once Apollo launches.

------
freyr
All this effort to create a single page app that likely doesn't need to be a
single page app in the first place.

If you're jumping through hoops to build an app that looks and feels like a
traditional web site, you're doing it wrong.

------
JoshGlazebrook
Am I the only person who just doesn't get the appeal of Webpack over using
something like Gulp? It just seems to me like Gulp is so much easier to use
and setup.

~~~
dsego
Webpack does a lot more. Gulp is just a glorified (and cross-platform) make.

~~~
JoshGlazebrook
I guess I meant more from a ease of use point of view. Gulp/Grunt are easier
to configure and get going.

~~~
dsego
Not that I have too much experience with either. But one example is having one
webpack configuration with misc. loaders vs. reinventing it yourself and
ending up with this mess:

1) You still get a config file, neat right
[https://github.com/mgechev/angular2-seed/blob/master/tools/c...](https://github.com/mgechev/angular2-seed/blob/master/tools/config/seed.config.ts)

2) And this boilerplate
[https://github.com/mgechev/angular2-seed/tree/master/tools/t...](https://github.com/mgechev/angular2-seed/tree/master/tools/tasks/seed)

------
dandare
There is something wrong with me but I can not/refuse to use command line. It
has no discoverability and no visible system state information. Every time I
try to use it I start to panic because I can not see my files, I can not see
the state of my task, I can not see anything. Maybe I have some form of
dyslexia. Anybody out there with similar symptoms? Anybody knows a remedy to
my problem please?

~~~
callalex
I would start with using a better shell that gives you more of the context you
are asking for. I would recommend zsh and using Oh My Zsh for easy setup

------
troncheadle
I have something VERY similar to this in production built with Angular, and
let me tell you, I'm looking forwards to the day that I get to refactor it in
React.

I get that it's frustrating to do a lot of setup. But that's the nature of the
game. We're all standing on the shoulders of giants.

React is a pleasure compared to other ways of conceptualizing and practicing
building user interfaces on the front end.

------
missing_cipher
I don't understand what people are saying, the basic Hello World App is right
here: [https://www.fullstackreact.com/articles/react-tutorial-
cloni...](https://www.fullstackreact.com/articles/react-tutorial-cloning-
yelp/#demo-basic-appjs)

Like 1/15th of the guide down.

------
mobiuscog
May I just thank you for:

a) providing an estimate of the time it will take

and

b) offering a simple way to receive it in PDF format for later consumption.

I wish every site did this.

------
jyriand
I wish somebody with clojurescript/reagent experience would rewrite this to
see how it compares.

------
chrishn
Not React specific, but how do we tackle SEO for a site like Yelp, where SEO
is very important? I want to turn an article-based site into a SPA, so it can
consume a stateless API and horizontally scale. But I fear it'd lose a lot of
pages in Google.

~~~
firasd
React can render on the server side using the initial app state.

Couple examples: (1) [https://github.com/mhart/react-server-
example](https://github.com/mhart/react-server-example) and (2) This article
from me: [https://medium.com/@firasd/quick-start-tutorial-universal-
re...](https://medium.com/@firasd/quick-start-tutorial-universal-react-with-
server-side-rendering-76fe5363d6e) (Previous discussion:
[https://news.ycombinator.com/item?id=11461159](https://news.ycombinator.com/item?id=11461159))

------
k__
If you want to look into React, but aren't in the mood for all the setup:

[https://github.com/kay-is/react-from-zero](https://github.com/kay-is/react-
from-zero)

~~~
blunatic
This is really great, thanks for posting!

------
mickael-kerjean
That's quite funny, I've spent the last few days achieving pretty much the
same thing but with Angular2. If some people are interested about it I might
write a few things about it as well

------
tonetheman
Interesting... he needs to include his webpage config from each stage. He
linked the full one but that will not work when you are still in the starting
parts.

------
kpwagner
[https://developers.google.com/speed/pagespeed/insights/?url=...](https://developers.google.com/speed/pagespeed/insights/?url=https%3A%2F%2Fwww.fullstackreact.com%2Farticles%2Freact-
tutorial-cloning-yelp%2F&tab=mobile)

Yikes.

------
gt384u
ITT: People who don't React well to critical feedback from new users

------
int_handler
The cover of this book is very a e s t h e t i c.

------
ahhsum
This looks awfully close to python. Is that true, or am i imagining things?

~~~
tschellenbach
That was what I thought :)

------
nijiko
All of that, for that simple demo...

~~~
missing_cipher
Simple Demo: [https://www.fullstackreact.com/articles/react-tutorial-
cloni...](https://www.fullstackreact.com/articles/react-tutorial-cloning-
yelp/#demo-basic-appjs)

------
Scarbutt
yes, your problem seems to be learning by banging the keyboard like a monkey
which you inherited from clicking like a monkey to get a mere sense of how to
use something instead of reading some upfront documentation.

~~~
dang
Personal attacks are not allowed on HN. We ban accounts for doing this, so
please don't do it again. Instead, please (re)-read the site guidelines and
comment civilly and substantively, or not at all.

[https://news.ycombinator.com/newsguidelines.html](https://news.ycombinator.com/newsguidelines.html)

[https://news.ycombinator.com/newswelcome.html](https://news.ycombinator.com/newswelcome.html)

We detached this comment from
[https://news.ycombinator.com/item?id=11781593](https://news.ycombinator.com/item?id=11781593)
and marked it off-topic.

------
zxcvcxz
Lots of complaining but no one offers a better solution. Any article detailing
how to build a yelp clone is going to be kind of long. It's really not that
bad compared to doing something like this with LAMP. Much simpler than Angular
too.

With Angular I feel like I have to re-learn web development and do everything
the "angular way", and who knows when Angular three is coming out and the
"Angular way" completely changes.

And then what are the non-javascript alternatives? It really doesn't matter
much because I'll have to interface with javascript anyway if I'm a
professional webdev, so why would I add even more clutter to the already
cluttered web dev world?

With React, I can learn a small framework that's highly extensible and
basically pure javascript. I don't feel like I have to re-learn everything I
know about web-dev when using react like I do with Angular.

~~~
carsongross
Here's a non-javascript javascript alternative that's a few orders of
magnitude simpler:

[http://intercoolerjs.org](http://intercoolerjs.org)

------
tschellenbach
More tutorials coming up soon: cabin.getstream.io

~~~
bdcravens
Is your site associated with this one? If not this comment seems very out of
place.

~~~
k__
Well, people are talking about React and React tutorials here. Everyone has a
different approach to teaching and learning, so this is a good place to share
:)

~~~
bdcravens
Yes, we're talking about tutorials here, not "coming soon but sign up for my
email list" pages :)

