> React is so much more than “just JavaScript”. React is an ecosystem. I feel like it’s a disservice to anyone trying to learn to diminish all that React entails. React shows up on the scene with Babel, Webpack, and JSX (which each have their own learning curve) then quickly branches out into technologies like Redux, React-Router, Immutable.js, Axios, Jest, Next.js, Create-React-App, GraphQL, and whatever weird plugin you need for your app.

> In my experience, there’s no casual mode within React. You need to be all-in, keeping up with the ecosystem, or else your knowledge evaporates.

This is not true at all. I use React for work and for pet projects, and I don't use or know what most of these libraries do. (We do use Redux).

It's easy to get caught up in library mania and chase after the newest javascript fads, but it is not necessary to build products.

Also, GraphQL is not tied to React or Javascript.

Perhaps a more charitable interpretation of the article is that when writing a larger application in React you'll be led from React-the-library (which is "just JavaScript") into React-the-ecosystem, which looks less like "just JavaScript" and more like the other frameworks.

You can definitely write your application in React without external dependencies, but how is a beginner expected to do that, especially with all these other popular libraries around?

And? It's a criticism or interesting observation that when you build large, complex applications that they can be large and complex?

I think the more salient point here is that React-the-ecosystem is just the JavaScript ecosystem. There were very few packages mentioned that are strictly only useful with React.

Just out of curiosity, what are your thoughts on Vue? I've heard a lot of good things about it.

Have been developing with React for last 3 years, and recently started building with Vue JS.

React's core philosophy is JS everywhere - there's no template, no HTML, no CSS; only JS. As much as possible, write JS, and if you can, pure JS.

It has its benefits - you can have code formatter to format your JSX, unit test any part of your code, or write integration tests with mount, or write snapshot tests. Extremely easy and natural to compose various components - because it's a function calling another function.

Vue is magic, and its own DSL rules will get in your way. For instance, inside the Vue templates you cannot use `this`. However, inside your methods and computed, you have to.

Coming from Angular 1, Vue JS would look feel like a breeze.

Never could make ESLint work on my Vue files, tried all plugins. Some parts of the code it lints, and some parts of the code it doesn't.

Inside your template, Vue.config can be undefined; so you've to assign it to something in mounted(), and then get it to work.

Vue artisans tell me Vue supports "this" or "that". I don't want something that supports A or B - I want something where A and B are inherently supported from the ground up.

It's not all bad. VueX is pretty cool, kinda like Redux without the drama. And I cannot stress this enough - it's insanely easy to go through a Vue codebase and pick up the business logic of your app.

It still takes me some time to get used to a new React codebase.

Overall, I felt Vue is really good to build MVP and get your product off the ground, but it starts to show why you need React's discipline in your codebase with growing requests from users to add new features and support more platforms.

Then again, I'm new to Vue JS; so ask me again in a year. Am keeping an open mind.

> Vue is magic, and its own DSL rules will get in your way. For instance, inside the Vue templates you cannot use `this`. However, inside your methods and computed, you have to.

Except everyone seems to complain that "this" exists at all, but then it's confusing that "this" is implicit inside an objects own template?

The DSL is awesome, and what makes it even more awesome is that it's optional. Your options are HTML, Jade/Pug, JSX, and a literal vanilla function. After the compile process, the template ends up as a render function.

> Never could make ESLint work on my Vue files, tried all plugins. Some parts of the code it lints, and some parts of the code it doesn't.

I can't say for sure this was true a year or more ago (especially in that short time you couldn't tell which libraries supported Vue 1 or 2 or both), but today and for as long as I've remembered eslint has been working in my Vue component files and inside sublime linter. My biggest complaint is that I want reasonML.

I dislike the templating language, preferring jsx which is mostly standard js syntax, e.g.:

Vue: <li v-for="i in items">{{i}}</li>

React: items.map((i) => <li>{i}</li>)

Just to make things clear. You can use JSX with Vue as well. It's even a recognized way to write code in the official documentation (https://vuejs.org/v2/guide/render-function.html#JSX). JSX is just a language that can be interpreted into code for React & Vue.

Not to mention that you can use Jade/pug, also.

I learned this the hard way, coming from React to Vue land; that v-for on an element would also repeat the element itself.

