The Text Version

Today I want to cover how I personally select frameworks and tools for development projects.

Let's lay down 2 upfront points:

First off, these are for projects that are professional on at least some level. Meaning there are stakeholders other than myself, a timeline (or deadline), and potentially a team.

Second, you may be surprised that these have little to nothing to do with the actual inner workings of the framework.

I have 5 ways to analyze here. So let's get started.

One - Familiarity and Experience

How familiar, or how well do I know a framework?

Look folks, this is arguably the most important because all other steps can stop here. If you know a framework well enough, and you know it can hit all the points on your projects with flying colors - you're done. You can stop here.

And really you should.

Beyond that - the process of building your project will speed up incredibly based on your familiarity and experience. If you know it like the back of your hand? Well, just consider all of the nights of internet-documentation deep diving you can save yourself. Think of how much faster you can meet that timeline.

At this point, someone is going to say "what if I'm not familiar with any of the frameworks?"

Well, this is the value of experience and investing time outside of projects to familiarize with frameworks. This is why companies look for direct experience and proof of it when hiring. Because if you don't have to waste ages learning something new, you jump start exponentially.

Also, I want to point out here that by familiarity and experience, I don't mean having read a hacker news article or marketing landing page...

...I mean you've built things with it.

You've seen some real shit in the field with it.

You've crushed bugs and peeled through git issues and their authors' snarky "it's just you" responses.

I'm bringing this up because I see a lot of developers get new projects and think: "ooooh, what new shiny, unproven framework can I use for this?"

But Cole - Technology moves fast and I should learn the newest thing!!

Yeah it does move fast. And yeah you should always be learning. But do you want or need to deal with that on a new project that may have tight deadlines?

Two points against using the newest, shiniest framework or version every single time:

First - not all updates are improvements. Sometimes they're just change.

Some framework team decides they believe in an entirely new architectural paradigm and rewrites the underlying foundation. The new version is completely incompatible with the old versions. They claim it's more "scalable" and runs like 10ms faster. But you can't find any real case or company for which these claims are true.

But what is clear is that you'd have to rewrite a portion of your app. The docs are still rather vacant on it. And all of the terminology is completely different.

Second - Update Purgatory

This is where teams become so obsessed with using the latest version of X, that they're in a perpetual state of updating.

a) update the framework
b) they fix all the breaking changes
c) they do a and b for all their tools
d) it's been so long that we do a - c again

The worst part is when all of these updates and fixes start getting logged as "progress." When in fact, nothing has really changed.

Point and case here - on professional projects, leverage your familiarity and experience with tools and frameworks. Don't be so quick to throw away what you've worked so hard to gain - familiarity and experience

This may seem cliche to some, but come on. We're all guilty of it. Even those of us painfully aware of it.

Second - Documentation and Community Knowledge

If a framework is pushed to a public repo with no documentation, and zero community knowledge... is it a framework?

Maybe, but not a very useful one.

But Cole - I'm a damn Jedi and use the Source.

Well good for you. I'm picking a framework because I need to save time and not peel through source code. I don't want to painfully figure out how a framework works through experimentation and iteration....

...I have to do that enough both with well documented frameworks and the project I'm building.

Oh and that weird bug at 2:00 AM you have no idea on how to solve? You'll be thankful you picked a framework with docs and community knowledge when you either:

A) find the answer in the documentation

Or

B) find a stack overflow answer by ObiWan098264 that tells you exactly what you need to know

For those of you who get a kick out of not touching docs; or those who think stack overflow is a scorn upon the earth. Well...

Anyway, how do you ID if a framework has good docs and community support? Just do some research:

Go through the documentation while keeping in mind with what your project needs to do. If you've thought through it, you've probably identified a few "crap, this may be tricky" parts. See if anything in the docs points to those.

Outline what your project needs to do and see if the framework's docs have any semblance of how to do it. Don't do this too deeply, mainly because you'll do a deeper dive into the docs later (if it passes the other indicators).

