Which framework should I use in 2018? - By James Thomson

This post ponders on a few of the key considerations that are often overlooked before choosing languages and frameworks to implement an new project.

Back in the day…. 

Perhaps one of the single biggest changes seen by those who have been constructing web applications over the last 10-15 years is the emergence and widescale adoption of web application frameworks.

Back when I started commercial software development in 2001 there was very little to choose from. Popular PHP frameworks such as Symfony and Zend were a few years away from initial release and it took another 9 years for the first version of Laravel to emerge. Even the ever-popular Spring framework wasn’t to surface for another year.

Fast forward to 2018

Recently the number of new JavaScript frameworks has become a bit of a running joke in the development community.

All jokes aside though, this is really important stuff. Technical debt can be crippling and the further the project gets down the road with more features added you’ll become more and more locked in to your technology choices - much as developers always talk about “we’ll address that when we rewrite version 2” the reality is at least one constraint of either time or funds usually prohibits this. Here is a list of some of the biggest mistakes I see businesses making when choosing technologies.

1.? Not checking developer availability - what happens when you need to add development resources to the team to support the project, or the first developers move on?

I’ve seen this really cripple projects - for example - up in the Durham/Teesside area, trying to grow a reasonably sized team of Ruby on Rails developers might be a struggle. Because they’re so thin on the ground you’ll have to persuade developers from outside the area to relocate, allow developers from other areas to work remotely or (at an even higher cost) cross-train developers from other disciplines.

From this point of view in the North East of England backend technologies such as .Net/C# or PHP seem the best bet - with Java/nodeJS coming in next. For front end, Angular and React seem to be best.

2. Not playing to the strengths of the team - a Mobile App project I reviewed recently had the app implemented in JavaScript/React Native and the backend in ASP.Net. 

The system was originally developed by a single person who had wanted to get into React Native and had heard that salaries for .Net based roles in the North East were on the rise so seemed like a worthwhile new skill to pick up.

The result of having to learn something new very quickly was (in this case) that the implementation of both sides was poor and really quite buggy and the software architecture inflexible - best practice that is acquired with experience was not followed.

3. Not checking out the upgrade path - as anyone who has had to migrate a project from Angular 1 can attest, it can be a pain when your framework upgrades fundamentally between major versions causing breaking changes that will in turn trigger lots of development work just to keep apace.

It’s always a good idea to build in some time in your development schedule for framework and security updates - the major established frameworks help with this because they have well documented upgrade paths and documentation that is easy for developers to follow.

4. Not understanding how to support your project - particularly back-end frameworks such as Laravel provide powerful in-built functionality for application development such as queueing and full text search which can be enabled often with little more than a few lines of code.

However it’s important to remember the need to support this stuff - traditionally implementing queue and messaging systems pre-frameworks required detailed knowledge and a sound understanding of the concepts at hand.

Having the ability to switch the features on is great, until it all goes wrong in production and you can’t figure out why - having a nose around under the hood and understanding the different configuration options will pay dividends

Conclusion 

Rapid prototype and application development has become easier than ever before - with an abundance of of well supported tools truly stable enterprise level application functionality can be achieved with open source components.

It’s always wise to do the due-diligence up front from both a technical and business/ cost perspective - and also factor in time for the strategy and implementation to replace technologies as the project grows.

By James Thomson - Big thanks!