This article first appeared in issue 239 of .net magazine – the world's best-selling magazine for web designers and developers.
The popularity of JavaScript has grown over the past few years. Dozens of libraries have been created. Yet there’s one that fuels controversial opinion: from its dedicated lovers to haters (who question the programming abilities of anyone who uses this library), yes, we’re talking about jQuery.
A designer’s story
When I started my career, it became obvious that frontend development skills are essential; I needed to be able to code my own designs or at least have a good understanding of markup to create easy-to-implement interfaces.
Photoshop is a key tool for most designers. But the nature of this gigantic piece of software is very different from development environments. You’re not able to debug anything and you (probably) don’t have any idea how it works. It’s a black box compared to the open nature of the web and software.
Along with the ease of reading code, which came with GitHub, came problems. We failed to take advantage of so many codebases being available to learn from. We took it for granted and assumed that things just magically work rather than caring about how. It all comes down to two types of developers, or people in general, actually.
Operator vs engineer
An operator knows how to use a tool without understanding how it works. On the other hand an engineer has full awareness of the code so he can modify and adjust it to his needs. This leads to the question: how many of you have read jQuery’s codebase? My guess would be not many. How many of you read the codebase of any library you’re using? So many developers wave the flag of ‘RTFM’ (Read The Fucking Manual) while they should be encouraging ‘RTFC’ (Read The Fucking Code).
The web gives an insane amount of freedom to complainers and people saying bad things about software. These opinions don’t belong to code-aware programmers, but lazy ones who are judging things they don’t necessarily know or understand.
Libraries usually try to solve a broad spectrum of problems, which alters the level of complexity. While developing, we should strive for simplicity, preventing unnecessary complication and increased cognitive load. But sometimes the tools we use can be over engineered, bloated or poorly written. For some cases, microframeworks are the most reasonable approach; they’re more lightweight, modular, address specific issues and are easier to understand because of smaller codebase. What’s the root problem of jQuery (and other JavaScript libraries) then? Are they really poor quality and should we write our own? Well, no.
jQuery is good
For certain purposes (and use cases), when used by a seasoned programmer, it is redundant. There are exceptions to the rule though. The long-awaited parent selector is still unavailable in CSS. While stylesheets give us native execution, which is faster due to hardware acceleration and interpretation mechanisms, they introduce degradation and cross-browser issues. There are multiple arguments and cases for and against jQuery, but that’s not the point. The point is: how we can improve as developers.
Be a better developer
There’s no single, valid and best approach, but this consideration may help write and maintain libraries.
First, remember the separation of concerns. Manage the independent nature of functionalities while making them work together. Maintain readability and accessibility. Design for connection and consider the idea of piping from Unix systems. Bear in mind that most libraries and tools were never designed to work together, so prevent conflicts. Simplify debugging and use common approaches.
Don’t disapprove solutions just because you don’t know them or that’s a hyped opinion. Explore options. Read the code. Know the tools. Be better.
Discover 40 top examples of JavaScript at our sister site, Creative Bloq.