Take topics from the documentation and go to google with them. See if the results are flush with discussion and answers.

Go to the GitHub repository (if they have one) and look through the issues. Look through the commit history for activity and improvements from the author.

Look for cohesive direction and community support. If multiple organizations are battling over the direction of the framework..... welllllll that's not a fabulous thing for your development.

Look for compatibility with other tools you may need to use.

But whatever you do. Please. Please. PLEASE don't base good docs and community support off of:

a) the framework's marketing page
b) Hacker News upvotes
c) Reddit upvotes
d) Github stars

Onwards!

Third - Usage Levels

If it's passed #1 or #2 you probably have a good feel for this one now:

How many people are using this?

How many big projects have been built with this?

How many big companies use this?

No matter how well documented a framework is, and no matter how endearing its mascot or logo - if no one has tackled any major venture with it ... ask yourself:

"Do I want to be the one to put this framework to the test?"

Or do you just want to finish your project with peace of mind that the framework you've chosen can handle it? And have proof of it?

There's nothing wrong with being the trailblazer of an untested framework. I'm just trying to point out that it's not required to build your project (more than likely)

Fourth - Functionality

At this point you should be asking if it does what you need it to.

This is a bit more specific than step 2 but definitely crosses over with it. In step 2 we were testing the water quality of their documentation and community knowledge. But only to an extent.

At this point you really need to look thru the core functionality of your application. Match it to the framework and see if it can handle the down and dirty parts.

How? At this point your basically doing an extended version of step 2. But honestly this is quite difficult if you're trying to make a decision right now. Ideally you'll have some time to experiment with the framework. And to do some building with it in order to validate its usefulness and fit with your project.

For those of you thinking "this is a lot of work" - it's not as much as being stuck with the wrong tools. Weeks into a project. And being forced to write some long winded hack that winds up being a sore spot from that point on.

There's also the opportunity cost of learning a better or more appropriate framework.

Fifth - Control vs Convenience

How low level do you want your framework to be? How automagical do you want it?

Automagical - where the nitty and gritty of a framework is abstracted from the developer. When/if the developer attempts to customize the framework, Gandolf appears and banishes them to the deep, dark of internet-documentation Moria...and often to their doom.

On one hand, the automagical ones can potentially save you ages (from reinventing the wheel)

On the other hand, automagical ones can turn into a never ending nightmare. Where you're trying to do something outside of the frameworks picturesque world... and it says "you shall not pass."

And on the other hand (yes 3), a low level framework may have you doing redundant crap more so than what actually makes your app valuable. Authentication and Authorization. Model to View to whatever. Scaffolding out files. Writing compilation scripts.

And before anyone says "well with low level frameworks, you can just pull in all sorts of extensions to solve things!"

About that - yes I'm sure each of those extensions probably works with the framework you're looking at ... but now you've started this entire process again.

Are they documented? Can they do what you need? Do others use them? Do they work with other extensions and packages you've selected?

And low level frameworks also come ripe with the paradox of choice. There's so many ways to do things that - you spend the majority of your time just making decisions. And the perceived opportunity cost skyrockets.

Now, for the low level side of things, if you find a set of packages that are reliable, that you can always chain together, and do everything you need... this is more or less the goldmine. Just make sure you support them!

When you have this type of setup, a low level framework + a set of reliable packages, you've more or less found the best of both worlds. All of the extensions and patterns more-or-less give you the automagical. And since it's still low level, you can extend it to match your snowflake of a project.

Software development has a very interesting aspect - most of the tools we use are free. On the contrary, most other fields' tools are not - the payment for the tool increases the likelihood that upfront research on it will be done.

So let's dig this into our brains here: just because these tools and frameworks are often free...that doesn't mean you should forgo any reasonable analysis.

If you had to pay for these you'd put in your due diligence to see if they're worth it. So let me drive this home -

You are paying.

Granted it's with your time (and hairline), but that's still worth something (right?).

Because you are paying, take the time to analyze as if.