jQuery/n

Many people in positions like mine, I suspect, travel through a specific arc, over the course of their career or across various challenging projects, when it comes to how they learn tools or concepts related to their work; programming languages, design thinking, creative techniques, you name it. In my mind, it looks something like this:

  1. Start with a straight-forward, limited understanding of capabilities. Generate effective but simple solutions to basic challenges. Wonder about the benefits of more complex or advanced approaches.

  2. Begin developing a more extensive understanding of what’s possible and how to achieve it. Create more complex, complicated solutions to advanced challenges—or basic challenges. Wonder about the benefits of more simple approaches.

  3. Recognize futility of achieving true mastery—and then continue seeking it anyway. Find the elegant balance between efficiency and scope, simplicity and complexity. Wonder what new fields might be worth playing in, to get back to the heady growth of stages one and two.

This isn’t set in stone, obviously, but, for me, thinking in these terms has helped me understand how I’ve approached advancing my knowledge and use of JavaScript—where I’ve spent the last year or so happily pinballing between the stages one and two.

And I have jQuery to thank for that. Or, well: ditching jQuery.

Do or do not…well, actually, there is try

For those who don’t know: jQuery is a library of JavaScript code that intends to help developers simplify or streamline the coding process. For many reasons, lots of people have written about how front-end developers should not use jQuery.

This post is not a “you should not use jQuery” post; rather, it’s a “Use jQuery. Or don’t use jQuery. Maybe, try both?” post.

jQuery is good. It’s a tool; it helps people get work done; it has a long, storied history; lots of smart people have looked at it and fixed it and made it better; it solves problems; there’s a rich ecosystem around it; it will, I suspect, outlive most blog posts about using it or not using it. One of these days I’m going to print out a copy of jQuery and I’m going to sit down with a couple pots of coffee and I’m going to read that thing line by line. It’s going to be a hard-rockin’ Friday night in Fun Town.

That said, while I’ve used jQuery in the past, we broke up last year. Lea Verou’s “jQuery Considered Harmful” post helped nudge me into a nerd spirit quest to better learn JavaScript. (Her title is a bit tongue-in-cheek. I think. Sort of? People sure do have strong opinions on the internet, huh?) Reading through that post, and some of the related resources, kind of got me wondering what, exactly, jQuery was doing for me that I couldn’t do for myself, using plain JavaScript. I mean, what I could do, if I actually, like, understood plain JavaScript. Could I do things faster or more flexibly? Would it open up new ideas or approaches? Would I stand a better chance at customizing or understanding other people’s code? Would I fall on my face? (Yes. Yes. Maybe. No, but there’s still time.)

Taking stock today, I can say that the experience has been fascinating. In creating the new winter term inspiration page, I was able to pull off some cool tricks behind the SVG-based map. I’ve got some projects and experiments on the burners that have me deep in stage two of that arc above; I’m realizing that some of my methods are more complex than they strictly need to be, as I try putting what I’m learning to work—and, unwrapping the complexity in favor of simplicity is a useful education in broadening my knowledge about how to do things with a deeper understanding of when to do things.

To put this another way: for me, when it comes to code, I recognized that I have a tendency to rush past understanding to start making. Realizing that helped me better understand why things often felt so frustrating. That, in turn, lead me to want to better engage with fundamentals. To do that, I needed to sidestep the shortcuts provided by jQuery and actually think about, like, actually reading the manual. I’m finding the benefits worth the time and effort, even though it feels like the metaphorical manual grows fatter with every page I read.

Me and jQuery: together, again, someday

For many reasons, I’m sure, we’ll get back together, jQuery and I. It feels kind of inevitable. We had some good times together! Me, over here, clueless—and clueless about my cluelessness; jQuery, over there, helping make everything just a bit smoother. And though we’ve separated, when we do drift (or collide) back together, I anticipate I’ll get it better, and will have better luck really knowing what it’s doing, and exactly how to make it do what I need it to do, and what it’s doing for me that I don’t want to do myself, and when I can happily tell it to get out of my way, I got this.

Like I said above, this isn’t a don’t use jQuery post. It’s a post about how you can, if you want, think about not using it. Depending on your needs, and your time and energy levels, there may be benefit in trying to not use it.

Add Your Comments

You must be logged in to comment.