Hacker News new | past | comments | ask | show | jobs | submit login
React Tutorial: Cloning Yelp (fullstackreact.com)
521 points by jashmenn on May 26, 2016 | hide | past | web | favorite | 245 comments



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.


The problem with the massive amount of churn is that it just doesn't pay off to learn the new, cool thing when it's going to be obsolete in 3 months or less. I think all programmers, especially ones who read HN, like to learn new things. It's fun to pick up new languages, learn new paradigms, and experiment with different technologies.

What's not fun is learning 10 different ways to handle promises, 4 different build tools, several frameworks, and dozens of new libraries over the course of a year just to keep up. By the time you reach a level of mastery over one of these tools, it's already been replaced by something else! I mean it's great that the tools are getting better, but it's really painful to deal with the constant churn.

/rant


>it just doesn't pay off to learn the new, cool thing when it's going to be obsolete in 3 months or less.

Does this actually happen? If you had learned Angular way back, you would still be in a comfortable situation. New stuff coming in, but it's compatible with the old stuff.

Same with React. Had you learned react when it was talked about, you would have gotten, what, at least 2 years worth of value by now?

And a lot of the build tools are independent of the tech. Grunt is still fine to use, and people release plugins for it all the time.

And here's the last thing: You don't have to spend 6 months to learn a thing. If you want to keep up, read about it for 15 minutes? That should be enough most of the time to get the philosophical differences between tools you know. And if it does intrigue you enough, engage with it.

This stuff is progress, if we went the other way we'd still be writing jQuery spaghetti code and having state integrity issues up the wazzoo from callback hell. You don't have to ride every train, but you can at least look at them as they go by.


Grunt is actually not still fine to use. I've been burnt by a lot of plugins coming out for Gulp only and now for webpack only. What the GP says is true: if you start using any of these JS tools prepare to switch them out every 6 months.


> What the GP says is true: if you start using any of these JS tools prepare to switch them out every 6 months.

As a full stack JavaScript developer, the tools I used over 6 months ago are also the tools I use today. Only difference is I left Angular for React. But my build tools are still the same. I use Gulp, SASS and Webpack.

You're talking out of your ass if you actually believe something can get to the popularity of Gulp or Webpack and then instantly be "old news" and "not worth using" within 6 months.


The problem is working with fanboys who refuse to use the tools that you've spend a year or two investing in. When the people you work with throw away your projects every couple of months, there's nothing you can do to keep using what works.


I'm with you, but there's a strong point with Grunt vs Gulp. Gulp is the new standard, and it usurped Grunt only how many months ago?


Grunt just released v1.0 and is still a great alternative. People fail to realize just because another way to do something comes out, doesn't mean all of the sudden the previous way is no longer a viable solution.


Like... a year ago was the tipping point.


You're arguing against a strawman, develop some reading comprehension before you insult people.


Maybe I'm not ahead of the curve enough. Still though, every 6 months? Did you start using Grunt only 6 months before running into this issue?

Maybe I'm reading this too literally, but personally I'm totally cool with using a tool for 2 years and then transitioning to another. 2 years is already a lot of good value.


My experience is that the decision to switch is often being made for you. I was perfectly happy with Grunt until some plugin maintainers didn't update the Grunt version and only worked on Gulp.


We started a brand new project in Ember (our second Ember project) in December; launched it in January. We've now started another project in Untangled because nobody wants to work in Ember anymore (apparently, it stopped being cool last year).

So, yes, this actually happens and it's incredibly painful for those of us who want to build a business not throw everything out and start over every few months.


The solution is not trying so hard to keep up. Keep your ears open for the major improvements that rise above the noise, but don't feel like you have to be on the cutting edge. Much of the cutting edge is (almost by definition) misguided or overcomplicated.

The sweet spot if your goal is to actually build something is taking whatever architecture is currently hip and throwing out about 2/3 of it in exchange for a simpler approach. Then circle back for the fancier libraries a few months later if and when you have a need for them.


> What's not fun is learning 10 different ways to handle promises, 4 different build tools, several frameworks, and dozens of new libraries over the course of a year just to keep up. By the time you reach a level of mastery over one of these tools, it's already been replaced by something else! I mean it's great that the tools are getting better, but it's really painful to deal with the constant churn.

I feel your pain, but on the other hand:

- tools with enough users are not going away, even if they're less actively maintained

- it's not like sticking to HTML + jQuery is desirable if you need to build a complex UI


Especially when even this article points out that webpack is difficult to set up, and basically requires a helper tool.


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.


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.


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


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


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.


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.


Would you use Grunt for new projects? Maven is still being actively used.


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


> you likely won't be writing a complex desktop application without some tooling installed

With C++ I can just download Visual Studio, or the Qt SDK. No other dependencies.

With Go, I download Go (a single installer) and also my Go IDE of choice - LiteIDE (a single zip).

I don't have to install an installer installer or any nonsense like that.


And go doesn't have a package manager? It doesn't need any other modules to create gui apps? Aren't there wrapper bindings that would be simpler than direct api calls?


Speaking for myself, I have used many platforms ranging from embedded to desktop and I also proud myself to be a competent old skool web developer - one who has avoided node.js, angular, amber and similar. React caught my attention and I tried to learn using it... What pain! What parent is saying about tooling is totally true. But maybe I just missed a simple hello world tutorial... I will check it out in a year or so, if it's still around by then.


Got a whole bunch of tutorials listed in my React/Redux links repo, at https://github.com/markerikson/react-redux-links. If you're looking for a couple that are really simple and involve no other tools or libraries, you may be interested in http://jamesknelson.com/learn-raw-react-no-jsx-flux-es6-webp... or https://github.com/kay-is/react-from-zero.


Thanks, appreciate it! I will save the links for the next time I go exploring React (which should be soon).


This is why I like Ember: you get setup in 2 seconds. Sure, I don't like all of the decisions they've made in the framework but it does work really well out of the box.

I think having a cli will become standard for JS frameworks. You just need to have the batteries included to capture the newb mindshare.