With React, it was pretty clear which element / component would repeat.

IIRC you can use JSX with Vue via a Babel plugin [1]. I can't vouch for it personally but it should be pretty easy to use.

[1] https://github.com/vuejs/babel-plugin-transform-vue-jsx#usag...

"Stringy code" is an issue, but it's more declarative and readable than JSX map.

exactly that. I prefer using javascript than inventing a template DSL

We're just finishing up porting our app from React to Vue and we're very happy with the results.

I don't really understand's the author's point about GraphQL and Axios. But React Router, Redux and its ecosystem of supporting libraries are issues in React development

Having state management (axios), a built-in router, "the" styling solution built into Vue is a big win for us. Single File Components (SFC) are a joy to work with.

I actually like JSX (which you can use in Vue too), and was worried about "stringy code" ala directives, but in practice it hasn't been a big deal. We also switched from Typescript to plain ES6 which is a big win in simplifying our code. I'm actually a big fan of static typing, but at the end of the day Typescript's complicated type system, typing file incompatibilities, and general fiddling around with types wasn't worth it for us.

Redux was just a nightmare for us to work with. A library on top of Redux like DVA https://github.com/dvajs/dva would've helped, but there's a very small community there. We went to Mobx State Tree for a while, but there were a bunch of issues there too.

I'm keeping an eye on Blazor for some administrative apps in the future, but for now we're very happy with Vue.

> Having state management (axios)

Axios is a http client library, not state management library, you're thinking of Vuex. That being said, I don't know why the author associates Axios with React ecosystem, it's just a library you can use with any of the client frameworks.

Right, I got my "library with x in the name" screwed up.

I've found vuex much more pleasant to work with than straight redux. I wish Facebook would just come out with an "official stack" already and put something on top of plain Redux to make it more programmer ergonomic.

For me, vue is more natural, as is easier to use html/css as "normal" and just spice things up with vue.

And it let me use LESS javascript. Less javascript is always good.

> My one complaint is that Vue components place templating, code and styles in a single file and I'd prefer a directory with three (or more) separate files.

You can have that. You do need an index.vue file containing something like:

    <template src="my-component.html" />
    <script src="my-component.js" />
    <style scoped lang="scss" src="my-component.scss" />

If you put that into a directory called my-component/ then you can just do:

    import MyComponent from 'my-component'

…and it will pull everything in.

I don’t think it’s a requirement. You can use Vue simply by including it from CDN and just sprinkle some functionality on a page.

It's absolutely fine to adopt React piece by piece, I disagree entirely that it's an all-or-nothing proposition. I've converted a heavily used in-production service from 0% to 100% React over the course of more than a year. And this is an SPA, so over that year there was literally jQuery and React rendering to the same DOM. It works just fine, it's all just JS.

You don't have to use Redux etc. (but you probably do if you have sufficiently complex state). Even then, you can do things like have multiple stores in the same app. It's fine! It's just JS objects being spliced, merged, propagated. You eventually converge on a single store as the various React parts merge.

You don't need to use react-router, or even a router lib. It's probably better if you don't, given how many times that shitshow of an API has been completely rewritten. I took one look at it, could tell that this lib wanted to be fully in charge, and noped out. It's fine to manage browser URL state yourself, it's just JS and the browser APIs are OK for that nowadays.

Now we're in the process of adopting Immutable.js. It's fine, it's just fancier collections, with some conveniences and being able to use React.PureComponent 99% of the time without worry. So your codebase is 50% fancy collections and 50% JS natives? That's fine, don't worry about it, just write new components using Immutable.js if that's the direction you're going. Don't worry about the top-level Redux container not being an Immutable instance, just use it for the leaves then.

Server side rendering? I retrofitted that in a weekend by compiling the app as a lib with Webpack (project started as Gulp way back), included that in Node.js as an import. Worked just fine, nothing to it. Now we're generating PDFs using the same frontend code with Puppeteer and SSR, it's awesome.

The app is in a better shape than ever, a real pleasure to work with. Jest tests for React stuff, Mocha tests for other parts. And that's fine, no need to get all religious about which one is the "one true" framework.

The jQuery api was hundreds of different methods, the best of which are now available natively in JavaScript.

