I think part of the reason why React causes negative reaction towards perceived "Javascript fatigue" is that Facebook introduced too much at once.
There's no reason why JSX had to be included at the same time with React. There's no reason for it to provide classes, the whole bells and whistles.
They could have released just the Virtual DOM part of the library (which was the major innovation) and keep other parts of it to themselves or release them later. When React released with so many features at once, it looked on the surface like just another framework. In fact, people still call it a framework today, even though it isn't one and was never really meant to be one.
And the fact that React was released in a such a big package, it meant that people weren't eased into each of the concepts, one at a time. Suddenly you not only have to learn about Virtual DOM, but the class API, JSX at once. Some people even throw Redux at the junior programmer at the same time. Imagine having to learn so many concepts at once! No wonder it's hard to learn.
It's a pretty basic pedagogical concept. You have to introduce each concept in isolation and then build understanding of the whole from those parts. If you do not understand what the problem with vanilla DOM manipulation is, there's no rush to learn JSX and Redux!
I guess in the end I'm just glad you decided to play around with vanilla DOM manipulation and build from that, step by step. "Learn everything at once" doesn't work very well.
Given that they also released full and clear documentation _with_ a full and clear tutorial, I have to strongly disagree. They didn't release a library, they released a full framework and methodology that they had been using them selves already for writing huge web application UIs. Releasing it in tiny chunks would have made zero sense.
Heck, it speaks to how well written their docs and tutorials were, and how easy it was to pick up, that it became this popular in the first place. After all: React isn't actually a web technology, it's a traditional OOP framework that happens to use the browser as its UI layer. Nothing it does respects how the real webstack works, and makes it impossible to debug "as a web page".
Irrespective of how you feel about that part (because I love React as UI framework, but hate how we've told React devs that they're web dev, when they're very much not), the fact that it's stuck around and has become as popular as it now is speaks volumes to how much their release history was just fine.
I didn't mean to say that React is bad, quite the opposite! It's a wonderful library and for good reason. But I've never used the OOP parts of it, because I like structuring my applications without a framework, customized to the domain I'm working on. Several mutable classes as a basic structure of an application is a no-go for me. Luckily, you could, can (and in my opinion should) use React without those parts, and the library works just fine as a VDOM engine.
Again, Facebook did an incredible job. I'm just commenting on why some people (not me) feel like React is "just another framework oh my god when does this stop". If they released the VDOM engine separately and the framework parts after that, people would understand that you can build your application in a way where you can pop out React and replace it with any other VDOM implementation. Most people don't seem to know this, and that's why they insist on calling it a framework.
Also, JSX caused so much confusion among people who were used to template engines. There was a huge opposition to React as a whole simply because JSX looked weird when people were explicitly taught to never mix JS with HTML. React didn't need JSX to work. For my first applications I didn't use it because I didn't want an extra compilation step, and the build/packaging tools back then were quite painful when compared to those of today. I could use React perfectly fine and it did its job in pure JS. JSX to me was just syntactic sugar, but it became a huge red herring to people who were introduced to React.
A different way to think about this is that if Facebook had piecemeal released these new concepts it could have caused _more_ fatigue since it might have felt like an endless parade of new things.
This is opposed to releasing it all at once, meaning you could sit down and learn the new things in one go, and apply that knowledge for some time before needing to learn anything else.
I get your point, but there’s still plenty of web-related concerns that don’t go away when you’re using React. Many aspects of accessibility, layout and styling, browser compatibility, performance, security, and more are largely unchanged whether you’re developing a React web app or a static HTML+CSS site.
Any time you encounter a website where the back button doesn’t work, or with a “link” that works when you click it but can’t be right-clicked to open in a new tab, that’s probably the work of a React dev who falsely believes they are not a web dev!
As someone who's worked with HTML 3.2: people using <a> as button, and button (and before that, input type=button) as link via JS predates React by several decades.
As for that last statement: not sure if you're missing words, but when I say someone is not a web dev, I mean they not web devs. They may be devs, and the technologies they use might use part of the web stack, but they're not developing web content, they're developing different content with a completely different event model, a completely different UI methodology, and completely different runtime requirements.
Any time you encounter a website where the back button doesn’t work, or with a “link” that works when you click it but can’t be right-clicked to open in a new tab, that’s probably the work of someone who doesn't understand their deployment target well enough to do the right thing, so educate them. Whether that's because they're only used to React, or because they don't realise that web content comes with conventions that they're not adhering to makes no difference. Any time you see broken behaviour, it's because the web stack made that easier than doing the right thing. That's on all of us.
> Any time you encounter a website where the back button doesn’t work, or with a “link” that works when you click it but can’t be right-clicked to open in a new tab, that’s probably the work of a React dev who falsely believes they are not a web dev!
Nah, that would probably be another framework, Angular is the usual offender. React-Router handles this perfectly.
> There's no reason why JSX had to be included at the same time with React.
Why? JSX was one of the main reasons React became so popular. What would you have instead of JSX?
> There's no reason for it to provide classes, the whole bells and whistles.
They didn't provide "classes whole bells and whistles". React came out before classes where even standardised in Javascript. And its original API of `React.createClass` was really no different from hundreds of similar APIs.
> When React released with so many features at once
What? Which "so many features"? It released exactly that: a VDOM library with JSX and an API that was not much different from those on the market. That was the main reason it gained this much adoption: it was very simple, easy to understand and get into.
> You have to introduce each concept in isolation and then build understanding of the whole from those parts.
That... That what React does. It introduces major new things with major new versions.
> Why? JSX was one of the main reasons React became so popular. What would you have instead of JSX?
JSX was also one of the main reasons why people opposed it at first. We were taught to never mix HTML and JS and put markup in a separate file. Of course separate template files as a concept were bad in the first place, but it served as a red herring for those learning. It "felt wrong" to many people who wanted to "just write Javascript". React works perfectly fine without JSX. I mean the syntactic sugar is nice, but the VDOM implementation was the breakthrough innovation that made React popular. You can have JSX if you want, but at the time of release, most people hated a new compilation step just for a bit of syntax comfort.
> its original API of `React.createClass` was really no different from hundreds of similar APIs.
Yes, this is the API that I am talking about. There was never a need to combine state handling into the first virtual DOM engine. If there are hundreds of similar APIs, why create another one? Why not let the developer choose their own favourite Class implementation? Some people (such as myself) try to distance themselves from OOP as much as possible, so the class API was quite worthless.
> We were taught to never mix HTML and JS and put markup in a separate file.
Yeah, but we were all still doing it anyways. Maybe not for our web pages, but definitely for our apps. I don’t think that part of react has ever been very controversial to people who were already building large webapps to begin with.
And the person who wrote that tweet wasn't alone. It's perhaps easy to forget how much opposition there was to React. Facebook was quite a bit further than many in the industry, and Pete Hunt from Facebook admits that "we weren't communicating what we were doing".
It was a bit much to swallow for many at first, but in the end, the VDOM was such a powerful idea that React was destined to take off sooner or later.
Getting ridiculed early on and then quickly becoming by far the most prominent and popular library in your category doesn’t sound so bad. It’s not something I would criticize React for.
I'm not criticizing the team. I definitely couldn't have done a better job myself. Hindsight is 20/20, I'm just observing and trying to dissect what it's like to learn React from scratch in... 2020.
> JSX was also one of the main reasons why people opposed it at first.
However, significantly more accepted it, and used it.
> React works perfectly fine without JSX. I mean the syntactic sugar is nice, but the VDOM implementation was the breakthrough innovation that made React popular.
There were several breakthrough innovations. The other one was unidirectional data flow. For some reason, you oppose it.
> > its original API of `React.createClass` was really no different from hundreds of similar APIs.
> Yes, this is the API that I am talking about.
1. This API is nowhere even close to "provide classes, the whole bells and whistles."
2. This API was very similar to nearly every other API that existed at the time
> There was never a need to combine state handling into the first virtual DOM engine.
Why? Why wasn't the need there? What value its absence would bring?
You are complaining now that "Some people even throw Redux at the junior programmer at the same time". And Redux exists precisely because React doesn't provide a solution in this space.
Now imagine if React only released the DOM diffing library. How many Reduxes there would be trying to fix the actual rendering of data? You would complain now that "Some people even throw <rendering> and Redux and novice programmers".
The beauty and simplicity of React was that it very neatly solved the rendering and re-rendering of data in very few concepts that you could learn in under an hour.
> If there are hundreds of similar APIs, why create another one?
Because those different APIs work in the context of a different framework with completely different semantics
> Why not let the developer choose their own favourite Class implementation?
There were no classes. React was released before classes where even standardised in the language. There were non "favorite class implementations". All these APIs where doing an equivalent of `Object.extend`. But since they needed to do different things, they provided different APIs.
Why is it so hard to understand?
- Backbone has Backbone.Collection.extend({...})
- Knockout has ko.components.register('...', {...})
- Ember had DS.Model.extend({...})
- React had React.createClass({...})
They are all similar APIs in the sense that they extend some objects with custom definitions for specific parts of the API. APIs that are specific to the frameworks that define them.
What "favorite class implementation" are you even talking about?
> Some people (such as myself) try to distance themselves from OOP as much as possible, so the class API was quite worthless.
You clearly have no idea what you're talking about.
Sigh... I am not trying to say React is bad. I'm just saying that for some people it's hard to learn because there are so many different things packaged there that it looks like a framework. I love React, I'm just saying it's not a perfect learning experience.
If that's too harsh of a criticism about React to you, that's fine, but I am not interested in continuing the discussion as it is rapidly moving away from my original point and your tone is becoming hostile.
> I'm just saying that for some people it's hard to learn because there are so many different things packaged there that it looks like a framework.
There are many different things packaged there now. When it as released it had maybe two concepts, and you could get started with it in under an hour.
> it is rapidly moving away from my original point and your tone is becoming hostile.
The original point you presented was: "There's no reason why JSX had to be included at the same time with React. There's no reason for it to provide classes, the whole bells and whistles. They could have released just the Virtual DOM part of the library" which just makes little sense. And I never moved away from it, showing how wrong your recollection of React is.
You yourself decided to move away from it somehow deciding to talk about Redux, and how it's hard to learn React today.
Indeed. When we did our first React applications without a JSX compile step, we even went further with the syntax with the power of functional programming. You could do stuff like:
div({className: 'm-3', onClick }, 'the text')
Or go an abstraction step further create your own elements as a function, that take in custom parameters:
I mean, isn't that line actually quite expressive? It felt powerful to build the DOM exactly as you needed. You could generate anything without having to worry about JSX syntax, cause it's all JS and you can abstract using all of your toolkit. And if something goes wrong, you never have to look at JSX documentation or the JSX compiler output.
For a long time React docs had a very prominent place for "React without JSX" that showed that JSX was nothing but a bunch of functions [1], and you could skip all of them by doing
var h = React.createElement
h(...)
A few people where doing that. And early on you could switch to Preact by substituting Preact.* functions for React.* functions in the transpilation tools.
In order to build the first airplane, you need to introduce a lot of concepts at once. The Wright brothers needed to build a custom engine just to get the weight-to-power ratio they needed, on top of understanding spruce wood fabrication, wing aerodynamics, propeller design, etc etc.
If there was a logical midway point between the old jQuery-style paradigm and react, I suspect it would quite popular. However, all the react alternatives I've found make an equally large leap in terms of new concepts, because that's what makes the total development experience viable.
I'm not sure I follow. ES classes predate react significantly IIRC. React may have been the first 'popular' library that made use of them extensively, but I don't think facebook should get credit for this one
> There's no reason why JSX had to be included at the same time with React
Without jsx, the value of react code is _much much_ lower IMO. I don't think it had any chance of catching on without it.
>Some people even throw Redux at the junior programmer at the same time.
Definitely agree that that is a mistake, but it also seems to be a mistake that people are long past. Not many people advocate redux these days, which I find unfortunate given how good redux toolkit makes it. That said, even without redux toolkit, it's definitely not something to throw at junior developers in their first week
No, React was announced in May of 2013, and ES6 wasn't finalized until a couple years later.
> it's definitely not something to throw at junior developers in their first week
FWIW, we specifically recommend that most folks should _not_ learn Redux until they're already comfortable with React. In fact, the new "Redux Essentials" [0] and "Redux Fundamentals" [1] core docs tutorials specifically say "we assume you know React already" as a prerequisite. (And yes, I really wish bootcamps didn't throw devs straight into Redux, but I understand why that happens. That's a large part of why I just rewrote our tutorials.)
> Not many people advocate redux these days, which I find unfortunate given how good redux toolkit makes it.
> I'm not sure I follow. ES classes predate react significantly IIRC.
Before React started supporting ES classes, they had React.createClass instead. I assume that is what the poster is referring to.
> I think part of the reason why React causes negative reaction towards perceived "Javascript fatigue" is that Facebook introduced too much at once.
This could be relevant if this conversation were taking place in 2014; but it’s 2020 now. Today, the negative reactions to React are caused by:
- it being on the heavier side of frameworks (given that some frameworks/libraries are below 10kB)
- its relative slowness in benchmarks (absent concurrent mode), and the ease with which an inexperienced programmer can make it slower and more resource-hungry than it should be
- its least compatibility with web components, compared to other frameworks
- bad practices that have arisen in the community around it (using react when there's no need for it; serving large html payloads with SSR containing a stringified populated redux state, etc.)
This. A lot of people get thrown into the top layer of the abstraction itself and then move down from there.
What instead should happens first is that these people should be shown the problems React or other frameworks for that matter are trying to solve. It is way more motivating to gradually move up the abstraction layer when learning.
Get the know the problem first and then find the solution to that problem. Not the other way around.
There's no reason why JSX had to be included at the same time with React. There's no reason for it to provide classes, the whole bells and whistles.
They could have released just the Virtual DOM part of the library (which was the major innovation) and keep other parts of it to themselves or release them later. When React released with so many features at once, it looked on the surface like just another framework. In fact, people still call it a framework today, even though it isn't one and was never really meant to be one.
And the fact that React was released in a such a big package, it meant that people weren't eased into each of the concepts, one at a time. Suddenly you not only have to learn about Virtual DOM, but the class API, JSX at once. Some people even throw Redux at the junior programmer at the same time. Imagine having to learn so many concepts at once! No wonder it's hard to learn.
It's a pretty basic pedagogical concept. You have to introduce each concept in isolation and then build understanding of the whole from those parts. If you do not understand what the problem with vanilla DOM manipulation is, there's no rush to learn JSX and Redux!
I guess in the end I'm just glad you decided to play around with vanilla DOM manipulation and build from that, step by step. "Learn everything at once" doesn't work very well.