I've recently started looking into Ember - which of their framework decisions do you dislike?


I prefer mocha to qunit and I'm a fan of coffeescript (ES6 can wait. I love the existential operator). My company had made a few decisions before ember-cli that weren't on the Ember Happy Path. I've tried to stick to those decisions to avoid making people learn a different stack. It's not that easy to rip and replace pieces of Ember.


I'm having trouble understanding your comment.

Neither the homepage, Getting Started, the tutorial, nor the downloads page mentions CommonJS. If you do choose to use browserify or webpack, you'll want Node and npm, but Node's homepage doesn't suggest using Homebrew so I'm not sure why that would be necessary. (Besides, in my experience, most programmers using a Mac have Homebrew already.)

> When you actually get into the tutorial, it starts with "Running a server". Running a server?

We included this as a sample because most people write clients against an app server so we thought it instructive to show how to fetch and post data via AJAX. Nothing about it is inherent to React and people make React apps without any server component all the time. It sounds like this was misleading to you, which is good feedback for us. I was thinking about revamping the tutorial soon anyway and my new example wasn't going to have any server component.


My comment was based on notes I took from a little over a month ago, when the Getting Started guide said "We recommend using React with a CommonJS module system like browserify or webpack."

https://web.archive.org/web/20160411175140/https://facebook....


Ah, indeed. Looks like we tried to simplify it recently:

https://github.com/facebook/react/pull/6148


I'm looking here: https://facebook.github.io/react/docs/getting-started.html

And seeing a JSFiddle link that is fully configured to work and zip file that includes all necessary files.

What am I missing?


A generalised hatred for the JS ecosystem, I believe.


the first line of HTML code in that Fiddle link is: https://facebook.github.io/react/js/jsfiddle-integration-bab...

What you are missing is that you probably don't want to develop by putting your code in JSFiddle.


A decent toolchain of various libraries and build tools is an opportunity to avoid bigger problems and nasty, subtle bugs when you are working on large codebases. I continue to have my share of them, which tend to be in areas of the codebases I worked on that is principally jquery spaghetti or undisciplined Backbone code.

I'd rather deal with the dependency hell; that's an opportunity cost. I'd rather deal with my current toolchain than having to tell stakeholders that a particular aspect of bad code is beyond repair and needs to be replaced badly, at the cost of a large time sink.


Submission largely accepted but you aren't making a real point with what you've submitted. I say "largely" because I agree with gp that 2 hours is hardly hell for a larger project but agreed that is pointless for basic/toy applications. This isn't really a solid indictment against React and webpack however. If you are really making a tiny/toy app, and not doing so for educational reasons, then yeah probably you should just use jquery and edit js/html/css (vs ES6/JSX or Jade/SASS + redux, testing, etc, etc which is not trivial).


Yeoman.io is supposed to solve the 'getting started' problem. But the quality of generators varies wildly, so it's hard to recommend.

You could probably build a tutorial around generator-react-webpack-redux.


I would very much appreciate this. Pull requests are welcome. I have been working on some examples, but did not have the time to refine them yet.

Started to implement the Todo App in this branch => https://github.com/stylesuxx/generator-react-webpack-redux/t...


react-cli is pretty good


Any language or environment has it's hoops that you have to jump through in order to use it, in some cases these happen to be installed for you so it's less noticeable.


I have no problem with the article or its goals, but my issue is why is so much configuration even necessary for a "large" frontend JS application?

Why don't we see this kind of configuration hell in other major languages? Look at Python, or Scala, or Go, or even Rust. Do you see projects requiring 10 dependencies just to setup a testing environment? Or having to manually integrate every piece of the build process instead of using pre-made plugins?

We don't even have to talk about the extremely low average lifetime of libraries in the JS world; it's like a perpetual popularity contest!


> We don't even have to talk about the extremely low average lifetime of libraries in the JS world; it's like a perpetual popularity contest!

This is the awful truth of programming in general today. Sadly, it's a train not many of us can jump off of because of employ-ability. If popular tool/framework/language/etc is not on your resume, you're not getting called back. If popular tool/framework/language/etc is not being used by anything in your Github, you're not getting called back.


Definitely true in general, but I think it's more noticeable in the JS world. Look at Java + Spring, C# + ASP.NET, Python + Django, Ruby + Rails: these are all examples of popular frameworks that have been around for much longer than any single JS library (except jQuery), and are all still in high demand.


I believe ASP.Net and Spring predate jQuery.


This is primarily a JS thing. Many nontechnical people that look over your resume don't know that Node Backbone React Angular and the random data visualization libraries are all "Javascript"


What are you doing with python and go that "just works"? Writing scripts? It takes a lot more work to build a yelp clone with python than it does with react.


> What are you doing with python and go that "just works"?

Anything you want. Dependency management is taken care of by a simple `pip install flask`, or a requirements.txt. The rest depends on the packages you are using.

> It takes a lot more work to build a yelp clone with python than it does with react.

And why do you think that? I could build a simple and performant Yelp clone with full authentication, admin access, and persistence using only a handful of Python packages:

* Flask: web app microframework

* Jinja2: view templating language

* SQLAlchemy: database ORM

* Psycopg: Postgres database driver

* Flask-SQLAlchemy: Flask plugin for SQLAlchemy

* Flask-Login: authentication, accounts

* Flask-Admin: administration

Of course, just like in the case of React, you'd need HTML + CSS for styling, and JS in case you'd like interactive elements. And finally, to run the app in production, I'd use Nginx + uWSGI.


> Anything you want. Dependency management is taken care of by a simple `pip install flask`, or a requirements.txt.

And what if I want to use multiple versions of a given library for my development? Suddenly I'm learning virtualenv...


Or, if you want to use compiled code and have it be installable on multiple OSs, conda


Yeah so it's really not very simple.


"My tool that I'm intimately familiar with is easier than that tool that I don't know much about"


Well yeah, it's not really an apples to apples comparison. A Yelp clone written in React lacks user auth, persistence, and admin.


And you will be able to use the same python tools for years to come. Good luck with JS frameworks there!


