As a react dev in a previous life, my interpretation of the web development world is that there are so many abstractions and tools, that the ecosystem encourages learning top down, "just do it this way" and then peel back the layers. This is the opposite of developers whom are used to learning bottom up, starting simple (i.e C, memory models) and adding abstractions later.
this is not even top-down approach really. because via usual quick react tutorials you don't start from next.js AND finish with really bottom thing. you see only top part. but it is what it is
The problem with this approach is that it allows people to get real IT jobs without ever getting around to actually peeling those layers back. You already get results, why bother going deep into how it works, right? I once made a backend for a guy who just learned React but somehow didn't know JS itself or the basics of how the web actually works. I had to explain him what an XmlHTTPRequest is and what I meant by "pass me a parameter". It's my own anecdote but it does show a glimpse of how bad this whole idea really is.
@@ninox14 dunno im using vue and nuxt... and have no problems understanding what's going on... their docs are also very good a lot of effort put into it... remove the abstracxtion, it's also just render functions of virtual dom nodes, patching and merging with real dom , ; )
I use react, I use it because there's a market for it so I don't feel at all personally attacked by any of this. I think it's cool that you're trying to learn how everything works from the ground up and I wish that there was more content that tried to do this in the React world. I don't know why people feel so attacked by this stuff. Weird.
Web development is just cesspool of fast and instant thing after all. They feel attacked when someone actually peek into their shallow understanding of their thing lol.
Regardless I think people need to distance themselves a little. Being upset because people attack the framework you use at work is laughable to me. But maybe that's because I don't create my entire personality off of being a developer.@@wsak5991
In biblical times Babel was literally the collapse of a single easy to understand language into thousands of languages. It resulted in confusion and mass-hysteria.
@@Zircuitz This is also just Create-React-App being bloated and slow. It hasn't even been the recommended way to start a react project for over a year at this point. That's why it wasn't recommended in the docs when Tsoding looked at them. But Vite should have been the most obvious react beginner friendly choice, not the huge metaframeworks like Next or Remix.
As a react dev who doesn’t make the library his personality, I find this to be entertaining and I even agree to some extent. These frameworks are crazy.
My condolences. React isn't that bad, what's bad is the entire bullshit of nodemodules and webpack and shite. By the way, I use Fable, and the Elmish architecture, so after that shit, everything is just F# I don't know why don't I use and HTMX instead. But oh well. I hate my life. The next WebApp I made will be in C++ and will only use the its going to be literally easier to manually program shite in OpenGL.
@@monad_tcp What would you use if not webpack? How would you assemble your application wiithout pain and split it into nice chunks? Ofc, you could write your own solution but then again: why not just stick to webpack which covers all your needs? What soulution would you bring up , not using all those modules? It is impossible. You have to have modules otherwise you must write your own one giant module which covers all possible use-cases. And also note that he used "create-react-app" that has many unnecessary things. You can configure your project on your own and have like 10-12 small-to-medium packages.
49:47 The reason React DOM is separate is because React just creates a tree and tracks updates. In truth you can use react to render to anything, not only the HTML DOM, but iOS widgets, Android widgets, or even receipt printers over UART.
Yeah the virtual DOM is there for a reason. It's made to scale. Gretcha.js reloading everything every time something changes will eventually be slower than React for a large enough app. If Tsoding were to keep extending Gretcha.js, he'd end up with a virtual DOM. I challenge him to prove me wrong.
@@SpeedingFlare Why is it weird? Like OP said, you can use the underlying React model for many different things besides the browser DOM. React Native will have a dependency on React, for example. It would be weird if you had Browser DOM code in your React Native app. It just makes sense to separate React from React (for) DOM.
@5:06, when you haven't even had time to break out your editor to write the obligatory "Hello, world!": installed 1459 packages. I feel your pain. We're all in a world of hurt.
3 days ago I literally just wanted to create simplest possible hello world in the react. I used create-react-app, I saw 60k files in repo and I uninstalled it in shock immediately and went with plain vanilla JS
tsoding, a big fan here. I agree with you about understanding from the ground up. I don't agree with the approach of not giving the article a chance. Most of the video you had the answers in a scrolling distance but you just got frustrated and returned to the familiar emacs screen. Also, react is not only for recursive elements but most of it is designed to render parts of the Dom that changed their state, but cache the rendering of the trees that didn't. Thus, react enables a convenient way to run heavy stuff on the client side.
Also the expectation from him that the docs should start directly with a deep dive how everything works under the hood, is "weird". Like how many developers gonna build stuff from the ground up. Its just a bad learning strategy for most. (not saying that looking under the is bad). The docs like you say pretty much explains alot how the stuff works without the need of explaining how to build it - what an edge case that a dozen of people will do
@@moritzschuessler The issue presents itself when a new developer gets told to learn react and they have no idea how anything actually works. They might be able to create a website, however they don't understand much about JS, just about react. Whenever they try to move onto something else, it will be a much greater challenge, this starts with the mentality that the base understanding of your tools should be ignored for instant results, even if that means you will bear the consequences later.
@@moritzschuessler That's not what he is criticizing. If the docs literally just "picks up" devs where they "normally" left, aka writing html and css and how react gets hooked creates the root etc. and how react virtual dom interacts and renders the actual dom. And how "react" is actually build out of, list the packages, modules and give an overview. That would be better than starting off with, "here's a magic jsx file, write "Button" that returns react elements and watch it work magically!" That's the gripe he's having. Thats the gripe many people have. Noone has anything against what react is trying to do.
Why do you even need a shadow DOM? Because HTML wasn't built to do shit like this and isn't performant otherwise for complicated UIs. It's just a solution to a self-created problem.
@@astrixxvirtual dom and shadow dom are completely different things. and if you insist on rendering everything e.g. in a canvas rather than html, you lose the semantics which allow screen readers etc. to work. literally noone thinks this is GOOD, it is just how history has played out.
I think people are saying that it's painful to watch, not because you are exploring and trying to create a functional React project from scratch (that is actually pretty cool, and I think every web developer who wants to really understand React should do this at least once), but because a lot of times when you say in the video that things are bullshit, they aren't bullshit (not always, sometimes it really is bullshit). It's just that you are literally learning and seeing the packages and tools for the first time, and you didn't understood what is the need for them to exist. React and ReactDOM being separated packages, for example, makes all the sense in the world because React is not only used in the browser. So it makes sense to have another package that handles browser-specific functionality, while React can focus only on creating component trees that can be rendered anywhere.
I just think it's fun when he goes through exactly the same emotions and reactions as I did when I started with React. I did it more or less the same way.
A fine example is tsoding knows that he needs a ReactContext to render React. So he opens up the documentation of ReactContext with "how does it work" and skips the first sentence which describes what it's used for and instead looks at the code on how it's used.
I think people are mad because they're thinking "oh no he's using react the wrong way, how painful!". When in reality he's not using react, he's trying to understand it by piecing everything together from the ground up, and consequently, understanding how everything works.
The fact that it is impossible to tell how your react project actually works because it's obfuscated behind 1400 mandatory dependencies that take two minutes to install by default is probably part of the issue
@@CyberDork34 yeah, it's not impossible (tsoding just proved it to be possible), but it's definitely way more complicated than it should. I've never done any serious UI development, but if I were to do webdev, I would definitely just use vanilla JS, but "me + webdev" is probably not happening anytime soon.
@@CyberDork34 Its why I just dont want to learn or use react. It feels like an amorphous blob of mulch. It just feels super heavy because there so many dependencies. So many single person projects the world depends on. So many cpu cycles wasted doing absolutely nothing of worth.
Most fun vod I've ever watched, you should create a series trying all these huge ass /frameworks that people don't understand in depth, it might as well be a good learning point for them.
React developers are React users, they are not developers of React. I fail to see why it would be valuable in any way for them. Do Java devs understand JVM? Do C devs understand LLVM? The whole point of documentation is that you are not supposed to understand how a library works, let alone the tools needed to build something. I understand that some people are frustrated with not understanding the underlying mechanics due to a lack of documentation but stop kidding, most developers do not understand how underlying tools work simply because they don't need to
@@xcy7I don't understand everything about the JVM but I understand the principles of how it works (JIT + the intermediate machine code-like language that the JVM then executes). I don't understand LLVM but I understand assembly and I understand what my code eventually turns into, at least pre-optimization. In fact, understanding this is crucial for C/C++ devs, as knowing it will let you make your code easier for the CPU to cache and execute it faster, and even without digging into that stuff, pretty much any C/C++ developer knows the performance costs of working with heap-allocated memory and jumping around pointers all the time. You generally need to understand at least somewhat wtf is going on under the hood to make your application not run like total garbage, but unfortunately most web devs (and web users) simply don't care about performance all that much
@@xcy7 This is not even something you need to develop React, but just a "compiler" toolchain, which is like saying you're learning c and instead of learning how gcc works, you go straight to makefiles cmake and all that shit. You're not a software developer, you're just a baboon putting the puzzle pieces together.
At its core, React does the same thing as your grecha.js, but instead of recreating the page on every change, it does a tree diff to only update the nodes that changed. That is all about optimisation, and that is all the stuff that you hear about, like "virtual DOM". I also think right now it can also do partial updates to stay within 60fps budget if an update takes longer than a frame. It also does some spooky stuff with "hooks" to save state inside the tree instead of global variables, so you can create multiple counter components, each with its own state. Also, someone did make an alternative framework called Preact, which does all the same stuff and is 10 times smaller
Im not much a fan of the virtual dom explanation.. Like why are we selling react on stuff like performance because of internal implementation details you dont even get to interact with? In the end react "apps" are slow as hell, spend too much time processing re-rendering of components and effects. I think we should sell it on its actual strengths like reactivity and declarativity, but its like selling functional programming to people, they only get it when they are deep in the weeds.
The speed of coding and building stuff is more important than the performance in the Browser, which, unless you do something horribly wrong, is already so fast, that the user wont notice any loading. The only bottleneck is the data fetching from the backend.
@@coldtech06 React's selling point is DX and ease of use. This attracts a ton of beginner developers lacking fundamentals. They write inefficient software. Business rarely cares about performance on the web. It is absolutely possible to create fast and responsive websites with React, but unfortunately it's rarely the goal.
@@wsak5991 From my experience if you prioritise speed of building too much you get to a point where everything is unmaintainable and you need 10x more devs to still work on it. Which creates even more issues. And react is created by Facebook and their browser application is so painfully slow it's barely usable, no wonder they moved to native apps on mobile
Nobody gives a shit he is trying to understand how stuff works, they get mad when he skips the docs and just starts pasting random code and thinks it should work. But pasting random code from the internet without reading docs is advanced webdev, so Tsoding might be senior webdev after all.
React and React DOM are separate packages because React is just a reactive/declarative runtime that creates a tree. React DOM will use the result of that tree to render HTML, but you could use the reactive/declarative system for other stuff like rendering stuff on the GPU, or making terminal GUIs with a lib React Terminal. Basically React is just something like the lib S.js with JSX syntax and stuff like contexts. (very good lib btw you should look it up, basically react without the bs, maybe you can break it appart and create your own react competitor (again)) And React DOM can take a react tree (just a bunch of objects) and render HTML with it.
I mean, it literally doesnt get simpler than this: const greeting = S.data("Hello"); const name = S.data("world"); S(() => document.body.textContent = `${greeting()}, ${name()}!`); name("reactivity"); With a single dependency, S.js itself
@@coldtech06so you have bagilion of those and also some of them are accessing the server and some are generated at the server and some share state but in different modules and styling must not affect other components and other things 😕
I am a react dev, this video was 1. Hilarious 2. Educative 3. Insulting 4. Realistic 5. Amazing. I see that your way of doing things is way way beyond what a normal dev does, and the fact that people were frustrated that you digged so deep is funny lol. When I started learning react I started it like this but guess what, There were billions of dependencies that if I started trying to understand everything at this level I found out that I would never have the time to create stuff, it's too much but this was amazing and thank you. Would love to see something else related to web development
If you want to build a window, do you have to know how glass is made? That part was already taken care of by someone else, same with react. Only in coding people are so obsessed with building everything from ground up.
@@wsak5991 its not about building, it's about understanding, thats why we are all dependent on stackoverflow ( or chatgpt now ) because we don't understand how everything is working, which is normal but to try and understand everything it's amazing, only people who truly love programming do that
@@wsak5991 maybe you want to know how the glass you are using in your window is made if you want to create a certain type of window? Maybe this kind of glass is better for large windows? Maybe there's something about a certain thickness of glass or the way they manufacture it that makes it bad for creating a certain kind of window? Knowing how something is made from the ground up is crucial for mastery of a discipline. Unless you're some fucking amoeba brain who can only glue together parts of a project like a braindead robot. You do you I guess.
@@wsak5991 If you want to use concrete, you have to mix it on the spot... You have to know how the concrete is made. Yes, no single person is going to bake the specific sand that you need at extreme heats to make windows because it's simply a lot cheaper to have it made in bulk at a factory, but the people in that factory still need to know how glass is made in order to make the window. Somewhere down the line there is someone who needs to know how something is made, things don't just appear out of thin air. The personal question is just; "Do you want to be the person using the products, or the person inventing the products?"
46:28 the NextJS tutorial actually goes through this from the ground up. they have a section called "from Javascript to ReactJS" where they explain this.
More please. I love the way you learn and obviously your learning process is great. Obviously the learning mindset is not the productivity mindset and people who were unhappy in the chat probably dont have the learning mindset.
Look, I am a beginner dev. when I was told "oh you should learn react" and I started doing tutorials, I would say the samethings "why JSX" "When does this get converted to JS?" "What is doing it?" "How is React managing the state?" And NOTHING answered those questions. fumbled around forever just messing with react. but I don't really have the skills or intuition to know where to look. SO this video was insanely helpful and thoughtful. Not only did it help me understand whatis going on under the hood. It gave me ideas on how I can piece apart new technology and how to mentally reason about it. I want to know: when SOMETHING goes wrong, or when I see some behavior that is really odd and stupid, I want to be able to reason about it. Just remember, the people that understand React at this level are the same people that are answering your stack overflow questions when you dont know what the hell is going on with your web app.
That generated product of JSX is big blob of 1 function. What you write in JSX maps to a function. That's why React elements could be either function or string.
Back in 2016/2017 there have been multiple presentations around "building React from the ground up" so that you can get all the points you make. It's unfortunate that it's been lost to time.
1. Every single real web developer knows very well how al this high level stuff works, because this is how we used to do things back in the days. (react is a 10 years old library) 2. Imho, The fact that you tried to learn react from the ground up is a good thing. 3. react (the library) is a library to create web and native interfaces. ReactDom is just the way to go to render a react app inside an html application. There are even tools to "render" react components in cli applications. (a good idea for a video?) 4. React is capable, at each render cycle, of updating only those portions of the DOM that have actually changed (diffing). 5. Your grecha.js stuff is just a meme at implementing counters (it rerenders the entire shit at every button click). 6. document.createElement is not a valid alternative to react components. Native web components (maybe) are. 69. Love you
hi, does your point 6. apply to other frameworks too? is there anywhere I can learn more about that document.createElement is not a valid alternative? Thanks
For me the problem with react is the shitty rerender stuff. You have toons of optimizations to do with child components. When you refresh the parent it will rerender everything which is bad in many cases. The useEffect is a problem too when it rerender twice for litteraly nothing. Most of the time it's not a problem but React is not that good for performance because only few devs are aware of this or do not take the time to optimize their app properly. Time and budget are often the problem and this part is skipped... I tried Web Components once and i think the industry is not ready. There is a lack of ressources or projects based on it. Stencil for exemple is a piece of shit. If someone ask you if you could start agnostic stuff with it run for your life !
I think its a difference in goals. If you want to learn react to make websites or for job security then you do not need to understand what happens under the hood. React is the means to the end (the end result being the product or react dev job you get). If the end goal is to learn react as a library, how its implemented then of course you are going to look into the underlying layers. Maybe you do this for your own curiosity, or to learn design practices and expand your knowledge of techniques and design philosophies libraries use. In the end it all depends on what you want out of it. It just so happens many of us aren't that interested in that, we just want to make a cool website or get a job, thus we arnt bothered with technical details under the abstractions. Whether this makes us seem worse or better than those that do look into the details lies entirely up to your values. If you value those skills then sure, we seem inferior, similar to how on the other side, they may view looking into the details as a waste of time. Because of this, i wouldnt say either side is "inferior" or "wrong", just that we have different goals.
theres also the fact that most web devs are either self-taught or comes from bootcamps, i don't blame them for not knowing how things actually works but for the others theres no excuses imho
I understand the sentiment, and I agree that practicality may outweigh deeper knowledge in same cases, but it's not "we seem inferior", it's quite literally that you (not you in specific) don't have any idea how the library you use works. If you're using React professionally, it is almost unbelievable to me that you would neglect to be proficient in JS to the point that, at the very least, you can set up react without needing automated tools.
If you're a React developer and got offended by this video, please watch any of his other videos. His approach to learning things aligns with how a lot of software developers go about learning new things. This is exactly the reason why it's so frustrating to start off with modern web development. So much weird stuff going on without any explanation, and the documents kind of just seem to ignore it and stick to copy-pasting basic commands.
I've been a React dev for about four years now and your observation is spot on: The problem is that these Getting Started tutorials are written with an absurd number of guardrails in place. They're intentionally dumbed down to give people instant gratification from running magic bootstrapping commands and then seeing an app on their screen; their goal is not to explain how the framework works under the hood. Then those devs walk away feeling like they learned something when in fact they didn't. I feel like this is an attempt to cater to non-CS folks or people transitioning from other career paths to web dev, so the framework is trying its best to not overwhelm them.
I got crushed by one such tutorial. install the thing copy the code look magic you're a react dev now! uh, no, you didn't explain how any of this did what it did. I understand nothing.
Funny to see how the guy who has never scratched the surface of react turns out to know more about react and web development than 99% of so called "senior react developers" upd: Tsoding man, cudos to you
I'm really glad for your work of unraveling its mechanics. Until now, I was frustrated by not undestanding how React really works, and nobody seemed to care about this. I was only encountering those "copy and paste those lines of code" tutorials. It is sad the lack of a concise documentation on what exactly it is and how it works.
I got so frustrated trying to get details from the docs that I went on a deep dive just reading the source code for a few weeks. It was painful, but it worked. I don't know everything, but I basically understand fibers, and have a loose understanding of reconciliation. Now, hopefully I never have to write any react code in the real world.
This was actually kinda eye opening as a react dev I just use pre defined functions and methods of react and other npm packages and I have never even looked at the implementation code of any of those packages
You don’t have to honestly, unless you’re contributing to React itself. It’s not realistic to understand every framework down to the machine code before you use it. You’re meant to use the API that react provides to make applications, not modify the react source code itself. However if you do want to learn how it works, you could Google “how react works” and that’s a starting point. Then look at the source code and it’ll make sense. Instead of doing what this guy is doing - barely even reading the user guides and complaining.
58:41 JSX is not limited to React, so "onclick" JSX attribute is transpiled as-is into "onclick" property for createElement funciton. And then it is React code that tries to find onClick but finds onclick and yells at you. Considering that Facebook created JSX specifically for React it is surprisingly stupid that static analisys is so weak. I guess it's a JS mindset, where failing at runtime is a norm.
** literally scrolls past it without even trying to read ** - the don't show you literally how to instantiate it! (not defending react though, modern web dev is an abomination)
56:30 but with react, we can isolate states using components. each component can have its related states and re render based on its own states. so the flow is a lot more predictable and easier to debug. in my opinion frameworks like svelte and solid are easier to understand ( the magic that's done by the framework ), but even react has this benefits over vanilla js. it's also harder to handle conditional renders and cleanups in vanilla js, react already provides apis that makes it easier to handle them.
dude, you are too self assured - why is ReactDOM a separate package? Because normal React is generic, and can work outside browser with a DOM context. - I don't know if anyone is using it for something else, but probably ... it can be used to "drive" arbitrary expensive tree by applying the diffs ...
it definitely SHOULD be a separate thing, and I like they made it reasonably. - It comes from the fact that JS has no GOOD dependency tree shaking, so you have to not include things like this.
It always surprises me that people don't want to explore how stuff works. Most of the programmers I've met care only about the end result. It other words the program they write. I always want to explore how my program actually works. Whether it's exploring the internals of some framework or learning assembly because I want to know how computer executes my program. Maybe I'm the weird one though.
I want to know how stuff works. What I've realized after a lot of pain is that I don't need to know how stuff works to use it. I'm very bad at black-box mentality since I feel the need to know how the internals works to use a tool, which is bullshit. Neural networks was the eye-opener for me. I was severely hampered by looking at hours of video lectures about neural networks and learning how the math symbols are used. So I slowly learned how they work, but I got no actual programs using them done. A sandwich approach from both ends, slowly learning from the basics while also using existing tools and examples to get practical experience is a better approach. The people who figured out how to effectively use backpropagation for training certainly weren't able to figure it out from theory alone - they had tons and tons of experience in neural networks too that aided them. For NN especially, trying to learn and write stuff from scratch is super painful since the NN code has to be pretty damn good and written with a lot of knowledge to get good results for any larger or more interesting datasets. The libraries are written by experts and it would be silly to evaluate their work without at least moderate understanding of the field. I've done that mistake enough times already.
FYI: react-dom is a different package because react (the core library) is designed to be platform-agnostic. You could therefore use react with react-dom and target the browser or you could use it with react-native and create android and ios apps.
Maybe you could abstract the refresh part into a function, something like useState which takes a value and returns a getter and setter and the setter calls refresh. 🤔
It doesn't returns a getter and a setter. It returns a VALUE and a setter. The thing you describe here are Signals. A getter is a a function that return a value AND the ref of this value. But in React we do not have a "useSignal" hook yet which is sad... Because of that, instead of declaring just a signal we have a bunch of hook to use if we want to achive the same (useState + useEffect + useMemo). Angular is better on this point
The problem is the gap between programming as a craft and programming as a job. Most people get the job without really learning the craft. The moment you've come to rely on a framework to make things easier as your starting point is the moment you cease to be able to function as anything but a cog in a corporate machine. Programming is programming, no matter if it's high level or low level, but if you're working at a high level, you have to understand what's underneath if you want to write good code. If you can do that, then the framework you use is irrelevant. If you can't, then you are dependent on the framework's environment, and are subject to all its problems.
Got at the end. 100% agree with Tsoding. My complimentary notes on React. First, the "real tutorial" is called "React Internals" (this is where they talk about React.createElement, etc). Second, all of that crap is bloated and obscure because "modern devs" adds an entire abstraction layer on top of a simple problem: React abstracts an UI component graph; ReactDOM abstracts using React on DOM trees (i.e. update HTML pages); JSX abstracts away "React.createElement"; Babel abstracts transformation of JSX into JS; Redux abstracts the state (i.e. global constants); NPX abstracts the setup of all of that shite... And thy Lord shall have mercy of anyone spreading some blasphemy like simplifying things or asking normal devs to understand anything beyond what's written in the tutorial...
I love the "Make a counter" request. In no time Tsoding realised his framework didn't support state change. The next request could be "make a page with 1000 buttons and counters". In no time he'd realise that refreshing the whole page when one of the buttons get clicked is overkill and will result in performance problems and/or unexpected ui behaviour like jumping back to the top of the page. He'd have to make his framework selectively reactive.
There is a good reason that react and react-dom are different packages(also when using tools they are always both included). They are different things. React has the diffing algorithm related details and hooks etc. etc. React-DOM is just the rendering side of it on the browser, that's how react can be used in different contexts like mobile development
Duuude, I never felt more relatable watchig programming content. I thought I was just stupid for not understanding and not appreciating 100 layers of abstraction.
"Why do we need React?" I would ask "Why do we need reactive frameworks?". And we need them, because with old way of writing websites (using JQuery) was extremely painful to scale up web apps that are automatically updating data onchange. Frameworks are tracking data by themselves and they update the DOM automatically when data changes. Also frameworks allow to create separate components (kinda like old twig/blade templates in PHP) which gives you the ability to reuse some views
This is super interesting, informative, and hilarious all at once! Who knew you just need to include 2 files to start writing React! Thank you for showing this as always.
he is talking about the abstract levels. Most frontend developers have no idea how their frameworks or libraries work, they might know something in theory but if you would ask them write their own jsx based framework they wouldn't be able to do it. They feel pretty comfortable on their level of abstract and there is no need to go deeper. That's why I am not considering them as the engineers they are just developers, not even programmers
I consider developer and engineer to be more catch-all terms. I'd describe them as point and clickers. They point and click to put stuff together that other people wrote.
I used to develop using react, and after some time of developing apps in react i was realized than much faster and optimized apps with same functionality can be done with vanilla js and also with much lower filesize than react apps and also you can control every symbol in your code and every byte of optimization
56:41 the reason why we need react is because it stores all elements in memory and when it's time to rerender to compare which element have changed it uses the react reconciliation strategy so that it doesn't traverse all the dom
The DOM is already in memory, you don't need a virtual DOM and fancy diffing algorithms if you just change the elements that need to be changed. This is why other frameworks (ex. Svelte) don't need a vdom and are faster than React.
@@youtubeviewer7077 yeah, but in the way he did, you get messy with state management once the code gets more complex, React isn't Svelte or Solid, but still better than this
This is gold. Seeing this god programmer struggle to navigate web frameworks, gives me reasurance that I am not that dumb feeling lost when dealing with frameworks.
Recently I trying to get this conception asking to myself: How this works? And dude, programming turns so much interesting. I love it how do you dissected the react and how this works behind. I use react for like 2~3 years and I never get this attitude. I really didn't understand why the people was hating, for me is so much interesting to see. Great video!
I do both web, backend and application dev, I love your work, made me brainstorm little bit. That why I tried to run away from web dev, and python dev. Involving into web/ python dev, It was like let thread panic for pleasure
Abstraction is the greatest form of complexity. Many devs don't care about the underlying functionality. Sometimes before I install a plugin I read through the code. I just ship and adjust it as a util rather than have npm module. Curious people build consumable plugins but most consumers don't like checking on the underlying details. The more you can offload the better.
If you want to do freelancing Im sure you will find a more juicy marked with the skills you already have such as C, Rust and all that stuff. Those skills are much more difficult to find. In today's job-market you lift a stone and under it come out react developers from below like cockroaches hahaha. I really enjoy your videos!
i am a software dev and i agree with a lot of tsodings frustration here. i love using rust (hoping unsafe rust becomes more stable soon for more fun) but i dont like how core features are left to separate community packages. i understand that there are benefits but it leaves a fragmented documentation quality experience. it's incredibly frustrating to not understand how a function works just to read empty docs with no examples. the standard library book is so good but when developers rely on community docs the quality drops significantly
for a scare, read the syn documentation. it is a recommended community package for developing proedural macros, a core rust feature. you'll find lots of empty pages and links to entirely underdocumented libraries that it uses. everything is abstracted away to the point of confusion with a thin interface over it
@@Cmanorange This is one of my chief arguments against Rust. At least C tells the truth that the standard library is basically empty. If I'm going to use a different language, it needs to provide nearly everything I've got in my own libraries. If I have to depend on a rando third party who may or may not be a good developer then I'm going to have to write it myself to have any trust in it, and I don't want to take the time to rewrite my own libraries.
@@anon_y_mousse I mean rust has a lot of libraries available, of course granted that it hasn't been around for that long so it won't be as big as some others. However, I'm pretty sure that they explicitly state that it's meant to have a small standard library because it's meant to be extremely lightweight. The main attraction to rust is the compiler, which actually reduces risks associated with third party libraries.
It's really interesting to see the attempt to _understand_ the mechanics of web framework. Wish I had the same mindset. But I'm just trying not to use frameworks.
But he doesn't attempt to understanding anything. He looks at the generated javascript(the calls to React.createElement), exclaims "but there is document.createElement, dont you know????" and then assumes he understands everything about react.
He isnt really tying to understand react. He is just trying to bundle everything from scratch - what will him not make learning the concepts and problems of the framework. Needing to know how to bundle JSX/React to make workable code with his approach wont be necessary for many. Its a edge case that a few persons will do. And there are actually good content explaining exactly that. Saying that react is shit because the first page in docs isnt "ok lets take 2 days to explain how create-react-app bundles stuff and how stuff works under the hood. Then we will show first code" isnt important. Its more important to explain the concepts of a framework and spinkle in the how its does things under the hood. Have you ever read a classic old backend doc? they literally throw some compiler output at you. nobody will learn with it.
I'm a react dev and this stream was enlightening. Your theory is close- but it's not the dirt they are reacting to, it's their ignorance. They are frustrated that they cant give you the answers to your questions. On the other hand, you are definitely trolling at times 😂. No, it is not strictly necessary to use anything other than vanilla js. Do you need it for for a form submission? Clicking a button? Tracking count? Making a website? Of course not. Does it make developing and maintaining large stateful apps in the browser easier? Yes. Yes it does. Is it the only option? No.
I came about your vod by the powers of the algorithm. And as a mostly react dev, let me tell you this video was highly instructive. I trully believe that if most frontend bootcamps pushed for students to create a react app from scratch as you did as a form of evaluation, none of them would pass. And so thank you for a much needed wake up call. For reference: just tried Django a few days ago, and the fact that Django comes packaged with: a templating language, API route handlers and database management tools; it just, blew my mind.
what people are missing from this video: > tutorial installs 1500 dependencies > then the guy manage to gather react, react-dom and babel for running everything I checked out the dependencies of react and react-dom which are just 2 in total: loose-envify and scheduler. Nothing more. I'm not a react dev myself so I cant say what are they offering within all those dependencies but it is worth to put things into perspective and question: is it really doing anything better or easy? In the video we can see that babel dont even check for correct html attributes during the jsx parsing.
I struggled a lot learning React because of this "top-down" approach. After read `build-your-own-react` from Rodrigo Pombo I've finnally understood. Even those quirkies of separated packages react, react-dom. But I've loved every single second of this video and I couldn't agree more with the current state of react. And it looks like it is going even deeper with RSC.
Getting stuck in an unclean state with an Angular project (Angular is much worse than React, btw) as well as having to deal with an insane build system that took forever (not even kidding. Before I optimized it myself, it took longer to compile said Angular website than it took to compile a Linux kernel on the same machine) inspired me to work on my own framework written in Go. WASM is a godsend for those of us who strive for more than resource hogging webdev.
I love how you‘re really exposing how everything works under the hood. Wish the entire space would approach teaching fundamentals as raw as you do here! This gave me a lot more insight into the tools I‘m using everyday
I dislike using React and the massive bloat of the npm ecosystem as much as the next guy, but the constant bashing and strawmanning is incredibly exhausting. Like, no shit, state management isn't incredibly difficult in a tiny play project. JQuery exists. Obviously JSX isn't "necessary" to produce readable code. Mythril exists. There are legitimate issues that larger frameworks address that with *never* be encountered by a small project. I'd argue that even medium-sized projects can avoid needing any sort of framework if you have competent developers.
learning react for a year. Applied everywhere for react jobs. create many projects in React for portfolio. But still can't get Job. It is that how u make money?
I loved this video so much! From someone who was introduced to computers in 1983 via a Commodore Vic-20, a BASIC language syntax book and Bruce Smith's Machine code book, I had no choice but to "learn" by understanding low-level concepts in order to develop high level abstractions. To me it seems frontend developers are more likely to find the inner workings boring whereas a backend engineer thrives on the knowledge of how everything is working down to it's basic cycles. Great content. Thank you very much.
Nice react-reaction. Frequent F-word usage was what I would expect. I have been tinkering with Internet stuff since before WWW, the first webserver I set up was the original CERN httpd, and I've read the standards RFCs since HTTP draft (version 0.9), which was really just a slight extension of what people were already doing ad hoc with various fingerd implementations, IIRC. (And finger/fingerd is probably the classic TCP/IP programming equivalent of "Hello World".) The whole WWW weirdness has since evolved into what I can only describe as complete insanity. Arguably this is just a corrollary of the more general statement about IT in general, of course. With the hyping of Generative LM "AI", and whatever other forms of socalled "AI" shAIte people are developing, I foresee that we soon will learn what happens when machine learning models are fed machine generated input in large quantities. It will cause feed back loops that just have to go completely bananas - but people will at that point believe anything. News at 11: Breaking - End of the world as we know it. The complete downfall of civilisation winthin the next 8 years.
Just to add a bit of context here: Q: Why do I need to install react-dom? Why shouldn't it be part of the react lib? A: Because react is platform-agnostic. The core lib implements a tree of nodes (VDOM) that can dynamically update when the state changes. react-dom translates these instructions to render to the DOM, but there are other targets that don't target web, like react-native which renders to native iOS/Android elements, react-pdf (PDF renderer), Remotion (video editor which uses ffmpeg), etc.
49:36. Why there is a separate package for rendering is because react is used also for mobile development (react native) so rendering in web and mobile is different, to have it possible to use the same logic for creating apps they needed to separate the core react features with rendering part that's why they are separate packages
im a web dev and i fucking love this video. the ecosystem is dogshit, the language is a hack - it doesnt mean its bad, its just how it is. anyone wanting to learn react should actually watch this video first before even looking at any tutorial!
Not an expert but most stuff tend to have sort of abstraction layer on top of it. Like you dont need to know about how processors or ram works to use computer, sure would be good to know but most probably dont need. Then if you know about processors and stuff, you can dig deeper with transistors and diodes and how voltage is regulated. I doubt many think about the movement of electrons and em waves while using internet. One can always dig deeper but for most people its not necessary for them to make some simple web app
the thing is react is not an abstraction, it's a bloated monster. Yes you do not need to know how transistors work in order to program, but you also don't need to buy an industrial lumbermill to chop up a plank of wood for a fire.
The frustrating thing about this stream is that you are indeed asking really good insightful questions but doing it in an incredibly negative and dismissive way. Like asking why "react-dom" is a separate package from "react". That, in and of itself, is a GREAT question to ask. But then you just have to follow it up by saying that you think it's stupid and it shouldn't be that way, even though you know nothing about the architecture of React. Or you go on a rant about how your chat is frustrated just because the entire stack is shit and you're just exposing it. Umm... maybe save your judgement for after you've learned how React works? Probably would've lead to a much more calm and productive conversation with your chat and you might've even got the answers you were looking for from them. I think it's more than clear that this was sadly not a good faith exploration of React.
What exactly was frustrating about it? also a "calm and productive" outcome might be less desirable than a truthful answer to the question whether or not this stack chaotic. (obviously the video is a literal proof of that and hence the value of this video in the first place to be uploaded to yt)
It s a joke for him, he is a low level developer, he doesnt care about front-end cause his channel is about true diffcult things and this is what I am here.
I enjoy that you made this video learning from bottom up, but sometimes you criticize wrong things. For example 58:23, onclick is a JavaScript attribute, and onClick is a React attribute. So the transpiler didn't catch it, because it's a valid JavaScript attribute. Or some other things like why do we need React if you can just use document.createElement... But that's basically what React is, but more robust. It's more convenient to write code that looks like HTML and then compiles to functions that create them, than write those functions. Maybe it's bigger than it could've been, but it's still the most robust.
Lol, this is awesome. I just learned react and was quickly productive but still got impression that the build/tooling is pretty bloated/over engineered. Can you do an episode breaking down and roasting the spring framework? Or developer experience for a java project lol
The reaction of the chat to you exploring how the sausage is made is actually hilarious. Whats wrong with learning from first principles. Once you run into a crazy issue and you have no idea where in the framework things have gone wrong, you will need to know how the sausage is made. Its unavoidable actually once you move beyond some simple hello world app.
I am so glad you called out these frontend "engineers" who are proud of centering a div. They have some serious inferiority complex knowing in reality they have no idea about the tools they are using. Very glad you dismantled their fragile egos
I think the problem is people like me are new in this, and don't even ask this kind of questions yet. But for me, all that work you did it just awesome
React developers who are offended by this are not Software Engineers, they are Software Masonries. Having an inquisitive mind to understand how something works is Engineering 101.
I think one of the reasons why such overly bloated web frameworks/libraries exists is to allow web devs to excessively charge clients for unnecessarily complex setups and maintenance of sites. But respect for wanting to get under the hood of react, I don’t know why people were mad at him for that.
As much as I always look forward to your content this was really painful to watch. Not because of you learning React as you go but due to your noticeable elevating aggravation as you get heckled and annoyed by the comments from the chat.
As a react dev in a previous life, my interpretation of the web development world is that there are so many abstractions and tools, that the ecosystem encourages learning top down, "just do it this way" and then peel back the layers. This is the opposite of developers whom are used to learning bottom up, starting simple (i.e C, memory models) and adding abstractions later.
This sums up really nicely!!! One reason why comp sci students get confused so often when they first get into modern web dev.
this is not even top-down approach really. because via usual quick react tutorials you don't start from next.js AND finish with really bottom thing. you see only top part. but it is what it is
The problem with this approach is that it allows people to get real IT jobs without ever getting around to actually peeling those layers back. You already get results, why bother going deep into how it works, right?
I once made a backend for a guy who just learned React but somehow didn't know JS itself or the basics of how the web actually works. I had to explain him what an XmlHTTPRequest is and what I meant by "pass me a parameter". It's my own anecdote but it does show a glimpse of how bad this whole idea really is.
So what are doing now after front end ?
@eazypeazy8559 yeah it's more like learning top-sideways
If you think React doesn't explain anything, wait til you see Android development, 100 Gradle tasks with who knows what is compiling and preparing.
and add a bitt of react native on top and we have a delicious hot steaming pile of shit!
😂😂😂
Hahahaha! I really hate Gradle!
@@ninox14 dunno im using vue and nuxt... and have no problems understanding what's going on... their docs are also very good a lot of effort put into it...
remove the abstracxtion, it's also just render functions of virtual dom nodes, patching and merging with real dom , ; )
Gradle will ruin mental health
Unironically this is the best react tutorial i've seen
Dan Abramov could never!
Exactly
I use react, I use it because there's a market for it so I don't feel at all personally attacked by any of this.
I think it's cool that you're trying to learn how everything works from the ground up and I wish that there was more content that tried to do this in the React world.
I don't know why people feel so attacked by this stuff. Weird.
If you are a web dev and nothing but a web dev only, then you'll never understand why people feel so attacked.
Web development is just cesspool of fast and instant thing after all. They feel attacked when someone actually peek into their shallow understanding of their thing lol.
No its because shitting on react or webdev is just a weird trend, usually from people who never actually worked in this sphere
How does that work? Is this some sort of vague insult 😂@@FullGardenStudent
Regardless I think people need to distance themselves a little. Being upset because people attack the framework you use at work is laughable to me. But maybe that's because I don't create my entire personality off of being a developer.@@wsak5991
In biblical times Babel was literally the collapse of a single easy to understand language into thousands of languages. It resulted in confusion and mass-hysteria.
No, it was a building.
the best commentary i've ever seen on youtube for 26 years.. 💜
@@Adiounys No, it was a metropolis, in which they built a building, called the Tower of Babel.
You know it’s not real right?😂
@@alst4817 i saw it with my own eyes
React: "added 1459 packages".
Tsoding: .....
React: "Happy Hacking!"
Tsoding: "What the Fck just happened?"
Love this guy!
😂
that is really an obscene number of packages...
HAHAHAHA was classic
And we wonder why web-browsers are memory hogs, and the webpages are sluggish...
@@Zircuitz This is also just Create-React-App being bloated and slow. It hasn't even been the recommended way to start a react project for over a year at this point. That's why it wasn't recommended in the docs when Tsoding looked at them. But Vite should have been the most obvious react beginner friendly choice, not the huge metaframeworks like Next or Remix.
As a react dev who doesn’t make the library his personality, I find this to be entertaining and I even agree to some extent. These frameworks are crazy.
My condolences.
React isn't that bad, what's bad is the entire bullshit of nodemodules and webpack and shite.
By the way, I use Fable, and the Elmish architecture, so after that shit, everything is just F#
I don't know why don't I use and HTMX instead.
But oh well. I hate my life.
The next WebApp I made will be in C++ and will only use the its going to be literally easier to manually program shite in OpenGL.
@@monad_tcp What would you use if not webpack? How would you assemble your application wiithout pain and split it into nice chunks? Ofc, you could write your own solution but then again: why not just stick to webpack which covers all your needs?
What soulution would you bring up , not using all those modules? It is impossible. You have to have modules otherwise you must write your own one giant module which covers all possible use-cases. And also note that he used "create-react-app" that has many unnecessary things. You can configure your project on your own and have like 10-12 small-to-medium packages.
These people who make react their life are so in denial of what the actual experience is like
@@lostsauce0 Actual experience is what you see on React jobs, and nobody uses React like he did
@@lostsauce0yeah react is bullshit 😂
dude asked one question and cursed Tsoding for the next hour... Thats true evil
49:47 The reason React DOM is separate is because React just creates a tree and tracks updates. In truth you can use react to render to anything, not only the HTML DOM, but iOS widgets, Android widgets, or even receipt printers over UART.
Yeah the virtual DOM is there for a reason. It's made to scale. Gretcha.js reloading everything every time something changes will eventually be slower than React for a large enough app. If Tsoding were to keep extending Gretcha.js, he'd end up with a virtual DOM. I challenge him to prove me wrong.
It is weird that it's a separate package tho
@@SpeedingFlare Why is it weird? Like OP said, you can use the underlying React model for many different things besides the browser DOM. React Native will have a dependency on React, for example. It would be weird if you had Browser DOM code in your React Native app. It just makes sense to separate React from React (for) DOM.
@@jh0ker After I said it I had a moment of doubt where I wondered if uses an interface that allows alternatives to be dropped in. Makes sense
@@SpeedingFlare Theo made a video about different React frontends that shows some cool applications of this ruclips.net/video/Y12sGu8-qFE/видео.html
As a backend, this is the best React tutorial I've ever seen.
@5:06, when you haven't even had time to break out your editor to write the obligatory "Hello, world!": installed 1459 packages.
I feel your pain. We're all in a world of hurt.
And webshitters will cope that downloading 1.5K packages to a "learn yourmom" application is suitable.
@@bertacchius No one says that and no one uses create-react-app for that exact reason.
3 days ago I literally just wanted to create simplest possible hello world in the react. I used create-react-app, I saw 60k files in repo and I uninstalled it in shock immediately and went with plain vanilla JS
@@bertacchius I only need 1 package to learn yourmom
Oh no, run! twitter JS devs are coming for your soul!
Dude, run away, go back to C, it's much safer there, this is a genuine advice from a react dev
bro react is not Israel there is nothing to be worried about, let him learn.
@@eboubaker3722
You're right.
It's like Satan, it's way smarter and worse 😂.
React was a mistake
I hope HTMX will remove that react-abomination from existence
@@rockytom5889B-but Israhell is run by satan(ic k!kes)
tsoding, a big fan here.
I agree with you about understanding from the ground up.
I don't agree with the approach of not giving the article a chance.
Most of the video you had the answers in a scrolling distance but you just got frustrated and returned to the familiar emacs screen.
Also, react is not only for recursive elements but most of it is designed to render parts of the Dom that changed their state, but cache the rendering of the trees that didn't.
Thus, react enables a convenient way to run heavy stuff on the client side.
Also the expectation from him that the docs should start directly with a deep dive how everything works under the hood, is "weird". Like how many developers gonna build stuff from the ground up. Its just a bad learning strategy for most. (not saying that looking under the is bad). The docs like you say pretty much explains alot how the stuff works without the need of explaining how to build it - what an edge case that a dozen of people will do
@@moritzschuessler The issue presents itself when a new developer gets told to learn react and they have no idea how anything actually works. They might be able to create a website, however they don't understand much about JS, just about react. Whenever they try to move onto something else, it will be a much greater challenge, this starts with the mentality that the base understanding of your tools should be ignored for instant results, even if that means you will bear the consequences later.
@@moritzschuessler That's not what he is criticizing. If the docs literally just "picks up" devs where they "normally" left, aka writing html and css and how react gets hooked creates the root etc. and how react virtual dom interacts and renders the actual dom. And how "react" is actually build out of, list the packages, modules and give an overview.
That would be better than starting off with,
"here's a magic jsx file, write "Button" that returns react elements and watch it work magically!"
That's the gripe he's having.
Thats the gripe many people have.
Noone has anything against what react is trying to do.
Why do you even need a shadow DOM? Because HTML wasn't built to do shit like this and isn't performant otherwise for complicated UIs. It's just a solution to a self-created problem.
@@astrixxvirtual dom and shadow dom are completely different things. and if you insist on rendering everything e.g. in a canvas rather than html, you lose the semantics which allow screen readers etc. to work.
literally noone thinks this is GOOD, it is just how history has played out.
If all web devs understood the fundamentals of the tools they use, they would definitely create better software for web.
I think if all web devs understood the fundamentals, React wouldn't exist in the first place
@@nefrace core principle of React was good: declarative UI and state. But a lot of stuff went south since then...
If webdevs understood the fundamentals, they wouldn't be doing webdev
@@MrLoquito12345 well... Someone need to make websites ¯\_(ツ)_/¯
Not like it's happening now but doesn't matter
javascript engines are pretty mercurial and unpredictable though
I think people are saying that it's painful to watch, not because you are exploring and trying to create a functional React project from scratch (that is actually pretty cool, and I think every web developer who wants to really understand React should do this at least once), but because a lot of times when you say in the video that things are bullshit, they aren't bullshit (not always, sometimes it really is bullshit). It's just that you are literally learning and seeing the packages and tools for the first time, and you didn't understood what is the need for them to exist. React and ReactDOM being separated packages, for example, makes all the sense in the world because React is not only used in the browser. So it makes sense to have another package that handles browser-specific functionality, while React can focus only on creating component trees that can be rendered anywhere.
Amen.
He should be taken with a bit of sarcasm gut
I just think it's fun when he goes through exactly the same emotions and reactions as I did when I started with React. I did it more or less the same way.
A fine example is tsoding knows that he needs a ReactContext to render React. So he opens up the documentation of ReactContext with "how does it work" and skips the first sentence which describes what it's used for and instead looks at the code on how it's used.
I 100% agree with your take. IMO the video should be titled "I tried web development and ruined my life" there is very little react happening.
I think people are mad because they're thinking "oh no he's using react the wrong way, how painful!". When in reality he's not using react, he's trying to understand it by piecing everything together from the ground up, and consequently, understanding how everything works.
The fact that it is impossible to tell how your react project actually works because it's obfuscated behind 1400 mandatory dependencies that take two minutes to install by default is probably part of the issue
@@CyberDork34 yeah, it's not impossible (tsoding just proved it to be possible), but it's definitely way more complicated than it should. I've never done any serious UI development, but if I were to do webdev, I would definitely just use vanilla JS, but "me + webdev" is probably not happening anytime soon.
he's literally using React. Also 1:00:07 welcome to the desert of real world Mr Anderson
@@monad_tcpyeah he literally just recreated react lol
@@CyberDork34 Its why I just dont want to learn or use react. It feels like an amorphous blob of mulch. It just feels super heavy because there so many dependencies. So many single person projects the world depends on. So many cpu cycles wasted doing absolutely nothing of worth.
Most fun vod I've ever watched, you should create a series trying all these huge ass /frameworks that people don't understand in depth, it might as well be a good learning point for them.
React developers are React users, they are not developers of React. I fail to see why it would be valuable in any way for them. Do Java devs understand JVM? Do C devs understand LLVM? The whole point of documentation is that you are not supposed to understand how a library works, let alone the tools needed to build something. I understand that some people are frustrated with not understanding the underlying mechanics due to a lack of documentation but stop kidding, most developers do not understand how underlying tools work simply because they don't need to
@@xcy7 dude....
@@vdchnsk Yeah? Care to elaborate? In my opinion I didn't say anything that was so stupid that a condescending "dude..." is warranted.
@@xcy7I don't understand everything about the JVM but I understand the principles of how it works (JIT + the intermediate machine code-like language that the JVM then executes). I don't understand LLVM but I understand assembly and I understand what my code eventually turns into, at least pre-optimization. In fact, understanding this is crucial for C/C++ devs, as knowing it will let you make your code easier for the CPU to cache and execute it faster, and even without digging into that stuff, pretty much any C/C++ developer knows the performance costs of working with heap-allocated memory and jumping around pointers all the time. You generally need to understand at least somewhat wtf is going on under the hood to make your application not run like total garbage, but unfortunately most web devs (and web users) simply don't care about performance all that much
@@xcy7 This is not even something you need to develop React, but just a "compiler" toolchain, which is like saying you're learning c and instead of learning how gcc works, you go straight to makefiles cmake and all that shit. You're not a software developer, you're just a baboon putting the puzzle pieces together.
At its core, React does the same thing as your grecha.js, but instead of recreating the page on every change, it does a tree diff to only update the nodes that changed. That is all about optimisation, and that is all the stuff that you hear about, like "virtual DOM". I also think right now it can also do partial updates to stay within 60fps budget if an update takes longer than a frame.
It also does some spooky stuff with "hooks" to save state inside the tree instead of global variables, so you can create multiple counter components, each with its own state.
Also, someone did make an alternative framework called Preact, which does all the same stuff and is 10 times smaller
Do you know how long it took me initially to find this information when I actually needed to know it a few years ago? 😂 Very good explanation!
Im not much a fan of the virtual dom explanation.. Like why are we selling react on stuff like performance because of internal implementation details you dont even get to interact with? In the end react "apps" are slow as hell, spend too much time processing re-rendering of components and effects.
I think we should sell it on its actual strengths like reactivity and declarativity, but its like selling functional programming to people, they only get it when they are deep in the weeds.
The speed of coding and building stuff is more important than the performance in the Browser, which, unless you do something horribly wrong, is already so fast, that the user wont notice any loading. The only bottleneck is the data fetching from the backend.
@@coldtech06 React's selling point is DX and ease of use. This attracts a ton of beginner developers lacking fundamentals. They write inefficient software. Business rarely cares about performance on the web.
It is absolutely possible to create fast and responsive websites with React, but unfortunately it's rarely the goal.
@@wsak5991 From my experience if you prioritise speed of building too much you get to a point where everything is unmaintainable and you need 10x more devs to still work on it. Which creates even more issues.
And react is created by Facebook and their browser application is so painfully slow it's barely usable, no wonder they moved to native apps on mobile
Nobody gives a shit he is trying to understand how stuff works, they get mad when he skips the docs and just starts pasting random code and thinks it should work. But pasting random code from the internet without reading docs is advanced webdev, so Tsoding might be senior webdev after all.
React and React DOM are separate packages because React is just a reactive/declarative runtime that creates a tree. React DOM will use the result of that tree to render HTML, but you could use the reactive/declarative system for other stuff like rendering stuff on the GPU, or making terminal GUIs with a lib React Terminal.
Basically React is just something like the lib S.js with JSX syntax and stuff like contexts. (very good lib btw you should look it up, basically react without the bs, maybe you can break it appart and create your own react competitor (again))
And React DOM can take a react tree (just a bunch of objects) and render HTML with it.
I mean, it literally doesnt get simpler than this:
const greeting = S.data("Hello");
const name = S.data("world");
S(() => document.body.textContent = `${greeting()}, ${name()}!`);
name("reactivity");
With a single dependency, S.js itself
It also make it simpler for react native right? Dividing such things is useful
@@coldtech06so you have bagilion of those and also some of them are accessing the server and some are generated at the server and some share state but in different modules and styling must not affect other components and other things 😕
@@coldtech06 dude the code you wrote is already more verbose and complicated than react with jsx
@@wsak5991verbose ok but compliwhat????
I am a react dev, this video was
1. Hilarious
2. Educative
3. Insulting
4. Realistic
5. Amazing.
I see that your way of doing things is way way beyond what a normal dev does, and the fact that people were frustrated that you digged so deep is funny lol.
When I started learning react I started it like this but guess what, There were billions of dependencies that if I started trying to understand everything at this level I found out that I would never have the time to create stuff, it's too much but this was amazing and thank you. Would love to see something else related to web development
If you want to build a window, do you have to know how glass is made? That part was already taken care of by someone else, same with react. Only in coding people are so obsessed with building everything from ground up.
@@wsak5991 its not about building, it's about understanding, thats why we are all dependent on stackoverflow ( or chatgpt now ) because we don't understand how everything is working, which is normal but to try and understand everything it's amazing, only people who truly love programming do that
@@wsak5991 Until you build something from the ground up, you do not fully understand how it works. This is universal.
@@wsak5991 maybe you want to know how the glass you are using in your window is made if you want to create a certain type of window? Maybe this kind of glass is better for large windows? Maybe there's something about a certain thickness of glass or the way they manufacture it that makes it bad for creating a certain kind of window? Knowing how something is made from the ground up is crucial for mastery of a discipline.
Unless you're some fucking amoeba brain who can only glue together parts of a project like a braindead robot. You do you I guess.
@@wsak5991 If you want to use concrete, you have to mix it on the spot... You have to know how the concrete is made. Yes, no single person is going to bake the specific sand that you need at extreme heats to make windows because it's simply a lot cheaper to have it made in bulk at a factory, but the people in that factory still need to know how glass is made in order to make the window.
Somewhere down the line there is someone who needs to know how something is made, things don't just appear out of thin air. The personal question is just; "Do you want to be the person using the products, or the person inventing the products?"
46:28 the NextJS tutorial actually goes through this from the ground up. they have a section called "from Javascript to ReactJS" where they explain this.
Just checked it out and it seems like a really good tutorial for beginners who actually want to understand the why and how
Why ready docs when you could be just shіtting on tech to farm views?
link to tutorial?
More please. I love the way you learn and obviously your learning process is great. Obviously the learning mindset is not the productivity mindset and people who were unhappy in the chat probably dont have the learning mindset.
Look, I am a beginner dev. when I was told "oh you should learn react" and I started doing tutorials, I would say the samethings "why JSX" "When does this get converted to JS?" "What is doing it?" "How is React managing the state?" And NOTHING answered those questions. fumbled around forever just messing with react. but I don't really have the skills or intuition to know where to look. SO this video was insanely helpful and thoughtful. Not only did it help me understand whatis going on under the hood. It gave me ideas on how I can piece apart new technology and how to mentally reason about it.
I want to know: when SOMETHING goes wrong, or when I see some behavior that is really odd and stupid, I want to be able to reason about it. Just remember, the people that understand React at this level are the same people that are answering your stack overflow questions when you dont know what the hell is going on with your web app.
That generated product of JSX is big blob of 1 function. What you write in JSX maps to a function. That's why React elements could be either function or string.
Back in 2016/2017 there have been multiple presentations around "building React from the ground up" so that you can get all the points you make. It's unfortunate that it's been lost to time.
1. Every single real web developer knows very well how al this high level stuff works, because this is how we used to do things back in the days. (react is a 10 years old library)
2. Imho, The fact that you tried to learn react from the ground up is a good thing.
3. react (the library) is a library to create web and native interfaces. ReactDom is just the way to go to render a react app inside an html application. There are even tools to "render" react components in cli applications. (a good idea for a video?)
4. React is capable, at each render cycle, of updating only those portions of the DOM that have actually changed (diffing).
5. Your grecha.js stuff is just a meme at implementing counters (it rerenders the entire shit at every button click).
6. document.createElement is not a valid alternative to react components. Native web components (maybe) are.
69. Love you
hi, does your point 6. apply to other frameworks too? is there anywhere I can learn more about that document.createElement is not a valid alternative? Thanks
For me the problem with react is the shitty rerender stuff. You have toons of optimizations to do with child components. When you refresh the parent it will rerender everything which is bad in many cases. The useEffect is a problem too when it rerender twice for litteraly nothing. Most of the time it's not a problem but React is not that good for performance because only few devs are aware of this or do not take the time to optimize their app properly. Time and budget are often the problem and this part is skipped...
I tried Web Components once and i think the industry is not ready. There is a lack of ressources or projects based on it. Stencil for exemple is a piece of shit. If someone ask you if you could start agnostic stuff with it run for your life !
I really love seeing him dig into things like this, because I don't have the understanding to do it myself yet
Same here.
I think its a difference in goals.
If you want to learn react to make websites or for job security then you do not need to understand what happens under the hood. React is the means to the end (the end result being the product or react dev job you get).
If the end goal is to learn react as a library, how its implemented then of course you are going to look into the underlying layers. Maybe you do this for your own curiosity, or to learn design practices and expand your knowledge of techniques and design philosophies libraries use. In the end it all depends on what you want out of it.
It just so happens many of us aren't that interested in that, we just want to make a cool website or get a job, thus we arnt bothered with technical details under the abstractions.
Whether this makes us seem worse or better than those that do look into the details lies entirely up to your values. If you value those skills then sure, we seem inferior, similar to how on the other side, they may view looking into the details as a waste of time.
Because of this, i wouldnt say either side is "inferior" or "wrong", just that we have different goals.
Well put.
theres also the fact that most web devs are either self-taught or comes from bootcamps, i don't blame them for not knowing how things actually works but for the others theres no excuses imho
I understand the sentiment, and I agree that practicality may outweigh deeper knowledge in same cases, but it's not "we seem inferior", it's quite literally that you (not you in specific) don't have any idea how the library you use works. If you're using React professionally, it is almost unbelievable to me that you would neglect to be proficient in JS to the point that, at the very least, you can set up react without needing automated tools.
If you're a React developer and got offended by this video, please watch any of his other videos. His approach to learning things aligns with how a lot of software developers go about learning new things. This is exactly the reason why it's so frustrating to start off with modern web development. So much weird stuff going on without any explanation, and the documents kind of just seem to ignore it and stick to copy-pasting basic commands.
I've been a React dev for about four years now and your observation is spot on: The problem is that these Getting Started tutorials are written with an absurd number of guardrails in place. They're intentionally dumbed down to give people instant gratification from running magic bootstrapping commands and then seeing an app on their screen; their goal is not to explain how the framework works under the hood. Then those devs walk away feeling like they learned something when in fact they didn't. I feel like this is an attempt to cater to non-CS folks or people transitioning from other career paths to web dev, so the framework is trying its best to not overwhelm them.
I got crushed by one such tutorial.
install the thing
copy the code
look magic you're a react dev now!
uh, no, you didn't explain how any of this did what it did. I understand nothing.
Funny to see how the guy who has never scratched the surface of react turns out to know more about react and web development than 99% of so called "senior react developers"
upd: Tsoding man, cudos to you
I'm really glad for your work of unraveling its mechanics. Until now, I was frustrated by not undestanding how React really works, and nobody seemed to care about this. I was only encountering those "copy and paste those lines of code" tutorials. It is sad the lack of a concise documentation on what exactly it is and how it works.
I got so frustrated trying to get details from the docs that I went on a deep dive just reading the source code for a few weeks. It was painful, but it worked. I don't know everything, but I basically understand fibers, and have a loose understanding of reconciliation. Now, hopefully I never have to write any react code in the real world.
There are no tutorials because literally no one knows how it works. Including the thousands of women and indians at facebook who wrote it.
This was actually kinda eye opening as a react dev I just use pre defined functions and methods of react and other npm packages and I have never even looked at the implementation code of any of those packages
You don’t have to honestly, unless you’re contributing to React itself. It’s not realistic to understand every framework down to the machine code before you use it. You’re meant to use the API that react provides to make applications, not modify the react source code itself.
However if you do want to learn how it works, you could Google “how react works” and that’s a starting point. Then look at the source code and it’ll make sense. Instead of doing what this guy is doing - barely even reading the user guides and complaining.
58:41 JSX is not limited to React, so "onclick" JSX attribute is transpiled as-is into "onclick" property for createElement funciton. And then it is React code that tries to find onClick but finds onclick and yells at you. Considering that Facebook created JSX specifically for React it is surprisingly stupid that static analisys is so weak. I guess it's a JS mindset, where failing at runtime is a norm.
it looked like the babel transcompilation was targeting react.createElement or whatever though..
@@sub-harmonik that's the impression I had too, it seems tightly coupled
I would never imagine FB dev will create something better (framework) than facebook shite ;)
i think it thinks that onclick could just be another HTML attribute and not the actual button handler
3:37 How to install about 1.3M LOC worth of dependencies to render Hello World in the browser window!
What a time to be alive!
** literally scrolls past it without even trying to read **
- the don't show you literally how to instantiate it!
(not defending react though, modern web dev is an abomination)
This stream fullfiled my every expetation.
56:30 but with react, we can isolate states using components. each component can have its related states and re render based on its own states. so the flow is a lot more predictable and easier to debug. in my opinion frameworks like svelte and solid are easier to understand ( the magic that's done by the framework ), but even react has this benefits over vanilla js. it's also harder to handle conditional renders and cleanups in vanilla js, react already provides apis that makes it easier to handle them.
"easier to debug" has to be the greatest react joke ever.
@@norliegh yeah i can't imagine debugging a larg scale frontend project without a particular framework or an isolated structure
@@norliegh well, its easier than debugging imperative programming with global mutable variables
Man! i'm senior dev - React mainly. And I need to say, I love this video!! especially your criticisms
dude, you are too self assured - why is ReactDOM a separate package? Because normal React is generic, and can work outside browser with a DOM context.
- I don't know if anyone is using it for something else, but probably ... it can be used to "drive" arbitrary expensive tree by applying the diffs ...
it definitely SHOULD be a separate thing, and I like they made it reasonably.
- It comes from the fact that JS has no GOOD dependency tree shaking, so you have to not include things like this.
I’ve been watching this guy for a while and have been just learning react recently. This man is crazy haha 😂
It always surprises me that people don't want to explore how stuff works. Most of the programmers I've met care only about the end result. It other words the program they write. I always want to explore how my program actually works. Whether it's exploring the internals of some framework or learning assembly because I want to know how computer executes my program. Maybe I'm the weird one though.
I want to know how stuff works. What I've realized after a lot of pain is that I don't need to know how stuff works to use it. I'm very bad at black-box mentality since I feel the need to know how the internals works to use a tool, which is bullshit. Neural networks was the eye-opener for me. I was severely hampered by looking at hours of video lectures about neural networks and learning how the math symbols are used. So I slowly learned how they work, but I got no actual programs using them done. A sandwich approach from both ends, slowly learning from the basics while also using existing tools and examples to get practical experience is a better approach.
The people who figured out how to effectively use backpropagation for training certainly weren't able to figure it out from theory alone - they had tons and tons of experience in neural networks too that aided them. For NN especially, trying to learn and write stuff from scratch is super painful since the NN code has to be pretty damn good and written with a lot of knowledge to get good results for any larger or more interesting datasets. The libraries are written by experts and it would be silly to evaluate their work without at least moderate understanding of the field. I've done that mistake enough times already.
FYI: react-dom is a different package because react (the core library) is designed to be platform-agnostic. You could therefore use react with react-dom and target the browser or you could use it with react-native and create android and ios apps.
Thank you kind sir.
Maybe you could abstract the refresh part into a function, something like useState which takes a value and returns a getter and setter and the setter calls refresh. 🤔
It doesn't returns a getter and a setter. It returns a VALUE and a setter. The thing you describe here are Signals. A getter is a a function that return a value AND the ref of this value. But in React we do not have a "useSignal" hook yet which is sad... Because of that, instead of declaring just a signal we have a bunch of hook to use if we want to achive the same (useState + useEffect + useMemo). Angular is better on this point
This is exactly the kind of tutorial I would have wanted back when my former workplace told me to learn React
The problem is the gap between programming as a craft and programming as a job. Most people get the job without really learning the craft. The moment you've come to rely on a framework to make things easier as your starting point is the moment you cease to be able to function as anything but a cog in a corporate machine. Programming is programming, no matter if it's high level or low level, but if you're working at a high level, you have to understand what's underneath if you want to write good code. If you can do that, then the framework you use is irrelevant. If you can't, then you are dependent on the framework's environment, and are subject to all its problems.
Got at the end. 100% agree with Tsoding. My complimentary notes on React. First, the "real tutorial" is called "React Internals" (this is where they talk about React.createElement, etc). Second, all of that crap is bloated and obscure because "modern devs" adds an entire abstraction layer on top of a simple problem: React abstracts an UI component graph; ReactDOM abstracts using React on DOM trees (i.e. update HTML pages); JSX abstracts away "React.createElement"; Babel abstracts transformation of JSX into JS; Redux abstracts the state (i.e. global constants); NPX abstracts the setup of all of that shite... And thy Lord shall have mercy of anyone spreading some blasphemy like simplifying things or asking normal devs to understand anything beyond what's written in the tutorial...
I love the "Make a counter" request. In no time Tsoding realised his framework didn't support state change.
The next request could be "make a page with 1000 buttons and counters".
In no time he'd realise that refreshing the whole page when one of the buttons get clicked is overkill and will result in performance problems and/or unexpected ui behaviour like jumping back to the top of the page. He'd have to make his framework selectively reactive.
look what they have to do to mimic a fraction of reacts power
@@lloydbonds9268 you mean HTMX
There is a good reason that react and react-dom are different packages(also when using tools they are always both included). They are different things. React has the diffing algorithm related details and hooks etc. etc. React-DOM is just the rendering side of it on the browser, that's how react can be used in different contexts like mobile development
Duuude, I never felt more relatable watchig programming content.
I thought I was just stupid for not understanding and not appreciating 100 layers of abstraction.
"Why do we need React?"
I would ask "Why do we need reactive frameworks?". And we need them, because with old way of writing websites (using JQuery) was extremely painful to scale up web apps that are automatically updating data onchange.
Frameworks are tracking data by themselves and they update the DOM automatically when data changes.
Also frameworks allow to create separate components (kinda like old twig/blade templates in PHP) which gives you the ability to reuse some views
This is super interesting, informative, and hilarious all at once! Who knew you just need to include 2 files to start writing React! Thank you for showing this as always.
he is talking about the abstract levels. Most frontend developers have no idea how their frameworks or libraries work, they might know something in theory but if you would ask them write their own jsx based framework they wouldn't be able to do it. They feel pretty comfortable on their level of abstract and there is no need to go deeper. That's why I am not considering them as the engineers they are just developers, not even programmers
I consider developer and engineer to be more catch-all terms. I'd describe them as point and clickers. They point and click to put stuff together that other people wrote.
But for interactivity we already have events and eventListeners right? So why not use that instead of reinventing kind of a event loop.
this video made me want to develop a deeper understanding of my tools when doing web development, thank you.
I used to develop using react, and after some time of developing apps in react i was realized than much faster and optimized apps with same functionality can be done with vanilla js and also with much lower filesize than react apps and also you can control every symbol in your code and every byte of optimization
56:41 the reason why we need react is because it stores all elements in memory and when it's time to rerender to compare which element have changed it uses the react reconciliation strategy so that it doesn't traverse all the dom
The DOM is already in memory, you don't need a virtual DOM and fancy diffing algorithms if you just change the elements that need to be changed. This is why other frameworks (ex. Svelte) don't need a vdom and are faster than React.
@@youtubeviewer7077, is that true though? I’ve always been told that changing the actual DOM is costly. Glad to be mistaken, if that’s not the case
@@youtubeviewer7077 yeah, but in the way he did, you get messy with state management once the code gets more complex, React isn't Svelte or Solid, but still better than this
The video title made me laugh out loud thanks it’s too real web dev is so ruined
This is gold. Seeing this god programmer struggle to navigate web frameworks, gives me reasurance that I am not that dumb feeling lost when dealing with frameworks.
Recently I trying to get this conception asking to myself: How this works? And dude, programming turns so much interesting. I love it how do you dissected the react and how this works behind. I use react for like 2~3 years and I never get this attitude.
I really didn't understand why the people was hating, for me is so much interesting to see.
Great video!
I do both web, backend and application dev, I love your work, made me brainstorm little bit. That why I tried to run away from web dev, and python dev. Involving into web/ python dev, It was like let thread panic for pleasure
Macro.... Expansion....
Abstraction is the greatest form of complexity. Many devs don't care about the underlying functionality. Sometimes before I install a plugin I read through the code. I just ship and adjust it as a util rather than have npm module. Curious people build consumable plugins but most consumers don't like checking on the underlying details. The more you can offload the better.
If you want to do freelancing Im sure you will find a more juicy marked with the skills you already have such as C, Rust and all that stuff. Those skills are much more difficult to find.
In today's job-market you lift a stone and under it come out react developers from below like cockroaches hahaha.
I really enjoy your videos!
as a freelancer you can do whatever the hell you want basically. i do webdev with my own astro build and it gives me great performance very easily
@@b_delta9725 I'm interested in looking into doing some freelance work, where do you find jobs for that?
Rust jobs? Where? There are a lot of people learning react because there are a lot of jobs.
What site or method would be best for doing freelance? I wanna try out freelancing since I can't get a job with my degree in this market.
Where's ebx, rax, rdi bro?!? What are those arrow stuff and hooks
i am a software dev and i agree with a lot of tsodings frustration here. i love using rust (hoping unsafe rust becomes more stable soon for more fun) but i dont like how core features are left to separate community packages. i understand that there are benefits but it leaves a fragmented documentation quality experience. it's incredibly frustrating to not understand how a function works just to read empty docs with no examples. the standard library book is so good but when developers rely on community docs the quality drops significantly
for a scare, read the syn documentation. it is a recommended community package for developing proedural macros, a core rust feature. you'll find lots of empty pages and links to entirely underdocumented libraries that it uses. everything is abstracted away to the point of confusion with a thin interface over it
@@Cmanorange This is one of my chief arguments against Rust. At least C tells the truth that the standard library is basically empty. If I'm going to use a different language, it needs to provide nearly everything I've got in my own libraries. If I have to depend on a rando third party who may or may not be a good developer then I'm going to have to write it myself to have any trust in it, and I don't want to take the time to rewrite my own libraries.
Have you tried Odin-lang?
@@anon_y_mousse I mean rust has a lot of libraries available, of course granted that it hasn't been around for that long so it won't be as big as some others. However, I'm pretty sure that they explicitly state that it's meant to have a small standard library because it's meant to be extremely lightweight. The main attraction to rust is the compiler, which actually reduces risks associated with third party libraries.
I am really glad you did this video... every time someone asks me what I think about react I am going to sent them the link to this video
It's really interesting to see the attempt to _understand_ the mechanics of web framework. Wish I had the same mindset.
But I'm just trying not to use frameworks.
But he doesn't attempt to understanding anything. He looks at the generated javascript(the calls to React.createElement), exclaims "but there is document.createElement, dont you know????" and then assumes he understands everything about react.
He isnt really tying to understand react. He is just trying to bundle everything from scratch - what will him not make learning the concepts and problems of the framework. Needing to know how to bundle JSX/React to make workable code with his approach wont be necessary for many. Its a edge case that a few persons will do. And there are actually good content explaining exactly that.
Saying that react is shit because the first page in docs isnt "ok lets take 2 days to explain how create-react-app bundles stuff and how stuff works under the hood. Then we will show first code" isnt important. Its more important to explain the concepts of a framework and spinkle in the how its does things under the hood.
Have you ever read a classic old backend doc? they literally throw some compiler output at you. nobody will learn with it.
I am grateful of your insight into react. We all should learn more from each other, rather than judging. :)
I'm a react dev and this stream was enlightening. Your theory is close- but it's not the dirt they are reacting to, it's their ignorance. They are frustrated that they cant give you the answers to your questions. On the other hand, you are definitely trolling at times 😂. No, it is not strictly necessary to use anything other than vanilla js. Do you need it for for a form submission? Clicking a button? Tracking count? Making a website? Of course not. Does it make developing and maintaining large stateful apps in the browser easier? Yes. Yes it does. Is it the only option? No.
"I wanna see all of that dirt, even if it makes you uncomfortable" - Tsoding
This video is gold and hilarious, and some people simply don't get it : P
I came about your vod by the powers of the algorithm. And as a mostly react dev, let me tell you this video was highly instructive. I trully believe that if most frontend bootcamps pushed for students to create a react app from scratch as you did as a form of evaluation, none of them would pass. And so thank you for a much needed wake up call.
For reference: just tried Django a few days ago, and the fact that Django comes packaged with: a templating language, API route handlers and database management tools; it just, blew my mind.
what people are missing from this video:
> tutorial installs 1500 dependencies
> then the guy manage to gather react, react-dom and babel for running everything
I checked out the dependencies of react and react-dom which are just 2 in total: loose-envify and scheduler. Nothing more. I'm not a react dev myself so I cant say what are they offering within all those dependencies but it is worth to put things into perspective and question: is it really doing anything better or easy? In the video we can see that babel dont even check for correct html attributes during the jsx parsing.
majority is for other thing that you need like dev dependencies to setup hot reload e etc, styling dependencies, or things like TS
I struggled a lot learning React because of this "top-down" approach. After read `build-your-own-react` from Rodrigo Pombo I've finnally understood. Even those quirkies of separated packages react, react-dom.
But I've loved every single second of this video and I couldn't agree more with the current state of react. And it looks like it is going even deeper with RSC.
Getting stuck in an unclean state with an Angular project (Angular is much worse than React, btw) as well as having to deal with an insane build system that took forever (not even kidding. Before I optimized it myself, it took longer to compile said Angular website than it took to compile a Linux kernel on the same machine) inspired me to work on my own framework written in Go. WASM is a godsend for those of us who strive for more than resource hogging webdev.
I'm sorry, you just glossed over creating your own framework there,
also do you just decide to compile the Kernel on your free time ?
@@MasterGxt It's Linux. Many people compile the kernel themselves, for better performance.
@@markbauermeister5449 You're using Gentoo aren't you ?
I love how you‘re really exposing how everything works under the hood.
Wish the entire space would approach teaching fundamentals as raw as you do here! This gave me a lot more insight into the tools I‘m using everyday
I dislike using React and the massive bloat of the npm ecosystem as much as the next guy, but the constant bashing and strawmanning is incredibly exhausting. Like, no shit, state management isn't incredibly difficult in a tiny play project. JQuery exists. Obviously JSX isn't "necessary" to produce readable code. Mythril exists. There are legitimate issues that larger frameworks address that with *never* be encountered by a small project. I'd argue that even medium-sized projects can avoid needing any sort of framework if you have competent developers.
This is the difference between hobby programmers and programmers/developers who are actually working and building stuff.
Bro
Keep going
I came from a meme of you in Instagram and now I love your work style
The best React feature is that is can produce money.
still waiting for the money part, for now it's just a lot of frustration xD
damn Bill Gates, how rich are you?
learning react for a year. Applied everywhere for react jobs. create many projects in React for portfolio. But still can't get Job.
It is that how u make money?
Best react tutorial starter on the whole youtube unironically
isn't create-react-app package dead?
create-vite has better config support and dx
Wouldn't have made a difference in this case.
I loved this video so much! From someone who was introduced to computers in 1983 via a Commodore Vic-20, a BASIC language syntax book and Bruce Smith's Machine code book, I had no choice but to "learn" by understanding low-level concepts in order to develop high level abstractions.
To me it seems frontend developers are more likely to find the inner workings boring whereas a backend engineer thrives on the knowledge of how everything is working down to it's basic cycles.
Great content. Thank you very much.
Nice react-reaction. Frequent F-word usage was what I would expect.
I have been tinkering with Internet stuff since before WWW, the first webserver I set up was the original CERN httpd, and I've read the standards RFCs since HTTP draft (version 0.9), which was really just a slight extension of what people were already doing ad hoc with various fingerd implementations, IIRC. (And finger/fingerd is probably the classic TCP/IP programming equivalent of "Hello World".) The whole WWW weirdness has since evolved into what I can only describe as complete insanity. Arguably this is just a corrollary of the more general statement about IT in general, of course.
With the hyping of Generative LM "AI", and whatever other forms of socalled "AI" shAIte people are developing, I foresee that we soon will learn what happens when machine learning models are fed machine generated input in large quantities. It will cause feed back loops that just have to go completely bananas - but people will at that point believe anything.
News at 11: Breaking - End of the world as we know it. The complete downfall of civilisation winthin the next 8 years.
Just to add a bit of context here:
Q: Why do I need to install react-dom? Why shouldn't it be part of the react lib?
A: Because react is platform-agnostic. The core lib implements a tree of nodes (VDOM) that can dynamically update when the state changes. react-dom translates these instructions to render to the DOM, but there are other targets that don't target web, like react-native which renders to native iOS/Android elements, react-pdf (PDF renderer), Remotion (video editor which uses ffmpeg), etc.
49:36. Why there is a separate package for rendering is because react is used also for mobile development (react native) so rendering in web and mobile is different, to have it possible to use the same logic for creating apps they needed to separate the core react features with rendering part that's why they are separate packages
And in fact the React pattern can be used for far more, like CLI applications.
@@andrew.lp.mcneill Out of curiosity, what are the use cases for react in CLI applications? Or was that just a throwaway example?
im a web dev and i fucking love this video. the ecosystem is dogshit, the language is a hack - it doesnt mean its bad, its just how it is. anyone wanting to learn react should actually watch this video first before even looking at any tutorial!
Not an expert but most stuff tend to have sort of abstraction layer on top of it. Like you dont need to know about how processors or ram works to use computer, sure would be good to know but most probably dont need. Then if you know about processors and stuff, you can dig deeper with transistors and diodes and how voltage is regulated. I doubt many think about the movement of electrons and em waves while using internet. One can always dig deeper but for most people its not necessary for them to make some simple web app
the thing is react is not an abstraction, it's a bloated monster. Yes you do not need to know how transistors work in order to program, but you also don't need to buy an industrial lumbermill to chop up a plank of wood for a fire.
@@aspectreishauntingeurope Cant deny that lol
@@alt-artOk, have fun then building a bigger website with pure JS
@@_orangutanyeah sure, then just write your websites in binary, I bet a lot of companies would want to hire you
No one needs to know how to write binary, that is not what he said@@wsak5991
You are the man ! Adding in real time support for counter, this was amazing, gj 😎
The frustrating thing about this stream is that you are indeed asking really good insightful questions but doing it in an incredibly negative and dismissive way. Like asking why "react-dom" is a separate package from "react". That, in and of itself, is a GREAT question to ask. But then you just have to follow it up by saying that you think it's stupid and it shouldn't be that way, even though you know nothing about the architecture of React. Or you go on a rant about how your chat is frustrated just because the entire stack is shit and you're just exposing it. Umm... maybe save your judgement for after you've learned how React works? Probably would've lead to a much more calm and productive conversation with your chat and you might've even got the answers you were looking for from them. I think it's more than clear that this was sadly not a good faith exploration of React.
What exactly was frustrating about it? also a "calm and productive" outcome might be less desirable than a truthful answer to the question whether or not this stack chaotic. (obviously the video is a literal proof of that and hence the value of this video in the first place to be uploaded to yt)
Sounds like you are coping finding out your stack is shit
It s a joke for him, he is a low level developer, he doesnt care about front-end cause his channel is about true diffcult things and this is what I am here.
Copium
@@alexandrohdez3982 such a huge ego for such a small brain
please solve P vs NP problem, if you here for true "true difficult things"
I enjoy that you made this video learning from bottom up, but sometimes you criticize wrong things.
For example 58:23, onclick is a JavaScript attribute, and onClick is a React attribute. So the transpiler didn't catch it, because it's a valid JavaScript attribute.
Or some other things like why do we need React if you can just use document.createElement... But that's basically what React is, but more robust. It's more convenient to write code that looks like HTML and then compiles to functions that create them, than write those functions. Maybe it's bigger than it could've been, but it's still the most robust.
Lol, this is awesome. I just learned react and was quickly productive but still got impression that the build/tooling is pretty bloated/over engineered. Can you do an episode breaking down and roasting the spring framework? Or developer experience for a java project lol
🤣
The reaction of the chat to you exploring how the sausage is made is actually hilarious. Whats wrong with learning from first principles. Once you run into a crazy issue and you have no idea where in the framework things have gone wrong, you will need to know how the sausage is made. Its unavoidable actually once you move beyond some simple hello world app.
I am so glad you called out these frontend "engineers" who are proud of centering a div. They have some serious inferiority complex knowing in reality they have no idea about the tools they are using. Very glad you dismantled their fragile egos
I think the problem is people like me are new in this, and don't even ask this kind of questions yet. But for me, all that work you did it just awesome
React developers who are offended by this are not Software Engineers, they are Software Masonries. Having an inquisitive mind to understand how something works is Engineering 101.
Exactly
I think one of the reasons why such overly bloated web frameworks/libraries exists is to allow web devs to excessively charge clients for unnecessarily complex setups and maintenance of sites. But respect for wanting to get under the hood of react, I don’t know why people were mad at him for that.
1:16:20 Destroy goalposts for 10 years straight and you'll have 1k NPM imports too.
This is awesome thank you for diving into what is going on behind the scenes!
As much as I always look forward to your content this was really painful to watch. Not because of you learning React as you go but due to your noticeable elevating aggravation as you get heckled and annoyed by the comments from the chat.
"This is how you learn: fuck around, and then you find out." 💯
This was excellent!