React Fundamentals: What I’m Learning
buaiscia.github.io
buaiscia.github.io
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.
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.
Anyone who has ever used the browser DOM and starts using react will intuitively understand this from day one.
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.
Still have no real idea how it's implemented, but it's pretty simple once you stop trying to overanalyze it.
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...
What does "fullstack" mean these days? Express and React (single language and two frameworks)?
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.
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
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))
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 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 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.
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
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.
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://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:
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
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.
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.
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.
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.
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.
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.
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 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.
Nah, that would probably be another framework, Angular is the usual offender. React-Router handles this perfectly.
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
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.
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.
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.
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.
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.
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.
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.
h('div', { class: 'm-3', onClick }, 'the text')
div({className: 'm-3', onClick }, 'the text')
navBar([navItem('Home', '/'), navItem('About', '/about')])
var h = React.createElement
h(...)
[1] It's still there in advanced guides: https://reactjs.org/docs/react-without-jsx.html
I also feel it has become more complicated now with hooks which, ironically, were supposed to make things simpler.
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.
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.
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
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.)
What is your native language and how did you get proficient in english? Thanks in advance.