Well said.

I like programming, I like different languages. Just few days ago I was once again lurking on other languages' sites and forums just to find something new. I realized when looking at other languages that JS has come a far way and now offers so much that I really like JS. I got spoiled and the urge to try, find and need something better has faded.

The language itself made huge leaps with ES6 and the ecosystem is just incredible. I see that fast pace as something positive and the 'JS churn' is relative or rather exaggerated. Node itself is very stable and new versions do not break old stuff in general. Grunt and Gulp got replaced by Webpack, React + Redux redefine UI. That's it, these are the typical examples in mind when people talk about 'churn', not really a lot to be worried about. And these changes didn't happen over night but over years, e.g. the first React version was introduced two or three years ago.

A counter example to churn: Express is still the to-go web app server for many years (5?), it's doesn't have the most modern foundation and other stuff (e.g. http2 is problematic) . I wish that new web app servers like Koa, Express' successor, would gain more traction but that happens only slowly.


I'm a fan of projects like https://github.com/petehunt/rwb

It's a little opinionated but aligns well with the decisions I independently made after spending way too much time on "build tool bullshit". That said, it's a little rough around the edges and development is not very active.


I agree. We've started a project at work that we will maintain for years. We researched the setup for a few weeks and continue to tune it. Once you understand the small components and create a working setup reacct/webpack/babel is much less daunting. This type of article is great when you're trying to ensure you've chosen the most optimal setup for your project yet it isn't for everyone.


There is a nice tutorial which is about building huge application in Ember.js. Totally free and easy to follow. Check it out. http://yoember.com


A large setup cost discourages you from creating many small projects; from creating experiments that may/may not pan out. This is why the browser/text editor flow of development will (eventually) win out. Hopefully people working in these toolchains are at least using some boilerplate projects or generators that cover 90% of cases.


react needs something like the ember-cli


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.


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.


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++.


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


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.


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?


Your examples aren't a front end application though... The tooling alone has a lot of options... same for desktop apps... are you going to go GTK, QT, Win32, some toolkit on top, what tooling do you need to construct your app, will you use an XML to language process? What about build constructs or third party libraries?

Front end applications of any kind of complexity are NOT simple... treating them as toys, and expecting them to grow in complexity doesn't work.


That's an unfair comparison. You are building the whole Ruby dev environment from scratch before coming to Rails. Which is not what is happening in the tutorial. Actually, if you have the typical ruby environment setup already (ruby, rubygems, bundler), then its only

gem install rails

rails new

rails s

You don't need postgres or any JS runtime to start off.


If you were trying to learn Rails (which this story ostensibly is doing with React) you wouldn't have Ruby installed. (or you'd be using system Ruby, which you generally shouldn't use: https://robots.thoughtbot.com/psa-do-not-use-system-ruby)


> If you were trying to learn Rails (which this story ostensibly is doing with React) you wouldn't have Ruby installed

Why? I went to Rails after I learnt Ruby. By that time, I already had rvm installed to manage Rubies.

I can agree that a lot of users jump to Rails without learning Ruby first, in which case the setup will be 4 commands longer. But that is not the case with React as you can't jump over JavaScript to React directly.


And you don't need 80% of the stuff in the article to start off either, this is a VERY in depth walkthrough...


But wouldn't it just be:

* install rails

* run 'rails s'


If you've already setup Ruby, which most haven't if they're going through a similar tutorial for Rails.


Well, Ruby is pre-installed on Mac OS.


I've never come across a single Ruby tutorial or talk or anything that suggests using system Ruby. For many good reasons.

https://robots.thoughtbot.com/psa-do-not-use-system-ruby


It's literally 93 page-downs to the "Hello world"

On the upside, it all seems clear (if somewhat laborious to go through in totality) and I definitely appreciate that the majority of those 93 page-downs were covering setting up testing and a testing strategy + framework. It seems most things of this type are more likely to either say "set up testing" without detail, OR are guides specifically for doing testing without going into great detail about the app being tested.


Huh? The first "hello world" equivalent occurs in the beginning.

https://www.fullstackreact.com/articles/react-tutorial-cloni...


That's the first time he prints anything to screen, but the actual first "Hello world" text is at the beginning of the Routing section where he's just finished all initial boilerplate and testing setup and puts in his first route. Which is a little more representative.

I think it's a good guide btw.


I guess it depends what one thinks is representative of a hello world. His first print out of the literal "hello world" may be down that far, but in terms of "classical" hello world "standards" (just based off what hello world apps have traditionally looked like), the section I linked is more analogous in my opinion. It shows react operational and rendering.

If the bar is a yelp clone (which is already contrary to what a hello world is), then sure, maybe page 93 is more apt. But...you're building a yelp clone.


My thinking was the bar would be "first output after boilerplate setup", in this case immediately before beginning to write any yelp-ish logic.


This is why I'm so gung ho about Elm.

To create a proper React single page app, you need React, Redux, lodash, react-router, webpack, Immutable.js, babel, npm, redux-thunk, isomorphic-fetch, webpack-hot-middleware, and ton of boilerplate and configuration (which everyone does differently). You can try to assemble this yourself, or choose one of hundreds of starter projects on Github.

A comparable Elm app is a lot simpler. It consists of Elm, a router such as elm-transit-router, and maybe webpack if you want to watch and minify your compiled javascript. Especially now with the new 0.17, Elm forces you to use the standard Elm Architecture, so you don't waste any time thinking about how to structure your app and there's very little boilerplate as a result. On top of this, Elm is statically typed, functional, and simply a joy to work with.


I wouldn't put lodash or immutible-js right away, and may gear towards axios as a client communication library.

The reason there's so much to do, is there are so many options... core parts of the tooling for modern js are fairly consistent... node is pretty much required, which brings npm.. understanding CJS and ES6 module syntax also required... a translator (babel|typescript|traceur) are pretty much required, as is a bundler (webpack|jspm+system|browserify). That'ss 1 x 3 x 3 potential configuration vectors without starting the application. Each has advantages and disadvantages... I'm webpack + babel myself.

