[kristiandupont]

Contrary to some commenters here, I think React is just about the best thing that has happened to UI programming in recent memory.

Everything I tried before it (jQuery, Backbone, Knockout, Angular, Meteor (with Handlebars)) felt like it fell short or, in the case of the databinding-oriented ones, like a broken abstraction. I get a similar feeling when looking at Vue though I have no experience so I might be wrong.

I too am a bit skeptical about hooks making what looks like pure functions act like stateful ones. I am not using hooks yet but besides from Dan Abramovs excellent articles about their rationale, I think I will look at them like a new paradigm, only using a syntax that we know from something else. In fact, I wouldn't be surprised if I some time in the future will be using React to write state machines for something that doesn't have anything to do with UI, where "rendering" composes state related to something else entirely. I could see hooks being a game changer here.

[shubhamjain]

One reason I love Vue over React is how beginner friendly it is. You can't make a "Hello World" app in React without getting bombarded with concepts and terms—states, props, JSX, stateful components. Just look that the "Getting Started" example of Vue [1] and compare it React's [2]. You don't need anything more than a notepad to get the first example running.

Progressing down Vue, you realize how they have tried to prioritize convenience. For example, using "v-on:keyup.enter" you can map an action to "Enter" key without writing code for handling that key.

I liked the React's approach but it seems its focus is on purity of abstractions than convenience. Don't even get me started on Redux which is epitome of needless complexity—containers, reducers, event emitters? Was all that really needed?

Note: I have no idea how Vue fares when code base is huge, but my intial impression makes me feel it's far better choice than React.

[1]: https://vuejs.org/v2/guide/#Declarative-Rendering [2]: https://reactjs.org/tutorial/tutorial.html

[danabramov]

>Just look that the "Getting Started" example of Vue [1] and compare it React's [2].

Thanks for feedback!

The linked React guide is intended to be a pretty comprehensive tutorial — not a getting started guide in the same sense. I wouldn’t say they’re comparable in how much about either of them teaches you about using a library. Maybe it’s not obvious from the wording.

If you do want a simple “getting started” guide that doesn’t require any tools, it’s right here:

https://reactjs.org/docs/add-react-to-a-website.html

And you can progressively learn all important concepts starting from here:

https://reactjs.org/docs/hello-world.html

Another common destination is this guide, which matches the Vue one in purpose a bit more closely: https://reactjs.org/docs/thinking-in-react.html

The “get started” link on the React page links to resources for people with different experience levels:

https://reactjs.org/docs/getting-started.html

Hope that helps!

[shubhamjain]

Fair enough. These seem much better for starting out. However, the progression in Vue's guide is much better thought out.

Step 1: Get a simple "Hello world" running.

Step 2: Get something dynamic on screen.

Step 3: A simple if statement.

Step 4: A loop.

Step 5: User Input.

By the end of the guide, I know all there is to know to make a very simple interactive component.

[danabramov]

Thanks for feedback. I do think the “main concepts” guide goes in roughly the same order but I agree there could be a more condensed single-page version of it. We’ll keep it in mind for the future!

[Silhouette]

The linked React guide is intended to be a pretty comprehensive tutorial — not a getting started guide in the same sense. I wouldn’t say they’re comparable in how much about either of them teaches you about using a library. Maybe it’s not obvious from the wording.

FWIW, I think the current introductory material on the React site is not as effective as how things were in the early days. IMHO, a significant benefit of React in its original form was its simplicity. The whole API practically fit on a single screen. You could write a tutorial that showed the basics of rendering a component or two on a single screen. Today React itself has become more complicated, and the tooling around it even more so, and I'm not sure that extra complexity offers a good return.

Just as a demonstration of my point, please imagine for a moment that you are a developer who understands the basics of the modern JS world but is new to React. Go to the React site and find the instructions on how to just install React with npm or yarn, the way you probably would with any other JS library.

OK, so there's nothing readily visible. No, really. How to just install React like every other JS library in the world isn't even described on the introductory pages. Well, maybe you try running

    {package manager} {install command} react

That used to do the obvious thing, but now it doesn't because even the essentials are divided among multiple packages with non-obvious names. So at this point, just a couple of minutes after you decided to give React a try, you're already confused about how it works in NPM and thinking basic documentation is missing, and you haven't even installed it or written a line of code yet.

Maybe you find a link somewhere to the page about the "most popular and approachable toolchains". OK, that looks promising. You click the link and... you're confronted with create-react-app, Gatsby, Next.js and a bunch of other dubious, heavyweight tools, not that you know that because you've never heard of them. But there's still no sign of how to just install React and try it out like any other JS library.

So you go to the kitchen, make a coffee, come back and ask your mentor whether it's really necessary for you to use such a complicated and difficult tool, and whether you can just use Vue instead.

