Abstraction is a trade-off
Abstraction provides a way of enabling people to do things without needing to learn everything about a subject. The drawback is that it often removes flexibility and control from what is possible.
Generally speaking, the more flexible something is, the less abstracted it is. Whereas the more something is abstracted, the less flexible it is.
Abstraction makes things easier to use, so we could change this scale to be Ease of use instead.
Things tend to become more difficult when there is little abstraction.
Here are a few examples of web developer choices where abstraction plays a key role.
Content Management System (CMS)
CMSs often implement a lot of abstraction, such as preventing you from making the text a random colour. The idea is that it prevents users from making mistakes, as that colour choice might not be on brand or accessible.
Giving the user fewer options also makes the system easier to use, trading flexibility or control for ease of use.
When making a CMS more flexible, you make it more difficult to use and increase the barrier to entry.
Website builder
Website builders give little abstraction, providing more flexibility and control over the content and how it is displayed.
The drawback is the same as the advantage – providing that level of control to users who shouldn’t have it can create an inconsistent, messy website. A user can do more things, but they might not be correct.
This is why website builders are more suited to freelance designers than editors or web developers. They allow enough abstraction from code for a designer to create a website.
The drawback is they rarely produce good quality code, and most clients will find them difficult to use due to the higher barrier to entry.
For a web developer, it’s frustrating to use as the abstraction gets in the way.
For editors, you either have too much free reign over the design and content or too little control that you can’t do what you want.
JavaScript packages
Web developers have the choice between using a framework-specific package or a more generalised core package.
The framework-specific package will make integrating easier, but the trade-off might be bugs, less support, relying on the developer to keep it in sync with the core package, or time wasted reading both documentations – one for the original core package and the other for the framework-specific package. Is it worth it?
I often find using core libraries to be a safer bet, even though they are more difficult to integrate.
Balance
It’s important to find a balance between abstraction, control and flexibility. Unfortunately, the answer for where on the scale you should be is, as always, it depends on the context.
Only you will know how much abstraction to apply. Be sure to consider the trade-offs.