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...
For further actions, you may consider blocking this person and/or reporting abuse
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!