React has a very small api, I hardly ever refer to the documentation (unlike when I was a jQuery or Angular developer)

I agree that people reach too early for helper libraries but you can go a long way in pure React.

Because React doesn't manipulate the DOM directly you're leaving every convention and tool about DOM manipulation behind, which means that the moment you want to do something more complex than composing components you either have to re-invent the wheel or use the brand new wheels that somebody re-invented.

React is brilliant but makes simple stuff that no one was thinking on anymore hard and complex again. So if you don't want to think about how to handle an AJAX request and an animation like it's 2004 you can just slap a library on top of React(and worry about the page size and loading strategies).

React is a statement, a revolution, it is about disowning the old Web and building it from scratch.

fetch and CSS handle AJAX and animation absolutely fine with native calls and work well with React, why would you bring in a library to handle these?

You bring animation libraries in when your UI animations don't necessarily match the component lifecycles and you don't want to do something basic. Well, you don't have to bring in animation libraries but then you'll have to engineer it by yourself and handle all the quirks.

In React you simulate a DOM(or whatever) instead of working on a DOM that's handled by the browser(or whatever).

It's just like the difference of a real-world physics and simulated physics. In the real world, you can throw a rock and the nature will handle everything. On a simulation, you will have to think about all kind of details to make your simulation as realistic as possible.

I don't really see how complex animations is something React (or any UI framework) should be responsible for ?

Who should be responsible if not the UI framework?

Oh, and by complex, I don't mean character animation or something. It's the stuff that is supposed to act differently than the React's internal workings.

For example, if you want to do an animation on items that disappear when the user takes an action it's not going to be easy as with plane JS manipulating the DOM. Also, you won't be able to use some nice artistic animations that were created by direct DOM manipulation.

Having an ecosystem does not, in my humble opinion, make writing a React application feel substantively different from writing a pure JS application.

Yes, JSX is not part of the core language (yet), but it's the closest to pure JS we are going to get considering developers' need for an intuitive, expressive, and virtually bulletproof templating language.

Before learning React, I built some decent-sized applications with Ember and Emblem (a whitespace-significant language that compiles to Handlebars) and it was utterly painful. Not wanting to deal with Handlebars' proprietary, Ruby-like syntax (not bad per se--Ruby is really cool--but out-of-place in a JS application) and its artificial limitations on what you can do with the language (anything resembling display logic has to be extracted into special helper functions) is probably the single biggest reason I ultimately came to prefer React over Ember, despite Ember having some conveniences React didn't and still doesn't (such as a concrete modeling and persistence layer like Ember Data).

With that aside, I think React is the closest we can get to "just JS" without abandoning pragmatism.

Transpilers and build systems are a necessity when the language itself is changing at such a rapid pace and there are so many different environmental concerns an application needs to satisfy.

Out of curiosity, what do you think about lit-html[1]? The main thing I’m interested in there is that it’s based on native web technologies so you don’t need the huge non-standard React stack just to be able to load a file. Having has similar experiences with frameworks in the past I’m increasingly inclined only to use things which are moving in the direction of web standards to reduce the amount of churn.

1. https://github.com/Polymer/lit-html/blob/master/README.md

Looks nice! I've thought about working with tagged template literals before, but I didn't know Google already had such a project.

On the flip side, I am apprehensive about it being run by Google. Look at what happened with Angular 1.x, which was also supposed to let you do data-binding without abandoning valid html completely.

Also, JSX offers some conveniences I'm not sure would be possible with tagged templates, such as not having to join an array explicitly after you map its data to markup. Edit: I stand corrected; lit-html supports mapping an array to markup naturally.

As far as churn, which in general is a valid concern, I don't think React is going anywhere in the foreseeable future; it, along with Vue, has gained developer mindshare even jQuery may not have enjoyed back in its glory day. Absent a totally unexpected breakthrough, or Facebook really dropping the ball on updates, I think React could easily be viable in 2025 or beyond.

Edit: lit-html is built with TypeScript, oh my! I will definitely be diving deeper into this project. Especially if I'm not building an SPA.

Personally I strongly disagree that you need to be "all in" on the React ecosystem if you don't want your knowledge to evaporate (as the author puts it):

I've been using React since 2015 when it was still in beta, so I witnessed the evolution and invention of the whole ecosystem around it firsthand.

