Tagged: frameworks

Published on:

Adactio: Journal—Dev perception

There’s so much in Jeremy’s post that I can relate to. If they weren’t that long, I would wear his closing remarks on a t-shirt.

When we’re evaluating technologies for appropriateness, I hope that we will do so through the lens of what’s best for users, not what we feel compelled to use based on a gnawing sense of irrelevancy driven by the perceived popularity of newer technologies.

Published on:

Framework considerations

I recently reviewed the performance of one of our clients’ websites. During its lifespan, a myriad of developers had contributed their code without any form version control.

One thing that struck me instantly was the heavy use of JavaScript and CSS frameworks. I counted a total of three framework integrations accompanied by several other scripts that seemed to be solely fulfilling just one purpose each. Even for an “organically grown” codebase this seemed a bit too much.

When it comes to frameworks of any kind, I think it’s worth considering that it comes at a cost. Not to sound old and grumpy but I still see especially young developers choosing their own convenience over the convenience of their users and disregarding the fact, that throwing another 100 KB JavaScript into the mix might actually do more harm than good in terms of performance (and therefore: user experience).

Don’t get me wrong: frameworks are great and they can make your life easier if they are considered well. Let’s say you’re building a web application and are planning to use all kinds of enhancements to make user input easier, i.e. date pickers, spinners, range sliders and so on, then sure, it might be worth considering a framework that can provide this kind of functionality for you.

But if you only want to attach an event listener to an element, then why bother including a JavaScript library to do what you could have done with just a few lines of JavaScript yourself?