Hacker News Reader

Comment by minimaxir | Hacker News Reader

As an aside, I hate the official React tutorial and am disappointed that there are no revisions to it with this significant redesign and React version update. It is the embodiment of the “how to draw an owl” meme, requiring you to have a strong JS frontend background in the first place, and the resulting demo application doesn’t give much insight in how to use React for standard websites. (Unfortunately, this isn’t unique to the official React tutorial; many React tutorials are like this)

Contrast with the official Vue.js tutorial (https://vuejs.org/v2/guide/), which goes through things step by step with normal HTML syntax.

View on HN

As the person who designed most of the tutorial, I'm sorry to hear this. My goal was to give people practice building a few simple components and connecting them together.

It's true that we assume preexisting JS knowledge, but your other point about how it doesn't give much insight into using React is one I haven't heard before. Can you say more about what you mean?

Anecdotally in my experience, most people seem to find the tutorial pretty helpful, but we can think about more options. Maybe there's space to add one that assumes less about JS. (And really -- thank you for complaining about this, or else we wouldn't have known.)

This is probably just me and feel free to disregard if this sounds silly, but I really wish miss the getting started guide from a few years ago that (iirc) had you drop an include statement in and go.

I feel like React expects me to have a deep knowledge of JS build tooling when all I care about getting started is building a page locally that works and does cool things.

FWIW this is how Vue's tutorial starts - and another really nice thing they do is teach you the API by entering things into your console on their tutorial page full of components.

I don't really know if this is constructive or useful, I hope it is - I just feel like React expects a lot of new users in a way it didn't used to.

Thanks! I agree the simplicity is compelling. Our Getting Started page does offer CDN script tags as an option but it's seemed like create-react-app is a better tool for most people getting started on a new app so we've had that more prominently.