From there you have React, you need an orchestration layer, which has started to settle on Redux for all but the most complex applications. If you need async workflows, you're probably going to need redux-thunk and a communication library (fetch or axios). Beyond that, it depends on your needs specific to the application. If you need more than one route, then react-router and binding to redux.

Everything beyond that depends on the specifics of your app and needs. There isn't a one size fits all.


I can't recommend Immutable.js enough though, especially as your Redux state object.


I agree it's useful... however, it's far from a requirement if you're using React+Redux. Though there are some workflow changes if you are using Immutable.js with Redux. It's also the size (min+gz) of preact + redux combined. While still relatively small, depending on your needs it all adds up, and it really should depend on one's specific needs.


I've no doubt Elm is simpler (considering it's more vertically integrated), but to be fair, if webpack is a maybe in Elm, lodash, immutable, isomorphic fetch, and webpack-hot-middleware would definitely be on my maybe list for React. Maybe maybes would include redux-thunk.


Vertical integration plays a part with blessed libraries for rendering, routing, and requests, but it's not just vertical integration: Elm completely obviates Immutable.js, TypeScript, Reselect, Redux-Thunk, and Lodash/Ramda by virtue of fundamental language design choices. The same goes for Haskell, OCaml, and PureScript. In that context, Redux becomes a design pattern, rather than a library.

Ultimately, it feels like React's best practices and associated libraries try to bludgeon JavaScript into acting like a functional, immutable language. If that's the right model, I'd rather just use a language that was intentionally designed to be functional and immutable from the start. :)


Can you embed an existing js app (angular) with Elm? Doesn't need to be any real communication between them. Just have the Elm app decide if the angular app is displayed or not. Honest question as I'm embedding angular in react at the moment and there's quite a lot of library fatigue going on.


Yes, this is possible. Angular and Elm could easily communicate through Elm's JavaScript FFI.


If you want to put together an Ikea chair, everything is in the box and the instructions are two pages long. If you want to put together a chair from scratch then you need the wood, hammers, nails, saws, a lathe, sandpaper (in multiple levels of coarseness), glue and a number of other tools. React is a lathe in this example, it's hard to put it in context without the rest of the tools but that doesn't make it complex.


This is a pet peeve of mine when it comes to React tutorials. Why waste so much time making the user set up a dev environment? Just give him/her a prebuilt and "black boxed" environment and get on with learning React (what they actually want to do). I've seen plenty of people give up because they couldn't get their webpack set up right.

Also, for those making courses, consider just using browserify. It's much easier on the newbies.

> I'm not blaming react, everything else in the javascript space is just as bad right now.

Not Ember! A great example of a blackboxed, prebuilt build system that gets out of the way.


>>This is a pet peeve of mine when it comes to React tutorials. Why waste so much time making the user set up a dev environment? Just give him/her a prebuilt and "black boxed" environment and get on with learning React

And yet one of the most common criticisms of Rails is that it's too black-box and has too much "magic."

So you're damned if you do, damned if you don't.


Rails is the actual framework. I can see why someone would hate the magic happening under the hood when attempting to get something done in Rails. When it comes to React, we're talking about the dev environment. I would love never having to configure webpack by myself ever again. Something like the rails scaffolding command would be excellent for working on React apps. I believe Ember has ember-cli to do this.


I think this is somewhat of a deceptive trap that people fall into. It's difficult to trial something like React unless you set up all the tooling around it, so Ember appears easier because it is blackboxed and sets things up for you.

However, that means that six months in, when your app has outgrown the constraints of the blackboxed starter, you are trapped.

There is absolutely more of a startup cost to something like React and that makes it hard to evaluate its fit for your project, but I would suggest it pays ridiculous dividends to understand the stack you're going to have to maintain for the next X years instead of having it hidden away from you.


You will find that Ember and Ember CLI are built on top of well-architected primitives; it's not that these things are hidden, it's just that understanding them isn't required to get started.


Seems like poor punishment to downvote Tom here. At the worst he made a blanket statement without backing it up, which is the exact same as what he was responding to.

> I think this is somewhat of a deceptive trap that people fall into. It's difficult to trial something like React unless you set up all the tooling around it, so Ember appears easier because it is blackboxed and sets things up for you.

> However, that means that six months in, when your app has outgrown the constraints of the blackboxed starter, you are trapped.

I have not seen a single company outgrow Ember-CLI. Imagine for a moment a big company with a huge app- Yahoo or LinkedIn or Twitch. These companies have apps that push the limits of Ember-CLI for sure, and have delved into the internals to add cutting edge features like lazy loading or optimized module loading, however none of them have abandoned it after six months.

Ember CLI has a public API for making changes to your build pipeline. Advanced users often reach for direct manipulation of Broccoli trees, another open source documented API with lots of example usage floating around. The "black box" referenced is non-existent. Ember-CLI is more like a car with a good manual. You don't need to understand fuel injection timing to get it out of the garage.

And Ember-CLI is fast. Out of the box it has great performance on Windows, Linux and OSX and there is even more room for improvement. Six months down the road, you will not find out it takes five seconds to rebuild your app. It will still be sub-second.

> it pays ridiculous dividends to understand the stack you're going to have to maintain for the next X years instead of having it hidden away from you.

We share software (proprietary or open) because it spreads the cost of maintenance. As a web developer I have plenty of work already, maintaining my own build pipeline is no more desirable than maintaining my own rendering engine or my own operating system. We always solve problems atop a certain level of abstraction.

