@@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 , ; )
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
@@cold_ultraso 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 😕
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.
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 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
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.
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?
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
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.
i really dont understand your whole rant about React...like its say that its library, not a framework, so its missing some futures...like they say that in React docs...and the whole point of React as a UI library is to abstract away low level logic from devs...its the same when you buy a car and a dealer doesnt require you to know exactly how car internals work in order to buy a car....when you see a man powering Vim, you already understand that it will be a rant if the code is not low level...like dude chill, if you like low level, then go build you own framework from binary :D
For me i do. Actually it is so shocking that a commentary like this doesn't get traction in modern times. What you need to understand is that corporations are focusing on creating developers not programmers. To build applications not to build software. If you understand that very clearly then is when you will gain clarity about the whole thing. Thing is companies realised they can get more people who are good enough to just follow a set of instructions and make it work than focusing on getting smart ones who understand and can build it right up. If you focus on being the former you will be more successful in job market than the latter. Companies dont care if you understand,thats your job- your convenience, companies just care if you can follow. Or rather they can get more people who can follow than who can understand or their intersect. It all comes down to power and economics. Companies want to make money not to learn code, science or the wonders of the world. And if you can survive without doing all that shit then good. That is the logic. Coming back to the commentary- react was a library focus on reactive code, it doesn't have to be dom, it happened that dom was the main application for it so it became more coupled Secondly you can code react without jsx, its only that official docs focus on that. See produced code, it is actually plain writable js. Jsx is syntatic sugar, maybe more, to enable the declarative code. Explore the system in your own time and you will be on your own as companies dont care about that, they just care if you can use the thing, understanding the thing is now up to you It is a shame bt yeap thats the new world. Its just economics, unfair bt yeap thats life
"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
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.
It might make sense to start from the top here just once, just to know what the point of everything is, so you.can gain some insight before digging into all the lower level functionality. like driving a car even once before learning mechanics. not necessary, but probably helpful.
React is not only about code, in front-end you start with a design like figma or sketch and try to convert that with all of the functions, state, interactions into components that work with each other and can be tested, maintained.
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.
I understand that you want to understand. I also see your frustration with the comments. What I don’t understand is why you didn’t have a look at the react documentation at all. All of the information about how to use react without JSX is literally there.
Also: React is a abstraction so that it can be used with different renderers. The react-dom package renders it to the browser but you can also have a renderer for the terminal or for native applications.
I'm not a React dev but.... I think that React is a framework for declarative programming by using components and the grecha script is for routing a Single Page web App using imperative programming.🤔
Deno and Bun have JSX support, no need to install anything. You could do a react app in the way you are trying to do with no dependencies. Yes the react docs don't direct a person in such a way and imply nodejs, but that is a doc flaw, not JSX or Frontend people.
Idk why there is always this elitist view on react. React isn't designed or supposed to be the fastest most optimized front end library/framework to build apps. React is all about developer experience, reducing the time it takes to build something that works, and the ability to be easily maintained for large teams. React also has a lot of cross platform support (you can write a web app, desktop app, and mobile app all with react). The fastest technology that takes years to make doesn't make businesses money. The technology that you can bring to market and add new features to in a shorter amount of time makes businesses money. With that in mind there's going to be trade off's for things like performance to achieve that. If you want maximum performance there is alternative options but in general react is great starting point for most projects.
@@AllSentientFreeman Idk there’s a lot of top tier apps made with React so therefore React has been proven to be a very capable technology. I’m not gonna die on a cross over react but I think the hate towards it is way blown out of proportion and toxic.
49:35 because we have different renderers for different use cases, like browser dom, mobile, threejs scene, console and etc. react-dom provides a renderer for rendering in browser.
React docs initial guide is crap. It should let you get going instantly, it forces you to use next or some other framework. Vue has a much better onboarding experience.
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.
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.
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
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.
@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
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.
** 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)
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.
@@SpeedingFlare Theo made a video about different React frontends that shows some cool applications of this ru-vid.com/video/%D0%B2%D0%B8%D0%B4%D0%B5%D0%BE-Y12sGu8-qFE.html
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.
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 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.
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.
@@cold_ultra 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
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.
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 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.
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.
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 too dislike React, but bro you were seriously malding for 1 hour straight and scrolling through hundreds of pages without actually reading any word of explanation saying wtf over and over again. This was not "learning" from the ground up, you've gone straight into foreign technologies with the expectation that it's all done the right (a.k.a. your) way. Humility isn't your strong side, is it? A quick 5-minute look at the React documentation gave me all the information you were looking for all this time, but you dismissed the whole docs based on the idea of the quick start "making you dumb". Wake up megalomaniac, not everyone is a senior dev, not everybody cares about the insides, a quick start/first tutorial is written for a broad variety of people. I also doubt learning React.createElement makes you a React master lmao
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
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.
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.
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.
This was painful to watch because you keep ignoring docs in front of your face in favour of assuming how everything works. I hate how the React ecosystem has gotten so complex, but your task would've been much simpler if you had just read docs for many of the packages you encountered. You immediately complain instead of your first intuition to be to check what the docs actually says. There's plenty to complain about after you do that; trust me. Also, the reason React and ReactDOM are separate packages is that React is now used in other environments other than DOM, and the React package is just a very generic vDOM implementation. They used to be one package.
I'm using a framework built on top of react for work and I stopped trying to understand it a long time ago. If your motivation is to actually build an app, the only way forward seems to be to let go of your critical mind... (And embrace the bs)
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.
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.
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.
40:40 The best web devs out there all need to understand how the frameworks work behind the scenes. The official tutorial just wants you to set up a full environment immediately with a simple command
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.
Your initial reaction to the size is EXACTLY how i felt...WTF am I downloading....almost 700mb...for a web framework...like thats the size of a standard CD...how the hell did this happen and how the fuck is anyone willingly downloading this monstrosity...just to render a button in a different way...
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.
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.
Average senior react developer, I think, unavoidably knows it. And it is pretty important to know how it works under the hood. React team answers under the hood questions in separated articles and tutorials. The usefulness of react is in composability, declarative, and reusable components. Also, react is more like a common language known to most web devs.
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'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.
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.
That's kinda like expecting C tutorials to first go over C's EBNF grammar and then jump into compiler IR semantics before showing how to do "Hello world" lol
The canonical beginners C book (K&R) that you can read through in a weekend or two covers such stuff as writing a memory allocator, the language grammar, and stdlib reference. You can learn the entire C langauage front-to-back in less time than it takes to understand what actually happens in a "hello world" react program. It does start with hello world though :)
@@youtubeviewer7077 I think there is a big gap between reading and comprehending - otherwise we all would have been Einsteins already :) But I think I get what you mean, React devs should definitely do a better job at cross-referencing their documentation, e.g. when they mention JSX it should directly link to more information about JSX so that you're always just a couple of pages away from finding the level of detail you desire.
The problem is here you are not aware of what the tooling works, what the different packages do etc... When you write a basic C programme, you just invoke the compiler and then the linker. There is no hidden configuration or step unless you choose to use an IDE and or a build system, which only makes sense for complex projects.
@@JuvStudios React is a framework, not a language. You want to compare React to something like GLib, which has both complex ecosystem and complex build system - good luck understanding all that in 30 minutes without yelling at clouds.
This guy reads a manual for how to grill a chicken and complains that it doesn't contain instructions for how to grow the wheat that the chicken will be fed, how to tend to them, how to store, kill and transport them, how to run a supermarket to distribute it to the end customer, and so on. Wanting to understand how the underlying mechanics of something work is totally fine. But tilting over the fact that a tool based on 10 layers of abstraction, whose entire purpose IS to hide them, doesn't include instructions on how all of the fundamentals work, is objectively nonsensical.
This guy was fairly chill but a lot of people legitimately have this mindset, comes from a place of wanting to feel superior because they use tooling slightly less abstracted
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.
You don't try to understand how a computer works to a transistor level when you buy it to use Photoshop for creating art, do you? That's where web development is going - you get tools that are dumbed down to a level that anyone can achieve results in a week of learning. Is that a good thing? From a point of view of a more old school developer it might not seem to be, because we love to understand everything all the way down to machine code, but the landscape is shifting, development is becoming more and more open to everyone... We will probably be writing text prompts to AI to develop at some point and people will not even know that such thing as a programing language exists.
LoL, bro react is a library which is built using JavaScript. so that means yes you can use JavaScript completely without touching React to build the entire website, but when a project gets bigger it will make your life heII. And React makes your life easier and also it has so many beneficial things that makes your work efficient and makes the website rendering faster.
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 !
52:40 you just popped in my feed and I genuinely find your content interesting but I think there's a misconception here. You know that React is not aimed at people who are actually trying to "understand how it works mechanically". It's made for an industry who hires quickly trained developers to make websites for cheap. It's not that people are insecure, it's just that you are using a tool for the wrong purpose and the fact that you are aware about it and complaining IS frustrating (for me at least).
I think the same as you in the sense of wanting to look "under the hood". There's a sub-section of web-developers that are the same, but unfortunately, not enough. Keep up the great content!
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.
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 know its a meme to hate on JS / React / Webdev space, but it does make me sad watching a talented developer not actually explore WHY a tool has gained so much traction and WHY it is more effective then writing 100 lines of plain js. Too narrow minded and elitist. Like @east_wood says, learning a framework is always going to be encouraged in a top-down approach. No one writing Unity tutorials is going to bother explaining in the internal mechanisms of Unity in their getting started section. Its kind of silly to expect that.
it's true, tutorials are designed with beginners in mind, why would they bother explaining complicated behind the scenes stuff in a getting started tutorial. He's bit of an egoist but mostly nice.
1. I've never touched web development before, but this video inspired me to try it out! After a couple of days I feel like I have a decent grasp on the basics of npm and a few frameworks. I basically worked my way from vanilla js with preact (no npm) up to a "proper" framework project with jsx and a bundler. 2. Solidjs seems like a more polished / fully-featured (although also more abstracted) version of the grecha.js modifications shown in this video. grecha.js could also be pretty easily modified to support jsx. 3. By far the best tool I found for doing js frameworks the "intended" way is esbuild, it has 0 dependencies, handles typescript and jsx transpilation, and it's written in go rather than js. 4. Although I don't love every part of this video, it was super helpful at somewhat demystifying js frameworks. The grecha.js counter issue also does a good job at demonstrating why people use these frameworks in the first place.
most painful is not using any kind of syntax highlight or formatting or JS intellisense... - There is zero reason for that, except being a defiant masochist.
I really would like to see a tutorial like you proposed "looking under the hood". I know most "modern" tools try to infect you with diabetes from the syntax sugar. Really appreciate your approach. "Was für eine Scheiße" :D
Idk why people feel uncomfortable. I am very satisfied with your videos, I even keep track of list of youtubers who dive into low level stuffs like these. Keep up the good work!
Like there is a lot of ranting in this, and I get a little bit of like linux bro elitism as a vibe ngl, but I also totally get what this guy is feeling and feel that too. It feels like how increasingly software and hardware just hides options away from you, and if you ask why, they just tell you "oh you're supposed to use it this way". "What if I don't? What if I want to use it a different way?" I might ask. "Don't. This way makes us more money" they'll respond. In this case, I think increasing layers of bs gives companies more control over the web. There are so many abstraction layers to play ball that you are forced to accept limitations put there on purpose because its just too complicated not to use it. You see it with modern web browsers for instance where there exist binary blob pieces of malware like Widevine which utilize hardware backdoors built into every complex processor since around 2015 at their l1 level of """security""", where you just should trust your hardware vendor to have the private and public asymmetric encryption keys to a locked off part of your processor that you aren't allowed to access, because you're just supposed to let google, netflix and intel "worry" about that for you. You know, give these arbitrary corporations unfettered access to whatever the hell they want because.... reasons.... Stay quiet young one, this is simply too complex for you to understand. Big Corpo has your best interests at heart! This is for """"""security"""""" and """"""""safety"""""""". Anyways. Just felt like going on that rant. Seriously though, look up widevine. If you care about your privacy, that rabbit hole will blow your god damn mind and piss you right off, because they took away your personal autonomy of your own device, regardless of what os you choose or software you download (so long as you use any web browser), and you are just supposed to trust them not to use in essence a vpn to and from an encrypted subprocessor on your computer. Absurd. I swear this relates to the web dev stuff too though. Part of the reason for minifiers, and all these frame works is to make sure end users simply have to use the "experiences" """provided""" for them. It all makes me feel sick.
