I don’t know how many times I’ve created an accordion in the last 20 years.
My first accordions used <div>-tags and were JavaScript-based. Later, they were based on the “checkbox-hack”. Then came HTML5 and the <details>-element, and the only JavaScript needed was to poly-fill the browsers which didn’t support that element.
Later I added structured markup (schema.org) for SEO-purposes — and my latest accordion added JavaScript for animating the <details>-element. A future accordion will possibly remove that again. But for now, I have the perfect accordion — at least my version of a perfect accordion!
It’ a “three-stage rocket” that:
- Looks OK and works with HTML only.
- Looks even greater and has a
height-transition, when CSS is enabled. - Has a smooth
height-animation, when JavaScript is enabled.
The UX and Design is based on research by the Nielsen/Norman Group. They always seem to have extensive, thorough research and user-feedback for the most popular web components.
Hence, it’s my default “goto”-place, before I develop any UI-component.
Future-proof?
So is that the end of it? Do I finally have an accordion, I can just copy/paste to future projects?
No. That’s not the end of it. Because even if I have the “final” HTML, CSS and JavaScript for that “perfect” accordion, the strange part of being a frontend developer, is that architectural decisions require me to use:
- Something else than JavaScript to output JavaScript (TypeScript)
- Something else than CSS to output CSS (Sass)
- Something else than HTML to output HTML (Pug)
In other words: I need to rewrite the code for all three languages to something else, that then compiles to something similar to the original code.
If a project uses a JavaScript-framework, which is more than likely, I need to re-write the code, so it fits that framework. And if I’m already using a framework, maybe Vue 2.x, should I then switch to the newer Vue 3.x? And if so, should I go for the “composition api”, or … ? Et cetera.
I can completely understand the frustrated project manager who doesn’t understand why it requires development time to develop something that has been developed so many times before.
And it’s not only frontend development time. It’s UX. Design. Backend. Meetings.
Even though the research has been done, and everybody agrees on how an accordion should look and function, there will be new iterations of that “final” accordion.
But here’s the thing:
The user of the website does NOT care how that accordion was made
In fact, the 20-year old, first version of my accordion, would be just fine for the user.
In many cases, it would be good enough for the client as well (if they don’t care much about SEO).
I wouldn’t be happy about it. In fact, I’d argue for a long time about semantic markup, accessibility, SEO and other stuff, trying to convince the client to chose the latest version.
But should the client pay for my happiness and a new accordion, if the old one works?
The Latest And The Greatest
When two frontend developers meet, they rarely have conversations about the stability, accessibility and user-friendliness of the sites, they’ve created. Instead, it’s:
— “Have you used framework X?”
— “Did you try build-tool Y?”
— “Everyone’s crazy about tool Z”
Web-architecture change all the time — for both backend and frontend.
But is it always necessary?
And, more importantly … is it driven by developers longing for change and using the latest technology, or by client needs?
There’s a huge cost involved in learning a new framework and re-writing an existing code-base.
What’s the cost-justification? By which parameters do we measure and justify that cost?
Typically, it’s:
- [easier] Maintenance
- Future-proof
- Scalable
But if we constantly need to re-write the code-base because there’s a new, smarter version of a popular framework, have we gained anything?
All developers should read this eye-opening article by Lea Verou. Lea has looked at the numbers, and in contrast to how the modern developer thinks the web-landscape looks, the web is built on stable, old tech.
Does that mean we should stick with the old? No, of course not. But maybe we shouldn’t always focus on the latest and the greatest, just because it’s new. Maybe we should focus on what we already have and try to make it better.
Or really measure the pros and cons when we decide to create yet another … accordion!
Thanks for reading!
NB! Kyle Simpson has written an article about Change vs. Inertia; maybe we’re slowly reaching a point, where inertia will triumph — at least until someone dares to challenge it.
Top comments (0)