Ember-CLI is the result of a concerted effort by individuals and the community that started in 2013. The project is clearly a massive success, demonstrated by its overwhelming adoption by Ember users (well over 90%, it isn't that popular because it sucks). It is a disservice to Ember-CLI to blow it off as "not scaling past six months" and to yourself as a developer to disregard Ember-CLI's hard-won lessons about how to build a good common build pipeline.

tl;dr please don't presume Ember-CLI is flawed because it "appears easy", making the hard look easy is a worthy goal.

[edit]: formatting :-p


> 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.

I'm writing a tutorial right now for testing AngularJS and this is exactly what I'm running into. It's a tutorial but half of my first part is "install this, put this line in this configuration file, install this, add this one here, etc." It's easy to feel like I'm not writing a good tutorial but really that's just the current state of JS development.


I'm way out of my league, but would it be possible to distribute a Docker container with all the boilerplate? Tutorial users could run that at the start, then do the "fun stuff".


The real gut punch is many parts of this tutorial will probably be obsolete within six months. Fast forward a couple years and this will look like the equivalent of "Backbonejs tutorial - Step 1: bower install requirejs".

Sometimes I feel bad complaining about this. Things are evolving fast for a reason. Everyone is trying to make every part of this process better. The backbone joke above illustrates the point. Would you go back in time and freeze the evolution just to regain sanity for today's devs?


I also share your frustration.

I am learning react. A few weeks ago I wrote a small app and based my work from a starterkit with a few thousand stars on github. I learned a lot from this app and the starterkit.

This week I decided to use what I learned at work, writing a small app that will be used only internally. When I cloned the same project at least 15-20% of the project was different.

Not just is a pain to set up a project but it's also changing very fast.


I feel the same frustration even though I am still at a point where I generally have a huge tolerance for this kind of stuff.

Slowly, however, things seem to be improving.

For one, Redux seems to be the preferred 'flux implementation'; that's an improvement over the countless implementations I had to choose from when I started about a year or two ago.

Then there are Rich Harris' Buble[1] and Rollup[2], which provide respectively batteries-included ES2015 transpiling and module bundling, and probably a bunch of other projects I'm not aware of that provide some sort of standardization or simplification in this process.

It's not happening as fast as I'd like, but it seems to be a move in the right direction.

[1]: https://gitlab.com/Rich-Harris/buble [2]: http://rollupjs.org/


Screw this, use Meteor to build React apps. It's super smooth, no BS, and integrates everything that sucks about Javascript development into a cohesive Omakase package.


>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.

Personally, I got so frustrated with ever-increasing complexity of tools and growing networks of dependencies that whenever I can I try to package my JS code in self-contained modules/files that depend on nothing -- not even on one another. Needless to say, it's not an approach that's very popular, but it works remarkably well for websites of moderate complexity. One thing I'm sure of: using those modules feels far more satisfying than using a framework.


Sounds very anti-DRY, though I get where you are coming from.


As far as DRY, the worst aspect of no-dependencies approach is dealing with AJAX. The rest of it is actually not that bad. After some experimentation, I separated the functionality into "behaviors", which are fairly reusable across different pages and projects.


Completely agreed. I had the same frustrations when I was looking at things like meteor, angular, etc and I definitely got that vibe when I saw this page. And I am saying that as someone who has already built websites with React.

I really don't know that it needs to be (or feel) this complicated If it's a React tutorial it shouldn't require people to navigate through Karma, Webpack and Postcss, not least of all because they may already be comfortable using perfectly serviceable alternatives.


> the same frustrations when I was looking at things like meteor

The main strength of Meteor is the speed you can get up and running

  $ meteor create my-app-name
  $ meteor npm install
  $ meteor
will set you up with a full stack application, running locally, with zero config


The thing is with Meteor I feel like I have to learn ALL of meteor to really expand/extend upon what it gives me or use some plugin, it feels like it takes away way too much control for me.

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

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.

Angular and Meteor try to do too much, this is why react is winning the framework wars.


> I don't feel like I have to re-learn everything I know about web-dev when using react like I do with Angular.

I find it odd that you feel that way given nearly every React tutorial absolutely does do things the "react way" including using mostly the same toolset.

Things like Flux, GraphQL, "Higher-order components" are not general web-dev knowledge you already have. React has it's own language, as much so as any other framework I've encountered.


Fair point, recent updates to Meteor (1.3) have made it much easier to use with the rest of the JS ecosystem (e.g. using react with meteor is as easy as using the default view library).

The reason you have all of this boilerplate setup with react is because it's only one small part of the equation, so you need to use and (ideally) understand a bunch of other libraries and tools to build something, hence these epic tutorials.


You could def skip some of these steps though. Postcss seems like solution without a problem imo. Sass seems a bit saner. And you can skip the tests for most projects.


Is Angular2 any better in terms of dependency hell since it provides a full stack front end solution?


> I'm not blaming react,

No, React is particularly bad here. RactiveJS for example can be used in a minute: http://www.ractivejs.org/60-second-setup


Concision is an art-form. In clojure I would do:

* lein new figwheel hello-world

And done. Say lein isn't installed, it is a simple script you download and run once.


>I'm 30 screens down (literally 30 page down presses)

If this web page were a book it would be about 30 pages.

What framework is there that allows you to build full scale web-apps in less time?

Certainly not Angular, an Angular tutorial would be at least twice as long and you wouldn't even use half the features of Angular.

Meteor? Sure, but meteor isn't a good choice for people who need a lot of control of what's going on under the hood.


This was the first thing I noticed as well. 40% of the tutorial is setup. It doesn't HAVE to be that painful just to get a working environment going, but it gets painful pretty quickly if you pile on Webpack and PostCSS and a testing setup and everything.

For true "Hello World", if all you just want is to play around with React without all the setup, try out quik[0] or react-heatpack[1]. I also wrote up a tutorial[2] using react-heatpack that gets a working Hello World in UNDER 3 page-downs :)

[0] https://www.npmjs.com/package/quik

[1] https://www.npmjs.com/package/react-heatpack

[2] https://daveceddia.com/test-drive-react/


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.


I feel this way about Node and React sometimes but I'm not sure other environments are necessarily better. In a way the fact that you can do all this in a bunch of text files is pretty elegant. Is installing and configuring Apache and PHP with a bunch of modules that much easier, or does it only appear easier because of apt-get, a2enmod, etc.?


I'm interested about why you mentioned Node—aside from the occasional silliness of npm I find it easy and quick with minimal to no boilerplate.


What people refer to as boilerplate for setting up React, including in this article, is about installing and configuring node modules, build systems and other tools. React itself is just two modules (React, React-DOM.)


