Frameworks are not always the best solution

(The match between library and framework is not yet finished)

When i look back at my career since 2001 where i have done my first commercial website for a company – a video game company based in Paris, Delphine Software International  -, to now, i was project manager of 62 professionals projects from any scale, and any timeframe.

On top of this 62 projects in 18 years, I have 2 majors big failures on my list  and this 2 failures was based on a IT “core” framework used.

Perhaps it’s only a statistic effect but 2 among 62 and the 2 was based on “core framework“.

When i speak about “big failure” is a project which finally did not end at all.

On this 62, about 18 was late , only 3 was out of budget finally.

Majority of theses projects was done as project manager , some of them was done a project director with project manager under my supervision too – it’s the case for all Edipresse’s website in switzerland – where we re-factored all major media website of the swiss french part.

A part of them was done using the my own saving money when i was building the core of my financial company with robot.

The first big failure was with Zend framework when it started to be “fashion” and the second was based in another known framework in another language (Django / Python).

Big success also was done using Drupal, Wordpress or Magento, then we may consider a “content/e-commerce management framework” but they are different from Laravel, Django or other Symphony based “core framework” because they directly “do the trick”.

When we speak about Framework, developers in all my team(s) was always very excited because they know that learning a framework is , for them, a way to improve their own value on the market.

Look at the jobs ads, and you will see a lot of framework’s names thrown as tag by recruiters. 

Managers who are not techies are also very confortable when they hear “framework” because they feel they can control better the team.

I was always surprised that a lot of developers now can’t imagine to start without a framework even if they don’t know yet one “really”.

Yes, it’s true that :

• Frameworks are fun to use. I don’t think I know any developer who actively seeks out a more challenging and less fun experience! And yes, absolutely, ergonomics are important.
   
• Frameworks make it quicker to build an MVP. This one is important, particularly for smaller, fledgling organizations or companies. Having a fast bootstrap may be the difference between shipping and not shipping.
   
• Frameworks work around lumps / bugs in the platform. I think this is less of an issue these days (though not irrelevant) as browsers have rallied around standards very well in the past few years. Certainly this is less painful compared to my early career, where we were dealing with IEs 5 and 6, and early versions of Firefox, Safari and, of course, Chrome.
   
• Knowing [insert framework] means I get paid. If you’re looking to get hired, saying that you know the latest and greatest framework(s) may be the difference maker.

But on the other hand….

• Sites and apps should load quickly.
• They should have smooth interactions.
• They shouldn’t slow down my phone.
• They shouldn’t crash.
• They should have features I want.
• Learning it. You have to take time out to learn any new framework: what it means to write “idiomatic” code for that framework; its patterns, practices, and ways of doing things. This is no different to the web platform itself. There’s no free ride, you’re just swapping one set of issues for another.
• Re-learning it. One day you’re just bimbling along, developing your app, and in the console you see a warning telling you that there’s been a deprecation, and that you need to update your code. That often requires figuring out what the latest version of the framework needs you to do differently, and that may also mean updating projects that shipped with older versions of the framework.
• Debugging it. Frameworks, like any software, have bugs. That’s to be expected, and it wouldn’t be any different if you went vanilla and wrote your own. Debugging a framework, however, often ranges from difficult to impossible. If you find the issue, you may have to keep your own frankensteined version around with a monkey patch applied until the real fix lands in the framework’s production build.
• Time. How long does it take to bootstrap the thing we sent down the wire?
• Bandwidth. How much bandwidth does it use up?
• CPU usage (battery). How CPU intensive is it? CPU utilization is going to correlate to battery usage: burn the CPU and the battery will get drained.
• Frame rate. How well does the code update the screen? (We know that users like smooth interactions.)
• Memory usage. How much memory does it use? Will it cause other apps to be evicted from memory? Perhaps even crash a tab?
• Frameworks contribute ideas and concepts. Frameworks are a crucial part of understanding what approaches work, and what don’t, and that ultimately drives improvements at the platform level. In that regard I think they serve as important testing grounds for the platform changes of tomorrow and let us figure things out before they become embedded in the web permanently.
• Frameworks are an inversion of control. The reason I parked libraries earlier on is that you can swap them out. Frameworks, on the other hand, invert control. They control the lifecycle of the app, and give you entry points where your code runs. You’re still responsible for the final code, but you’re not in control.
• Frameworks are expensive on mobile. Compared to vanilla, at least. For me, prohibitively so, but everyone has their own limits of what they’re willing to tolerate.

Then what is the alternative to frameworks ? 

Librairies….

For example, i rank more a bootstrap framework as a “library” then , really, a framework. You can compose with Bootstrap and add on top of any script you may have.

