Haven't done a discussion post yet and I thought maybe this one might be interesting.
I have a really bad habit of trying to write my websites and web apps as vanilla as possible until it gets complicated enough that I end up writing my own mini-framework.
At this point I either ditch the project, soldier on, or rewrite it in an already established framework.
I'm usually under the assumption that the people working on these large frameworks for years are smarter than me and/or have gone through the work of dealing with edge cases and performance bugs to the point of where the file size bump is worth it.
Some people I have talked to like to write a ton of helper methods and refuse to touch a framework unless they're instructed or as part of a team effort.
At what point do you ditch the helper methods and move on to a regular framework? There seems to be a lot of opinions back and forth and I would love to hear some more.
Top comments (7)
I think there's a lot to be said about the distinction between "exploring solutions in an unknown problem space" and "applying a known solution in a well-defined problem space". I treat frameworks kind of like time-capsules about the practices generally considered 'best-practice' toward providing a certain solution in a defined problem area.
If you don't yet know what the shape of your solution, or even the shape of your problem are yet? You don't know enough to evaluate what frameworks might help you.
But if there's a well-defined problem, with many well-known solutions - I think it would be a little daft in most situations to ignore the best-practices of the present day and build something else. It might be worthwhile for education, or if you're trying to actively (consciously) improve over the state of the art, but in most situations it makes sense to pick the framework that most closely models the solution you're trying to provide.
Another way to think of frameworks like like a pre-flight checklist. If you don't know what you're doing, grabbing a pre-made checklist may not help you, but if you know you're flying an airplane, and a specific model of an airplane, I bet there's a really good pre-flight checklist for that model of plane that would be wise to follow before flying it.
One plus point of sticking with a framework is that you usually can receive tons of blogs and tricks, for instance, state management at first was a vanilla->flux->redux->other utilities bundled with it->other big APIs.
Generally I think it's ideal to choose whether you're going to use a framework or not before you start coding. When you know what problems you need to solve and what your project needs to do, then it is time to evaluate what libraries/frameworks to use.
Obviously, we're all human and make mistakes, so it's perfectly acceptable to realise that a framework might help you, or that you should ditch it in favour of vanilla/another one later. That stuff happens. But I think then you'll be in a much better position to quickly make a good choice if you have already spent time thinking about it before you started coding.
I usually flow from concrete methods while the spec is coming together, then abstraction when I see it's a healthy choice. When the spec/abstraction has congealed enough, I almost always see trends that boil down to something like "well, this is pretty similar to (blank)"
That's when I check out blank, and evaluate it for gain vs expense.
I give a lot of points to the same thought as you: there's no way little me can match velocity with a 9k-contributor project.
I give just as many points to the same idea on cost, though: do I absorb a ton of responsibility for out-of-scope issues?
If it passes gain/expense... Framework, here we go!
Frontend exception: if I need an SPA, I'll default to Vue. Rolling a front-end spa on my own is... 🤮
My internal PHP MVC framework served me well for about 10 years. It was stable, covered the features I needed & did very little magic so was easy to understand. And since I was too busy using it rather than working on it directly, I almost never had to upgrade projects built on it.
But I reached the point that I want to do more advanced things, and reinventing the wheel is nonsense.
I feel it's a level of experience you reach where you truly understand the value of leveraging 3rd party components- it's like having an expert staff.
Relevant to this discussion.
Oops, I'm Making A Framework
Ben Lovy ・ Aug 19 ・ 2 min read
Wow, title and content is uncanny.
Thanks for the link!