Got it. Thought you meant just Node. Thanks for clearing it up.


You don't need all of them to create a modern js app. I use just browserify and watchify with node scripts under package.json. Simple to copy and modify for new projects.


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.


React itself is a view library with a very small learning curve and narrow API. You can view all the documentation on their website. It's about 5 pages. This has nothing to do with Facebook's scale and Facebook didn't design this complexity.

Webpack isn't React, Redux isn't React, ES2015 isn't React. They're commonly used with React and add complexity to both your architecture and build step, but you're not required to use them.

This tutorial is getting a lot of negative replies because it's a tutorial on all those other things in addition to React. It takes 90 pages before you write React code because the author spent a lot of it explaining how Webpack configurations work.


Are you trying to say that if you are building a simple web app you should be building a server-side rendered web app using Rails/Phoenix?


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.


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.


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.


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


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.


I disagree. React it's self is very simple. It's web development that is complicated. Other frameworks that try to do everything like angular are also complicated for the developers. The frameworks that do everything and are easy to use (like meteor) don't offer the extensibility of the more bare bones frameworks. Any web site that wants to grow needs a full control of the stack.

Of course, if all you're building is a static web page then I can see just using some HTML and CSS. But if you want to work professionally as a web developer then you need to know javascript and at least one major framework. You can not stay employed as a "full stack dev" if all you do is write an a couple HTML and CSS files and serve them with python httpSimpleServer.


React is complex because there are realms of new things you can do with it that you couldnt do before in a web app, and the best version hasnt been found yet.


React is just for view layer. Its not much complex. Its simple enough to add to normal pages let alone SPA.


Shouldn't stuff like this be as easy as cloning a bootstrap, npm install and go?

I'm an acknowledged novice but I find "modern" web development to be completely insane.


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.


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.


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.


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.


You should check out http://mithril.js.org/.

It's been around for a few years, it's very lightweight with a small API, not opinionated, and surprisingly powerful. It doesn't have all the wiz bang gadgets right of the box, but it provides the fundamentals you need for a well designed, full-fledged frontend app.

I've enjoyed using it a lot the past few months on a few small projects, and I'm also using it for a larger project that I've just started working on.

Oh also, I haven't even bothered with a build tool or anything yet (I find the current js build tool landscape rather dismal). Turns out it is surprisingly easy to get by with <script src="..."> lines into index.html for smaller/mid-sized apps =) The only thing I've really missed so far is SASS.


This isn't mainstream; it's barely behind the bleeding edge. Mainstream is Express, Angular 1.5, and Browserify, and you can have it up and running in five minutes, maybe fifteen if you don't have Node installed.


Can you post one of your projects?


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?


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!


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.


> 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.


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.


Nifty! The config needed some fixes and tweaks (using `babel-loader`, `<MyRootComponent/>`, a `resolve` section) before it actually works out of the box, but it's a nice idea. I made a `git clone`:able version of the setup with fixes and a `Makefile` at https://github.com/johan/make-react-hack


Out of curiosity, why did you write the function like this:

   const MyRootComponent = (props) => {
When it's shorter and more obvious what's happening if you write them like this:

  function MyRootComponent(props) {


"An arrow function expression has a shorter syntax compared to function expressions and lexically binds the this value (does not bind its own this, arguments, super, or new.target). Arrow functions are always anonymous."

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...


Why do you want it to be anonymous in this context? I get you can drop the `return`, but I don't see how you gain anything (apart from a tiny reduction typing and a small increase in incomprehensibility) by using anonymous functions to define components (I know the pattern is used a lot in the wild, but there seems to be zero reasoning for it; lexical binding isn't really relevant here)


In this case: You're potentially closing over node's "this inside of module body === exports" which seems more confusing than helpful..?


None of which, in this context, matters; none of those is in scope where the function is defined, so it won't be closing over them anyway.


Yep, that looks much cleaner and easier to reason about. Thanks for the sample config file.


1. you don't need them all, but for using the latest ES future spec and ideas and hot reloading they are needed. es2015 : to use ES6, stage-0: all babel plugins: async/await, 22, trailing comma a(1,2,), spread {1, ...a}, and more : http://babeljs.io/docs/plugins/preset-stage-0/ the react plugin is to transform the JSX syntax <component/>, and react-hmre is a preset for hot reloading.

2. we need webpack to bundle the js, jsx, css, images if they are small or use them as asset if they are big. With Gulp you have to re-create painfully what webpack already offer. Webpack is declarative configuration, gulp is complex plumbing.

3. Webpack is powerful, but i am pretty sure the average webpack config file is way less the size of gulps files.

4. PostCSS is more powerful and can strongly link your postcss and component class without having to invent a complex and tedious naming style.

5. PostCSS make terser and safer css.

6. this is exactly the use of plugins for webpack.

7. because you want to have a dev and production mode, in dev mode react test lot of thing like properties type and invariants, you don't want that in production mode because it slow things. Also if you want to make different variants of your project, webpack can at compile time use those env variables to remove some functionalities just put an if (env.CLIENT === "bigcorp") {...} and webpack with the help of uglify will remove or add the code in the then part.

8. each lib has a reason and is orthogonal to one another.

9. to load an asset json file as a parsed JS object with the syntax like you would import a module. very useful.

10.-> 13. webpack is used for all assets and to find the tests and to present them to mocha et al.

lot of them a dev dependencies it means you can deactivate them and still ship your product.


Wow, thanks for going through them one by one!


I completely agree with you and this is a large part of why I simply avoid Webpack, Babel and other, similar tools. Yes they can be useful but they are completely unnecessary. Yes I said it.

Everyone wants to get into the latest and greatest ASAP and this completely disregards the entire project. I would love to use EMCAScript 6 too but you know what? I don't want all the additional dependencies of babel, the configuration and the setup to run my code through it constantly just to test my code. I will wait 5 years when it's available enough on the client machines that I work with and then I will use it.

Sometimes I feel like the "old timer" complaining about all the new wizbang things but at the end of the day I don't even care because my build will run, with minimal dependencies, out of the box after cloning the git repo. It's reproducible. It takes seconds at most and it's debuggable without trying to figure out how to use source maps inside of chrome.


> 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?

This tutorial is trying to guide you over the initial hump with the tooling by letting you hit the issues you'd hit if you were learning it on your own (like dependencies which need tweaks to your Webpack config to work properly like sinon, enzyme, moment...).

They _could_ have handed you a completely pre-baked config and got to Hello World in step 2, but you wouldn't have learnt anything about the tooling.

In terms of a development library you depend on being abandoned or broken, I've extracted my React development environment out into a separate npm package [1] and it's still using Babel 5, auto-prefixer loader (which is deprecated in favour of using PostCSS directly) and is working around every version of babel-runtime v5 after 5.8.29 containing a broken version of an important module. By pinning your dependencies, you can keep using old or deprecated versions of things until you're ready to upgrade, and by managing development tools in an external module you can upgrade your projects when you're good and ready by bumping a version number.

If you do that, starting a React project (or any other project which gets tool-heavy for apps of any size) can be a 1-step proceess you can have an understanding of the tooling, and you have a way to keep it manageable over time.

[1] https://github.com/insin/nwb#nwb


I am not a front end dev so this is a serious question.

The new shiny seems to be using dependencies straight from git and vendoring them.

Presumably new versions come out because they fix bugs or security issues.

How do you keep your projects up to date? Do you manually check every dependency in your project once in a while? Do you have some automation which alerts you to security issues in a dependency of yours?

If you decide you need to stay on an older version, is someone backporting fixes?

Is there a curated set of packages that are known to work together?

When an update comes in, do you audit it to make sure nothing malicious makes it on to your systems?

Or does one have to wait until this stuff stabilizes and baked it's easy into linux distributions before one gets these nice features? (Which basically isn't easy to do with how fast the landscape is evolving).