And while it's true that the team and community introduced many new tools and technologies, you could probably still use the original React documentation from 2015 to build a simple app (as to my knowledge no backwards-incompatible syntax changes were introduced).

Also, for 99 % of apps you probably don't need the full-blown React stack like React Router, Redux, server-side rendering, hot reloading, transpiling with Babel, bundling with Webpack2 etc. I routinely build small React apps for websites (e.g. for contact forms) using just vanilla React.js (actually Preact.js as it has a smaller footrprint) without any of the amenities listed above, and sometimes I even write old-style ES5 code and use JS-based tags instead of JSX.

So please only introduce additional complexity (in form of tools, libraries and add-ons) if you really really need it. The more complex your toolchain, the more effort you will spend just maintaining and upgrading it instead of doing productive work (frontend devs who tried upgrading Webpack and Babel.js to the latest version in an existing project with many dependencies probably know what I'm taking about).

React has certainly inspired a huge shift in how we architect frontend web apps, and I think I'd rather view it on those terms instead of just how much you might buy into React's worldview and all of the libraries that subscribe to it when building your app.

React is one particularly well-regarded implementation of a virtual DOM library with one way databinding and ever since then we've seen various flavours of it with innovations of their own: Elm and the architecture that inspired Redux, ReasonML, reflex-frp, CLJS/Om Vue, Cycle.js, Glimmer, etc... React, as far as I know it, was the first for the web and while it might have been well-known in other situations, we were all scrambling around trying to solve the data-binding problem when building anything large scale in JS.

In that way, React's impact on the frontend ecosystem is profound much in the way jQuery's impact was back in the darker days, and what that technology has allowed us to do without depending on React itself is significant, much more so than its own ecosystem.

Strange article. The add-on libraries described aren't necessary at all.

The benefits of React (such as its templating syntax) can be had with much simpler libraries, such as this one: https://github.com/wisercoder/uibuilder

The much touted benefit of React, DOM diffing, is useful if you have a very complex screen and you need to make surgical updates. Most applications have simple screens that can be completely re-rendered and the user won't know the difference.

> I sometimes browse React projects and look at the import blocks to see if I recognize any of the dependencies; I probably average about ~8%.

This is very true, not just because of the libraries you don't know yet but also because those you do know are continuously evolving. I've been working in the React ecosystem for about 4 years now. I think constantly keeping an eye on the changing ecosystem, and constantly changing the way you do things where it makes sense, just comes with the territory now. You just have to accept it as a way of working, if you're going to enjoy working with React (and JS generally).

Whenever I've locked down dependencies and just got my head down and built stuff for a few months, without fail every time I've looked up I've realised that there are now multiple things in my stack that are 'outdated' and there are some genuinely better ways of doing things (some really are just different and equally good, and it's fine to ignore those) that have evolved and been evaluated and ultimately embraced by the community in parallel in the few short months I've had my head down.

To be honest it's what I love about the JS ecosystem in general - it's an environment of continual improvement and blisteringly fast pace of change.

I too love the constant change its exciting.

But you can't live like that forever. Things need to remain constant so you can work on difficult business logic instead of changing how you do standard things.

The point I was making though is that this isn't necessarily true - you can do both simultaneously. Your stack can be continually improving while you still focus on feature delivery in parallel. What I was getting at is that you should embrace and enjoy this if you want to be happy working in the frontend, specifically React, world.

As an "Angular-guy" I can ensure you that with Angular we use also builders, minifiers and even TypeScript compiler. And testing is a separate story with painful moments. Of course, we have much more tools out of the box - we don't have to look for a good router, for example.

But there is no paradise of one magic tool in the web development.

As a long time React user (four years), I agree with this article for reasons different from what the author intended, perhaps. That's why I've recently started learning Dart and hoping that it'll catch on. I want to focus on solving the problem, not battling the ecosystem...

This confuses React with the react eco system.

I am a happy producrive React user and I don't know two figs about the wider eco system.

Whatever man, React is just JavaScript and they've learnt what not to do from Adobe Flex, that is why I am so fast and productive in it

If anything I'd love to see a barebones 'obj => native DOM' library built into browsers

Let React and others compete over the more advanced use cases like context, lifecycle methods etc