frameworks

Frameworks

You were supposed to make my life easier!!

Well OK they have. And they have also helped thousands of other developers.

In this piece I'm only speaking from my perspective, and from that of developers I have worked with (and who happen to agree with me or whose opinions I have changed in my head to suit my arguments, so you should assume these are just my opinions).

Modern software projects

The majority of development tasks I have been involved with over the last decade or so have been of the database front-end variety. You know the thing, this is the flow:

1. DB
2. middle bit
3. front end
4. middle bit
5. go to step 1

So what's with plethora of options.

Frameworks have taken the same evolutionary path as most technology. For example these points apply to both frameworks and mobile phones:

• A new release was the best at the time; everyone sang it's praises; but it gradually faded away when something else came along with more functionality or a more intuitive interface.
• The market is now saturated with near identical offerings, all doing the the same thing, looking the same but forcing entrenchment in little camps
• You still have to pick one, just to do the same thing the other does, it's just different that's all, they all work, they all do the same thing.
• You don't really care; you just want to serve that web page, or navigate to it, or send a text, or save some data to the database.

Using a framework

Say we're working with a persistence framework on a brand new project, there's a prescribed way to tag domain classes, and to interact with the database. Granted the framework will have evolved over time and there will be a lot of legacy APIs knocking about in it. But just pick an approach and stick with it throughout the development of the new product.

This will make it easier for future changes as there will only be one methodology to deal with, you'll have to be vigilant though, anyone deviating from the chosen approach should either rewrite the code to conform or be able to explain their deviant behaviour. Code optimisation is not an excuse, don't try to optimise the code until you hit a bottleneck, go for the simplest API and stick with it.

Spring

I started using Spring somewhere around the late naughties, back then XML was an added layer of boredom to get through; but never mind, once you got used to it it was relatively easy to configure alternative bits for development vs production for instance. XML configuration is like all the other stuff I do on a Monday morning when I'm still in shock from having to come into work again.

Spring was pretty lean back then:

• IOC
• JPA
• JMS
• controllers
• JSP tags (yuck)
• a few other bits i never really used.

Compare that to Spring now, go to their main page https://spring.io/projects/spring-framework and you'll see 22 different projects so you can pick and choose depending on what you're doing. WHAT?!?! 22?

To reflect all that bulky noise there's a book I got a few years ago due to being misguided by reviews, the massive tome that is Spring Recipes, this was the usual flow while using the book:

1. let me see how to do x-y-z
2. let me implement it to see how it works
3. turn the page
4. "or you can do it like this"
5. turn the page
6. "or you can do it like this"
7. turn the page
8. "or you can do it like this"

Come on!!, I don't want to read your book then go to stack overflow to figure out whether I should choose the 'a' approach vs the 'b' approach ... vs the 'k' approach only to end up going to the Pivotal site and just use the latest recommended approach.