The tutorial asks you to either use CodePen (which requires no build tooling) or Create React App (which requires you to run a command in the terminal but then you don't need to configure anything):

https://reactjs.org/tutorial/tutorial.html#how-to-follow-alo...

Similarly, the installation page offers you to either download a single HTML file, or to install a CLI that gives you a project that's ready to go: https://reactjs.org/docs/installation.html

Could you clarify what give you an impression that you need to have a deep knowledge of build tooling to follow along?

Hey Dan, I really appreciate you responding here - I know things like Create React App have come in the past couple years, and that people love it - I'm not trying to take anything away from what you've built. I know the way I learned React isn't how anybody is ever going to make anything production quality.

I'll try to clarify. If you don't mind another comparison to Vue, their equivalent page: https://vuejs.org/v2/guide/ says "Or, you can create an index.html file and include Vue with: <script src="https://unpkg.com/vue"></script>", while your get started page says "If you’d rather use a local development environment, check out the Installation page." I know, if I click there it'll say I have an index.html and I know I shouldn't do it that way, but if I have none of the infrastructure on my computer and I want to build my thing on my computer, I'm looking for the script - not installation instructions.

On that 'how to follow along' page, under prerequisites it says "Note that we’re also using some features from ES6, a recent version of JavaScript. In this tutorial, we’re using arrow functions, classes, let, and const statements. You can use Babel REPL to check what ES6 code compiles to.". If this was the first React tutorial I ever looked at I'd be completely lost here and concluding I don't understand the prerequisites. If I know anything about 'relatively new' things in Javascript or Babel then I assume that I'm expected to use it somehow to actually use those relatively new things in my browser, but I have no idea how.

Also, scrolling down a bit, "if you prefer to write code in your editor" is a list of 6 steps, one of which is installing Node and another is "Follow the installation instructions to create a new project." I might not need deep knowledge, but this feels like a lot of stuff to do to follow a tutorial in my editor.

Here's my story about the old, do-it-all-locally tutorial: I'd just started an internship, and got a brief about doing some dynamic UI generation from schemas in .net stuff I'd never used, and was meant to be designing a schema to use. I had no idea what that should look like, so I learned React with your old tutorial and within a few hours could iterate on a schema to build UI components like theirs in the browser. This was amazingly helpful to me, and looked way more impressive than it actually was when I showed the boss! I just doubt that I'd do that based on your current tutorial, because I'd be on a Windows machine and get hung up installing NPM or something silly.. and that feels like a shame to me.

Thanks for sharing the concerns. It's a bit of a tough balance. For example before we mentioned the prerequisites like understanding ES5 and basics of ES6, people were complaining that we don't make the assumed knowledge clear. Before we used ES6, people were complaining our code doesn't look like the ones they see in examples and docs for other libraries. Et cetera. Somebody always is upset, although maybe we're just doing a bad job. :-(

We do offer an HTML file to download that you can tinker with, but only on "Installation" page rather than the Tutorial. Maybe we can unify them somehow.

Overall, it's frustrating that people tell us about these issues once a year when we release something, instead of raising an issue and discussing it there. :-) If somebody told us on GitHub this is a problem, we would have fixed it a long time ago.

I agree it's a tough balance, and I definitely wouldn't say you're doing a bad job, I hope I don't come across like I think that you are!

I appreciate that frustration, I didn't raise this as a Github issue because it didn't feel actionable and I don't want to spam all your maintainers with a complaint without having something more concrete to suggest. I'll try to put something together though if that'd be useful :)

Dan, it might be worth throwing in links to CodeSandbox/StackBlitz/WebpackBin somewhere obvious in addition to CodePen, since each of those are online IDEs oriented towards working with React.

I wish there was a link to the old tutorial

I've used React occasionally for a couple of years. I just blasted through the tutorial in 10 minutes to refresh my knowledge and check if any best practices changed in the last year or so. It was perfect for this.

As someone who has been learning React for the last couple of days, I found the tutorial quite adequate. My approach to learning was first going through the tutorial, then I began working on a real project, revisiting the tutorial code every time I needed to refresh my memory about some concept. I do agree it could've been more comprehensive and dealt with some real world scenarios like inputs, data-binding and whatnot, but generally speaking it was a nice showcase of what React can do.

Thanks for replying. With respect to the insight in using React, I assume that the majority of React users are using it to build websites/SPAs, with concerns such as client/server data flows, templating/styling, and URL routing. While the tutorial does demonstrate a good demonstration how React works, it doesn’t provide much practical knowledge for building websites, and worse, doesn’t provide info on how to start building a website. (which just leads me to look at another tutorial)

Yes, it's intentionally not aimed at teaching SPAs, but teaching React itself. FWIW a lot of apps built with React are not SPAs.

I agree though that there is a niche for the other kind of tutorial you're describing. :-)

>it doesn’t provide much practical knowledge for building websites

That shouldn't be its purpose.

They tried to add routing to to docs/tutorials. react-router devs hijacked the effort, ground it to a halt with claims of copyright to their code, and the pull request to docs got rejected in the end

Link?

Relevant comment is here: https://github.com/facebook/react/pull/8848#discussion_r1055...

Full pull request is here: https://github.com/facebook/react/pull/8848

As a result one of the React contributors ended up apologizing to react-router https://github.com/facebook/react/pull/8848#issuecomment-285...

I think "requiring you to have a strong JS frontend background in the first place" is NOT a bad thing. People really should be learning the basics before diving into using a framework. Unless, of course, the goal of ReactJS is to give non-JavaScript developers access to application creation. But I suspect not.

EDIT: missing the "NOT" in my opening sentence.

Ideally the goal of a tutorial is to give an idea of the basics before diving in, and to properly assess the skill level necessary to take the full dive into a real application.

I think the tutorial is awesome! I made an ironic comparison between it and the status quo in the industry

https://news.ycombinator.com/item?id=15367480

(I think people didn't get it.)

Good job, fantastic. Don't let the parent complainer get you down, you really nailed it. There's a reason everyone uses React and you're a large part of that reason. Kudos.

It's been a year or two since I did some rails, but what I vaguely remember as uncomfortable was the lack of something like guidance on the "project-level". I could never figure out which components to pick for the stack, or even where to place certain types of files.

I know most of that isn't really react's responsibility. It just happens to inhabit this sort of central position within today's JS that people look at it for guidance.

I'll be stoned here at HN for saying this, but I always considered Rails to be the high-water mark in terms of standardisation: with some experience, you could join any project and were already familiar with the folder structure and many other conventions.

I think there's something like a "React Starter Pack" project now that seems to do exactly what I was looking for last year: a set of known-good components, (pre-)configured, tested, and with the virtual stamp of approval from people who know more than me.

Yeah, the React team has really tried to avoid "blessing" any specific tools or approaches, for several reasons. Facebook uses React in certain ways that are different than the community, and the community is doing a lot of different things anyway.

CRA helps with getting started by providing an opinionated build setup, but leaves the entire rest of the application structure up to you. Sounds like you're looking for something more on top of that.

I think I vaguely tossed out an idea of "CRA templates" on Twitter not too long ago, where maybe in addition to telling CRA what version of `react-scripts` you want to use, you could also give it a template package name. That way, you could specify something like `--template simple-react-redux` or `--template my-react-router-semantic-ui-setup` or something.

There's actually a pretty similar issue with Redux too (and I say that as a Redux maintainer). I opened up an issue a while back to get ideas for what a better starting experience with Redux might look like: https://github.com/reactjs/redux/issues/2295 .

> requiring you to have a strong JS frontend background in the first place

Is that a high bar for a JS frontend framework? Serious question, as it doesn't seem that way to me. This seems analogous to saying "Django docs require you to know python" or "Postgres docs require you to understand how databases work".

I lost an entire week of work last year to not knowing that React switched from automatically binding methods, because none of the documents mentioned that. Including the release notes of the version of React where they turned that off, IIRC.

It is easily the most rage-inducing programmer moment I ever had, mainly because it's so fucking stupid and the only reason it took me so long was because the actual tutorial and documentation was fucking lying to me.

Technically speaking they fixed it by now: they mention the bind-thingy under "Handling Events" in the documentation, which you randomly have to stumble upon:

    constructor(props) {
      super(props);
      this.state = {isToggleOn: true};
  
      // This binding is necessary to make `this` work in the callback
      this.handleClick = this.handleClick.bind(this);
    }
  
    handleClick() {
      this.setState(prevState => ({
        isToggleOn: !prevState.isToggleOn
      }));
    }

However, the tutorial is still deceiving:

    constructor() {
      super();
      this.state = {
        squares: Array(9).fill(null),
      };
    }
    
    handleClick(i) {
      const squares = this.state.squares.slice();
      squares[i] = 'X';
      this.setState({squares: squares});
    }

This is fine in this specific situation because the render method uses a closure:

    onClick={() => this.handleClick(i)}

But this is a subtle nuance that can be an incredible pain to figure out. There is no mention of all the this-related pains in the tutorial anywhere.

[0] https://reactjs.org/tutorial/tutorial.html

[1] https://reactjs.org/docs/handling-events.html

I think you might be mistaken. `React.createClass` always did autobinding, and it still does. The ES6 classes (which the tutorial now uses) never supported autobinding.

React documentation switched from `React.createClass` to ES6 classes because they community already did at that point, and wanted to see the more "mainstream" pattern documented. I'm sorry it wasn't obvious that there is a difference between the function call and the language syntax, but it's definitely not a change in React.

The tutorial you mention works fine because `onClick={() => this.handleClick(i)}` is an alternative way to bind methods that also works. That's what the tutorial uses because it's easier to explain React first without diving into how `this` works in ES6 classes. And you can run that code and verify it works. (Every step of the tutorial has a link with a code example.) So no, it has not been broken for a year.

We also did blog about ES6 class support: https://reactjs.org/blog/2015/01/27/react-v0.13.0-beta-1.htm...

And autobinding of `React.createClass` (which you can still use—it's just in a separate package) is also still documented: https://reactjs.org/docs/react-without-es6.html

That said I'm sorry about your bad experience.

Comment-sniped before I could update my message. Yes, I was mistaken, it has been changed.

> We also did blog about ES6 class support

Not everyone reads blogs all the time. If a new product is released, it's reasonable to expect the documentation to mention the breaking changes.

That's my point: there was no breaking change :-)

React.createClass() always did (and still does) autobinding.

ES6 classes never supported autobinding.

We couldn't have changed your code from one to the other. There is no "release notes" associated with that change—changing the syntax was a conscious decision you made either when converting or when writing a new components.

While you're right that there was no breaking change, it isn't unreasonable for a developer to expect, when a feature is introduced that is analogous to an existing feature, that the new feature's differences will be explained.

If you already know about ES6 classes, what you say is obvious, I'm sure. Or if you're in a place where someone more experienced can teach you. Neither of those things applied to me. I had no prior webdev experience, used to languages where this does not behave like it does in JS, and relying on documentation to guide me.

It can be nearly impossible to Google something if you don't even know what it is that you don't know.

There's a comment by, well, YOU, from March this year[0] on a github issue discussing improvements to documentation, suggesting it is one of the most common troubleshooting issues, so I'm not the only idiot failing to grasp this when first diving into webdev.

It would help tremendously if there was even just a simple sentence in the tutorial like:

> "By the way, we are using an arrow function here because JavaScript has some subtle behaviour when it comes to this, but explaining the details of that here would take too long. See [here], [here] and [here]"

.. with a few links explaining both this and ES6 classes in more detail. Because otherwise you can easily get stuck not even knowing where to look for the cause of the bug.

[0] https://github.com/facebook/react/issues/8060#issuecomment-2...

I think you need to take some personal responsibility here for not knowing how Javascript works.

That you've written so much indicates to me that you expect other people (like a framework's documentation) to introduce you to every language idiosyncrasy in any place you happen to be reading.

That's not what I want people to expect from me as a professional. People should be able to expect me to credentialize in the domain at hand.

I sincerely hope you never have and never will work in education, or in any way have to teach others how something works.

Still, it isn't entirely obvious under what conditions the methods of a React Component class are going to be called. For all you know they might always be called against the instance.

Would you like to send a PR? I don't mean to sound defensively, but I have spent a huge amount of effort on docs in the past, and as you can see they're still not good. :-) So some help from you (you know the pain points!) would be handy.

The subtlety that arrow functions are different would bite you anywhere in javascript, including vanilla. It should come up if you read the MDN documentation on this or arrow functions.

For those who are confused... If you have a click handler "handleClick" that references "this" inside of its definition it will be broken if you do

onClick = {this.handleClick}

This is due to the way "this" is scoped in JS.

Dan mentions that it works fine if you instead do: onClick = {() => this.handleClick()}

This is using the new ES6 arrow functions which fix the "this" scoping problem.

Another alternative is to use bind() inside the onClick and set "this" to the correct value that you want.

onClick = {this.handleClick.bind(this)}

Considering backend developers are still routinely thrown on the frontend because “it’s easy and doesn’t need to look pretty,” I’d say yes.

This does bring up an interesting point about the community and its different populations.

JS includes _a lot_ of people, of all levels. You don't really have much choice but to do the lowest common denominators (people newer to it probably consist of the majority right now).

When I went through the VueJS stuff originally, I had a feel of "Come on, get to the point already" as I went through pages over pages to get the whole idea.

When I learnt React (originally when it came out), I looked at the first page, went quickly over the element creation (I was anti-jsx at the time. Times long gone, haha) and lifecycle hooks in like 5 minutes, went "Okay, got it. I already know how this works" and built an app.

Obviously my situation is not the common one, so doc like VueJS should be standard...but having a good "tl;dr" is critical (maybe it is in there, I didn't look, but when I learnt Vue's basic, by the time I went through most of the pages looking for a tl;dr, I had found everything else)

A Tweet by @reactjs:

> We hope the new site will make it easier for you all to contribute improvements as well. We look forward to working with you to improve it! [1]

This was just the first phase of them moving to the new site. They understand that the docs can be better. Maybe instead of just complaining about them, you contribute to them to make them more "noob" friendly, like you are describing.

[1] https://twitter.com/reactjs/status/913797589421629440

Before even finishing your comment, in my head I was saying "compared to vue.js where the tutorials instantly clicked for me". I'm no master js guru, and agree completely with you.

Reply on news.ycombinator.com