We could get some API to do some part of the job, take the classic layer to access the database and just mount them together to go fast and exactly where we want.

A library is something your code calls, a framework calls your code.

the biggest and most obvious problem with frameworks is that they cannot be composed.

Tomas Petricek uses the same framework definition and argues that the biggest and most obvious problem with frameworks is that they cannot be composed. When using two frameworks there is commonly no way to fit one of them into the other; when using two libraries this is easily done.

He also notes that frameworks are hard to explore and affect the way you code.

The perfect example of this question was to answer the question to the city of Yverdon-Les-Bains during Covid crisis to deliver meals and goods. Answer needs to go fast and a very secure way….

We needed an apps running live in one week and this app would need to be used by many people who won’t see each other, won’t learn, won’t be educated to this apps . We did not have any direction other than let people meet around a common objective to deliver meal with a lot of benevoles behind.

We did not have the time to see if a framework like Laravel in this case could be suitable for all “cases” we would have. We had no ideas of the cases we will have and by the way users of the apps will send us every day by SMS at 10:00 PM what would be the next features tomorrow….

Apps was out in 7 days. Running during 1 years…was adapted to restaurant after shop and delivered meal to more than 10’000 people in the region….and features go from basic form to automated route via google drive/map API

Then ?

I am thinking now there is a big error concerning frameworks. We think, usually, we need a framework when we will have an apps for several years to allow new developers to onboard easily on the project, be stable and just pick the new features from the framework.

First, how many “new developers” you will have during your journey ? A website cycle is about 5 to 6 years. Every 5 to 6 years, companies begin to think to do a new website or change the website….in 5 to 6 years, what is the hire plan for developers in the team ? 1, 2 ?, 3 ? the whole team ?

Then the reason “of new developer” to come is something weird in the majority of the IT team because during the next 5 to 6 years, a large part of the team(s) will be “stable” with few new comers.

The second aspect is hiring only new comers who know this framework is hard to find.

Just try to search a magento specialist in Switzerland or a Symphony specialist ….not so easy.

Then the new comer will have to learn finally the framework which is good for him/her for his/her own value on the market but for the company learning a framework is a minimum of 3 months for mid-level developer before to be really operationnal on it.

A junior developer can manage a wordpress or a drupal in one month….laravel or symphony is not the same story.

…a good script done with right libraries even in full procedural could be tweaked by a junior in one or two weeks….

Just compare the 2 weeks to the 3 months….

Perhaps the biggest point for frameworks are the security aspects.

Indeed Frameworks – the modern ones – are more secure than a script done by a bunch of developers with different level who have no experiences on security because the community already solved the majority of the security leak. Just look at the twitter of Laravel (https://twitter.com/laravelphp) and you will see what i mean.

On this point, i agree and the dark side of the library “composition” is the breach developers could let trying to run the puzzle without perhaps mastering all the aspects.

Going “free” of framework would mean spend time to make a correct security assessment on your app to avoid the basic traps.

Frameworks could be the “base” of an IT culture in the company you are participating. Yes. A meeting point for developers who “embrace” the framework as well as the company itself. 

But in this case, the introduction of the framework ” culture ” can’t be link to a project with a short deadline – only.

Perhaps the best way could be to install the framework in long term project which is more a background project at the beginning to not over-expose developers to “the stress to learn while the project is advancing”. When developers are becoming confortable with the framework we could think then to switch to critical project using this framework.

Then the “one shot with one new framework” with “the project of the company” is perhaps not the right idea.

In this case. developing the core with libraries and compose with them may be more suitable and introducing the new framework in a back-office project after a good way to prepare the “change” to the framework IF this change has to be made.

I am more and more thinking that the real challenge for today IT companies (companies who have IT) is to be able to exchange easily its data via API (server/client) and then with the development of API language like GraphQL, there is a come back of the “mini-service” spirit where simple scripts are doing simple tasks. In that case, introducing globally a framework could be harmfull for the project because majority of the time spent on the framework will be only “bureaucratic time” to respect the logic of the framework itself and not the logic of the apps you are bullding.

Conclusions

As always in our modern world full of incertitude, there is no easy answer but excluding all others options than framework “by default” is an error, it’s a certitude.

Study what you want to acheive first, what is the level of your team now, what is the project to grow later or not, and try to search what kind of library composition could be suitable for your project. and then compare to a framework.

If the framework does , by default, 90% of the features you want, perhaps it’s good to move on even if this framework is hard to learn.

If the framework has to be understood deeply before to reach the majority of your feature, it’s perhaps a bad choice to start with now with this project.