By Christian Heilmann CHAPTER 3to be; and the more code you write that does something in a short period of
time, the more awesome you get. This is not necessarily true.
Yes, typing less means we can do other things, but if it comes at the
cost of abstracting what we do into libraries and plugins it can get tricky.
What we never know on the Web is what our users do or have at their
disposal. So relying on an abstraction that we don’t control and whose pro-
cesses we don’t understand seems dangerous. We feel this already. A lot of
small solutions dependent on jQuery or other libraries perform incredibly
badly on mobile devices.
Impressive plugins that tell us they are only a few KB or take just three
lines of code to implement tend to end up sending a much larger number
of bytes to our users, wrapped up in many HTTP requests and adding to
the overall amount of JavaScript in our apps. It is not uncommon to see
people use several libraries at once because they like widgets built in each
of them. This is not the purpose of browser libraries. They should solve
problems and make our work easier, not harder. It is especially dangerous
when libraries stop being maintained or updated and turn out to cause
performance problems. Of course, a good build or deployment script deals
with these issues — yet another thing to learn and to maintain. Why add
more to undo what was done before, when we should avoid overloading
our solutions with small, seemingly useful helpers in the first place?
As shown earlier, using a bit more semantic HTML can trigger the ben-
efits of built-in browser functionality. The same applies to all of our code. It
is much more important to build a solid base into our products, an easy to
read and understandable core that can be added to. We do this by writing
clean, easy-to-understand code that has sensible variable and method
names that does one thing well. Not by writing abstraction APIs for others
to use to achieve a lot quickly without knowing what they’re doing and
hiding the complexities away from them.
The advocacy for short code is at times just an excuse to be lazy. This
can lead to ridiculous threads on forums and message boards where people
use and elements instead of with a sensible class name