When we start our career as a developer, it’s quite common to learn how to work with abstractions, it makes our workflow smoother and can powerfully increase our learning curve. jQuery is a good example of that, it’s likely the first lib we, as a front end devs, have contact with.
Abstractions are fine, they help us improve our productivity. However, in often times, devs get stuck and dependant of these abstractions among the fundamentals regarding such technologies.
Hence the importance of thinking out of the abstractions’ universe, by doing so, you understand when to use or avoid them. If the only tool you own is a hammer, then all of the sudden everything else start to look a lot like a nail.
For example, many jQuery made animations could be easily achieved using pure and plain CSS.
By using Angular and similar frameworks, we end up following the same path. We usually think on how we can solve an issue using that specific technology rather than trying to understand how could we do the same thing without a particular framework in mind.
An example here is the angular.forEach function. We could easily use the Array.forEach, the JS native version, instead.
I know there are cases in which you need to iterate an object and not an array, but for that you could simply use Object.keys(Array).forEach, another native function. But it’s more comfortable to use Angular’s version, right?
We
don’t need to stop there, we also tend to use: factory, service, session, value, constant, dependency Injection, all
that coming directly from Angular. When we need to do a specific integration
such as a websocket service,
then we use modules like Angular
Socket IO instead of using socket.io-client.
When you look back, you notice your code is completely attached and dependant
of the framework.
One could argue it’s possible to have an independent app, and that those modules only deal with the Angular’s async nature. For example, by using constructors rather than factories, so on and so forth. However it implies on creating a numerous amount of workarounds throughout the code such as $scope.$apply to sync the digest cycle. Also, it wouldn’t be considered as the “Angular way”, and therefore, it’d be read as a bad practice.
I know I’m giving Angular a hard time; however, I’m doing this due to the fact it’s one of the most popular frameworks nowadays, thus it’s easier to explain how we can get dependant of a specific framework.
Having a framework that demands you to build your app following its “recipe” is bad. If tomorrow a new and better technology that could address a specific part of your application comes up, you probably won’t be able to use it due the limitations your initial framework imposes.
Angular isn’t the problem here, however, every framework that makes you work in a fixed way and to forcibly use the “whole package” coming with it can become a headache in the future.
Don’t miss the end of this analysis:
#2 – Separation of concerns(SoC)#3 – Has React and Redux helped me become a better dev?