The fragmentation of UI frameworks and structuring for the future

The highway of UI

Given the fast moving space in which modern UI frameworks operate, its more important than ever to have some methods behind the madness. Adhering to some SOLID OO principles to help keep code clean, maintainable and most importantly; separated from the functions of the user interface. The most important of these SOLID principles in this case is the separation of concerns. By keeping the actions of the UI separate from the logic behind it we allow portability. A lift and shift exercise can be reduced from a back breaking week to a nice easy afternoon.

Great, I hear you say. Nothing too hard there!

Except there is. Frameworks are clever. They will offer out sweet treats in the form of functionality shortcuts and before you know it you will find yourself knee deep in bespoke routing patterns, crazy packaging scenarios and any other number of things. If you can’t look at your code and see a coherent structure without any of the pseudo controllers or other framework entry points, then you have been suckered by the framework loan shark and will be paying the cost with interest in the future. Especially when trying to move onto the latest UI craze. The obvious case study for this is Angular and the complete disparity between AngularJS and Angular 2+. AngularJS is only around still today because people became so tied into the mechanisms of that particular framework they couldn’t escape when 2+ came around.

So, what to do?

The majority of any JavaScript/Typescript functionality should be in it’s own domain, and not that of the framework. Looking at creating some fancy dynamic interactive web app? Great! Three quarters of your code should easily be in your own namespace. Any actions and input required from users should then be wrapped up nicely by the framework and passed backwards for your own proprietary code to handle.

Structuring your code in this way will take a bit more leg work up front. However, this will pay it self off many times over in the future. Moving between different front end frameworks will be a breeze, and your core code will still be valid many years down the line.

Time to stop remaking the wheel

The crazy thing is, nothing here is new. This has been common in server side architecture for a while now, and before that for hundreds of years in manufacturing. However programmers have this odd superstition that old practices just won’t work for them. Turns out they do! Now more and more architecture patterns are being taken from more mature industries. It’s time we caught on. Software UI is no different from any other type of engineering and we should make use of what our forebears have already found out the hard way.