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:
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.
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.
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.
And I have jQuery to thank for that. Or, well: ditching jQuery.
Do or do not…well, actually, there is try
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.
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.