Ernie Miller started a tweetstorm on Friday that really rang true to me, about how certain abstractions are “dishonest”. In my mind, the dishonesty is calling them abstractions in the first place.
I've been thinking a lot about honesty in software development lately. Not just honesty from people, but from technology.— Ernie Miller (@erniemiller) February 19, 2016
I think this general sense of honesty is at the core of my feelings about, e.g., HAML/SASS/CoffeeScript vs ERB/SCSS/ES2015.— Ernie Miller (@erniemiller) February 19, 2016
I had embraced them for their aesthetic appeal, but realized that I was really running from the technology I perceived them to replace.— Ernie Miller (@erniemiller) February 19, 2016
These tweets really spoke to me, but I don’t think abstractions are “lies” per se. Rather, I feel that the technologies listed (and others like them) are just really weak. They don’t deliver complete solutions to the problems they are there to solve and are built on poor (or no) abstractions, such that they require more of the user than they ultimately give.
In a sense, HAML, SASS, CoffeeScript, etc. are nothing more than sophisticated
sed scripts (or macro languages). But this problem isn’t specific to
front-end technologies. AREL and Rails Migrations are two back-end examples. They profess to “save you” from SQL, but you really can’t use them without
understanding SQL, you can’t access the full power of your database with them, and you can’t debug what they are doing without knowing SQL.
Compare this to writing C. Do you need to know assembly language to write C? For almost all cases, the answer is “no”. Sure, there may be cases where you have to dig into the assembly to figure out a problem, but these are vanishingly small.
The scare quotes are intentional: to call HAML, CoffeeScript, and friends “abstractions” is to almost render the term meaningless. They don’t abstract anything away from you on any real level.
These tools don’t meet any higher-order need a developer has. They provide the ability to execute code only and when compared to the technologies they replace, they appeal more to aesthetics than the ability to better deliver quality software.
Web front-end technologies seem woefully stuck in this quagmire. React gives you the ability to type markup that looks like a higher-order abstraction, but it’s still just a macro language for producing HTML that you must debug directly. Yes, source maps and other browser extensions exist to make this less painful, but your job at the end of the day is still trying to figure out what events are firing on what DOM elements, and how CSS is being applied to them.