This comment is based on a true story. :-(

[danabramov]

I think this page is written for that exact use case!

https://reactjs.org/docs/add-react-to-a-website.html

And it’s linked to from the other pages you mention with a disclaimer that a simple HTML page is still the best way to get started. Sure, you can ignore that, but what can we do.

But whether we like it or not, plenty of people want to kick off a single-page app with a whole toolchain rather than just “try React”. Earlier docs that you fondly remember didn’t help with that at all, leading to a lot of frustration.

Some people will be unhappy with either approach. That’s why the docs include instructions for both.

[Silhouette]

I think this page is written for that exact use case!

I understand that this is what the React team think. I am trying to explain that that page (and the other "getting started" level material on the current React site) is not necessarily working very well.

Maybe we're unusual, but among my professional network the overwhelming majority of React users do so with what now seems to be considered a custom tool chain, even if it's just "Bundler + Babel plugin for JSX". The first question everyone asks when they want to try out React, like any other new JS library or tool, is what they need to npm-install or yarn-install to get a minimal example going. And this information has now been hidden away several layers deep on the React site, as if it's an unusual use case.

Loading scripts from CDNs is fine for a very early experiment but quickly outgrown in production environments. There is create-react-app, but most people I know are sceptical about such tools and in any case it's debatable whether you want to start with scaffolding/framework tools if you're learning a new library for the first time and want to understand how it fits into everything else you're doing.

In short, the current site (and your reply here) seem to be predicated on a false dichotomy. Presumably you have access to better metrics than I do as a random individual and you know that most people really do fall into one of those two groups. All I can tell you is that almost no-one I know does, including those I have introduced to React myself in recent times.

Maybe it's just the curse of the modern JS world that everyone feels obligated to try to show how their individual tool or library works with 500 different other tools and libraries. Even so, there's probably a reason that almost every modern JS library's home page seems to have a screenshot with the words "npm install" in it above the fold.

[danabramov]

Thanks for feedback! Will keep that in mind next time we look at the docs. (FWIW we used to do exactly what you said and heard many complaints about that — people didn’t want to see npm, didn’t know what Babel is, and so on.)

[Longwelwind]

If your project grows big, you will at some point need to use a state management library like VueX which has similar concepts than Redux, so I'm not sure this argument holds.

My biggest problem with Vue is the template syntax. Since JSX is a thin layer over Javascript, few modifications have to be done over Javascript (or Typescript) tools to make them work with JSX (or TSX). Vue templates are a totally new language which requires more complex tools. I've never had any problem using refactoring tools (renaming variables, go to declaration, find usages, ...) with React, while in my last Vue project, renaming a variable broke code.

Vue has Vuetify, which has been a breeze to use, though. I don't know if there is a React equivalent.

[leipert]

You can use TSX and JSX with Vue: https://vuejs.org/v2/guide/render-function.html

[mcv]

Vue templates are not in any way more of a totally new language than JSX is. Vue templates are simply XHTML snippets with added data bindings. JSX is not quite XHTML (you have to use className instead of class) with added data bindings.

I find Vue templates slightly cleaner for that reason, but the difference isn't big. How they're used is different, though: React wants everything, including the XHTML, to be javascript. Vue puts it all in HTML, with script tags for the javascript.

[Longwelwind]

If I have this:

  <div v-for="item in items">
    <span>...</span>
  </div>

The refactoring tools must know that the "items" inside the "v-for" refers to a property of the data object. In other words, the content of the data bindings is a totally new language by itself (the content of v-for has its own syntax, with a parser).

Compared to the equivalent in React, which would be:

  {this.items.map(i => (
    <span>...</span>
  )}

Or possibly

  let elements = [];
  for (item in this.items) {
    elements = <span>...</span>
  }

It's way easier for a refactoring tool to support JSX since it's just syntactic sugar over JS. If you were the developer of such a tool, you would just need to consider "<>" as values and possibly consider anything inside "{}" as normal Javascript.

And indeed, as pointed by another commenter, React supports classes and integrates very well with Typescript since React 16.

[mlsarecmg]

JSX is a dsl, like typescript or flow, it doesn’t change or affect your code, all assumptions stand, it doesn’t break scope. Vue templates are not a dsl, they break all assumptions and your scope. There is no difference between Vue and angular in that regard, both could not do this with templates:

    const A = () => <div />
    const B = () => <A />

JSX turns that into:

    const A = () => createElement('div')
    const B = () => createElement(A)

That is all that JSX does. Vue on the otherhand parses its own language, breaks scope, separates concerns that shouldn’t be separated and in the end joins them via dependency injection again. We’ve been through this years before Vue existed with angular and others.

BTW, your info is outdated. "class" is allowed in React as of V16.

[woah]

I can’t go back to a hobbled templating pseudolang after jsx

[dkersten]

> I think React is just about the best thing that has happened to UI programming in recent memory.

I completely agree that it’s the best thing that has happened to web UI programming in recent memory, but for me, personally, I think Qt’s QML is the best thing that has happened to UI programming in general in recentish years. I like using react, especially from clojurescript using re-frame and I’m very thankful that it exists, but QML has been some of the most pleasant complex UI development I’ve done in the last few years. Now, if only Qt were more like re-frame, then I’d be super happy, but I love the declarative nature of QML and the anchor-based layouts.

[baddox]

> I too am a bit skeptical about hooks making what looks like pure functions act like stateful ones.

What’s wrong with that? Any conceivable application needs to actually have state that changes over time. That’s true of all software written in a purely functional style.

[Silhouette]

That’s true of all software written in a purely functional style.

By definition, any software that is purely functional does not have explicit mutable state. In practice, it is often useful to have parts of a system written in a pure functional style but other parts that do use mutable state, either explicitly or via some mechanism that simulates it in a functional context.

[olavgg]

You mention a lot of frameworks and libraries that abstract frontend development into its own "kind". I feel like you're already colored with the "crap" they come with. They all abstract something very simple into something that doesn't scale well for solving many of the common challenges for frontend development. They are all leaky abstractions.

Of all these I have used jQuery and React, but I prefer plain vanilla over these. No breaking changes, no hype cycle, excellent documentation and with good old design patterns any complex problem is easily solvable. Believe it or not, but managing state is dead simple with just vanilla javascript.

[Vinnl]

> Believe it or not, but managing state is dead simple with just vanilla javascript.

Keeping state and the view in sync, however, is not. For example, if you have a list of TODO's that the user can edit in the browser, and that you want to be able to send to the back-end, every time the user adds a TODO, you'll have to remember to update both the model and the DOM. Likewise after an edit or deletion.

These tools really do solve a problem.

[olavgg]

There is a design pattern for that called Observer pattern.