Death to monolithic libraries

by Cedric Dugas on February 7, 2013

If you write code for the web you have dealt with them, gigantic libraries that does everything for you in one nice package. I’m not talking about utilities libs & frameworks like jQuery and backbone. I’m talking about Lightboxes, sliders, form validators, file uploaders, wysiwygs, and etc. They offer you tons of features, a big code base, a big following and well, they generally come with a ton of bugs too.

I find myself guilty of writing one of those too, my validation engine got from 400 to 2000+ LOC in 3 years. Adding features, one by one, it has becomes overweight, and it has becomes harder and harder to debug.

A long time ago..

Ask me 4 years ago if you should delve into doing a lightbox yourself and I would tell you that you are a fool. Ask me that now? My answer would be a lot more nuanced. Before integrating any 3rd party code I ask myself a couple of questions (roughly in that order):

  • Can I code it myself easily?
  • Do I have time?
  • What browsers is this supporting?
  • Number of open issues?
  • What’s the code size?
  • Do I trust this guy (or team)?

Sometimes I can’t code it myself, I would not code something like Highchart, so I need to use it (or some alternative) & sometimes I just do not have the time. But in my experience, big libraries call for trouble in the long term. You will hit bugs that you will have to deal with, and in that big codebase that’s probably not going to be easy.

How I came to this mentality

Over the years I used multiple big libraries, they all got 2 things in common (mostly), they have multiple bugs & they are hard to debug. Even if you get to debug it, you are now stuck with your version, forget about updates. You can if course create a pull request  to get your fix in, but in most “hobby” libs your pull request will sit there for a long time, and often be rejected for multiple reasons, then you have to make a better pull request or just abandon that.

You also have to consider that you get a lot of dead code, I never use the ajax functionality of my validation engine, but I got that code in every app I make.

An example?

First example, Colorbox, a jQuery plugin that do lightboxes in every ways imaginable. Well all those features have a cost, there is currently 128 open issues on github. Colorbox have 1000 loc & the thing is, a minimal lightbox script it’s about 100 loc. The one I coded for CakeMail does 130 and I’m not even trying to optimize the size, that include options, passing variables and integrating a templating engine. It’s consistent, it’s very small, and it’s easy to build upon if needed by anybody.

Obviously I don’t have all the features Colorbox have, but really, I do not need them.

Let’s take another example, chosen, a very known lib that change your select box into a more friendly usable box. If you go to the chosen github repo you will see that the project is very popular, but you will also see it got 2 versions, one using jQuery and an other using prototype. Most importantly there is about 300 issues and 50 pull requests pending. That’s certainly not extraordinary.

Even better, you can replicate some of chosen features like skinning the select using only some css tricks, and it’s valid up to ie7. Talk about performance enhancements.

An exception, the agency developer

Having work in multiple web agencies I can see how big libraries becomes handy. You work on multiple websites or apps at once, on tight budget & tight delays. Creating a ton of different products makes for a ton of requirements, and that’s where these libraries comes in, you don’t want to code yourself an image sliders in a lightbox, it’s much faster taking one that does everything for you and hope for the best.

Also theoretically, it  makes it easier on the long run for your team to collaborate always using and fixing the same plugins, even if there are big.

The Validation Engine future

Like I said, I am in this boat. I am currently looking at making a much, much lighter version of my validation engine, I want to get back to that swift and more manageable first version of 400 loc. I’m not saying I’m killing the big one of course, it’s just that I am currently lacking a light validator in my day to day work and I want it, badly.



5 comments

Speaking of client side validation, this form doesn’t have one :)

by Dave on February 21, 2013 at 9:53 am. Reply #

It’s a double edged sword. The more time you save by using something pre-baked, generally the more ‘at risk’ you are. I prefer coding everything from scratch (if the business logic is simple enough) because that way I hold %100 accountability. Nothing worse than getting a nasty email from a client and your truthful answer being something along the lines of: ‘oh, it’s the plugin’s fault…’

by Tyler on February 21, 2013 at 11:15 am. Reply #

I have a similar process when deciding on a library:

1. Is it hosted in a version controlled system?
1a. If so, is it active?
2. Is it well documented?
3. Do they depend on other popular frameworks (jQuery, etc)
4. Do they provide tests?

by Simon W. Jackson on February 21, 2013 at 11:43 am. Reply #

What do you mean? with : tight budget & tight delays
Do you have any range?

by Thomas on March 13, 2013 at 1:41 pm. Reply #

Nice post. I understand something far more challenging on distinctive blogs everyday. It will often be stimulating to read content from other writers and practice just a little something from their store. I’d prefer to use some with the content on my weblog regardless of whether you don’t mind. Natually I’ll provide you with a link on your internet weblog. Thanks for sharing.

christian louboutin outlets

by Whovalona on April 9, 2013 at 10:57 pm. Reply #

Leave your comment

Required.

Required. Not published.

If you have one.