To be honest buying the book was my mistake I should have learned from similar books (C++ the complete reference - I'm looking at you).

So what happened to doing one thing one way and doing it well?

Well, thankfully Pivotal noticed this massive explosion and also noticed that most projects are still of the database front-end variety so they came up with Spring Boot, what's in spring boot:

• IOC
• JPA
• JMS
• controllers
• a few other bits i never really used.

Oh look that's pretty much all I need anyway, and if I need anything else I'll put it in there when I want it, and if it's not in Spring Boot I'll just add the library I need. BTW, you'll notice I left out JSP, this is 2018 get with it.

So now they are called opinionated frameworks. Although in all honesty it does rather sounds as if we simply got back what we originally liked about Spring in the first place -via a massive 10 year detour.

But that's not all, the pivotal team have gone further, there are prescribed ways of:

• adding configuration files so you don't have to even worry about parsing them (nice property files too, clean key value pairs not clonky xml)
• logging
• using rest
• json processing
• scheduling

And they've even thrown in a production-ready lightweight http server by default

What I want from a framework - rigidity

Now Spring boot isn't the only framework, but when you use it you realise that things are where you feel they should be:

• no blooming weird configuration spread over 72 xml files
• no reliance on generated classes
• no reliance on classes that do nothing but take up space and have to be in a different package -just because (I'm looking at you interface/*impl').

README

Take something as simple as a README.md file. Imagine you wanted to make some changes to an existing README which had been maintained along with the code base over the past 6 years. Now imagine markdown was a framework, there would be 4 ways to underline some text, 4 ways to create a bullet point list, each HTML element would have 2 or 3 different ways of being called into action and -just because- the designers have added their own elements which have to be translated into regular markdown before being translated into html. So how do you approach the change, do you:

1. copy an unfamiliar way of doing things.
2. break from the current norm and do things the way you know, at least it will work (or you'll be able to fix it without pulling out your hair).

It's nonsense of course, markdown only has a few choice elements and you can only instantiate them in a predefined way, it does one thing only and does it well, result: it's clean easy to read and easy to maintain.

Spongy frameworks

If a framework isn't rigid, it's not really a framework, it's a pot you boil veggies in; imagine a flexible calcium framework for bone replacement therapy, you end up with spongy bones that don't fulfill their primary role -support.

The same thing happens to a code base with a spongy framework: you give people freedom to do something 30 different ways and they will!

Sure you review each commit, and review the code base once in a blue moon. But that's extra work for everyone involved and you gain nothing from it: Maintaining application state in your head while reading a method and having to translate between approaches is just unnecessary and liable to lead me to mess up somewhere. And you know full well that if there's an emergency release at 2am, the code is going to be approved no matter what it looks like as long as it fixes the issue.

Front Ends

Yes, front ends.

The wrong way

The same thing happens in the front end but at a much greater speed, take Bootstrap.

Bootstrap used to be lightweight, offered a few choices on layout and that was it. Over time it's got much bigger but we're still using it for pretty much the same stuff: element layout, anything fancy is done using a separate css, so now you end up with more than 150K just to use a few elements unless you start fiddling about with it in order to avoid downloading everything, and it needs jQuery too!!! that's another 80K.

Wait jQuery? what's this 2007?

For personal projects I use Skeleton and although it works fine it hasn't been updated in a few years. For clients who have no preference I use pure-css - although most still choose Bootstrap. But this is all front end stuff which changes every few weeks, as a result I'm not as invested in it.

A better way

A happier example is Angular. It is a fairly big thing, instantiating a project takes a fair few downloads, but blimey it's nice and rigid! there are predefined ways to:

• write tests
• design forms (angular/material)
• use javascript (typescript)

This makes jumping between clients and projects much easier, there is simply no overhead in getting used to one person's approach as there is only one approach, this way I can focus about the important stuff: what the client does it with not how it's done.

The only other difference is one person's idea of a pretty website versus another, and that's all taken care of by CSS. That simply leaves you to concentrate on the code: generate components, generate the app, yes please!!

With database front ends I just want to plumb in the data and get out of there quickly.

Having said all that I prefer React for personal projects or when a client has not preference, it's lightweight and has an implicit way of generating components (besides if you don't do it correctly it might build but linters will shout at you and it won't work anyway). Plus, what you learn about React is transferable to mobile platforms: React Native and KaiOS (yeah I know you can use Angular on KaiOS but it feels wrong to use something so big on such a little platform). But this is all for another blog.

So where are we at

As it stands, the majority of development work out there is all about generating database front ends that do the exact same thing:

• authenticate user
• read data from a database and display it
• write data entered by the user to the database

Of course there are many more sub-tasks the above can be broken into:

• pretty format the data on the screen
• validate user input
• let user update data (if they're allowed to update it)
• make rest calls to external systems
• make jms calls to communicate with external systems
• reporting
• perform some logic based on the data to update some other bit of data or the screen. ps - I know there are business engines, but they're ugly and boring and if you become an expert in one that's all you'll ever do

The majority of all this can be managed with three frame works:

• Spring boot
• React (or Angular)
• Bootstrap (or skeleton or pure-css)

That means you only have to:

• design a pretty front end
• define data types
• wire the systems together
• add your business logic where appropriate

Now, I know those four things are pretty onerous; and it take months of hard work to get the them right and get the system up to a point where it does what it should. But imagine if we didn't have frameworks, those four aspects would be the least important amongst all the development needed for a simple database front end, and they are not.

So even if frameworks are sometimes boring, and they seem to suck the life and fun out of development (specially when they are misused) use them; and use the time you gain to hone your development skills. Who knows you might be able to learn enough to steer clear of database front-ends in the future.

Evaluating a framework - it's simple

If a framework allows you to do something as mundane as connecting to a database in more than a couple of ways steer clear of it if you can. Do you really want to waste your time learning and evaluating 6 different ways to do something only to realise it doesn't make any difference 95% of the time which way you choose (the other 5% is probably around performance and you should always avoid early optimisations).

Instead learn additional language features and try to improve your design skills so you don't hit those bottle necks in the first place.