React Fundamentals: What I’m Learning(buaiscia.github.io)
buaiscia.github.io
React Fundamentals: What I’m Learning
https://buaiscia.github.io/posts/learning-on-epic-react-fundamentals
66 comments
It's dangerous to think of any React prop as "corresponding" to a DOM property. Only exception I can think of is "dangerouslySetInnerHTML" which has "dangerous" in the name already.
Children can be a function, node, or array of nodes (or something else); and you need to know the API of the component you're using before you can really know anything about any prop.
Children can be a function, node, or array of nodes (or something else); and you need to know the API of the component you're using before you can really know anything about any prop.
It’s not dangerous, it’s just a sometimes sensical and sometimes somewhat wrong approximation.
Anyone who has ever used the browser DOM and starts using react will intuitively understand this from day one.
Anyone who has ever used the browser DOM and starts using react will intuitively understand this from day one.
It's a leaky abstraction at best. Obviously leaving out the ones that are literally written to the DOM, can you give some more examples of React props (like 'children') that are helpful to think about in this way?
I wrote vanilla JS for years, then Backbone, then Angular, and now React. I am the counterexample to your second sentence. My "intuitive understanding" is that props are actually keys in a plain-ol' JS function argument, and I'm sure that you're handicapping yourself if you're going out of your way to map React concepts to DOM concepts. This is why people find hooks so confusing and weird, because they're trying so hard to map it to some other concept. See the many comments about JSX in this thread - the more you try force React ideas into your preconceptions about web dev, the worse time you'll have.
I wrote vanilla JS for years, then Backbone, then Angular, and now React. I am the counterexample to your second sentence. My "intuitive understanding" is that props are actually keys in a plain-ol' JS function argument, and I'm sure that you're handicapping yourself if you're going out of your way to map React concepts to DOM concepts. This is why people find hooks so confusing and weird, because they're trying so hard to map it to some other concept. See the many comments about JSX in this thread - the more you try force React ideas into your preconceptions about web dev, the worse time you'll have.
Yeah hooks are much easier if you just accept them as a new "language feature" that magically works.
Still have no real idea how it's implemented, but it's pretty simple once you stop trying to overanalyze it.
Still have no real idea how it's implemented, but it's pretty simple once you stop trying to overanalyze it.
Short version: React already knows what component instance it's rendering. Whenever a hook is called, React looks up the right data from a linked list stored in the internal component metadata objects.
For more details, see:
- Shawn Wang's talk "Getting Closure on Hooks": https://www.swyx.io/getting-closure-on-hooks/
- React Hooks Demystified: https://dev.to/kayis/react-hooks-demystified-2af6
- React Hooks - Not Magic, Just Arrays: https://medium.com/@ryardley/react-hooks-not-magic-just-arra...
- additional articles: https://github.com/markerikson/react-redux-links/blob/master...
For more details, see:
- Shawn Wang's talk "Getting Closure on Hooks": https://www.swyx.io/getting-closure-on-hooks/
- React Hooks Demystified: https://dev.to/kayis/react-hooks-demystified-2af6
- React Hooks - Not Magic, Just Arrays: https://medium.com/@ryardley/react-hooks-not-magic-just-arra...
- additional articles: https://github.com/markerikson/react-redux-links/blob/master...
I’m sorry if there was a misunderstanding, but I was talking about the children prop specifically, not props in general. That would be different story.
If you want to learn React, but somehow the approach of most tutorials elude you. I wrote one from a different perspective.
https://github.com/kay-is/react-from-zero
https://github.com/kay-is/react-from-zero
> JavaScript fullstack developer
What does "fullstack" mean these days? Express and React (single language and two frameworks)?
What does "fullstack" mean these days? Express and React (single language and two frameworks)?
Having wore that title before, it means "developer who is able to build a JavaScript application and bring it to production".
For me, this included doing UX/UI, the design, implementing web front-end (HTML, CSS, making sure it's responsive and optimized), the front-end business logic (Angular, React, Vue), setting up the server (typically the "back-end", either node.js or a more traditional approach like PHP), persisting to a database (like using MongoDB), managing APIs, etc.
I am not a fan of the title "full-stack" (to me, that's just what being a developer is) but you need to wear it in order to get the right job offers and salary.
For the longest time, front-end meant "HTML+CSS and a pinch of jQuery". So we need a title to break away from that trend.
For me, this included doing UX/UI, the design, implementing web front-end (HTML, CSS, making sure it's responsive and optimized), the front-end business logic (Angular, React, Vue), setting up the server (typically the "back-end", either node.js or a more traditional approach like PHP), persisting to a database (like using MongoDB), managing APIs, etc.
I am not a fan of the title "full-stack" (to me, that's just what being a developer is) but you need to wear it in order to get the right job offers and salary.
For the longest time, front-end meant "HTML+CSS and a pinch of jQuery". So we need a title to break away from that trend.
Yeah, it feels to me that it used to be HTML, CSS, JavaScript, a server language like PHP, and a SQL database. Now it's just JavaScript (with JSX), JavaScript (with express), and a JSON store (MongoDB, etc). The term "javascript fullstack" in the submitted article just gave me pause, you can be "fullstack" and really know a stack that's one thing deep.
Something like that yeah, maybe not React and maybe not Express but Javascript on the frontend and backend for sure.
Interested to see this because I'm neither a JavaScript nor frontend dev, but over the last two weeks have been gently learning React out of curiosity, applying it to a small personal project. The last time I used JavaScript was with Angular 1.x around 2013. Iirc the angular learning curve was negligible; React's is steeper, but I can't compare with modern Angular - seems it's up to 11.rc1. I get the impression React has mostly won the battle. I was wondering if maybe I should have tried Svelte instead, but React is the name I keep seeing, so figured that's where I'll peek (first?). I think the muddle I need to sort through at the moment is the old tutorials vs the new tutorials as I'm seeing multiple ways of doing things but don't yet know which are the new ways, the best practices, or the trade-offs with each.
The latest consensus is to avoid class components, use only functional components and use hooks to handle state & side effects. Ninety percent of React is building DOM, hitting APIs with an HTTP client and using useState + useEffect. And remembering that you must pass functions & data to child elements to communicate between or share logic across components.
What’s the reason to avoid class components though? The official tutorial still uses it, though that could just be because it’s outdated?
The React team is currently working on a complete rewrite of the docs, which will include a focus on hooks first:
https://github.com/reactjs/reactjs.org/issues/3308
In the meantime, someone else ported the existing docs to teach function components and hooks in the examples:
https://reactwithhooks.netlify.app/
https://github.com/reactjs/reactjs.org/issues/3308
In the meantime, someone else ported the existing docs to teach function components and hooks in the examples:
https://reactwithhooks.netlify.app/
The zeitgeist is that hooks are easier to reason about than life cycle methods, functional components are more lightweight and result in less bundled code.
It's more of a hype train than a "zeitgeist". Major community contributors like Jared Palmer have stepped forward in the past year to critique the complexity of React hooks.
https://jaredpalmer.com/blog/react-is-becoming-a-black-box
https://dillonshook.com/a-critique-of-react-hooks-addendum/
Personally, I think blindly adopting the latest frontend trends is the opposite of being "radically pragmatic".
https://jaredpalmer.com/blog/react-is-becoming-a-black-box
https://dillonshook.com/a-critique-of-react-hooks-addendum/
Personally, I think blindly adopting the latest frontend trends is the opposite of being "radically pragmatic".
Stay with React, don't go with the newest shiniest JS framework. React has a 3rd party solution for nearly everything so you can piece all these well-developed and well-tested modules together to make your app.
Others may suggest using Hooks right from the start, so I'll act as the counterpoint. Starting with Class components is easier to understand and less is happening magically. Almost everything can be accomplished using only 3 lifecycle methods - constructor, render() and componentDidMount. Once you're comfortable with how that all comes together, start to pick up Hooks
Others may suggest using Hooks right from the start, so I'll act as the counterpoint. Starting with Class components is easier to understand and less is happening magically. Almost everything can be accomplished using only 3 lifecycle methods - constructor, render() and componentDidMount. Once you're comfortable with how that all comes together, start to pick up Hooks
If you are doing asynchronous data fetching in your components, only using those three lifecycle methods will inevitably lead to bugs when your props or state update but your asynchronous call doesn't fire again because it was in componentDidMount. You need to use componentDidUpdate to trigger the call again when props or state update. Alternatively useEffect with the dependency array properly filled won't allow a stale state like that to occur.
React is indeed very steep, but it is very productive if your application is complex enough. If you are going to use Static Site generation (react-static) and GraphQl (relay), then React quickly pays off.
My experience with Vuejs/React is that Vue is easy to start with and good enough. But once you need more integration with the ecosystem, you realize that React has better support.
My experience with Vuejs/React is that Vue is easy to start with and good enough. But once you need more integration with the ecosystem, you realize that React has better support.
> Iirc the angular learning curve was negligible; React's is steeper,
Almost everyone I've encountered has found React easier than Angular, though React is more prone to lead you into analysis paralysis with options, since it covers less OOTB and there are so many alternatives that interact with React for each of the other bits.
Almost everyone I've encountered has found React easier than Angular, though React is more prone to lead you into analysis paralysis with options, since it covers less OOTB and there are so many alternatives that interact with React for each of the other bits.
Good call on React vs Angular, Although Svelte is the newest cool kid in town, I'd rather go with Vue than Svelte.
Also NextJS is the best way to learn React IMHO, but it adds a lot of extra stuff so maybe wait until you need it
Also NextJS is the best way to learn React IMHO, but it adds a lot of extra stuff so maybe wait until you need it
Besides the bigger ecosystem, curious as to why you'd go with Vue over Svelte?
I've used Vue for pet projects but Svelte a lot over the last 6-months and don't think I would reach for anything else but Svelte right now. (I'm sure that opinion will change over time, but between the speed of development, and the incredibly nice / fast applications I'm able to build, I've never felt more productive (on the frontend))
I've used Vue for pet projects but Svelte a lot over the last 6-months and don't think I would reach for anything else but Svelte right now. (I'm sure that opinion will change over time, but between the speed of development, and the incredibly nice / fast applications I'm able to build, I've never felt more productive (on the frontend))
I like vue a lot more.
In regards to the ecosystem, tooling is much better for vue. In fact, given how similar react/vue/svelte are, the tooling makes a big difference.
Other than that, I like that vue (ironically) has less magic than svelte. If I wanted to switch over to react, I could just use react+mobx for pretty much the same experience. Vue's reactivity is basically very simple observables that I can easily envision in my head. Even though it uses a dsl - there are like 6 directives that I have to remember that are pretty much common to any template engine (i.e. v-for, v-if, etc). Whereas, svelte has a lot more magical syntax that makes it perhaps more pleasant to program in, but not something I am willing to invest in until it becomes more mature.
I use the object style for components and really like it because it makes things more explicit and clear. I know svelte is smaller and so it's more productive for smaller use cases, but in the long run, I like the more explicit nature for when I am switching between front-end and back-end.
Also, vue is a lot easier to integrate incrementally since it does a fair amount of stuff during runtime in contrast to svelte which does the main work at compile time. The latter obviously makes it a little bit faster, but the web environment is slow enough that my other techniques (like lazy loading) are enough to cover for it.
In regards to the ecosystem, tooling is much better for vue. In fact, given how similar react/vue/svelte are, the tooling makes a big difference.
Other than that, I like that vue (ironically) has less magic than svelte. If I wanted to switch over to react, I could just use react+mobx for pretty much the same experience. Vue's reactivity is basically very simple observables that I can easily envision in my head. Even though it uses a dsl - there are like 6 directives that I have to remember that are pretty much common to any template engine (i.e. v-for, v-if, etc). Whereas, svelte has a lot more magical syntax that makes it perhaps more pleasant to program in, but not something I am willing to invest in until it becomes more mature.
I use the object style for components and really like it because it makes things more explicit and clear. I know svelte is smaller and so it's more productive for smaller use cases, but in the long run, I like the more explicit nature for when I am switching between front-end and back-end.
Also, vue is a lot easier to integrate incrementally since it does a fair amount of stuff during runtime in contrast to svelte which does the main work at compile time. The latter obviously makes it a little bit faster, but the web environment is slow enough that my other techniques (like lazy loading) are enough to cover for it.
I've found Svelte's tooling to be great. Can you elaborate on what's lacking and what Vue provides that's better?
I come from a Rails background, so I don't tend to find anything "magical". I guess to me, it's all pretty simple so long as you take the time to read how it all works. (I understand not everyone has time to do that).
I'm not sure about the incremental stuff- it may be that I'm used to it going fast. You should also checkout the latest Svelte (not public yet) from Rich, it's able to automatically show updates after every save, with state being kept within the refresh.
I come from a Rails background, so I don't tend to find anything "magical". I guess to me, it's all pretty simple so long as you take the time to read how it all works. (I understand not everyone has time to do that).
I'm not sure about the incremental stuff- it may be that I'm used to it going fast. You should also checkout the latest Svelte (not public yet) from Rich, it's able to automatically show updates after every save, with state being kept within the refresh.
Thinking react vs. angular as though they are trying to "win" some universal battle is just propagated by clickbait blogging. Enterprise + larger scale teams tend towards Angular, blog posts and hip projects tend towards react.
I don't think this distinction is exactly correct. I've worked on some enterprise projects with larger scale teams that have used React. It offers a bit more control than Angular does in terms of what your frontend 'stack' is comprised of. This level of control can be appealing for large projects.
I kinda see a trend that projects started after x date tend to use React over Angular, but I am unsure of what x is or how universal this is.
I kinda see a trend that projects started after x date tend to use React over Angular, but I am unsure of what x is or how universal this is.
Obviously some enterprises have used either. This is not about subjective experience.
Regardless, it should be obvious to anybody that has ever worked in a massive corporation that a DIY approach with react will not be opted for. Talking about the corps where most people get jobs, not the ones that publish blog posts on hacker news
Regardless, it should be obvious to anybody that has ever worked in a massive corporation that a DIY approach with react will not be opted for. Talking about the corps where most people get jobs, not the ones that publish blog posts on hacker news
In my experience bigger companies seem possibly _more_ prone to a DIY approach than scrappy startup. Especially if there is a 'not built here' mentality.
> Regardless, it should be obvious to anybody that has ever worked in a massive corporation that a DIY approach with react will not be opted for.
While it's public sector, I work for a fairly big, boring, enterprise org that doesn't publish anything on HN and for our apps that use a SPA framework, a “DIY approach with React” is pretty much exactly what we are doing,at least in my corner of the org. Never heard of anyone in the org using Angular (there's some shops doing jQuery/Bootstrap stuff, and some at least experimenting with Blazor which isn't surprising given how .NET-heavy the org has been.)
There was a time when Angular was sort of the enterprise Java of SPA frameworks, but I think that's kinda past already, and lots of big boring enterprises missed it completely.
While it's public sector, I work for a fairly big, boring, enterprise org that doesn't publish anything on HN and for our apps that use a SPA framework, a “DIY approach with React” is pretty much exactly what we are doing,at least in my corner of the org. Never heard of anyone in the org using Angular (there's some shops doing jQuery/Bootstrap stuff, and some at least experimenting with Blazor which isn't surprising given how .NET-heavy the org has been.)
There was a time when Angular was sort of the enterprise Java of SPA frameworks, but I think that's kinda past already, and lots of big boring enterprises missed it completely.
yes, hip "projects" like as facebook, airbnb, walmart, nytimes, netflix use react
I disagree with this statement. The last 3 projects I've been on, all huge enterprise level projects, have all been React. Angular was purposefully not picked on the first project because it gets hard to maintain on huge projects, and the last 2 projects were moving existing Angular apps to React for that same reason.
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.
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.
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.
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.
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!
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.
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.
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?
> 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.
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.
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.
Yes I agree, React broke that mould and web apps are better for it.
But it was controversial. The React team even got ridiculed early on: https://www.youtube.com/watch?v=x7cQ3mrcKaY#t=35s
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.
But it was controversial. The React team even got ridiculed early on: https://www.youtube.com/watch?v=x7cQ3mrcKaY#t=35s
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.
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.
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.
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.
React could have used syntax similar to hyperscript by default, like:
h('div', { class: 'm-3', onClick }, 'the text')
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')
navBar([navItem('Home', '/'), navItem('About', '/about')])
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
[1] It's still there in advanced guides: https://reactjs.org/docs/react-without-jsx.html
var h = React.createElement
h(...)
[1] It's still there in advanced guides: https://reactjs.org/docs/react-without-jsx.html
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.
Edit: typo
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.
Edit: typo
I think the reason is rather that React forces you to write a lot of JS and learn many concepts vs something like Svelte.
I also feel it has become more complicated now with hooks which, ironically, were supposed to make things simpler.
I also feel it has become more complicated now with hooks which, ironically, were supposed to make things simpler.
This argument applies more to Angular 2 and them bundling rxjs with it. Learning React was a very pleasant experience
> There's no reason for it to provide classes
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
...maybe week 3.
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
...maybe week 3.
> ES classes predate react significantly IIRC
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.
Appreciate the kind words :)
[0] https://redux.js.org/tutorials/essentials/part-1-overview-co...
[1] https://redux.js.org/tutorials/fundamentals/part-1-overview
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.
Appreciate the kind words :)
[0] https://redux.js.org/tutorials/essentials/part-1-overview-co...
[1] https://redux.js.org/tutorials/fundamentals/part-1-overview
> 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 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.)
I use react all day and the thought of doing it without JSX chills me
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.
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.
Your english is so articulate. iss this your native language, which i dont think so?
What is your native language and how did you get proficient in english? Thanks in advance.
What is your native language and how did you get proficient in english? Thanks in advance.
[deleted]
That’s incorrect, if anything it corresponds to .childNodes. The textContent property is a getter that extracts text nodes only from all the nested children of an element.