Naming Things is Hard

Ascetic code

I posted some thoughts about using or not using jQuery today at the Oberlin Webteam blog. Pew pew! Hot button topic! Or at least it was a hot button topic? Maybe? I'm out of touch.

Anyway! This post (and the follow-up post which should come soon) inspired lots of offshoot thoughts that didn't fit into the main posts' narratives. Which I'm dumping out over here so I can be feel far less pressure to fussy-edity about them.

One thing I did want to get down quickly is that I'm in no way advocating for code asceticism when I say consider dropping what's arguably one of the most default chunks of code on the web. Simply put, not using a particular library hardly means not using any libraries at all.

It's a little bit complicated, and I don't have as many case studies under my belt as I'd like to have thought through all this in practice, but the route I'm charting out for myself is one in which I'm ultimately very selective and thoughtful about the code I apply to a project, particularly when it gets sent across the world to literally I don't know what kind of computing device. If I can accomplish a task in plain JavaScript, I'm going to aim for that. This benefits me by hopefully simplifying a codebase for future maintainability, and makes life better for the end user in that there's less code being delivered to their device so they can get my brilliant work sooner rather than later.

But the flip side of that is that some things just aren't worth the effort required to do it yourself. I'm thinking of things like complex animation libraries or asset preloaders, where it might make more sense just to drop in someone else's work and get on with the bigger picture. Even then, I think there's a certain responsibility to be had to carefully evaluate what's being pulled in and just how much of it's actually required for the given task. On smaller scales, I've happily stolen bits of code from libraries like Underscore and rolled them into my own projects without having fully grokked every line because they were the specific bits I needed to get the job done. 

I'm definitely not thinking about things like React or Angular, which I've yet to find the opportunity to play with.

All that said I'll also say I generally find it more fun to write my own code, when I can, not just because it helps me learn coding better, but because, at least ideally, I'm spending more time making and less time searching, less time looking at someone else's code, trying to make sense of it. I'm obviously trying to get better at reading code, and I'm going to be making an effort to integrate code reading and use of others' code in my own work more efficiently, but the bigger kicks for me right now seem to come from...typing my own code and seeing the magic happen off that.

tags

Home & About & Micro.blog & Feed (Atom)