4 ms·

Any one saying they are not using a framework is not being honest with themselves. They may not be using a formal published framework like those mentioned in t

Any one saying they are not using a framework is not being honest with themselves. They may not be using a formal published framework like those mentioned in the article, but they have a personal set of tools, techniques, and methods on which to design and build things. To maximize flexibility, minimize dependency, & maximize performance means you have to use some set of tools & methods (aka framework) that have been designed to reach those goals.

kilroy123 5y ago
Yup back in the day when I first started doing frontend work in ~2009. Everything was vanilla JS / jQuery. What did we end up with? A custom build framework.
- jmull 5y ago
  Yup^2. It has ever been thus. I started in the early ‘80s and of course built up a personal collection of BASIC routines to solve the common problems and get a quick start on the games I made. LOL, I still have to stop myself from calling the symbol to reference the upper left of a drawing surface “L”. I got to pick the brains of my Mother (RIP), who got her start in the ‘50s, and it was the same. So between us we have three long generations. I don’t really have illusions about these common frameworks. They are so full of drawbacks and unnecessary complexities, and you need to understand them pretty well to use them effectively in production for even slightly successful projects. But they solve many of the problems you’d have to solve anyway, and in a way that may already be documented and maybe even well understood by others. Unless you’re really going for something bespoke/unique/different, the advantages are so large it’s usually worth it. I’m starting a project for a client now, and I’m using a popular framework of today… because it’s a popular framework of today. E.g., if it’s successful, I don’t want to be making tweaks to this 5 or 7 or 10 years from now, and if I’m using a popular framework, maybe I won’t have to. (And if it’s not successful, it doesn’t matter what I used.)
Sateeshm 5y ago
Yeah, vanilla js for large projects only makes sense if you don't agree with with the way existing frameworks are doing things, because you are going end up creating a framework for the project anyway.

kilroy123 5y ago

Yup back in the day when I first started doing frontend work in ~2009. Everything was vanilla JS / jQuery. What did we end up with? A custom build framework.

jmull 5y ago
Yup^2. It has ever been thus. I started in the early ‘80s and of course built up a personal collection of BASIC routines to solve the common problems and get a quick start on the games I made. LOL, I still have to stop myself from calling the symbol to reference the upper left of a drawing surface “L”. I got to pick the brains of my Mother (RIP), who got her start in the ‘50s, and it was the same. So between us we have three long generations. I don’t really have illusions about these common frameworks. They are so full of drawbacks and unnecessary complexities, and you need to understand them pretty well to use them effectively in production for even slightly successful projects. But they solve many of the problems you’d have to solve anyway, and in a way that may already be documented and maybe even well understood by others. Unless you’re really going for something bespoke/unique/different, the advantages are so large it’s usually worth it. I’m starting a project for a client now, and I’m using a popular framework of today… because it’s a popular framework of today. E.g., if it’s successful, I don’t want to be making tweaks to this 5 or 7 or 10 years from now, and if I’m using a popular framework, maybe I won’t have to. (And if it’s not successful, it doesn’t matter what I used.)

Sateeshm 5y ago

Yeah, vanilla js for large projects only makes sense if you don't agree with with the way existing frameworks are doing things, because you are going end up creating a framework for the project anyway.