The biggest problem so far with React is that its often advertised as beginner friendly when in reality its not. You should only learn React If you can sit through understanding its APIs and the motivations behind them. Once you do that you'll realise its like using any other library.
Agree! Wrapping your head around useEffect, useCallback, useMemo dependencies ... and how re-rendering works etc. jQuery was much simpler for beginners! And conceptually... VueJS is much simpler. I haven't used Solid beyond basic tutorials... so can't comment there.
Among all the whining, this is the only comment that makes sense. Yes, it's not as beginner friendly as some other frameworks. But it's definitely worth your time and an enjoyable career if you truly like clean frameworks.
@@OneGuyWolfpack I have seen it done directly and sometimes indirectly. I have even seen some advice which said you don't need to learn JS to start using React, which is just horrible advice.
Being a Vue developer, articles like that makes me even happier I had chosen Vue a long time ago. I have never had to fight against the framework when the project scales in complexity. That's something I never had when using jQuery, qooxdoo, angular, ember. Primeagen should make a video with Evan You, it would be sooo interesting to watch.
While I used react first, it was short lived between jquery and vue. I jumped ship and started using vue in production in 2016. Fast forward, now I'm working in react(not my choice) and I'm genuinely appalled by it. It's like nothing has been learned. It's different than it was, maybe simpler in superficial ways, but it's not fundamentally better
at this point in time, the truth is that using react is like having stockholm syndrome. I have tried using Vue and Solidjs and it is spectacular. But in my company they only use react, and honestly I've been writing react for so long that when I use something else (although it's enjoyable) I feel like I'm developing slower. I don't know, it's confusing. We have to go to therapy
We just need some brave souls putting their foot down and just telling their manager the app's moving to solidjs. "Don't worry, it uses JSX, looks very similar to react, any react developer will get it immediatly. It's just better in every way"
I've used React for my job for 2.5 years to build a highly interactive app. The more I use react, the more I love VueJS. I've never spent so much time debugging race conditions in code. My team are all junior and intermediate devs. I wonder if react experience is different with a team of seniors building a slightly less interactive app??
React-dev say they want the render-function to be pure: `ui = f(state)`. In my opinion this is 100% true and 90% irrelevant. The hard part is to change your state on event emission, so that it stays synchronized, rendering is 'easy' (that means that there is knowledge on how to do that efficient). To help with that solid separates its state in two parts: State and Derived-State. Your ui has then the relation `ui = fn(state + derived_state)`. When State is updated any Derived-State will update automatically, and once that is done you can render. React does not have derived state as a first class concept. It can simulate it by rerunning your component and recomputing every local variable (with optional caching), and declare these variables as derived state. But it is a simulation and the underlying mechanisms leak and now they start to stink.
i love vue man, but finding jobs in it is hard. i'm trying to jump companies and there are like 10x less jobs, unless you're really experienced developer you're really being punished for liking not-the-mainstream-framework.
I'm currently doing Angular at work, and i've done VueJS for class projects, the thing is, i'm developing with some mates the last project for class and i'm in the front-end with React, i cannot even describe how i was feeling while learning how React worked. It feels so much more complicated, and even with Typescript and Angular i feel more comfortable than with react.
I would like to as well. With React, most complicated ui websites have React and i always wonder how would it run without having to constantly run a million functions for each each ui change lol
Actually there are complex stuff built with solidjs, such as zapp, a sandbox for building dart and flutter applications inside the browser page. There's asciinema player which is a web player for terminal session recordings, it's most notable feature is the ability to copy-paste terminal content, it's just a text after all! The virtual terminal interpreter uses Rust, while the views (UI or frontend of player) uses solidjs. Another project is aoe4 explorer, has useful visualization and UI to explore units, their stats and abilities and all possible upgrades and technologies for Age Of Empires 4. Lastly CodeImage, similar to carbon, where you create and share beautiful images of your source code snippets.
"When you use something try to imagine how you would implement it" - I do this with most software I use, It's the same curiosity that bites when I hear music I like and _attempt_ to play it on my guitar.
I'm not sure whether React is inherently more difficult to learn or whether new devs have holes in their JS understanding - I found in my React journey, the better I understood JS, the easier it was to understand React.
I think that it's a bit of both. I think it's possible for someone to be an absolute expert in JavaScript - full understanding of the event loop, no confusion about closure, the works - and still be thrown for a loop with React. React is increasingly becoming more of a black box. Whenever you use a hook, you just expect the state associated with it to persist across renders "somehow". To get the most out of rendering performance, you need to have a full, through understanding of what does and doesn't cause a re-render (especially when context gets involved). You have to be mindful of how you're defining non-primitives and whether changing values could cause all memoization to break (especially for seemingly innocuous things like the children API). You also have to be aware of when effects run, and make sure you don't run into timing issues. If you're on board with the React team in minimizing the use of useEffect, you suddenly have to be aware of previously-niche things like calling a state dispatch directly in the render logic, to make sure the current render gets discarded, and immediately re-runs with the updated state. I think one of the things that might be contributing to the sense of grumpiness is a disconnect between how React presents itself, and how it's actually being used. React always promised to be based in functional programming, but even back in the day, they were stretching the definition of it by including state in things. Now it feels like you have to keep getting more and more imperative with your code to keep things performant, but the tools you're working with are still couched in this franken-functional approach, and it's just painful.
This. I see a lot of “React problems” but are problems made from people that don’t understand how JavaScript works. Also, a lot of people don’t read the docs. Create memos and useCallbacks everywhere, when the docs say they should be last resort.
@toast svelte has an entire section devoted to templating and directives, as well as special syntax - how is this not its own language? That being said, I'm not saying one is better, but I'm glad that good alternatives exist for those who don't enjoy React's philosophy. Personally, of the newer frameworks out there, only SolidJS appeals to me.
I can speak to this a little. I have only been coding about 2 years. About 3 months in, I’d been working with JS for about a month and a half. I decided to jump straight and build an e-commerce site for my mom with react. It took a month, but I got it done, and I’m proud of it, but it nearly broke my brain. At the end, I wasn’t even sure what was react and what was JavaScript . Making anything else was extremely difficult. I decided to go back and just do JS. That’s all I did was drill JS fundamentals for 4 months. When I went back to react it was sooooo much easier
1:15 Jquery was useful when js was shitty for handling async data and the selectors were shitty, after those things were fixed they didn't really pushed for something game changing and they existed for years as a dependency in Bootstrap 🤣
Well, for those of us who discovered modern front-end with AngularJS when it came out, 3 years before React, sorry but never went through the square "react is awesome". Vue on the other hand, really felt like the best of both worlds to me
14:05 This is the default mode my brain is in all the time. Can't turn it off, only recognise it and switch thoughts. The moment I see a feature that stands out in a game or just attracts my attention, or something on a website, etc. my mind starts working out how it could be made.
Forms in React are really a conceptional nightmare. A DOM input element already has it's own state. It holds the value in state, and it must hold the value in state, because its functionality is unrelated to frameworks and must work even for unscripted forms. For most forms and inputs, there's no need to write React controlled inputs. It's sufficient for most forms and inputs to use onSubmit handling along with named submit buttons. A form.onSubmit handler could be as "simple" (and I'm being sarcastic here) as ev.preventDefault(); setState(Array.from(new FormData(ev.target)).reduce((a, [k, v]) => (a[k] = v, a), {})) The biggest issue with this approach: this fails for complex forms for managing nested data. A few additional minor inconveniences are how it requires setting the input[name] and using [type=submit] buttons, and appropriately preventing the DOM default behavior of onSubmit. Unfortunately, fixing/changing the DOM behavior of HTML forms is out-of-scope for React developers and React users, or even anyone else for that matter. The W3C seems violently opposed to introducing any change in any practical and sensible manner, and especially when such a change would benefit the HTML/JS ecosystem as a whole. There's some kind of reasoning for backwards compatibility, but this seems more like cultic chanting than actually sensible reflection - without JS and frameworks a huge amount of todays www would simply be non-functional putting the usefulness of supporting such clients in question. Not sure why the W3C created versioned drafts and versioned standards, but never bothered to create a versioning draft and versioning standard for capability checks of clients. Obviously, because it's way to useful and practical.
For my freelancing, I prefer my ALMOST external dependency free approach to building out a UI; - Shadow DOM enabled Web Components - Declarative Shadow DOM enabled Web Components when doing SSR - Import assertions for native CSS modules and JSON modules - FLUX implementation for client-side state management - Navigo router (when building an SPA. Once the Navigation API is widely supported, I'll drop this external dependency) - Some polyfills - Cypress for testing With that being said, I make sure I'm proficient with React if a good corporate opportunity presents itself to me.
@@lukivan8 Whereas most languages have edges cases and hidden pitfalls you need to watch out for, Javascript feels like a language composed entirely out of edge cases and hidden pitfalls
A language or a library or a framework can't hold you hostage but the industry and the community around it do, because you can't avoid a technology if everyone is using it.
I just want to throw my point, because it's seems opposite to the one prevalent here, so i work with react mostly, i tried svelte and don't get the hype. Also before i worked with vue and it was meh, moved to react and never looking back. So, what i love that in react you're making things more programmatically and functionally, you can map jsx, ternary it, you can even pattern match jsx with ts-pattern(!!), add ramda or whatever if you wish even more fp, and etc, it's just much more flexible and powerful than template languages, in this regard svelte and vue feel like step back. Also huuge ecosystem, tools, hireability, ts support, and much more, right now I don't see any reason to use anything else on production frontend(except for projects that need very little of frontend). So yeah, i love it, happy with it, highly recommend to anyone, and just don't understand this hate, seems like some ppl just don't get the point of react or scared of jsx syntax at first and never tried to understand motivation behind it really. Or maybe this quote about languages can be used here too - there are the ones people complain about and the ones nobody uses.
17:00 honestly webdevs need to develop on 10 year old thinkpads (or at least do web testing on them). If the site can't run decently on it, you made it crappy and slow for no reason.
I find using something like HTMX is really easy to do and can take you a long ways. For interactive pages add in web components. For highly interactive pages use a front end framework or create a flow yourself.
HTMX is taking the purist direction and sticking with the fundamental concepts of Hypertext instead of beating everything to death with JavaScript state component hell.
In all honesty, should I learn react for the large number of jobs requesting it? Or just learn Vue? I’ve heard Vue is so much more forgiving to the programmer.
I have a question about the memoization statement around 18:50. He says that using a Hashmap for Memoization is less performative than using a list and iterating through it. From a big O perspective isn't using memoization with a hashmap a time complexity of O(1) with a space complexity of O(N) while iterateing through a list O(N) with a space of O(N)? How could iterating through an entire list be faster at least from a big O standpoint?
like he says, hash maps have to resize. hash msps have some non trivial hash function involved. Collision mitigation. etc. Hence possibly not faster than an array type of collection when it comes to small sets. It really depends on the particular implementation of those things in the medium at hand, which in JS are well under the hood, as well as the specific use case. Big O is a broad generalization but here he's talking about the possibilities of specific circumstances outside of generalization.
4:55 Yeah I absolutely dont like hooks. The continuity of codebases just fell apart as soon as they were introduced. I remember looking at the proposal and thinking "this is really dumb" and almost always when I have that feeling it turns out to be vindicated eventually. It seemed like a bunch of FP zealots were just getting a hardon at the prospect of being able to remove classes for the sake of it. Some of the best and cleanest react apps subscribed to the Container-Presenter Pattern where containers were classes and presenters were pure functions/ dumb components. React codebases have been unanimously shoddier since hooks were added. Yes there was a edge case where they would add value. i.e. where you didint want to have to pipe state around your application but it was and should have been an edge case not the default. Sort of how when SwiftUI was announced the the person doing the presentation had the foresight to explicitly say ObservedObjects were not the default mode of state management but was there in cases where you needed state modularity. React did the complete opposite. They painted hooks as some sort of magical win for FP. "Rejoice! Now we can completely rid ourselves of classes" ... as if that was something that needed to be done. If that wasn't enough to make you cringe/ your spidey senses start to tingle then you probably are beyond help.
I love React. I use to prefer Vue, but with TypeScript React is the much better experience between the two. That and you have to deal with a custom file type with Vue where as React is just JS/TS. The truth is you need to be fairly good at programming to enjoy working with it, and if you aren't it's going to suck. That said I don't think that is a bad thing. Making UIs are hard for a reason, there are a lot of things you need to get right regardless of the tooling or language. The truth is most of these bloggers or programmers that complain about React suck at it.
Designing UIs is hard. Making UIs is piss easy. React made it hard. If you're fairly good at programming, you wouldn't choose React, simply because you'd avoid problems that you shouldn't have in the first place.
@cocoscacao6102 well, considering I've been a software engineer since 2007, and for UX I've worked with everything from php and concatted js, to backbonejs and requirejs, ampersandjs, to angular, to vue, React (of course), to Svelte, and Solid.js. I'm fluent in PHP (gross), Ruby, Java, JS, Python, TS, Zig, and Rust. I've built backends with CakePHP, RubyOnRails, Spring, Django, Nodejs, Tide, actix and yew, and others (still waiting for Zig to have something mature). I've led a number of teams and architected a number of software products. With all these technologies, I've built component libraries and applications, monoliths, and microservices. Out of these tools, in regards to frontends, I find I quite like React and find it to be a great tool to create a maintainable and reusable code, and I vividly remember what it was like before any of these modern tools and libraries existed - many years before. It was awful, and if you think otherwise, you're absolutely wrong. Also, building application interfaces isn't a trivial problem, if you think it is, then you must be pretty green. But hey, who to f**k am I right? You must know better.
Honestly from start I liked jquery more than react. Although I had only learnt of class components in react, which I didn't liked the broiler plate of. And even with hooks I could never be as comfortable as I'm with jquery, and will still use fair amount of jquery with ref. But svelte for me was and is magical it's everything I would have wanted react to be. Hooks innitially seemed fun, before hooks put me through hell and back just to understand why a piece of code was either not running or running too many times.
1:07 *I disliked JQuery from the beginning* Yes, it made write a little less chars, but at the expense of: - understanding what JS was actually doing - bandwidth - memory usage Of course, compared with the nuclear steam mammoth that are sent by TCP for every page component today, it's nothing. But I almost immediately disliked the fact it was made for noobs rather than for machines. In fact, it's not that JQuery was bad, but that it was a quick patch on the lack of standardisation of the browsers.
this was a big comment here. you end with the reason why jquery exists and why it was great but start of saying it wasn't gerat ;) it was great, you know it, i know it, we all know it.
@@ThePrimeTimeagen I never used _JQuery_ but in tutorials and private tests. I'm still writing JS without framework nor library quite often, just because I don't find what compiles in what I actually want without bloat. :p Most of the time I look for a framework or a library that does what I want, I spend more time comparing all the ones that pretend to do what I want without knowing, reverse-engineering them to make sure they do what they claims to do, debugging their documentation, patching out their unneeded code, hacking around their limitations, getting lost, crying… than doing the very modest thing I actually need and I can code from scratch. And anytime I'm finished accepting the flaws of a tool… an update comes. Soon people are going to rely on "magic" obscure AI to optimise their code and compile better… like if they couldn't be intelligent enough themselves, or better said like if they didn't wanted to be. Good luck maintaining an automated online service maintenance monster instead of an online service. :p Languages are great already. And when they aren't, libraries and framework can only camouflage their flaws. I don't work well at all with camouflaged flaws. They beat me. I want way too much control on the final result. Nostalgia of _6502 Assembly_ , maybe. ;D And yes, this is me being very silly. In practice, there is no way to work with others without shared libraries and frameworks. Better bad work than nothing works.
Having started with web development in the previous century, I dare to say that the scale of impact that Firebug/DevTools and jQuery have had will be impossible to beat.
@@thomasw.4298 And so what? TUI is still UI development, and it has the same practices and problems inherent to it. I bet the first thing people would do if TUI's would become popular, is create a templating engine. And then you wouldn't notice how you got reactivity built around it. It's full circle.
I guess I'm in an unpopular opinion as well. I have the same point of view. I started disliking React when Hooks were introduced. Call me old-fashioned, but I found it easier to prepare as Class Components, especially with lifecycle functions. When I saw useEffect the first time, I thought it was a CSS effect 😅Wasn't it easier to identify something like componentDidLoad?
Vue in my opinion is just the best. Very stable and reliable, you don't have to constanctly adjust to new versions. But I only had to work with Angular, React and Vue so far. From those 3, clear winner Vue.
As someone who started studying coding 2 months ago it's such a good feeling that every part I had a problem with ended up being that the language itself was bad. I went through Ruby and python courses no problem. JavaScript just doesn't make sense to me and when I got to the react I told myself I'm never using this and I'm never going to get a job where they use this 😂
i want you to look at the code again. look at it really carefully, because its siting right there.... IN FACT, i'll start typing it here const value = useMemo(() => { ... //
I've only ever used Vue Class Components and React and React is miles better. That's not to say that React is good, but a lot better than Vue Class Components which are so insanely boilerplatey
Did you mean Options API? Or just class components, bc they are no longer used for a bit of time. Nowadays Vue 3 introduced Composition API with is kind of similar to React, albeit still with template, but you can use jsx if you would realllly want.
in react class components are just so much easier to design for and functional are just qucker for small task IMO , i dont like being forced by industry to convert to functional when its not needed. from the point of view of project constency maybe but the level of complexity functional component hooks add to project when having to get simple things done through useEffect and initializing multple setState variables over having singular state object becomes a nightmare to me and handling conditional set states instead of using set class state callbacks , just makes a back and forth tracking head ache for larger components and increases code of a complex component by tons with each useEffect that could have been replaced by a more readable small call back or multi state single update. I agree , React started off great but its forced migration to hooks instead of optional usage isnt something I agree with, sure its optional now but every article i read and google search I see , implies that class components are goign to be phased out at a point which forces companies to enforce developers to only use pure functional .
I wonder what web devs have against just pushing shit to the stack and using static memory, it seems like everyone likes to depende on their slow heap and be affected by the GC? most of these problems that incur in huge times of GC seems to be a simple problem to solve in languages that allow you to allocate in the stack
I remember when I used to dislike Angular because I was a react fan. Now I'm jumping around different projects that use angular and its such a breeze. Every new react project I would join I would just look at the code like "wtf is going on here"
"Think how oyu'd implement it" see problem is I'd build vue to maximize reuse of state and functions, aka not recreating it all every frame and minimize the amount of redraw/overdraw. That's precisely why I hate react, it utterly sucks to work with. Theres a reason Im building my team around vue, juniors can understand how it works because its intuitive; setup is setup the template is what gets rendered, when a variable gets updated the proxy informs only the things that it affects, easy. Would never expect a junior to know how to build that from scratch though
Man I don't use JavaScript and I'm happy about that. When I see articles like this, or videos like this it just makes me glad that I am not a front-end engineer at all. I don't really do web dev either that often, when I do it's mostly back end or server side stuff. Even when I have built UIs and stuff like that I usually use SSR via some native language not some nonsense like JavaScript. The funniest thing about react to me is the fact that they're effectively trying to recreate some of the powerful features of functional languages like elm or ocaml. Hell, react was originally written with Ocaml which is also why they released reasonML (I guess it's called rescript these days). The problem is that JavaScript just doesn't support the features that they're trying to build. You can talk all you want about having immutable data structures and reactive systems but you have a single threaded model that runs using event loops and even the non-mutable variables in JavaScript can get mutated behind the scenes.
"You should take a moment to think about how things work" Completely agree but it's also telling us that the abstraction is therefore incomplete. And that's something most people refuse to realize.
Also the problem with skill rots. I recently got laid off so I've had sometimes to look back at my career. React traps you, everybody uses it, it's like Java. You can't get out of it, learn something new, or become better.
I believe hooks was the place it started to fall apart. It's very similar to Angulars life cycle hooks. Yet react had not previously done this and so it was a very early feature.
I never learned ReactJS, because I created my own framework back in 2017. Sadly I never released, only using in my own projects. Reason why I rejected to learn ReactJS is pretty simple. I goto Facebook and search something. Then I opened browser's task manager and scroll page down little bit. Then look back to the task manager, Facebook single web page using over 1GB ram. I was like WHAT??? I think that problem was still existed in previous year too, I don't what happens now. One thing for sure. There is a lot of garbage collection and memory related issues. That is why i said HELL NO to ReactJS!
I see a trend on hating React. Have you guys seen angular? Nothing against it it's just way harder. Solidjs? I'm actually excited to learn but to say React is bad? goh. Hooks ARE easier, it simplified sooo much. Just like Redux to Redux toolkit but somehow people are complaining more 🤷🏼♂️
I agree, people are hating on react the same way they complained about jQuery, but they forget that it has been around for ages, and as every bit of tech, does not age perfectly. But there is a reason why Solid is SO alike to React, the patterns and structures React allows are proven and clearly preferred by a lot of people. Hell even Angular shapeshifted to survive agains React
@@Fernando-ry5qt I'm just saying people always did reactive programming, along comes react everybody looses their mind and adopts. Few years later, nah react doesn't work let's go back to reactivate instead of functional. Also you could manage state reactively with mobx, subscribing to and having observers and all that jazz
those prefer class over hooks are not react developers, not sure are they even frontend ? probably some java 'fullstack' devs. just go use angular dude
"Take a moment and imagine how you would do something." See, here's the trouble. I do that. I do that all the time, in fact. My troubles come because I'm a new programmer, and I have a very bare-metal imagination about how things should be done. I don't understand what and why a class should be a thing, I don't understand how methods or functions get attached to classes, and I am therefore missing a large chunk of the toolset used by most programmers to do most things. So I'm over here trying to use a table saw as if it were built by hammers and hand saws, meanwhile the person making the damn thing is using exclusively electric screwdrivers and CNC machines to build it. I have sat there and stared at my screen for many an hour because of this fundamental mismatch.
When someone asks me 'Why do you have some concerns about React Hooks?' I always answer: Read those Rules of Hooks, and read them carefully. Try to understand them well. Then you will see the answer by yourself. No other discussion will be needed... Usually, no one wants to argue with me after that 😊
Oddly, I avoided React like a plague during the class component/high order component bullshit and hooks where to me the reason to get back, I find it a trillion times better DX and easier to maintain
The biggest problem so far with React is that its often advertised as beginner friendly when in reality its not. You should only learn React If you can sit through understanding its APIs and the motivations behind them. Once you do that you'll realise its like using any other library.
EXACTLY
Agree! Wrapping your head around useEffect, useCallback, useMemo dependencies ... and how re-rendering works etc. jQuery was much simpler for beginners!
And conceptually... VueJS is much simpler.
I haven't used Solid beyond basic tutorials... so can't comment there.
Among all the whining, this is the only comment that makes sense. Yes, it's not as beginner friendly as some other frameworks. But it's definitely worth your time and an enjoyable career if you truly like clean frameworks.
I've never heard it described as beginner friendly. Whoever said that must be trying to sell their code camp course
@@OneGuyWolfpack I have seen it done directly and sometimes indirectly. I have even seen some advice which said you don't need to learn JS to start using React, which is just horrible advice.
Being a Vue developer, articles like that makes me even happier I had chosen Vue a long time ago. I have never had to fight against the framework when the project scales in complexity. That's something I never had when using jQuery, qooxdoo, angular, ember. Primeagen should make a video with Evan You, it would be sooo interesting to watch.
While I used react first, it was short lived between jquery and vue. I jumped ship and started using vue in production in 2016. Fast forward, now I'm working in react(not my choice) and I'm genuinely appalled by it. It's like nothing has been learned. It's different than it was, maybe simpler in superficial ways, but it's not fundamentally better
At the end of the day, the problem is Javascript. There will be a new React in the years to come, and people will be whining again on medium articles.
these are facts
new react is solidjs
As a rookie dev, I found react to be unintuitive, half-baked... Always needing more and more dependencies to make simple features work.
@@A--_--M like what
Solid has entered the chat, with Qwik and Astro waiting behind it.
at this point in time, the truth is that using react is like having stockholm syndrome. I have tried using Vue and Solidjs and it is spectacular. But in my company they only use react, and honestly I've been writing react for so long that when I use something else (although it's enjoyable) I feel like I'm developing slower. I don't know, it's confusing. We have to go to therapy
We just need some brave souls putting their foot down and just telling their manager the app's moving to solidjs. "Don't worry, it uses JSX, looks very similar to react, any react developer will get it immediatly. It's just better in every way"
It's normal if X is faster to develop than Y, if you have 10 years of XP in Y you'll be faster with Y at least for a certain time.
What’s the value of the constant P?
@@Chris-se3nc Not sure whether your questions is sarcasm. Anyway, XP stands here for experience.
I've used React for my job for 2.5 years to build a highly interactive app. The more I use react, the more I love VueJS.
I've never spent so much time debugging race conditions in code. My team are all junior and intermediate devs. I wonder if react experience is different with a team of seniors building a slightly less interactive app??
Vanilla JS/TS and Web Components. Do the DOM yourself. Performance goes through the roof. Everyone’s happy.
why people don't do it ? vanilla is better though. and It is faster too
People love jsx, not react, they just don't know it yet
Yeeeees
@toast I grow quickly tired or template composition with angularJS, like jsx better due to the collocation of related state and output
React-dev say they want the render-function to be pure: `ui = f(state)`. In my opinion this is 100% true and 90% irrelevant. The hard part is to change your state on event emission, so that it stays synchronized, rendering is 'easy' (that means that there is knowledge on how to do that efficient). To help with that solid separates its state in two parts: State and Derived-State. Your ui has then the relation `ui = fn(state + derived_state)`. When State is updated any Derived-State will update automatically, and once that is done you can render. React does not have derived state as a first class concept. It can simulate it by rerunning your component and recomputing every local variable (with optional caching), and declare these variables as derived state. But it is a simulation and the underlying mechanisms leak and now they start to stink.
i love vue man, but finding jobs in it is hard. i'm trying to jump companies and there are like 10x less jobs, unless you're really experienced developer you're really being punished for liking not-the-mainstream-framework.
I hope you can dive deeper into svelte/sveltekit. I wanna see a deep dive take from you of it vs SolidJS
Once thing is certain, I really like your energy, ThePrimeagen! Keep up the great content.
I'm currently doing Angular at work, and i've done VueJS for class projects, the thing is, i'm developing with some mates the last project for class and i'm in the front-end with React, i cannot even describe how i was feeling while learning how React worked. It feels so much more complicated, and even with Typescript and Angular i feel more comfortable than with react.
Glad you like it but Angular is absolute garbage for me.
Last version is so much better
I mean the last version of Angular
I'd like to see something really complex or real world built with solidjs, not just their docs site :)
I would like to as well. With React, most complicated ui websites have React and i always wonder how would it run without having to constantly run a million functions for each each ui change lol
Actually there are complex stuff built with solidjs, such as zapp, a sandbox for building dart and flutter applications inside the browser page. There's asciinema player which is a web player for terminal session recordings, it's most notable feature is the ability to copy-paste terminal content, it's just a text after all! The virtual terminal interpreter uses Rust, while the views (UI or frontend of player) uses solidjs. Another project is aoe4 explorer, has useful visualization and UI to explore units, their stats and abilities and all possible upgrades and technologies for Age Of Empires 4. Lastly CodeImage, similar to carbon, where you create and share beautiful images of your source code snippets.
@@peanutcelery still running millions interconnected signals ( functions )
@@peanutcelery maybe they are not using hooks at all and imposing some mvc -esque design pattern to separate purity, impurity and UI etc
You say you hate the take that “fast enough is good enough” but you earlier said you don’t really bother memorizing in Solid because it’s fast enough.
"When you use something try to imagine how you would implement it" - I do this with most software I use, It's the same curiosity that bites when I hear music I like and _attempt_ to play it on my guitar.
I'm not sure whether React is inherently more difficult to learn or whether new devs have holes in their JS understanding - I found in my React journey, the better I understood JS, the easier it was to understand React.
Most new developers I feel are skipping learning js and going straight to react.
I think that it's a bit of both. I think it's possible for someone to be an absolute expert in JavaScript - full understanding of the event loop, no confusion about closure, the works - and still be thrown for a loop with React.
React is increasingly becoming more of a black box. Whenever you use a hook, you just expect the state associated with it to persist across renders "somehow". To get the most out of rendering performance, you need to have a full, through understanding of what does and doesn't cause a re-render (especially when context gets involved). You have to be mindful of how you're defining non-primitives and whether changing values could cause all memoization to break (especially for seemingly innocuous things like the children API). You also have to be aware of when effects run, and make sure you don't run into timing issues. If you're on board with the React team in minimizing the use of useEffect, you suddenly have to be aware of previously-niche things like calling a state dispatch directly in the render logic, to make sure the current render gets discarded, and immediately re-runs with the updated state.
I think one of the things that might be contributing to the sense of grumpiness is a disconnect between how React presents itself, and how it's actually being used. React always promised to be based in functional programming, but even back in the day, they were stretching the definition of it by including state in things. Now it feels like you have to keep getting more and more imperative with your code to keep things performant, but the tools you're working with are still couched in this franken-functional approach, and it's just painful.
This. I see a lot of “React problems” but are problems made from people that don’t understand how JavaScript works. Also, a lot of people don’t read the docs. Create memos and useCallbacks everywhere, when the docs say they should be last resort.
@toast svelte has an entire section devoted to templating and directives, as well as special syntax - how is this not its own language?
That being said, I'm not saying one is better, but I'm glad that good alternatives exist for those who don't enjoy React's philosophy. Personally, of the newer frameworks out there, only SolidJS appeals to me.
I can speak to this a little. I have only been coding about 2 years. About 3 months in, I’d been working with JS for about a month and a half. I decided to jump straight and build an e-commerce site for my mom with react. It took a month, but I got it done, and I’m proud of it, but it nearly broke my brain. At the end, I wasn’t even sure what was react and what was JavaScript . Making anything else was extremely difficult. I decided to go back and just do JS. That’s all I did was drill JS fundamentals for 4 months. When I went back to react it was sooooo much easier
I use Vue 3 at work and it's so easy to maintain.
#Vue4Gainz
Do you use it with Typescript or plain Javascript?
1:15 Jquery was useful when js was shitty for handling async data and the selectors were shitty, after those things were fixed they didn't really pushed for something game changing and they existed for years as a dependency in Bootstrap 🤣
Well, for those of us who discovered modern front-end with AngularJS when it came out, 3 years before React, sorry but never went through the square "react is awesome". Vue on the other hand, really felt like the best of both worlds to me
14:05 This is the default mode my brain is in all the time. Can't turn it off, only recognise it and switch thoughts. The moment I see a feature that stands out in a game or just attracts my attention, or something on a website, etc. my mind starts working out how it could be made.
Forms in React are really a conceptional nightmare. A DOM input element already has it's own state. It holds the value in state, and it must hold the value in state, because its functionality is unrelated to frameworks and must work even for unscripted forms. For most forms and inputs, there's no need to write React controlled inputs. It's sufficient for most forms and inputs to use onSubmit handling along with named submit buttons. A form.onSubmit handler could be as "simple" (and I'm being sarcastic here) as
ev.preventDefault(); setState(Array.from(new FormData(ev.target)).reduce((a, [k, v]) => (a[k] = v, a), {}))
The biggest issue with this approach: this fails for complex forms for managing nested data. A few additional minor inconveniences are how it requires setting the input[name] and using [type=submit] buttons, and appropriately preventing the DOM default behavior of onSubmit.
Unfortunately, fixing/changing the DOM behavior of HTML forms is out-of-scope for React developers and React users, or even anyone else for that matter. The W3C seems violently opposed to introducing any change in any practical and sensible manner, and especially when such a change would benefit the HTML/JS ecosystem as a whole. There's some kind of reasoning for backwards compatibility, but this seems more like cultic chanting than actually sensible reflection - without JS and frameworks a huge amount of todays www would simply be non-functional putting the usefulness of supporting such clients in question. Not sure why the W3C created versioned drafts and versioned standards, but never bothered to create a versioning draft and versioning standard for capability checks of clients. Obviously, because it's way to useful and practical.
On the form's being hard, Remix did a good job reminding and teaching new folks that we rarely need to control our form inputs.
Thanks for the read!
Oh hey it EmNudge
For my freelancing, I prefer my ALMOST external dependency free approach to building out a UI;
- Shadow DOM enabled Web Components
- Declarative Shadow DOM enabled Web Components when doing SSR
- Import assertions for native CSS modules and JSON modules
- FLUX implementation for client-side state management
- Navigo router (when building an SPA. Once the Navigation API is widely supported, I'll drop this external dependency)
- Some polyfills
- Cypress for testing
With that being said, I make sure I'm proficient with React if a good corporate opportunity presents itself to me.
prime if react content holding you hostage blink twice in the next reaction video
Signals is now everywhere, preact, angular and so on... They all follow the lead of solidjs
agreed
Everytime I watch a React video, I am reminded why I avoid front-end/full stack like it's the plague
I mean, why? I haven’t felt like this. And I was back-end dev for almost 2 years before shifting to full-stack
I always hated frontend until I found svelte
@@lukivan8 Whereas most languages have edges cases and hidden pitfalls you need to watch out for, Javascript feels like a language composed entirely out of edge cases and hidden pitfalls
he always says "let's see" when he reads its kinda funny
A language or a library or a framework can't hold you hostage but the industry and the community around it do, because you can't avoid a technology if everyone is using it.
I just want to throw my point, because it's seems opposite to the one prevalent here, so i work with react mostly, i tried svelte and don't get the hype. Also before i worked with vue and it was meh, moved to react and never looking back. So, what i love that in react you're making things more programmatically and functionally, you can map jsx, ternary it, you can even pattern match jsx with ts-pattern(!!), add ramda or whatever if you wish even more fp, and etc, it's just much more flexible and powerful than template languages, in this regard svelte and vue feel like step back. Also huuge ecosystem, tools, hireability, ts support, and much more, right now I don't see any reason to use anything else on production frontend(except for projects that need very little of frontend). So yeah, i love it, happy with it, highly recommend to anyone, and just don't understand this hate, seems like some ppl just don't get the point of react or scared of jsx syntax at first and never tried to understand motivation behind it really. Or maybe this quote about languages can be used here too - there are the ones people complain about and the ones nobody uses.
"Spend time thinking about how you would have wrote it". But that's the problem Prime. I wouldn't have written this dev experience upon anyone.
Where can I find the link to the article, it's not in the video description 🥺
Guys somehow AlpineJS is "almost react" but it does everything with like 4-5 html tags ( most of time ).... that cant be any simplier
17:00 honestly webdevs need to develop on 10 year old thinkpads (or at least do web testing on them). If the site can't run decently on it, you made it crappy and slow for no reason.
One of the biggest problems with web dev, a lot of dev work is done disconnected from what the common user daily drives.
@@allesarfint but how would that work?
That's my pc
@@ZeroBl_ I love my old Thinkpad
Or just turn on CPU throttling?
I find using something like HTMX is really easy to do and can take you a long ways. For interactive pages add in web components. For highly interactive pages use a front end framework or create a flow yourself.
HTMX is taking the purist direction and sticking with the fundamental concepts of Hypertext instead of beating everything to death with JavaScript state component hell.
get Evan you to the show! please!!
The more I use Svelte the more I love it and hate React.
I found it hard to understand react I just wanted to do vanilla js and html files
Try Svelte then
This just helped me dedub an application for work lol. Cheers Prime
Even in the early days of hooks, I often included the term "hooker" in my talks...
at this point im just using prime as an audio book reader
In all honesty, should I learn react for the large number of jobs requesting it? Or just learn Vue? I’ve heard Vue is so much more forgiving to the programmer.
I have a question about the memoization statement around 18:50. He says that using a Hashmap for Memoization is less performative than using a list and iterating through it. From a big O perspective isn't using memoization with a hashmap a time complexity of O(1) with a space complexity of O(N) while iterateing through a list O(N) with a space of O(N)? How could iterating through an entire list be faster at least from a big O standpoint?
like he says, hash maps have to resize. hash msps have some non trivial hash function involved. Collision mitigation. etc. Hence possibly not faster than an array type of collection when it comes to small sets. It really depends on the particular implementation of those things in the medium at hand, which in JS are well under the hood, as well as the specific use case. Big O is a broad generalization but here he's talking about the possibilities of specific circumstances outside of generalization.
4:55 Yeah I absolutely dont like hooks. The continuity of codebases just fell apart as soon as they were introduced. I remember looking at the proposal and thinking "this is really dumb" and almost always when I have that feeling it turns out to be vindicated eventually.
It seemed like a bunch of FP zealots were just getting a hardon at the prospect of being able to remove classes for the sake of it.
Some of the best and cleanest react apps subscribed to the Container-Presenter Pattern where containers were classes and presenters were pure functions/ dumb components.
React codebases have been unanimously shoddier since hooks were added. Yes there was a edge case where they would add value. i.e. where you didint want to have to pipe state around your application but it was and should have been an edge case not the default.
Sort of how when SwiftUI was announced the the person doing the presentation had the foresight to explicitly say ObservedObjects were not the default mode of state management but was there in cases where you needed state modularity.
React did the complete opposite. They painted hooks as some sort of magical win for FP. "Rejoice! Now we can completely rid ourselves of classes" ... as if that was something that needed to be done.
If that wasn't enough to make you cringe/ your spidey senses start to tingle then you probably are beyond help.
I love React. I use to prefer Vue, but with TypeScript React is the much better experience between the two. That and you have to deal with a custom file type with Vue where as React is just JS/TS. The truth is you need to be fairly good at programming to enjoy working with it, and if you aren't it's going to suck. That said I don't think that is a bad thing. Making UIs are hard for a reason, there are a lot of things you need to get right regardless of the tooling or language. The truth is most of these bloggers or programmers that complain about React suck at it.
Designing UIs is hard. Making UIs is piss easy. React made it hard. If you're fairly good at programming, you wouldn't choose React, simply because you'd avoid problems that you shouldn't have in the first place.
@cocoscacao6102 well, considering I've been a software engineer since 2007, and for UX I've worked with everything from php and concatted js, to backbonejs and requirejs, ampersandjs, to angular, to vue, React (of course), to Svelte, and Solid.js. I'm fluent in PHP (gross), Ruby, Java, JS, Python, TS, Zig, and Rust. I've built backends with CakePHP, RubyOnRails, Spring, Django, Nodejs, Tide, actix and yew, and others (still waiting for Zig to have something mature). I've led a number of teams and architected a number of software products. With all these technologies, I've built component libraries and applications, monoliths, and microservices. Out of these tools, in regards to frontends, I find I quite like React and find it to be a great tool to create a maintainable and reusable code, and I vividly remember what it was like before any of these modern tools and libraries existed - many years before. It was awful, and if you think otherwise, you're absolutely wrong. Also, building application interfaces isn't a trivial problem, if you think it is, then you must be pretty green. But hey, who to f**k am I right? You must know better.
Honestly from start I liked jquery more than react. Although I had only learnt of class components in react, which I didn't liked the broiler plate of. And even with hooks I could never be as comfortable as I'm with jquery, and will still use fair amount of jquery with ref. But svelte for me was and is magical it's everything I would have wanted react to be. Hooks innitially seemed fun, before hooks put me through hell and back just to understand why a piece of code was either not running or running too many times.
@ThePrimeTime Looking for a video/stream where we see discussion on GRPC
Hi why did you stop posting to your other account on YT? I was wondering why you hadn't any new vids then someone mention you had another channel.
new video this week....
1:07 *I disliked JQuery from the beginning*
Yes, it made write a little less chars, but at the expense of:
- understanding what JS was actually doing
- bandwidth
- memory usage
Of course, compared with the nuclear steam mammoth that are sent by TCP for every page component today, it's nothing. But I almost immediately disliked the fact it was made for noobs rather than for machines. In fact, it's not that JQuery was bad, but that it was a quick patch on the lack of standardisation of the browsers.
this was a big comment here.
you end with the reason why jquery exists and why it was great but start of saying it wasn't gerat ;)
it was great, you know it, i know it, we all know it.
@@ThePrimeTimeagen I never used _JQuery_ but in tutorials and private tests.
I'm still writing JS without framework nor library quite often, just because I don't find what compiles in what I actually want without bloat. :p
Most of the time I look for a framework or a library that does what I want, I spend more time comparing all the ones that pretend to do what I want without knowing, reverse-engineering them to make sure they do what they claims to do, debugging their documentation, patching out their unneeded code, hacking around their limitations, getting lost, crying… than doing the very modest thing I actually need and I can code from scratch. And anytime I'm finished accepting the flaws of a tool… an update comes.
Soon people are going to rely on "magic" obscure AI to optimise their code and compile better… like if they couldn't be intelligent enough themselves, or better said like if they didn't wanted to be.
Good luck maintaining an automated online service maintenance monster instead of an online service. :p
Languages are great already. And when they aren't, libraries and framework can only camouflage their flaws. I don't work well at all with camouflaged flaws. They beat me.
I want way too much control on the final result. Nostalgia of _6502 Assembly_ , maybe. ;D
And yes, this is me being very silly. In practice, there is no way to work with others without shared libraries and frameworks. Better bad work than nothing works.
Having started with web development in the previous century, I dare to say that the scale of impact that Firebug/DevTools and jQuery have had will be impossible to beat.
We should all go on strike and make TUI's (terminal user interfaces). All hot keys no clicking. Our demands will be, "Hey, just try it"
you can also have all hot keys in a gui app
@@mzg147 ... ok but when we go on strike we get to take a break from making gui's.
@@thomasw.4298 And so what? TUI is still UI development, and it has the same practices and problems inherent to it. I bet the first thing people would do if TUI's would become popular, is create a templating engine. And then you wouldn't notice how you got reactivity built around it. It's full circle.
I guess I'm in an unpopular opinion as well. I have the same point of view. I started disliking React when Hooks were introduced. Call me old-fashioned, but I found it easier to prepare as Class Components, especially with lifecycle functions. When I saw useEffect the first time, I thought it was a CSS effect 😅Wasn't it easier to identify something like componentDidLoad?
These comments really discourage me to continue to learn react 😢
Vue in my opinion is just the best. Very stable and reliable, you don't have to constanctly adjust to new versions. But I only had to work with Angular, React and Vue so far. From those 3, clear winner Vue.
Link to the article please
When React and React Native broke up so did the idea of React. Why add a build time for something that only generates HTML5?
I just wanna say, I still like react 👌 somebody kill me
i still have to use react from time to time...
@@ThePrimeTimeagen what do you use most of the days? Besides Chad stack
solid analysis
Angular feels so much better despite all the hate.
Solid JS is difficult for Nested Reactivity!!
All frameworks are cults. I will keep saying this until it sticks. Join a cult, by all means, but keep that understanding in your mind and be wary.
Any thoughts on ember?
React Hooks is exactly where I jumped to Vue, as much as possible, until Svelte came out.
Solidjs also uses hooks, so whats the big win over there?
It uses a compiler, and doesn't re-run the entire function component that you wrote on literally every state update
As someone who started studying coding 2 months ago it's such a good feeling that every part I had a problem with ended up being that the language itself was bad. I went through Ruby and python courses no problem. JavaScript just doesn't make sense to me and when I got to the react I told myself I'm never using this and I'm never going to get a job where they use this 😂
I started coding about 2 months ago as well. And goddamn i hate javascript/react 😂😂😂 i started with python
how it was coded was wrong. Pro tip, limit your useState usage. I hate when giving a bad example proves a point
useMemo doesn’t create that array or function on every re render. 21:33 . please re check your knowledge about use memo
i want you to look at the code again. look at it really carefully, because its siting right there....
IN FACT, i'll start typing it here
const value = useMemo(() => { ... //
Is this one recreating the object on every re render?
const [obj, setObj] = useState({ _type: 'obj', size: '10gb' });
@ThePrimeTime
Thought again and it probably is. My bad
I've only ever used Vue Class Components and React and React is miles better. That's not to say that React is good, but a lot better than Vue Class Components which are so insanely boilerplatey
Did you mean Options API? Or just class components, bc they are no longer used for a bit of time. Nowadays Vue 3 introduced Composition API with is kind of similar to React, albeit still with template, but you can use jsx if you would realllly want.
@@kaedriz I do mean the legacy class components.
POV I have to read an Essay but I really have to pee
in react class components are just so much easier to design for and functional are just qucker for small task IMO , i dont like being forced by industry to convert to functional when its not needed.
from the point of view of project constency maybe but the level of complexity functional component hooks add to project when having to get simple things done through useEffect and initializing multple setState variables over having singular state object becomes a nightmare to me and handling conditional set states instead of using set class state callbacks , just makes a back and forth tracking head ache for larger components and increases code of a complex component by tons with each useEffect that could have been replaced by a more readable small call back or multi state single update. I agree , React started off great but its forced migration to hooks instead of optional usage isnt something I agree with, sure its optional now but every article i read and google search I see , implies that class components are goign to be phased out at a point which forces companies to enforce developers to only use pure functional .
I wonder what web devs have against just pushing shit to the stack and using static memory, it seems like everyone likes to depende on their slow heap and be affected by the GC? most of these problems that incur in huge times of GC seems to be a simple problem to solve in languages that allow you to allocate in the stack
I remember when I used to dislike Angular because I was a react fan. Now I'm jumping around different projects that use angular and its such a breeze. Every new react project I would join I would just look at the code like "wtf is going on here"
Wait until you use Vue, you will start shaking your head whenever you have to work with one of them.
I think this is happening with every single React developer trying a new framework at this point..
Agreed. Angular gets too much hate because of the 1.x versions. And don't get me started about forms in react Vs angular lol
As an avid user of Vue, I approve this message.
Link to this article?
Svelte babaaayyy
Does anyone has link to this article
"Think how oyu'd implement it" see problem is I'd build vue to maximize reuse of state and functions, aka not recreating it all every frame and minimize the amount of redraw/overdraw. That's precisely why I hate react, it utterly sucks to work with. Theres a reason Im building my team around vue, juniors can understand how it works because its intuitive; setup is setup the template is what gets rendered, when a variable gets updated the proxy informs only the things that it affects, easy. Would never expect a junior to know how to build that from scratch though
you're quite privileged, I'm still held hostage by jQuery.
or am I the privileged one?
My next target in life is kill react in my company. And I am willing to sacrifice a lot for it. Stay tuned.
Man I don't use JavaScript and I'm happy about that. When I see articles like this, or videos like this it just makes me glad that I am not a front-end engineer at all. I don't really do web dev either that often, when I do it's mostly back end or server side stuff. Even when I have built UIs and stuff like that I usually use SSR via some native language not some nonsense like JavaScript. The funniest thing about react to me is the fact that they're effectively trying to recreate some of the powerful features of functional languages like elm or ocaml. Hell, react was originally written with Ocaml which is also why they released reasonML (I guess it's called rescript these days). The problem is that JavaScript just doesn't support the features that they're trying to build. You can talk all you want about having immutable data structures and reactive systems but you have a single threaded model that runs using event loops and even the non-mutable variables in JavaScript can get mutated behind the scenes.
Vue gang rise up
I think if your learning React as a newbie..... then your learning React and development I think you should come to it lastly. YOU DON'T NEED IT
Hooks are overrated. They might be easier to read, but they're not easier to understand.
Please use angular, thats it
Vue it is! And yes I worked professionally with Angular already, it sucks compared to Vue imho.
"You should take a moment to think about how things work" Completely agree but it's also telling us that the abstraction is therefore incomplete. And that's something most people refuse to realize.
React is like gender pronouns, heavily pushed by a vocal minority, adopted by woke corporations, secretly hated by most.
Also the problem with skill rots. I recently got laid off so I've had sometimes to look back at my career. React traps you, everybody uses it, it's like Java. You can't get out of it, learn something new, or become better.
I believe hooks was the place it started to fall apart.
It's very similar to Angulars life cycle hooks. Yet react had not previously done this and so it was a very early feature.
Hey, I know that guy
Try elm. You'll never look back
I never learned ReactJS, because I created my own framework back in 2017. Sadly I never released, only using in my own projects. Reason why I rejected to learn ReactJS is pretty simple. I goto Facebook and search something. Then I opened browser's task manager and scroll page down little bit. Then look back to the task manager, Facebook single web page using over 1GB ram. I was like WHAT??? I think that problem was still existed in previous year too, I don't what happens now. One thing for sure. There is a lot of garbage collection and memory related issues. That is why i said HELL NO to ReactJS!
Svelte anyone?
yes, please
Would a noob suffer learning React? Well, I wouldn't even know what's wrong with it as someone who's not good at any framework.
JQUUUUEEEEERRRRRYYYYYYY😛
in 5th grade i had to memoize all 50 states and their capitols, can react do that!?
I see a trend on hating React. Have you guys seen angular? Nothing against it it's just way harder. Solidjs? I'm actually excited to learn but to say React is bad? goh. Hooks ARE easier, it simplified sooo much. Just like Redux to Redux toolkit but somehow people are complaining more 🤷🏼♂️
I agree, people are hating on react the same way they complained about jQuery, but they forget that it has been around for ages, and as every bit of tech, does not age perfectly.
But there is a reason why Solid is SO alike to React, the patterns and structures React allows are proven and clearly preferred by a lot of people.
Hell even Angular shapeshifted to survive agains React
@@Fernando-ry5qt I'm just saying people always did reactive programming, along comes react everybody looses their mind and adopts.
Few years later, nah react doesn't work let's go back to reactivate instead of functional.
Also you could manage state reactively with mobx, subscribing to and having observers and all that jazz
The entire point of the article and the video went a mile over your heads. It wasn't about ergonomics at all
@@danielchettiar5670 That's the thing though, I'm not addressing the video specifically. Just another point somewhat related to the video.
those prefer class over hooks are not react developers, not sure are they even frontend ? probably some java 'fullstack' devs. just go use angular dude
Need an htmx video
Vue > React
"Take a moment and imagine how you would do something." See, here's the trouble. I do that. I do that all the time, in fact. My troubles come because I'm a new programmer, and I have a very bare-metal imagination about how things should be done. I don't understand what and why a class should be a thing, I don't understand how methods or functions get attached to classes, and I am therefore missing a large chunk of the toolset used by most programmers to do most things. So I'm over here trying to use a table saw as if it were built by hammers and hand saws, meanwhile the person making the damn thing is using exclusively electric screwdrivers and CNC machines to build it. I have sat there and stared at my screen for many an hour because of this fundamental mismatch.
When someone asks me 'Why do you have some concerns about React Hooks?' I always answer: Read those Rules of Hooks, and read them carefully. Try to understand them well. Then you will see the answer by yourself. No other discussion will be needed... Usually, no one wants to argue with me after that 😊
You can't just read the rules of swimming and learn to swim 😂. Better way is to practice it in right environment 😊.
@@ImranSheikh-kg4qd I think you didn't get my point
Explain simply, the problem with hooks.
Using React feels like coding in a weird version of BASIC where you have COMEFROM instruction instead of GOTO. 😅
I don’t know anything about basic, but this makes sense to me lol. I do well with react, but I have to think about everything backwards
@@matthewwoodard9810 How do you keep track of what depends on what you are editing?
@@emjizone I apologize, but I don’t understand the question
You won my like @ "Hooks is where things started to fall apart"! 👊
Oddly, I avoided React like a plague during the class component/high order component bullshit and hooks where to me the reason to get back, I find it a trillion times better DX and easier to maintain
Solid is great, plain I'll functions for everything. Svelte on the other hand sucks , full of random symbols and rules
post