DEV Community

Cover image for You don’t need the framework that builds you a blog in 10 minutes.
Bruno Noriller
Bruno Noriller

Posted on • Originally published at Medium


You don’t need the framework that builds you a blog in 10 minutes.

I can't deny that it's impressive that you can set up a blog, e-commerce, or anything else in just under the time you take to name said blog or e-commerce.

That’s not what you need

Even if you are creating one of those, you might not want the framework that will do that for you.

Your needs are your own and while it’s easy to set up, will it keep helping and working for you?

It doesn’t matter that you can scaffold the project in minutes if everything you need to make after that takes hours.

It’s a marriage

Choosing a framework is like marriage.

For good or ill the framework will be there and it’s a messing thing the divorce (if it’s even possible).

More than that, it’s often hostile to infidelity, so when you can’t solve a problem in that framework with its approved tools, then you are in for a bad time.

How to evaluate a framework?

As with everything in programming… it depends.

The most important thing is how much support it has and if you can see it increasing or not. (There are tells, and unfortunately, this means the new fresh out of the oven framework, as good as it looks, is probably not one you should consider.)

Then you should evaluate how they do things and how they tell you should use their framework.
Do you agree with their choices or would do it differently?

And finally, does it helps you with what you need most? And how hard is it to bring third-party solutions for places it doesn't cover?

A framework serves itself first

Few players can greatly influence a framework to solve one specific need just because they need it. Even if you try to PR a solution, the owners might not agree with it.

I say this because they probably made the framework for a reason and they have their own beliefs of what and how it should solve them. And you needing something is not a priority for them.

Have you gathered all the requisites?

If you know exactly what you’ll need along the way then you can evaluate if the framework you're considering has everything you need and helps you with all of that.

You can also consider that anything you think it’s not done in a way you would do is or will be some kind of problem along the way.

If you’re making your framework, then you totally need your version of “build a blog in 10 minutes”

Unless you’re solving some real niche problem, it’s easier for creators to share with their fanbase a framework you can just spin something fast and have it working than if you need lots of complicated steps and whatnot.

The best framework is not always about being the “best”, but about solving a problem and having enough people using it to move it forward.

And the more people are using, the more content is made…

If you’re into React, then you probably heard about Next and if you’re updated, you might have thought Next 13 was revolutionary. You also probably heard about Remix and might even have thought that Remix was doing some of those revolutionary things first. And if go down the hole, then you have even heard about RedwoodJS which also came with an amazing way of doing some of those revolutionary things.

At this point I’m not sure which one is the “best”, but Next probably takes the crown just because it’s so widely used that doesn’t matter the problem you have, you have enough people having the same problems and solving them. Being so widely used also means people already know how to use it and starting new projects with it is a good choice because you’ll easily find people to be productive with it.

Photo by Alex Knight on Unsplash

Oldest comments (1)

theaccordance profile image
Joe Mainwaring

Choosing a framework is like marriage.

Probably one of the more enlightening ways to describe a relationship with a framework; one I wish was emphasized more often. I concur with this sentiment, if you decide on a framework, you really have to embrace it. When folks circumvent the framework because either they don't understand or they're trying to be clever, it typically creates frustrating tech debt down the road.

Visualizing Promises and Async/Await 🤓

async await

☝️ Check out this all-time classic DEV post on visualizing Promises and Async/Await 🤓