Hacker News Reader

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.

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

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

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.

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

> 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

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