I keep coming back to this talk and using it as a foundation to explain the framework for making architectural decisions.. So many tough coding/architectural decisions are simplified when you recast them using abstractness/power vs concreteness/utility model
Having experience with React and some other frameworks as well as vanilla JS, jquery etc. it feels good to step back from the code and look into the engineering aspect of things. This was an insightful talk and despite its age, it still holds up because it's just not about a specific framework or library or their version, it's essentially about the approach to programming. Thanks for sharing this talk, much appreciated.
Great talk! I love the comment regarding how "Not DRY is fine"...In my experience, DRY oftentimes creates tight couplings that slow down development pace.
Amazing talk. I understand the desire for abstractions and seem to run my life looking at how everything is abstracted, not just programming. I personally got destroyed when I was mismanaged thinking I would eventually be assigned the chance to change the abstractions of the projects I was working on. I had kept things too concise where you did not have to drill down through dozens of files to understand what was actually going on. I just felt I needed to comment on your mention of too much abstraction around @31:30
What a talk!! I always had the doubt why the child is 'sub-class' which has more properties (relatively superior). Your Answer makes sense. Thank you :)
19:00 Ah man. That's a great visual. Thank you. Not sure I completely understand what you mean by 'functional level' vs 'declarative DSL', but that's okay. Curious to know if Nix, which to my understanding uses a declarative configuration, would address some of issues of Grunt without being Gulp like. (Total novice btw)
Concerning DRY, I've learned to wait to consider abstracting something until I need 3 or more instances of it, because it is nice to be able to immediately see the structure of what is needed rather than trying to understand the abstraction. He basically said this so this comment doesn't really add much value, but anyway, my experience is the same.
What power does abstracting view elements to the function level give you? The one I can think of off the top of my head is dynamic reordering of unique elements, but is there another one?
I would say we're seeking more *manageable* ways of using our existing power rather than *principled* ways. Principles naturally arise from the effort to make bugs, performance, and change as manageable as possible, but there will *always* be edge cases where a given principle gets in the way of manageability. For example: the need to denormalize data in certain cases; __dangerouslySetInnerHtml; etc.
Excellent talk!. But just replace "abstraction" and "levels of abstraction" with "simplification" and "levels of simplification" and a wider audience will be able to understand. Engineers have been "simplifying" our interaction with the physical world with many "levels of simplification"; computer scientists have been "simplifying" our interaction with informational systems and ultimately with the physical world. Excellent, excellent!
After some time, I have re-watched this and I see a lot of inconsistencies. A basic one is the idea that abstractions contain less properties and apply to more situations (correct), but then saying that frameworks are more powerful and libraries more useful. Old Angular extended jQuery. Remember that? jQuery was more powerful, Angular more useful. jQuery was the superclass.
According to his definition, framework has higher level of abstraction than library. If you consider jQuery as library instead of framework, then the old Angular that extended jQuery should not be considered as framework.
Amazing talk and the great conference, not every audience would be able appreciate such talks, but this one definitely did.
I feel enlightened :)
I keep coming back to this talk and using it as a foundation to explain the framework for making architectural decisions.. So many tough coding/architectural decisions are simplified when you recast them using abstractness/power vs concreteness/utility model
Having experience with React and some other frameworks as well as vanilla JS, jquery etc. it feels good to step back from the code and look into the engineering aspect of things. This was an insightful talk and despite its age, it still holds up because it's just not about a specific framework or library or their version, it's essentially about the approach to programming.
Thanks for sharing this talk, much appreciated.
The best talk in a long time. It has been enlightening.
Great talk! I love the comment regarding how "Not DRY is fine"...In my experience, DRY oftentimes creates tight couplings that slow down development pace.
Totally agree, see
www.sandimetz.com/blog/2016/1/20/the-wrong-abstraction
udidahan.com/2009/06/07/the-fallacy-of-reuse/
great read! just shared the article with my team
Our next conference will be on May 18th-19th in Paris. Stay tuned for more news! www.react-europe.org
Amazing talk. I understand the desire for abstractions and seem to run my life looking at how everything is abstracted, not just programming. I personally got destroyed when I was mismanaged thinking I would eventually be assigned the chance to change the abstractions of the projects I was working on. I had kept things too concise where you did not have to drill down through dozens of files to understand what was actually going on. I just felt I needed to comment on your mention of too much abstraction around @31:30
hes such a good speaker. well done
Very nice talk!!! Really challenged my thinking about software engineering
Man.. this is really good. Thank you so much!
Wish there were more talks like this. This was awesome.
Solid talk, this guy is going to the moon
Amazing talk. Such an important lesson for developers to understand
What a talk!! I always had the doubt why the child is 'sub-class' which has more properties (relatively superior). Your Answer makes sense. Thank you :)
This was absolutely amazing. I'm a newer programmer, but this was...just enlightening.
Great talk, very powerful
19:00 Ah man. That's a great visual. Thank you.
Not sure I completely understand what you mean by 'functional level' vs 'declarative DSL', but that's okay. Curious to know if Nix, which to my understanding uses a declarative configuration, would address some of issues of Grunt without being Gulp like. (Total novice btw)
Concerning DRY, I've learned to wait to consider abstracting something until I need 3 or more instances of it, because it is nice to be able to immediately see the structure of what is needed rather than trying to understand the abstraction. He basically said this so this comment doesn't really add much value, but anyway, my experience is the same.
Simply brilliant
Best talk
33:55 "your abstraction is leaking"
Very enjoyable meta-dev talk:)
enlightening！ Thanks!
What power does abstracting view elements to the function level give you? The one I can think of off the top of my head is dynamic reordering of unique elements, but is there another one?
"indistringuishable"
The perfect unintended pun. And no one laughed.
I laughed out loud when I heard that, it was perfect! @13:00 for anyone searching
Same! Lowkey best line.
i was looking for this comment!
did he really just say that 13:00 🤣
wow this is an abstract talk. i haven't really understand the idea behind all the trees.
20:18 amazing talk !
I would say we're seeking more *manageable* ways of using our existing power rather than *principled* ways. Principles naturally arise from the effort to make bugs, performance, and change as manageable as possible, but there will *always* be edge cases where a given principle gets in the way of manageability. For example: the need to denormalize data in certain cases; __dangerouslySetInnerHtml; etc.
Mind Blown
Excellent talk!. But just replace "abstraction" and "levels of abstraction" with "simplification" and "levels of simplification" and a wider audience will be able to understand. Engineers have been "simplifying" our interaction with the physical world with many "levels of simplification"; computer scientists have been "simplifying" our interaction with informational systems and ultimately with the physical world. Excellent, excellent!
Well said. Notes for my talks as well
Grunt and Gulp...LOL 2016
Great talk, I can't imagine what excuse would someone have to downvote this video ;)
Ignacio Chavez 10 people use Angular.
厉害
After some time, I have re-watched this and I see a lot of inconsistencies. A basic one is the idea that abstractions contain less properties and apply to more situations (correct), but then saying that frameworks are more powerful and libraries more useful. Old Angular extended jQuery. Remember that? jQuery was more powerful, Angular more useful. jQuery was the superclass.
According to his definition, framework has higher level of abstraction than library. If you consider jQuery as library instead of framework, then the old Angular that extended jQuery should not be considered as framework.
@@xumike3929 yes, he has the wrong definition of abstraction when talking about library vs framework
"Undistringuishable" 😂