@@Gioeufshi The bane of "business talk and job culture", and the famous "hero everything" in web frontend... Hero section, Hero app, Hero Carrousel, Hero highlight, HERO ANYTHING WHATSOEVER. Annoying how a bunch of people take one word, and use it to imply only one small facet of what its meaning invoke, and overused it ad infinitum...
The doc is fine. It's four months now, I'm sure you must have gotten a hang on it by now. You can take Maximilan's free course on RUclips if you aren't good yet with it.
A talk that made it into the history books of app development. From React to SwiftUI to Flutter , the reactive frameworks have transformed the whole industry .
Almost 8 years later and this talk is just as relevant and informative about how React works and why we should be using it. Did anyone else shocking whisper "Holy shit" when you saw what React code looked like on 2013? :D
@@benzemamumba I was finding the code awful as well when I was looking at the small examples, but when looking at a real example, the JSX part in the render function pretty much looks like a template and everything else managing it is just pure JS. I wasn't sure about not using bi-directionnal binding since I am so much used to it, but that actually makes everything simpler to not have to care about how the frameworks does bi-directionnal binding (which leads to different limitations per framework). After trying the short tutorial, I was actually hooked
well... To be honest, I just learned React because the job asked it, because you get jobs really easy if you know React. Now, if you ask to my neerdy heart what is better? I have a long list of frameworks way better than React. For me, React is bad albeit popular.
17:40 - React components are just idempotent functions, that describe your UI at any point in time, just like a server-rendered app. **Again, because they're just functions that take some parameters, and output a description of the UI, they are very easy to unit test.**
yeah, they havent explained how fibers work but it feels like they are doing depth first memoization of the app component tree. The fibers are compared, not the object-in-object vdom model. From videos, they compare fibers to a virtual call stack but i prolly need to EFF around with it. I think there virtual dom is a vague word to describe what the component based frameworks are doing. Anything that uses nested component instances represented by is going to be a virtual dom by nature of these objects in objects representing the document object model.
Being a React developer coming from a Mechanical background the whole story of REACT give me goosebumps. I wished i was there in the infant stage of React back in 2013
I like how React API was designed. It's almost the same as it was 4 years ago! That can be a sign of carefully chosen abstractions that as good today as they were a while back.
After 10 years, this is still true. I completely agree. I love JSX. I don't know why people hate it. It could be the "Panini Effect" ( Representation of fans of who love you when you're small.), I used MVC type stuff with PHP and it was hell, just hell. And it is true, the controller becomes so fat.
sounds like a talk on unix philosophy .... modules vs monilith, bazaar vs cathedral, villages vs empire sounds like part of the "paradigm shift" towards an actually functional "one world" order conjunctio oppositorum .... mutual completion of opposites
I will always serve static html that works without any dependencies whenever possible. Because css and js can always fail to download. And I love that I can still do this with React!
@@carldrogo9492 I've come across several occurrences where files fail to load, hardly unrealistic. Going by your other comments, you just seem to hate programming in general.
I felt like this brings us back to the age of web form but who knows, having html in js and having a middle layer between js and dom gives react supreme advantage over angular. Overall, in terms of Template: Angular > React but in terms of speed, debugging, available UI options... : React > Angular
8 years late to the party, but I have to point out the fact that the entire premise of his argument arises from him putting presentation logic inside the controller? Putting a "tableRowColor" in the view model is such a glaring violation of separation of concern. Presentation is style. It concerns the style sheet and nothing else. If you absolutely have to put it somewhere else, it belongs in your template, but in the example uses it's inserted into the view model (i.e. by the controller/component logic) which seems like such a textbook example of violation of SoC to me.
At ruclips.net/video/x7cQ3mrcKaY/видео.html Instead of calling it composition, it should be called association. Because react can have components which can work/reused independently regardless of the parent type. Sometimes there can be aggregation as well as composition relationships between components. So should have been callled association
The debate of whether it's best to add JS to HTML or add HTML to JS is merely a preference. I'm not convinced after watching this that adding JS to HTML is any better. This video and React's documentation claim that doing so separates concerns. Per this video, separation of concerns occurs by reducing coupling and increasing cohesion. Creating small reusable components reduces coupling. How a developer chooses to organize code that make up layers of a component (presentation, data, etc) does not affect coupling. I could create a single file component or a folder with separate files for each layer. Grouping components into modules increases cohesion, but again, the organization of the various code layers within the components that make up the module doesn't really matter. Therefore, I'd argue that adding JS to HTML doesn't separate concerns. It has nothing do to with separating concerns.
You shouldn't mix languages. It's more difficult for the entire tool chain to work with multiple languages in a single document. You should only use dependencies. Also, I agree.
IMHO - There shouldnt be HTML and JS together in the first place. HTML was meant for mainly static stuff and to be amended a little by JS. These days we have superpower-ewwb-apps. If you ask me , there should be only JS + CSS.
Agree mostly, except for the point about it being a preference. The web is fundamentally about documents: information being served and retrieved. JS had essentially nothing to do with this (unless you're running it on the server). It seems like these days, most people get lost in the shininess of JS and the technology du jour and don't seem to understand the fundamental purpose of the web. That's how you get incredibly misguided comments like the one above mine, where this person is claiming that the web should not have HTML because it's redundant.
The row color example couldn't be a worse argument for coupled code. It can be a strong argument for RTFM. nth child has been handling this in 80%+ of browser marketshare for how many years? Styling logic doesn't belong in your templates, it's not 1999, those problems are solved. If you want to argue that this reduces HTTP calls that's fine, but when HTTP2 is up and running there wouldn't be as strong a need for this IMO. Less about the video at hand and more about the industry... As a developer who was working on the web at the turn of the century, I fear the future of using a framework instead of learning the underlying technology. Though web properties turn over every few years (or even months) these days, some don't and maintaining sites is "a thing". With each new framework turning the conventions of the technology on it's ear and then fading away when some new shiny framework comes around, this is just going to get harder...
This. Every bit of this. I've seen this "let me make a completely controversial statement that throws decades of best practices out the window because _we_ are different and think we have something better" schtick far too many times. A few years down the line, they go, "Oops..." I mean even Facebook's original motto was "Move fast and break things", and now that they've actually grown up, it's "Move fast with stable infra"
We are now almost 10 years later and frameworks are more relevant then ever. Those decades of best practices describe a www that just isn't anymore. Ur talking about the internet of the 90s and the 00s, lol.
Question: if React is so good, why is the Facebook page so appallingly slow and resource-intensive? It's one of the worst offenders out there. It's a showcase for how NOT to make a web page.
So, if I change a template I have to check where it's used. fair enough, but that's true for *everything* that is re-usable, incuding react components. I get the scary feeling that Hunt is just making shit up to make his new product look like a solution to a problem that doesn't exist, while not being a solution at all. I get the feeling that React is very much like PHP and MySQL where in the beginning: pretending very hard that the established practises where bad, only to later evolve into exactly those practises because... well they work best.
To be fair, this video is 4 years old and React has updated a bit since then. But yea, there's a lot of "We never had to do X so you shouldn't either" declarations in their docs. Never had to !== shouldn't. But that's how it gets interpreted by a lot of people. "Don't write spaghetti code" - easy to say, a lot more difficult to enforce on an enterprise level.
@vinny142 This is exactly what I was thinking when he said that. For example suppose in my React app I have created a custom button component and used it in 50 different components. So if I add a new property to the button component I will still need to track down all the locations where it's being used and set the new property where it's being used in other components. I am really new to React so please correct me if I am wrong.
Yep! That's why I get frustrated when he's like "You don't need any inheritance". If you have a button, and it only needs that new property some of the time. You might as well just extend the button into a new subclass which uses the same components but has that extra property. Ta-da. Problem solved. Oh, but in React that's bad. You need to rewrite your button for each use case.
Actually I kind of disagree with your first sentence. If I have a rating component inside a product review component, if I change the rating from using yellow stars to silver stars, why would I have to check its usages? How could that possibly affect the component which uses the rating? I can only speak from an Angular perspective, but in Angular components are supposed to be small building blocks, just like classes in OOP. You can then think of the possible usages of a component as its interface to other components. And as long as an interface doesn't change the implementation should be able to change as needed, that's a fundamental principle in OOP. In the same vein, as long as the rating component displays a rating in the way I want ratings to be displayed on the site, why should the components incorporating the rating component care about changes to its template? EDIT: What I'm saying is, it depends on what the respective component does.
@@andreasmuller6365 Precisely. And the exact same principle goes for templates, which also presents an API to those looking to use it. We just don't like to think of it that way because change-management is hard.
No matter what else you make of React, the best thing about it IMHO is React Router. Declarative routing is so much more intuitive than having to go to a separate router config like in Vue. It's almost worth using React for that alone.
You realize which one inspired the other, right? Also, as someone who worked with Vue well before touching React, JSX is only ugly in the hands of bad developers.
I came here from the React documentation, they say there "check this (terrible) video, it may convince you that embedding JSX into JS is a good thing". Damn it. This is the most terrible idea of all times. He says that this will reduce coupling. I really don't see it at all, it does nothing except putting html in JS. This why I like Vue.js better, in fact, this is the first thing that got me away from React, even though it's the hottest UI library these days, but I really hate this JSX thing. Until I find an alternative to this, it'll stay the worst thing in my opinion, even if I'd use it for some projects.
I agree. He mentions coupling and cohesion, but forgot developer cognitive load. We separate concerns, so that code makes sense. JSX can get downright mofugly and it takes extra extraneously built and controlled rules and constraints from developers using React to contain JSX from becoming a big ugly mess and that is where Vue shines. It offers these constraints built in and they are still fairly easy to learn. This has a twofold advantage. Vue is fairly easy to learn to use and more importantly, it means any Vue app will be built in practically the same way, every time. That means devs who have learned Vue can dig right into other applications and understand, fairly well, how the application is supposed to work. This "jump in and get wet and swim fast" kind of process isn't so simple with React built apps, because the "best practices" aren't built into the React framework. Nope, it just gives you JSX and let's dev go for a free-for-all. Vue also has this same issue (as does React), as soon as the app gets to any kind of larger size. There is no standard way to put together a larger app. One might say this is flexibility, but in the end, a "best way" will always be found. The new Vue-CLI is supposedly taking on this area of best practice for larger apps. For React, there are also solutions being developed, but external to the core, and again, this is where Vue shines. So, separation of concerns all comes down to ease of use, reduced cognitive load for the dev including a quick understanding of legacy/ already built code. IMHO, that is the win Vue offers and where JSX, without those external "best practices", loses.
Nice comment, though I disagree.. soc doesn't boils down only to reducing cognitive overload for developers. Soc is also about reuseability of the code and not breaking existing features being used by other customers.
If you have a click counter state and a counter template, the template will inevitably depend on the counter state. You cannot escape it. They are therefore *coupled* (cohesive). If you change the counter name from "numberOfClicks" to "count", you'll have to go update the view to access .count instead of .numberOfClicks On the other hand, if you have a click counter and a todo list, they are not coupled at all. They don't need to know anything about each other - ideally they wouldn't even be able to tell if the other one exists. If you add a checkbox of completion to the todo list, the click counter... doesn't care, at all. The view templates know almost everything about the state. If the structure of state changes, the view must also change to reflect the state change. Therefore the view should live close to the state, in a new abstraction that combines both called "component". This is very much in tune with more abstract software engineering principles, like "encapsulate what varies" softwareengineering.stackexchange.com/questions/337413/what-does-it-mean-when-one-says-encapsulate-what-varies - instead of the more specific and dubious "separate logic from markup" we got as an over-reaction to the PHP spaghetti mess. Where you can and really should separate things is between components. There are of course sometimes different situations. If your design changes a lot, but the data transformations don't, it might be a good idea to separate them. Even then the first thing to try are components: display components without logic that render things with the appropriate classes and styles (Button, NavBar, Panel etc) + logical components use them for the conceptual layout of the page. And if that is still not sufficient (e.g. you have two different views, web and mobile), *thats* when you separate out parts of the model.
I don't think he makes the case for JSX either. The disagreement is over how cohesive markup and JavaScript are. I think it's telling that at about 6:08, he says markup and JavaScript do the same thing... and then he says *two* things: rendering data and handling events...
@Spiun666 So, having a dependency isn't the same thing as being cohesive. To take your example of counter state, maybe the server is keeping a count of every user to visit the site. Maybe that's stored in a relational database. Following your logic, because there's a dependency, your markup is therefore cohesive with your database schema. This isn't what cohesion means. What you will have is interfaces between different components (in the general software sense of the word "component"). In your example, the variable name ("numberOfClicks" or "count") is the interface between a template and the JavaScript. (In my example, there would be some API layer, probably with an HTTP interface. It would, in turn, consider the database schema an interface. But, none of that implies cohesion.) You are definitely coupled to the interface at each layer, but you're decoupled from the actual implementation. State can be stored and handled multiple ways in different servers communicating over different protocols, all without needing to change the template.
I was told in React docs that this could convince me. I am not convinced. Aside from about 1/3 of presentation being a marketing campaign (bleh), the fact that you need JSX crutch just to make code human-readable again should trigger some alerts. It's a mixed bag of good ideas and bad ideas thrown together. There are a few things to carry from this (like thinking in components). But while I kinda understand and can support the idea of uniting logic and markup, how React does it is simply disgusting.
there's a reason why React got popular. You cannot say that is disgusting when earlier webdevs use PHP, to templating, to jquery. Making a reactive app back then is just the worst when you grapple changing state. Their implementation works and gets shit done as fast as possible compared to others
@@tstcikhthys How exactly does the web fundamentally work, oh enlightened one? Templates and controllers were there when the fundamentals of the web were established?
![[JSConfUS 2013] Tom Occhino and Jordan Walke: JS Apps at Facebook](http://i.ytimg.com/vi/GW0rj4sNH2w/mqdefault.jpg)
![[JSConfUS 2013] Tom Occhino and Jordan Walke: JS Apps at Facebook](/img/tr.png)
![Felix "Unfair" | [Stray Kids : SKZ-PLAYER]](http://i.ytimg.com/vi/Oswujxm2Ag0/mqdefault.jpg)
I'm here to see if this talk might convince me otherwise.
Lmao. Me too
@David Smitherman heroes? Seriously? Learning react is now a heroic act?
@@Gioeufshi Lmao my thoughts exactly
did it?
@@Gioeufshi The bane of "business talk and job culture", and the famous "hero everything" in web frontend...
Hero section, Hero app, Hero Carrousel, Hero highlight, HERO ANYTHING WHATSOEVER.
Annoying how a bunch of people take one word, and use it to imply only one small facet of what its meaning invoke, and overused it ad infinitum...
On the React Docs, they told me : " this talk might convince you otherwise." so Im here.......loooooool
same
Same. I'm fairly new to React and following it's official documentation. Can you suggest me any good resources you are following?
Me too :D
The doc is fine. It's four months now, I'm sure you must have gotten a hang on it by now. You can take Maximilan's free course on RUclips if you aren't good yet with it.
Same here :D
10 years later and I still got a lot of new insights from here 🤯
A talk that made it into the history books of app development. From React to SwiftUI to Flutter , the reactive frameworks have transformed the whole industry .
Almost 8 years later and this talk is just as relevant and informative about how React works and why we should be using it.
Did anyone else shocking whisper "Holy shit" when you saw what React code looked like on 2013? :D
I still don't buy into the grotesque looking code of React, that's why Angular and Vue will forever be my go to technologies.
@@benzemamumba I was finding the code awful as well when I was looking at the small examples, but when looking at a real example, the JSX part in the render function pretty much looks like a template and everything else managing it is just pure JS. I wasn't sure about not using bi-directionnal binding since I am so much used to it, but that actually makes everything simpler to not have to care about how the frameworks does bi-directionnal binding (which leads to different limitations per framework). After trying the short tutorial, I was actually hooked
8 Years later and you still should avoid all of these bloated and pointless frameworks that are bigger than entire well structured apps.
well... To be honest, I just learned React because the job asked it, because you get jobs really easy if you know React. Now, if you ask to my neerdy heart what is better? I have a long list of frameworks way better than React. For me, React is bad albeit popular.
who came from the react documentary ?
What's the point of this comment and why does it matter?
What react documentary?
I came from GitHub by awesome-react
I did
This is amazing to watch at this point in time!
"Re-render don't mutate," my biggest takeaway.
Really interesting. I felt same emotion & motivation when I watched Clojure presentation from Rich Hickey. Thanks.
17:40 - React components are just idempotent functions, that describe your UI at any point in time, just like a server-rendered app. **Again, because they're just functions that take some parameters, and output a description of the UI, they are very easy to unit test.**
great talk. As a backend engineer, I wish people showed me this when I tried to understand the design patterns for Frontend.
Best part of the talk, as a novice programmer, is diving into virtual DOM as 19:30
yeah, they havent explained how fibers work but it feels like they are doing depth first memoization of the app component tree.
The fibers are compared, not the object-in-object vdom model.
From videos, they compare fibers to a virtual call stack but i prolly need to EFF around with it.
I think there virtual dom is a vague word to describe what the component based frameworks are doing.
Anything that uses nested component instances represented by is going to be a virtual dom by nature of these objects in objects representing the document object model.
Being a React developer coming from a Mechanical background the whole story of REACT give me goosebumps. I wished i was there in the infant stage of React back in 2013
I'm not convinced otherwise. Handlebars is just so clean.
Who else is here from Reactjs docs. Lol. I'm here to be convinced!
x2
I like how React API was designed. It's almost the same as it was 4 years ago! That can be a sign of carefully chosen abstractions that as good today as they were a while back.
4 years later it is same
@@sfafsashfdh6589 Functional components and hooks have changed things greatly though.
The talk that kickstarted a new way of JS & GUI dev
Watching this in 2018, came from the documentation and loving React !!
This is a seminal discussion about the beauty and utility of a virtual dom. It loosened up hard notions about what separation of concerns means.
After 10 years, this is still true. I completely agree. I love JSX. I don't know why people hate it. It could be the "Panini Effect" ( Representation of fans of who love you when you're small.), I used MVC type stuff with PHP and it was hell, just hell. And it is true, the controller becomes so fat.
I'm here from react docs...what a valuable video
Pete hunt left no stone unturned to market React, but no doubt React is awesome. Thank you team facebook!!
" this talk might convince you otherwise."
So JSX looks like html but it actually is function. Thank you. I have less anxiety using it.
nah, its an expression
sounds like a talk on unix philosophy ....
modules vs monilith, bazaar vs cathedral, villages vs empire
sounds like part of the "paradigm shift" towards an actually functional "one world" order
conjunctio oppositorum .... mutual completion of opposites
I spent this whole video thinking "Dude! Drink some water!"
wow, at the end realised this is from 2013 !? wtf. great talk
Thank you, Pete and React team!
someone give him a glass of water!
LoL I was thinking the same thing after watching for like 7 mins. Glad this is like the second comment in the stack.
Watching this video made me drink lots of water.
A defibrillator would have been important as well.
My thoughts exactly. Do not start a speech while being dehydrated! :-)
Great content but its so painful to watch!
I will always serve static html that works without any dependencies whenever possible. Because css and js can always fail to download. And I love that I can still do this with React!
@@carldrogo9492 I've come across several occurrences where files fail to load, hardly unrealistic. Going by your other comments, you just seem to hate programming in general.
That was a great talk Pete. I'm very exited about Reactjs. :)
This should convince me to ditch my classical understanding of html and js being sparate... hmm I guess I should give it a try
I felt like this brings us back to the age of web form but who knows, having html in js and having a middle layer between js and dom gives react supreme advantage over angular.
Overall, in terms of Template: Angular > React
but in terms of speed, debugging, available UI options... : React > Angular
Two years later: "in terms of speed, debugging, available UI options" Angular > React
@@munaq-jp lol wrong.
React is in NO way, shape, or form better than Angular!
This should be mandatory for every JavaScript developer in a bootcamp who is now learning about react
Just re-visited this video ~4 years later for the nostalgia. Still loving React, still using it every day, still re-thinking best practices!
8 years late to the party, but I have to point out the fact that the entire premise of his argument arises from him putting presentation logic inside the controller? Putting a "tableRowColor" in the view model is such a glaring violation of separation of concern. Presentation is style. It concerns the style sheet and nothing else. If you absolutely have to put it somewhere else, it belongs in your template, but in the example uses it's inserted into the view model (i.e. by the controller/component logic) which seems like such a textbook example of violation of SoC to me.
At ruclips.net/video/x7cQ3mrcKaY/видео.html
Instead of calling it composition, it should be called association. Because react can have components which can work/reused independently regardless of the parent type.
Sometimes there can be aggregation as well as composition relationships between components. So should have been callled association
Can someone recommend a talk or book that just speaks about the theoretical concepts, principles of React. Like this video.
The intro soundtrack ... I did react :-p
Love React...ur right frameworks shouldn't force us to code in a certain way...
The debate of whether it's best to add JS to HTML or add HTML to JS is merely a preference. I'm not convinced after watching this that adding JS to HTML is any better.
This video and React's documentation claim that doing so separates concerns.
Per this video, separation of concerns occurs by reducing coupling and increasing cohesion. Creating small reusable components reduces coupling. How a developer chooses to organize code that make up layers of a component (presentation, data, etc) does not affect coupling. I could create a single file component or a folder with separate files for each layer.
Grouping components into modules increases cohesion, but again, the organization of the various code layers within the components that make up the module doesn't really matter.
Therefore, I'd argue that adding JS to HTML doesn't separate concerns. It has nothing do to with separating concerns.
You shouldn't mix languages. It's more difficult for the entire tool chain to work with multiple languages in a single document. You should only use dependencies.
Also, I agree.
IMHO - There shouldnt be HTML and JS together in the first place. HTML was meant for mainly static stuff and to be amended a little by JS. These days we have superpower-ewwb-apps. If you ask me , there should be only JS + CSS.
Agree mostly, except for the point about it being a preference. The web is fundamentally about documents: information being served and retrieved. JS had essentially nothing to do with this (unless you're running it on the server). It seems like these days, most people get lost in the shininess of JS and the technology du jour and don't seem to understand the fundamental purpose of the web. That's how you get incredibly misguided comments like the one above mine, where this person is claiming that the web should not have HTML because it's redundant.
From React Docs?))
I am thinking to LEARN React
I wish I knew what the @cowboy tweet said. The account is suspended. Anyone know the contents of this fabled tweet?
amazing to watch this in 2017 when react is now the framework to beat!
I'm also here to be convinced otherwise!
Here to just check why it all started
What did the @cowboy twitter say? Does anyone know?
Those generated sub-titles are kind of useless. At exactly 12:00 they get downright obscene.
Andre Roodt Just switched the flag, so you can fix them!
The 2014 videos have sub titles from live captions created during the original talk.
this talk did NOT quite convinced me otherwise...
The video and content is marvellous. But gosh, Pete is struggling, I need a glass of water for myself after that.
These pretzels are making me thirsty
Does react still work the same way? rerender, don't mutate
Why people are not REACTing to presenter.
The row color example couldn't be a worse argument for coupled code. It can be a strong argument for RTFM. nth child has been handling this in 80%+ of browser marketshare for how many years? Styling logic doesn't belong in your templates, it's not 1999, those problems are solved. If you want to argue that this reduces HTTP calls that's fine, but when HTTP2 is up and running there wouldn't be as strong a need for this IMO.
Less about the video at hand and more about the industry... As a developer who was working on the web at the turn of the century, I fear the future of using a framework instead of learning the underlying technology. Though web properties turn over every few years (or even months) these days, some don't and maintaining sites is "a thing". With each new framework turning the conventions of the technology on it's ear and then fading away when some new shiny framework comes around, this is just going to get harder...
This. Every bit of this. I've seen this "let me make a completely controversial statement that throws decades of best practices out the window because _we_ are different and think we have something better" schtick far too many times. A few years down the line, they go, "Oops..." I mean even Facebook's original motto was "Move fast and break things", and now that they've actually grown up, it's "Move fast with stable infra"
We are now almost 10 years later and frameworks are more relevant then ever. Those decades of best practices describe a www that just isn't anymore. Ur talking about the internet of the 90s and the 00s, lol.
Crazy to see how it started. No JSX. The ‘var’ keyword
they do use jsx later in this talk though
Amazing talk, wow
idempotent
Mathematics
1.
denoting an element of a set which is unchanged in value when multiplied or otherwise operated on by itself.
Curious to see how React handles updating of millions of rows.
better than Angular?
you also shouldn't be displaying millions of rows at once ;)
Is there some reason you want to show millions of rows on a Web page?
I don't think this convinced me as stated. I still support separating the presentation logic from data and its manipulation.
Me too. i cringe whenever using React or anything else that has to deal with a hundred dependencies.
It's a very mediocre and grotesque Framework that every shitdev pretends to love.
"Just don't write spaghetti code"... One could say the same about PHP
Thank you!
One could say the same about every programming language.
ASP.NET code behinds are lasagna code 😬
anybody from Honeypot documentary? :)
Question: if React is so good, why is the Facebook page so appallingly slow and resource-intensive?
It's one of the worst offenders out there. It's a showcase for how NOT to make a web page.
Suggest to subtitle video，thanks
I have been convinced
Good video, I’m surprised there are only 30~ comments on it though
I hope this talk might convince me otherwise.
Give him some water Jesus
Here to convince myself ;)
is it outdated?
Phantomjs, phonegap lol. It says something at least that React has survived while these other technologies haven't.
lmao rip indeed
You king of convinced me
Nobody can refuse tasty food ... 7:30
So, if I change a template I have to check where it's used. fair enough, but that's true for *everything* that is re-usable, incuding react components.
I get the scary feeling that Hunt is just making shit up to make his new product look like a solution to a problem that doesn't exist, while not being a solution at all.
I get the feeling that React is very much like PHP and MySQL where in the beginning: pretending very hard that the established practises where bad, only to later evolve into exactly those practises because... well they work best.
To be fair, this video is 4 years old and React has updated a bit since then. But yea, there's a lot of "We never had to do X so you shouldn't either" declarations in their docs. Never had to !== shouldn't. But that's how it gets interpreted by a lot of people.
"Don't write spaghetti code" - easy to say, a lot more difficult to enforce on an enterprise level.
@vinny142 This is exactly what I was thinking when he said that. For example suppose in my React app I have created a custom button component and used it in 50 different components. So if I add a new property to the button component I will still need to track down all the locations where it's being used and set the new property where it's being used in other components. I am really new to React so please correct me if I am wrong.
Yep! That's why I get frustrated when he's like "You don't need any inheritance". If you have a button, and it only needs that new property some of the time. You might as well just extend the button into a new subclass which uses the same components but has that extra property. Ta-da. Problem solved. Oh, but in React that's bad. You need to rewrite your button for each use case.
Actually I kind of disagree with your first sentence. If I have a rating component inside a product review component, if I change the rating from using yellow stars to silver stars, why would I have to check its usages? How could that possibly affect the component which uses the rating? I can only speak from an Angular perspective, but in Angular components are supposed to be small building blocks, just like classes in OOP. You can then think of the possible usages of a component as its interface to other components. And as long as an interface doesn't change the implementation should be able to change as needed, that's a fundamental principle in OOP. In the same vein, as long as the rating component displays a rating in the way I want ratings to be displayed on the site, why should the components incorporating the rating component care about changes to its template?
EDIT: What I'm saying is, it depends on what the respective component does.
@@andreasmuller6365 Precisely. And the exact same principle goes for templates, which also presents an API to those looking to use it. We just don't like to think of it that way because change-management is hard.
No matter what else you make of React, the best thing about it IMHO is React Router. Declarative routing is so much more intuitive than having to go to a separate router config like in Vue. It's almost worth using React for that alone.
Weird, I find routing to be a tiny part of the app and it being declarative doesn't buy me anything at all.
Pete hunt is the senior team lead I wish I had so I can be one to my team
I'm not convinced otherwise
Watching this in 2021 feels exactly like Steve Jobs presenting the first iPhone
Or every next iPhone.
There are useful bits but you still feel like you've been fed a pile of shit.
This has convinced me otherwise
All I hear is is "we do the same what vue.js does now, except our syntax is ugly as hell"
You realize which one inspired the other, right? Also, as someone who worked with Vue well before touching React, JSX is only ugly in the hands of bad developers.
Not convincing. Especially when you know Vue.js where there is no "View-Model" so no coupling of modules leading to cascading changes
I came here from the React documentation, they say there "check this (terrible) video, it may convince you that embedding JSX into JS is a good thing".
Damn it. This is the most terrible idea of all times. He says that this will reduce coupling. I really don't see it at all, it does nothing except putting html in JS.
This why I like Vue.js better, in fact, this is the first thing that got me away from React, even though it's the hottest UI library these days, but I really hate this JSX thing.
Until I find an alternative to this, it'll stay the worst thing in my opinion, even if I'd use it for some projects.
I agree. He mentions coupling and cohesion, but forgot developer cognitive load. We separate concerns, so that code makes sense. JSX can get downright mofugly and it takes extra extraneously built and controlled rules and constraints from developers using React to contain JSX from becoming a big ugly mess and that is where Vue shines. It offers these constraints built in and they are still fairly easy to learn. This has a twofold advantage. Vue is fairly easy to learn to use and more importantly, it means any Vue app will be built in practically the same way, every time. That means devs who have learned Vue can dig right into other applications and understand, fairly well, how the application is supposed to work. This "jump in and get wet and swim fast" kind of process isn't so simple with React built apps, because the "best practices" aren't built into the React framework. Nope, it just gives you JSX and let's dev go for a free-for-all.
Vue also has this same issue (as does React), as soon as the app gets to any kind of larger size. There is no standard way to put together a larger app. One might say this is flexibility, but in the end, a "best way" will always be found. The new Vue-CLI is supposedly taking on this area of best practice for larger apps. For React, there are also solutions being developed, but external to the core, and again, this is where Vue shines.
So, separation of concerns all comes down to ease of use, reduced cognitive load for the dev including a quick understanding of legacy/ already built code. IMHO, that is the win Vue offers and where JSX, without those external "best practices", loses.
Nice comment, though I disagree.. soc doesn't boils down only to reducing cognitive overload for developers.
Soc is also about reuseability of the code and not breaking existing features being used by other customers.
If you have a click counter state and a counter template, the template will inevitably depend on the counter state. You cannot escape it. They are therefore *coupled* (cohesive). If you change the counter name from "numberOfClicks" to "count", you'll have to go update the view to access .count instead of .numberOfClicks
On the other hand, if you have a click counter and a todo list, they are not coupled at all. They don't need to know anything about each other - ideally they wouldn't even be able to tell if the other one exists. If you add a checkbox of completion to the todo list, the click counter... doesn't care, at all.
The view templates know almost everything about the state. If the structure of state changes, the view must also change to reflect the state change. Therefore the view should live close to the state, in a new abstraction that combines both called "component". This is very much in tune with more abstract software engineering principles, like "encapsulate what varies" softwareengineering.stackexchange.com/questions/337413/what-does-it-mean-when-one-says-encapsulate-what-varies - instead of the more specific and dubious "separate logic from markup" we got as an over-reaction to the PHP spaghetti mess.
Where you can and really should separate things is between components.
There are of course sometimes different situations. If your design changes a lot, but the data transformations don't, it might be a good idea to separate them. Even then the first thing to try are components: display components without logic that render things with the appropriate classes and styles (Button, NavBar, Panel etc) + logical components use them for the conceptual layout of the page. And if that is still not sufficient (e.g. you have two different views, web and mobile), *thats* when you separate out parts of the model.
I don't think he makes the case for JSX either. The disagreement is over how cohesive markup and JavaScript are. I think it's telling that at about 6:08, he says markup and JavaScript do the same thing... and then he says *two* things: rendering data and handling events...
@Spiun666 So, having a dependency isn't the same thing as being cohesive. To take your example of counter state, maybe the server is keeping a count of every user to visit the site. Maybe that's stored in a relational database. Following your logic, because there's a dependency, your markup is therefore cohesive with your database schema. This isn't what cohesion means. What you will have is interfaces between different components (in the general software sense of the word "component"). In your example, the variable name ("numberOfClicks" or "count") is the interface between a template and the JavaScript. (In my example, there would be some API layer, probably with an HTTP interface. It would, in turn, consider the database schema an interface. But, none of that implies cohesion.) You are definitely coupled to the interface at each layer, but you're decoupled from the actual implementation. State can be stored and handled multiple ways in different servers communicating over different protocols, all without needing to change the template.
Oh yes, it convinced me
I was told in React docs that this could convince me.
I am not convinced.
Aside from about 1/3 of presentation being a marketing campaign (bleh), the fact that you need JSX crutch just to make code human-readable again should trigger some alerts. It's a mixed bag of good ideas and bad ideas thrown together.
There are a few things to carry from this (like thinking in components). But while I kinda understand and can support the idea of uniting logic and markup, how React does it is simply disgusting.
there's a reason why React got popular. You cannot say that is disgusting when earlier webdevs use PHP, to templating, to jquery. Making a reactive app back then is just the worst when you grapple changing state. Their implementation works and gets shit done as fast as possible compared to others
We want those glowing apple logos back
1:05. Give it 5 minutes - agreed. Be Shoshin (初心). Give it a chance.
Jonathan Conway Are you Chinese ?
Thanks a lot man!
React is amazing
Is that still valid? Pete talked it 7 years ago
Not convinced... Why to keep it simple when you could do it complex... Native web components is a better alternative.
same, funny they show a 7 years old video
Thank you.
For god sake someone give him some water
"child"... "partial" 7:20 ... react lapsus. Love it!
Ahhhhhhhhhhhh. I'm convinced :)
Has anyone been convinced otherwise as of yet?
Not anyone who knows how the web fundamentally works and knows how to program properly, no.
@@tstcikhthys How exactly does the web fundamentally work, oh enlightened one? Templates and controllers were there when the fundamentals of the web were established?
@@baldcoder_ Yes, in a sense; separation of concerns essentially always existed. Templates are HTML; controllers are JavaScript, and styles are CSS.
Well, I'm not convinced
So, React is basically VBScript for modern era. Fair enough.
Taking DOM into JS is bad! You need to take into account CSS & design.
since you made this 2yrs back, you should have know better now
best video !!!