How to choose a framework

With so many options available, how does one choose what to use for a new project? This question came up recently in a discussion with colleagues and I wanted to share my thoughts.

For Websites

If the project is a website, the question of whether or not a CMS (Content Management System) is appropriate is one of my first considerations. If a CMS is appropriate, it can be invaluable throughout the life of the site, but if it isn’t needed, avoiding it will reap lasting security and performance benefits.

CMS

Will the client be updating the site regularly with new content (like news articles or blog posts)? Does the site require functionality that we know we can solve efficiently and reliably with, say, a WordPress plugin like WooCommerce, Paid Memberships Pro, or Formidable Forms? Or maybe the client has something very specific in mind that matches well with a product like MediaWiki or Moodle. These are all cases where a CMS is likely a better solution.

Static Site

What if the client just wants a basic web presence? No functionality (because perhaps a contact method or newsletter signup) and no plans for regular content posts? This is a good candidate for a static site. The advantages of a static site are speed, hosting simplicity, no need for software updates (like a CMS and its plugins), and they’re virtually hack-proof.

For Web Applications

Sometimes it’s hard to tell where a website ends and a web application begins. Personally, I think the target audience is an important factor. If the target of the project is public users and its main goal is to provide information – or perhaps products to sell – then I’m likely to begin my analysis in “website” terms. I would consider also how much of the desired functionality is common to websites (like e-commerce, social functions, etc.)

If, on the other hand, the product is about providing robust, specific functionality to select users (like company employees or paid subscribers), then my thoughts will be more “web application” focused. A lot depended on whether or not the project will require a lot of custom development.

Why?

For one thing, there’s performance. When we optimize websites, we’re focused on more static content that will be seen by users who aren’t logged into the site, and we rely heavily on page caching. If the data being displayed is rapidly changing, a page cache will interfere, and the performance strategy has to be rethought.

If custom development is a major factor, then we’d much rather use a development framework as a starting point. While you most certainly can create applications in a CMS like WordPress, we don’t recommend it. While many CMS platforms are developer-friendly, they weren’t made to be blank slates upon which we can paint our perfect app; when there’s a lot to be developed from scratch, the elements of a CMS can just get in the way. Also, if your application doesn’t need the things that a CMS brings, then you’ve got a lot of unnecessary bloat.

Choosing a framework

Even after deciding that you want to build an application using a development framework, there are still questions to be answered. Do you want to use a JavaScript framework like React, Angular, or Vue.js and create a separate backend with something like Node.js or Go? Or perhaps you’d rather build a more traditional browser-based application; you could use Java/Kotlin, PHP with Laravel, CakePHP, CodeIgniter, or maybe go the C# route and write something using ASP.NET. (Oh, and don’t forget… there’s Python with Django and Ruby on Rails, too! The list could go on, and on, and…)

It’s not enough to know a programming language. Invariably there’s some kind of framework to learn (like .NET, Rails, Laravel, etc.), libraries to include, and for browser-based applications, there’s no getting around the need for HTML/CSS and (in some form or another) JavaScript. You’ll also deal with dependency managers (Composer, NPM, etc.), asset management, and a number of other things that I’m sure I’m forgetting.

If you’re a solo developer or part of a small team, pick something and stick with it. For my team, it’s been LEMP (Linux, Nginx, MySQL, and PHP) for years because that’s where we landed. If you specifically want your application developed in, say, Ruby on Rails, then you need someone besides us to do it (and we’ll try and recommend someone!) Brains can only hold so much, and clients may be better served by well-rounded developers (I’m including “soft” skills here, too!) than people who are trying to know way too many tools.

The bottom line

News flash: We developer types can definitely overthink things at times. It’s good to make an intelligent choice (such as using a CMS only when a CMS is needed) but one can make a really good website (or app) in almost any language.

A website that is clear in its message, reliable, SEO friendly, and fast in any language is better than one that uses all of the latest and greatest tools but misses the mark with site visitors.

An application that is well-designed with the end user’s processes in mind, one that’s secure and that performs well, is going to make for a happy client.

As an individual developer, you are likely to be asked to learn new things over time… and you should be learning new things (just because you enjoy it!) But I think it’s healthy to have some boundaries for yourself. There’s a part of me that wants to run off and learn Kotlin but that means also learning Ktor and/or Spring and Maven and who knows what else. (There’s no part of me that wants to learn .NET, BTW.) I could do those things, but I could also spend time learning things a little closer to (my) home.

Make reasonable choices – like when a static site is preferable to a CMS – and know enough technically to support those choices. No client is ever going to ask for a refund because the great app you made for them, on time and within budget, wasn’t written in the latest buzzword framework.

Leave a Reply

Your email address will not be published. Required fields are marked *