Monica’s presentation skills are some of the best I’ve ever seen in the tech field. This was a near flawless execution. I loved the content as well, very important and informative stuff she was talking about. I definitely took notes!
"Forbidden dependency test": the concept I've been dreaming about for years, but that I did not know where to look for information!!! Thanks, great talk.
Really like the part about internal dependency management, lot of people in the FE space don't think about this. I found that following a kind of modified version of domain driven architecture works very well for me. I also followed some "what can import from where" type of rules in the past, bu I wasn't aware of a tool that can actually enforce those rules in a JS project, very good to know that there is such a thing, will definitely use it next time.
I like the structure of the talk and content, but I'm not a fan of the passive-agressive and bit sarcastic tone from the speaker. Small note, I did enjoy it and will recommend it
I remember when XP first introduced DRY to the world. One reuse meant copy/paste, two reuses meant copy/paste but seriously think about making a shared component. A shared component isn't a given until you have the third reuse opportunity. Somehow over the years, it changed to making the shared component on the first reuse instead of waiting for the second or third one.
For like 10+ years I had the strong belief that "copy and pasting code means you're probably doing something wrong"... but yeah over time, I've come to the same realisation that sometimes it's just more sensible than creating abstracted dependencies. A lot of the abstractions I wrote in the past never even got used a 2nd time anyway.
Argh.. I wish there was a "here's what you should watch/view/read next" to go along with this. This is EXACTLY the kind of thing I need to know right now. So thank you for a wonderful talk Ms. Lent. Just wish I could find *more* :D
Great presentation, Address a lot of issues between Decoupling > Dry, Explains when to choose what. Clearly explains that there is no silver bullet when it comes to "best practices". EOD "it depends" is the final answer.
I agree to a greater extent to what you said. My manager always insists on keeping things decoupled to such a level that the change over time does not impact other business areas.
It is quite opposite to how my company works xD it's all a coupled mess and terrible APIs. Ui code literally has Java class names in the if blocks of javascript. Quitting soon
Sounds like an old monolith you have been working on, but hey, software development is a complex world, no matter how much you want to steer away from this kinda stuff, you end up working on it, one time or the other :)
Twenty years ago, I wrote my Perl object oriented and my Javascript with prototypes. Confused the crap out of everyone else. People still try hard to avoid the prototyping aspects of Javascript.
Great talk. In our React code base we use madge for circular dependency checks. It is very helpful and helped us avoid regression issues in our large codebase.
This was a good reminder ! Thank you Monica Lent. A lot of frontend developper are like "this does the same thing so i made a component folder that shares the component. I just put a condition if its in this or in this page". Backend are like "Dude, you are just telling me there a not doing the same thing" haha . And i still dont understand why in Mobile App you use Observables and stuff. Doing module app and you dont do the same in frontend. I have some doubt of the benifit of Redux on webapp for the frontend community developpers. Cheers guys
Constraining the dependency import architecture rings true to me. I made an eslint plugin for whitelisting and blacklisting dependencies for folders in the app for the company I am working for. It really is helpful.
I think there are some great thoughts here from a pure code standpoint, but all the decision flow was discussed as one way. Like new business requirements fracturing a generic shared component. But I also like to look at things like that in a reverse flow of thought. Sometimes a designer has created a piece of UI that is complicating the code of a shared component and rather than saying "then we should split this code" you should consider if it's a smell that the designer is breaking pattern of the design system. Why should a one-off coded component be created to meet a one-off design need rather than the design using the already provided component? Sometimes it's necessary, but I think using the introduction of complexity to an architecture can be a good canary for why it's happening rather than just blind implementation.
![Tee Grizzley - Blow for Blow (feat. J. Cole) [Official Video]](http://i.ytimg.com/vi/wNLN5xsx5dc/mqdefault.jpg)
"Technical debt on a subscription model" hits far too close to home
GOTO should make a GOBACKTO playlist with brillant talks that remain valid in time
Monica’s presentation skills are some of the best I’ve ever seen in the tech field. This was a near flawless execution. I loved the content as well, very important and informative stuff she was talking about. I definitely took notes!
"Forbidden dependency test": the concept I've been dreaming about for years, but that I did not know where to look for information!!! Thanks, great talk.
Do look for architectural fitness functions. That is yet another name !
"Senior engineer or whatever it is we call 19 year olds these days"
Killer joke 😂😂
Now you have my attention !!!
Brilliant talk Monica! and great delivery! transcends front-end. Addresses software engineering in general.
Her presentation skills are awesome.
Really like the part about internal dependency management, lot of people in the FE space don't think about this. I found that following a kind of modified version of domain driven architecture works very well for me. I also followed some "what can import from where" type of rules in the past, bu I wasn't aware of a tool that can actually enforce those rules in a JS project, very good to know that there is such a thing, will definitely use it next time.
I like the structure of the talk and content, but I'm not a fan of the passive-agressive and bit sarcastic tone from the speaker. Small note, I did enjoy it and will recommend it
Tremendous talk! All the principles presented are applicable not just to FE development, but to software development in general.
The component having an existential crisis cracked me up 😂 "Where am I??"
I generally don't like these kind of talks, but this was a very good one
This is the fastest 30-minute video I have ever seen! Felt like ten minutes. Tops!
Big plus for copy & paste code if needed. Bad abstraction is worse than no abstraction.
Oh wow, she is a good speaker. Love the talk!
Amazing talk! I wish I was there to give her an stand ovation 👏🏼
I remember when XP first introduced DRY to the world. One reuse meant copy/paste, two reuses meant copy/paste but seriously think about making a shared component. A shared component isn't a given until you have the third reuse opportunity. Somehow over the years, it changed to making the shared component on the first reuse instead of waiting for the second or third one.
DRY long predates XP. But the "third use" principle is a good one to balance things out.
"Migration is the name of the game. If you are not migrating in FE you're left behind." - l love that.
For like 10+ years I had the strong belief that "copy and pasting code means you're probably doing something wrong"... but yeah over time, I've come to the same realisation that sometimes it's just more sensible than creating abstracted dependencies. A lot of the abstractions I wrote in the past never even got used a 2nd time anyway.
I think she does herself a disservice with the "Frontend" label. Everything she's said applies to system wide architecture. Great talk!
Exactly! I'm not into frontend development but I'm glad I have "misclicked" on this. Great presentation.
Why rewrite the code? Sometimes, it is because "YOU THINK" you have a "BETTER" solution
Argh.. I wish there was a "here's what you should watch/view/read next" to go along with this. This is EXACTLY the kind of thing I need to know right now. So thank you for a wonderful talk Ms. Lent. Just wish I could find *more* :D
Over-engineering is huge problem in Software Development community. Great presentation and very good way to highlight those problems
Just before I watched this talk, I was just thinking about the folder structure of my project. Thanks for this.
god damn, this was awesome
damn she is cool, I wish I had a co-worker like her
this an amazing talk ❤️
Very accurate and real observations. A very interesting talk. Thanks a lot. 🙋
This was great really
29:06 constraints for more resilient architecture
- dependence inward
- code reuse might not help
- enforce boudaries
I agreeeeeee... As Sandi Metz use to say: Duplication is cheaper than the wrong abstraction.
OOP/Functional constraints/benefits isn't always mutually exclusive
Loved this talk! However, I don't feel that monorepos are very out of reach anymore. Yarn workspaces makes things like this so easy!
now we're using Nx, and it works like a charm
Great presentation, Address a lot of issues between Decoupling > Dry, Explains when to choose what. Clearly explains that there is no silver bullet when it comes to "best practices". EOD "it depends" is the final answer.
amazing lecture, kudos Monica!
Ironically, the way I found this video is by searching up "react architecture"
This whole talk feels like a personal attack 😂
Boundary enforcement is really interesting. I never thought of it. Might try it on my next project
She is spot on about everything she mentions.
I come here for the topic. I'm a simple developer. Everything she said is absolutely right :v
"big ball of mud" also known by italiano as "big ball of spaghetti" code
I love this talk. Everything makes sense as an FE dev
Very helpful, not just for front-end development. Thank you!
A great presentation Monica, I really like the way you deliver the info and the way you present. Hope to see great talks for you again 😘
Great
Fantastic talk! Thank you!
Really amazing talk , monica you know really how to speak really nicely thanks I learned alot
Just because someone speaks so beautifuly, I does make sense all the time.
such a great presentation! love it
Nx has a very neat way of restricting dependency rules
I agree to a greater extent to what you said. My manager always insists on keeping things decoupled to such a level that the change over time does not impact other business areas.
It is quite opposite to how my company works xD it's all a coupled mess and terrible APIs. Ui code literally has Java class names in the if blocks of javascript. Quitting soon
Sounds like an old monolith you have been working on, but hey, software development is a complex world, no matter how much you want to steer away from this kinda stuff, you end up working on it, one time or the other :)
Twenty years ago, I wrote my Perl object oriented and my Javascript with prototypes. Confused the crap out of everyone else. People still try hard to avoid the prototyping aspects of Javascript.
Shared components are not just about DRY, but also consistency and synchronization in updates. I think this is more important.
Great talk. In our React code base we use madge for circular dependency checks. It is very helpful and helped us avoid regression issues in our large codebase.
Never heard of Madge. thank you for the tip.
This pragmatic approach is really touching to me.
Best talk I've heard in a while!
Thank you Monica very interesting Talk
Great talk! Wish I could hit like 10 times.
This was a good reminder ! Thank you Monica Lent.
A lot of frontend developper are like "this does the same thing so i made a component folder that shares the component. I just put a condition if its in this or in this page".
Backend are like "Dude, you are just telling me there a not doing the same thing" haha .
And i still dont understand why in Mobile App you use Observables and stuff. Doing module app and you dont do the same in frontend. I have some doubt of the benifit of Redux on webapp for the frontend community developpers.
Cheers guys
Great talk! Thanks for the tips.
Great talk! Thanks for the video!
I seriously loved it :) thanks
This is infotainment. Monica is brilliant!
Fantastic talk. Still holds up to this day.
It's really good topic, great thanks for it!
Constraining the dependency import architecture rings true to me. I made an eslint plugin for whitelisting and blacklisting dependencies for folders in the app for the company I am working for. It really is helpful.
What a brilliant lady!
excellent talk. decoupled > dry is wonderfully succinct.
nice talk
A+ content and A++ delivery
Less substance..more emotion.
This actually very similar to what dan abramov was talking about in his wet codebase talk
She is brilliant wow
Really awesome explanation
Great presentation!
Thanks for a great talk!
Great talk👍🏻
Great talk!🎊
Great talk! 🙂
Great talk, thank y0u.
great talk,thanks
She knows her stuff... can't believe she's that young.
existential crisis for a component behaving like a dangling pointer is so true
Amazing talk.
good talk
this was brilliant!
Truth has been spoken :D
I liked it!
Great talk!
can someone tell GOTO channel about the timecodes?
goddamn good
Great talk! :)
22:46
Angular gives us good architecture right out of the box...
That's the comment i was looking for.
I think there are some great thoughts here from a pure code standpoint, but all the decision flow was discussed as one way. Like new business requirements fracturing a generic shared component. But I also like to look at things like that in a reverse flow of thought.
Sometimes a designer has created a piece of UI that is complicating the code of a shared component and rather than saying "then we should split this code" you should consider if it's a smell that the designer is breaking pattern of the design system. Why should a one-off coded component be created to meet a one-off design need rather than the design using the already provided component? Sometimes it's necessary, but I think using the introduction of complexity to an architecture can be a good canary for why it's happening rather than just blind implementation.
A very well thought out talk relevant to areas of software engineering beyond frontend. Takes me back to embedded days.
Monica bringin that sassy attitude while droppin insights!
Good talk thanks.
Excelent talk! :)
Nice