I'm curious about solutions to these problems.


> The new shiny seems to be using dependencies straight from git and vendoring them.

That's news to me, it's all npm and node_modules/ as far as I can see.

> How do you keep your projects up to date? Do you manually check every dependency in your project once in a while? Do you have some automation which alerts you to security issues in a dependency of yours?

You can get https://greenkeeper.io/ to watch your project and its dependencies - it creates Pull Requests to update dependencies with details of what changed in the description, and all the usual PR stuff like running whatever CI you've configured happens as a result of creating it.

If I don't have Greenkeeper set up (the PRs can get a bit noisy), I just run npm outdated --depth=0 any time I'm poking about in a project.

> If you decide you need to stay on an older version, is someone backporting fixes?

Depends entirely on the maintainers of that project. Babel 5 has had a couple of things backported, like support for Flow annotations, for example.

> Is there a curated set of packages that are known to work together?

Not curated as such, but you can just look at what people are successfully using and sharing, and tools people are creating. nwb is effectively my own curated package of development tools pre-wired together.

> When an update comes in, do you audit it to make sure nothing malicious makes it on to your systems?

I usually check the diff between the release tags/changelogs between what I'm updating to before, but not specifically security auditing.

> Or does one have to wait until this stuff stabilizes and baked it's easy into linux distributions before one gets these nice features?

That's not going to happen :)


There are simpler ways; I don't mind webpack, I just find it hideously over complex at times; if a large % of React tutorials preface the part you want to read with long, differing, detailed explanations as to how to set Webpack up, I think there's something wrong. Brunch works well, for example this is simpler:

    npm i -g brunch
    brunch new myApp -s react
    cd myApp
    npm start // server starts on port 3333
That's just basic react app (here's an idea, why not add incrementally as things are needed???). Brunch doesn't do hot reloading ATM, but otherwise it Just Works, and is deployable and very extensible based on need.

So normally I'd go nuts and put sass, JS' staging features, a test framework in for dev. And redux, a router, immutability for the app. But only the bit above this paragraph is needed to get started with an app, not a toy, pretend one, an actual app. v0v

    npm i --save-dev sass-brunch ava babel-preset-stage-0
    npm i --save  redux react-router immutable some-other-shiny-react-library


(Warning: shameless self promotion ahead)

I wrote parched-tasks-webapp, heavily inspired by Brunch, but built on top of gulp and browserify. It does have hot reloading.

Say you want to build a font from .svgs:

    npm install --save parched-webfont
    mkdir -p app/assets/glyphs/
Now you'll get an icon font from any SVGs in that folder.

Here's an example app to try out: https://github.com/bravenewworlddev/parched-example-app


Brunch looks pretty cool actually.


It's been around for ages (2011), and I still don't think anything else has it beat in terms of 'get developing an app immediately'. It hasn't really got any magic, and yet it mostly just works out-of-the-box without any configuration. Some of the stuff surrounding it is a little out of date (for example, the Sass package is a bit flakey at times, though that can generally be fixed by just blowing away node_modules and `npm i` reinstalling), but it's used as the frontend build system for the Elixir web framework Phoenix, so it's been getting quite a bit of TLC recently.

It also only got proper, inbuilt NPM support near the end of last year (though that can occasionally be flakey), which I guess is one of the major reasons it hasn't had a lot of love vs Webpack, or Grunt/Gulp (w/Browserify) prior to that.


Exact same feeling here, well put. I recently started Tyler McGinnis' excellent React.js Fundamentals and the entire first section of the course is setting up Webpack, Babel, etc. Once you're set up there, then you need to decide how you'll handle routing, AJAX - and so on.

The older I get the more I hate third party dependencies. You're asking for trouble.


Check out DoneJS which gives you everything you need: https://donejs.com/Guide.html

  donejs add app my-app
  cd my-app
  donejs develop
A full environment with hot module swapping included, code-splitting for production builds, etc. No configuration required.


I might look at that for my next frontend project. Thanks for the link.


To reiterate the top comment up above, the idea of this tutorial is to explicate everything a front-end dev might need to know. Furthermore, the tutorial is deliberately throwing in wrenches here and there (problems with loaders and such) in order to convey "how might one approach a similar problem".

