React Tutorial: Cloning Yelp

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

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.

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!

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.

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.

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.

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.

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.

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.

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.

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

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/

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.

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.

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

* lein new figwheel hello-world

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

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.

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/

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

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.

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.

  $ 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

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

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

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

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

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.

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.

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

    npm i -g brunch
    brunch new myApp -s react
    cd myApp
    npm start // server starts on port 3333

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

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

  donejs add app my-app
  cd my-app
  donejs develop

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.

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?

https://gist.github.com/danawoodman/9cfddb1a0c934a35f31a

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

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.

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.

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)

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.

http://intercoolerjs.org