How do you architect your project to cater to changes in frameworks and libraries?

For example, when react-router moved to v4, there was a significant paradigm shift in the way react-router worked. If your application was heavily invested in react-router, migrating to v4 was a painful experience.

PS - I don't mean to call out react-router here. I ❤️ v4 and the work that they are doing. Just highlighting a scenario that I've run into. 😄

There is an awesome service called libraries.io. First and foremost I use that to track changes in my dependencies.

When there is a minor or micro chance (second or third number in the version), the upgrade is straight forward, or at least it should be.

Major upgrades are a real PITA whatever you do, but if the developers are kind enough, they deprecate symbols on the way, and even add some of the new functions if possible. If I go through a major upgrade, I switch to the new version without a code change and run my tests. If you have a good test suite, you will see immediately where you need to change your code.

Your project's architecture has nothing to do with 3rd party major updates. v4 means 4.x.x, which means major version, which means a lot of breaking changes, which means there should be an upgrade guide. You also don't have to upgrade everything to latest version all the time, however, in ideal case, you should. That is part of the "maintenance".

Use decent IDE, tools, tests for refactoring

When new major release is available and I make a decision to upgrade, I just follow the guide, search for occurrences in codebase and do refactoring wherever needed and if you have problems here...

Stop writing code in Notepad and have some tests.

Fork or add additional layer when you change 3rd party code

Only if you want to use small own changes in the original 3rd party product, you either do a fork, or add additional abstraction layer between your main codebase and 3rd party product. In any decent framework you should be able to extend/inject/replace core components easily.

If you ever wondered how to pronounce software architecture, it is "changes af".

Easy, I don't use them. PARTICULARLY on the front-end. MORE so with HTML/CSS/JS where they are mind-numbingly idiotic halfwit garbage that no sane developer would use by choice; resulting in writing two to ten times the HTML needed to do the job, pissing on semantics, failing to maintain separation of presentation from content, and in general missing the entire POINT of HTML. Then people have the unmitigated gall to call more markup and specificity hell "easier"? BULLCOOKIES!

Server-side frameworks aren't much better; but then most of them rarely work on problems the way I think about solutions, so they are incompatible with my methodologies.

As I often say:

For people who know nothing about websites, BY people who know nothing about websites is NOT a plan for success.

Which even the bloody examples in the first few pages of react's tutorial quite clearly illustrates.

Though it's probably fine if you're the type vomiting up HTML with CtCR's of 10:1 (code to content ratio) instead of 2:1 or less thanks to endless pointless DIV for nothing, endless pointless classes for nothing, and a general ignorance of how to leverage CSS selectors and semantic markup properly.

You seem to have a very negative view on many aspects of the industry... and, unfortunately, I agree with you most of the time and feel that point-of-view is important and challenging. "Bad cops" exist for a reason.

All of these front-end frameworks take more to time to learn (properly) than it would just to build it yourself.

Bootstrap, Angular, etc. I don't like them at all and really feel bad for new developers who put all their effort into learning them for long-term use. By the time you learn half of the front-end frameworks - which always include stumbling upon several roadblocks that will need to be resolved - you would have probably been so much better of a developer if you had learned to do it from scratch. Some frameworks will even hit EoL, just as folks have become really good at avoiding those issues and teaching others how to as well. AngularJS is a great example of a horrible choice.

Fast, Inexpensive, Quality. Choose two.

Think of it as building a home. If you learn about materials you have an option of using - you won't ever decide to make the house out of cardboard. I feel we're at a critical stage of the industry, where garbage code is outnumbering the clean code - just for the sake of getting things out quicker.

Alongside a course for Angular, I purposely did the exact same thing they were teaching me... but, in vanilla. Guess what? My site not only performed better and didn't have as many dependencies, but everything I would write in vanilla js took at least twice as much time (if not more) to do in Angular - with zero cleanup even focused on in professional courses. The one that sticks out in my mind are event listeners that just keep going and going without any method of destroying them.

So, that's basically what we end up with these days... children who take all of their toys out to play, ignore 3/4s of them, and then never put them back into the toy chest.

For paradigm shifts, you really can not do much other than look out for breaking changes in the beta builds as Sebastian pointed out.

For libraries, I tend to create my own abstraction over them, so that whenever I call my own CustomRequestClass.get() from other part of the code, I don't have to bother about whether I'm using XMLHttpRequest or superagent. So if something is wrong in an internal library or need to use another for more features, I have to change it at one place.

I guess, always create a shell around the code you don't own.

I think this is a problem you have to deal with as a developer and this is not limited to the JS/Web world.

Golden rule here is: expected major problems on major releases.

Personally I always try to take with any Beta Phase on libraries I have on radar so breaking changes can come to surface as soon as possible. Also keep an eye on change logs on major releases is a good idea since at least on a slightly bigger framework they are usually well maintained.

Steven Ventimiglia The toybox analogy alone got you an upvote.

... and if I have a negative view of the industry, its' due to the overabundance of scammers, liars, and just plain incompetent fools who cannot grasp even the most basic concepts of the technology.

Made all the worse by many so called 'names' in the industry singing the praises of bad systems like second rate cultist spewing deception from the pulpit. Most of these "developer conferences" having been reduced to echo chambers of head-bobbers like a meeting of Heaven's Gate.

NONE of the people singing these praises or using these frameworks knowing enough about the underlying languages to even know if what they are using is ACTUALLY easier, or better, or gave them any real benefit; they just blindly parrot the same unfounded unbackable claims the marketing BS and cult has spoon-fed them like some sort of religious or political extremist.

Aka, the 7 classical propaganda techniques that have been used to spread bunko since Orruk first hollowed out a rock, pissed in it, mixed in some charcoal for colour, and sold it to Grok as hair tonic.

Thread

How do you architect your project to cater to changes in frameworks and libraries?

Responses(6)

Use decent IDE, tools, tests for refactoring

Fork or add additional layer when you change 3rd party code

Recent threads

Search Hashnode

How do you architect your project to cater to changes in frameworks and libraries?

Responses(6)

Use decent IDE, tools, tests for refactoring

Fork or add additional layer when you change 3rd party code

Recent threads