You're absolutely correct that most of this is, strictly speaking, unnecessary to get a basic React project off the ground. But one idea I don't think gets credit from folks not actively involved with front-end development is that medium-to-large scale front-end developers have very few choices regarding the runtime environment of their code- especially at B2C companies. Your scripts have to eventually be Javascript, and your stylesheets have to eventually be CSS. It's incredibly tedious to write reams of this stuff in a way which works across browsers. Moreover, libraries which abstract across browser differences (like jQuery) need to be transmitted to the client, and eat up runtime.

If you're looking to just hack around with this stuff, try just using one piece at a time. It's relatively easy to just `npm install --save-dev babel-cli` and use it completely independently of Webpack- just letting it happily do its transformation thing.

1. Babel "presets" are basically just individually-packaged sets of syntax transformations that Babel can uses to transpile your code into ES5-compliant Javascript. If you don't give it a preset, Babel will happily transform your code into... exactly the same code. If you give it the ES2015 preset, it will transform ES2015 syntax constructs into equivalent ES5 constructs. If you also add the JSX preset (as is common in React projects), it will convert JSX syntax into the corresponding React function calls. For instance, <span className="hello" /> would be converted into React.createElement("span", { className: "hello" }). Various other presets apply other transformations, but the general idea is to allow developers to begin using language features in their codebase which don't have full support across browsers.

2. The thing with Gulp is that it's a great general-purpose Javascript build system, but its primary use case became transpiling and packaging assets for single-page applications. Integrating these build steps into a pipeline tended to be frustrating- there was a disconnect between what people wanted to do (I just want my assets transpiled, compressed, and bundled, kplzthx) and what they had to implement to do that (writing and wiring up Gulp tasks). Webpack kinda turns that on its head- it implements bundling via its various plugins.

3. Because this tutorial is using a lot of Webpack loaders, and until you kinda grok loaders, it's going to be unclear what's going on.

4. From my understanding (which is admittedly rather limited), postcss is very similar to babel: the idea is to allow you to transpile different syntaxes into "standard" CSS. The analogy goes sort of like "sass/less : postcss :: coffeescript : babel". Again, it's a power tool. Personally, I use Webpack's sass-loader, because I already know SCSS pretty well and I haven't had the time to really look into postcss.

5. How much CSS wrangling have you done in your career? Lemme tell you, CSS can be a massive pain to deal with once your app reaches a certain size, and that can't always be managed fully by methodologies like SMACSS. These are power tools which (are intended to) allow front-end developers to establish some amount of control over a language that's interpreted dozens of different ways, depending on the browser it runs on.

6. That bit did seem slightly extraneous- although I do appreciate that part of the tutorial is going into detail about how I might finagle Webpack to do exactly what I need it to do.

7. Because the output of these tools needs to be different for development vs. production. A comparison in systems languages might be building a C program at low optimization levels and with debugging symbols during a development build, and then a highly-optimized version during a production build.

8. Yes, so many libraries. Other languages (for better or for worse) have extensive testing frameworks, but fully testing web applications also requires means to simulate a browser so you have a good testing environment in the first place. Remember, this is a tutorial for a large-scale web application- automation and consistent testing is crucial unless you actually like paying tons of money for a bunch of QA engineers.

9. All this does is transform pure JSON files into Javascript modules. Literally, this all it does: "https://github.com/webpack/json-loader/blob/master/index.js". Any time you see a loader, what you're getting is a transformation from a source format into a Javascript module (which webpack then compiles into its Javascript bundle).

10. See 8.


Dude thanks for taking the time writing such a detailed reply! I wish I could give you more than one upvote..


Totally! To tell the truth, I actually really appreciated that you started your comment off with a complimentary tone, even if you had your frustrations about the tech. Small bits of positivity go a long way. :)


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.


> 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?



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.


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.


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.


The problem is that there isn’t really such a thing as an “idiomatic React app”. React is just a view-rendering layer with a small API. You have to put together all the other pieces of your application stack…



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.


The way you're talking suggests you're not a JS developer, so I'm discounting your opinion on JS topics to zero.


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.


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


I like it. Thanks!


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.


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.


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.


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...


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


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


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? :-)


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


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/

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.


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".


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.


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?.


I'm not sure about "large applications", but agreed about "data that changes". It's definitely not like dropping in a library like jQuery to spice up some interactions on a webpage.

I wrote something about the 'Why' of React (with some related links that talk more about it): "Interface from Data... Rendering views as a function of state." https://medium.com/@firasd/interface-from-data-using-react-t...


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.


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.


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.


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.


only thing left for Meteor is the release of Apollo !


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.


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

https://github.com/nanote-io/nanote-web

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


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


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


What makes you say it failed?



Sure- that's the article I was thinking about when I mentioned that it faltered. It still has quite the dedicated base, and with 1.3, has corrected many of the complaints (npm support, etc)


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.


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.


Webpack isn't like Gulp at all. It's absolutely insane what Webpack can do. It can solve any asset-related problem imaginable. Compile SCSS into CSS into JSON and require it in your Javascript? Convert SVG images into data-URLs that work on all browsers? Manage async dependencies in your JS code without dynamic script tags or global variables? Automatically figure out exactly which assets you need on which page and chunk them all together? All of the above.


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


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


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...

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


With gulp you rewrite webpack in every project. no thanks.


Webpack is amazing. You can even use Gulp with Webpack. Both are not identical tools.


I just discovered brunch and it works well for me.


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?


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


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.


I don't understand what people are saying, the basic Hello World App is right here: https://www.fullstackreact.com/articles/react-tutorial-cloni...

Like 1/15th of the guide down.


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.


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


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.


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

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


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


This is really great, thanks for posting!


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


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.



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


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


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


That was what I thought :)


All of that, for that simple demo...



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.


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/newswelcome.html

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


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.


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

http://intercoolerjs.org


More tutorials coming up soon: cabin.getstream.io


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


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 :)


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




Applications are open for YC Summer 2019

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: