I read a few of the functionality on Vue mastery and reached the conclusion that you need to make a clean distinction between using them in a project for a client vs using them to make a package to re-use. The experience is different and should be pointed out especially for juniors since you have the basic Vue stuff that you learn in a guide then you have all the use this that this that (and there are a lot of them) that can make your life easier or not. A lot of people have a profesional defect assuming some things because of their experience.
My personal one, that's not limited to Vue devs, is to stop putting business logic inside of components or composables. The business logic should be separate and agnostic, the components and composables should only use those agnostic pieces
The "grouping by logical units" are called Composables.. We are grouping our stuff by template-refs, computed, private methods, exposed methods, data, event methods and life cycle.. Otherwise, everything becomes a mess. I know you guys want us to NOT do this, but we have 86 million lines of code that prove otherwise that it works.. We also have a lot of Splitting up grouped logic into composables and not in the vue files directly.
@@RizkyMatupena because we could do better simpler things with solidjs. But solidjs grows slowly because we have 2 big giants vue and react. Also library authors dont understand how to create framework/platform-agnostic codebases.
One of the worst takes I've seen... In my decade of experience as a developer, comments like these typically come from people who made a mess of their code base and instead of learning proper design patterns and how to write maintainable code, they blame the framework. Eventually, they move to another and make a mess of that one, too. For those reading this thread, ignore this comment.
Ready to master Vue.js? Level up here 👉 www.vuemastery.com
Really good tips of advice ❤
Lots of good material here 🔥
I read a few of the functionality on Vue mastery and reached the conclusion that you need to make a clean distinction between using them in a project for a client vs using them to make a package to re-use.
The experience is different and should be pointed out especially for juniors since you have the basic Vue stuff that you learn in a guide then you have all the use this that this that (and there are a lot of them) that can make your life easier or not.
A lot of people have a profesional defect assuming some things because of their experience.
with examples this video would be so much better
Very valuable ❤
very good tips 👍👍👍
Big thanks!
My personal one, that's not limited to Vue devs, is to stop putting business logic inside of components or composables. The business logic should be separate and agnostic, the components and composables should only use those agnostic pieces
The "grouping by logical units" are called Composables..
We are grouping our stuff by template-refs, computed, private methods, exposed methods, data, event methods and life cycle..
Otherwise, everything becomes a mess. I know you guys want us to NOT do this, but we have 86 million lines of code that prove otherwise that it works..
We also have a lot of Splitting up grouped logic into composables and not in the vue files directly.
Inline Composables are the way!
Investing in vuejs instead of solidjs is the biggest mistake frontend developers make.
Tell the reason why?
@@RizkyMatupena because we could do better simpler things with solidjs. But solidjs grows slowly because we have 2 big giants vue and react. Also library authors dont understand how to create framework/platform-agnostic codebases.
but not if you want a job
One of the worst takes I've seen... In my decade of experience as a developer, comments like these typically come from people who made a mess of their code base and instead of learning proper design patterns and how to write maintainable code, they blame the framework. Eventually, they move to another and make a mess of that one, too. For those reading this thread, ignore this comment.