Pushing forward; pushing back

Lately, I’ve been trying to push forward with best practices for our library webpage. This has meant moving toward Vue and moving away from jQuery. The result is a more modern site. While a lot of the changes that I’ve made recently have been invisible to the end user, there has been a lot of progress behind the scenes on modernizing our code.

But I’m also pushing back. I know we can’t get into a situation where the site is unmaintainable by another librarian, so I’ve been trying to reduce complexity. Pushing back against complexity is necessary in the face of the (seemingly inevitable?) complexity of many JavaScript frameworks.

Pushing back can be strategic: we can pick the parts of a framework that help us and discard the ones that just make things unweildly. There’s no need for an “all in” mentality on a framework; a selective approach is likely more suitable for a small department like ours.

Posted in javascript, vue | Leave a comment

In praise of Single File Components

One of the recommended ways to organize Vue code is to use Single File Components, and I have to say, they are wonderful. Instead of the traditional separation of concerns into HTML, CSS and JS, Single File Components allow you to separate your project into chunks that are intuitive to you. You get to decide what you want to make into a “component”. The component is written as a single file with a “.vue” extension and all of the relevant bits get included. As a bonus, you get scope for the component, which you did not get when everything was dumped into the global namespace.

My hope is that using SFCs will also improve the maintainability of our library website. I am hoping that a librarian who is new to our codebase will more easily be able to make edits, because they can focus on a specific component that they want to modify, and they will not have to worry about what is going on with the rest of the page. SFCs provide a more modular approach, which I think is valuable.

So now I’m in the process of breaking down our page into SFCs. This will be fairly easy to do for the JavaScript, because there is not too much of it, but a bit more onerous for the CSS. The benefits of scoped CSS are obvious, however, and I am committed to getting us there.

Posted in vue | Leave a comment

Up to date

There is more than one way to simplify code. You could, for example, adopt new abstractions that make things that were previously difficult, easier to implement. Of course this requires learning new things, and it requires pushing yourself a bit to adapt.

Or you could stay simple by not adapting. By using the same tools we’ve always used, you could reduce the amount of mental effort you need to put into a new project. This is simplicity of a sort, too.[1]

The dilemma is salient for librarians. Do we use the old ways, so that more or less anyone in the department can maintain our web stuff, or do we try to stay up to speed with modern tooling, which many librarians will not touch? Both of these approaches have risks. Life will obviously not stand still, but we need to decide if, as a department, we’re going to keep up with the leading edge or the trailing edge of web technologies.

Anyhow, these problems raise important questions. I don’t have the answers. I do have my opinions, but I am very cognizant that not everyone will agree with me.

[1] There are probably other ways to simplify programming, but I’ll leave those aside for now.

Posted in libraries | Leave a comment

May is Library Infrastructure Month

In advance of a very busy summer, I have some free time right now to focus on the library website. So I decided that May is Library Infrastructure Month, and I have been going about on Mastodon pretending like this is actually a thing.

It’s not entirely a joke. Academic libraries are very infrastructural projects. Academic librarians make sure that students, faculty and others get the building blocks they need for their academic endeavors. But academic libraries aren’t usually thought of as infrastructure, except in the frustratingly old-timey way that a library is seen as a building to hold books. But library websites are infrastructure, discovery services are infrastructure, ILL is infrastructure, metadata is infrastructure, etc.

Those who build this infrastructure know that their work is foundational, but much of it goes mostly unseen by the academic community. Let’s add a bit of visibility this year by celebrating Library Infrastructure Month this May.

Posted in infrastructure, libraries | Leave a comment

I successfully did a JavaScript build!

For a long time, I’ve been intimidated by JavaScript builds. They have a reputation for being complicated, difficult to understand, and unforgiving. This tracks with my past experiences. I have been burned before, so my approach has been to avoid builds, and just use script tags like it is 2005. Yes, it is possible to do this.

A blog post by Julia Evans offered a way forward. She describes her experiences with a simpler build tool called esbuild. Following Julia’s lead, I gave esbuild a try with some Kingsborough Library Vue code. It really opened up a lot more doors than I expected. Helpfully, using a build for Vue allowed me to take advantage of Vue’s single-file component system. The result was that I could make my code more modular, and access nice features like scoped CSS. Most importantly, the build itself just worked! No impenetrable errors, no mysterious behaviors. It behaved as expected. This is a low bar, but I was thrilled.

I don’t think I trust esbuild enough to use it on the production library homepage yet, but I will keep experimenting with it. So far it is promising.

Posted in javascript | Leave a comment

A tentative use case for machine learning in academic libraries

Being a subject selector in an academic library is pretty repetitive. I’m basically applying the same selection criteria to different materials over and over again. In my specific role, I’m almost always looking for books (and ebooks) that are for lower-division undergraduates/general readers; that are from reputable academic presses; and that fall within the subject in question. I have some other more subtle requirements that I won’t attempt to explain here, but the point is that I’m applying these same criteria every single time.

Perhaps we could train a machine learning model to do this work. If it watched me select books long enough, I bet such a model could even pick up on the finer nuances by which I’m choosing titles. It could then probably do a great job of applying those criteria. The relatively constrained nature of the problem might make this a feasible problem to solve.

Librarians would probably want to train the model with their own preferences for their subject areas. A human-in-the-loop approach might be sensible. Maybe the team at ProQuest’s Oasis (for example) would be willing to build us such a feature?

Posted in acquisitions, ai | 1 Response


I’m really taking my time writing some JavaScript for our library homepage. The current code (that I want to replace) is working fine, but that’s not the reason I’m dawdling.

I’m going slowly because I want JavaScript to move more slowly. In my opinion, the whole language can just slow down. I know that’s an absurdly Quixotic idea, considering how fast the JS ecosystem churns through ideas and code. But if open source has taught me one thing, it’s that you make your code how you want it, and others can take it or leave it. A very important part of open source is having code that meets our needs. If I want slow JavaScript, I’ll make it slow, damnit. (I know there are very real practical problems with this, such as ending up with codebases that are no longer supported, etc., but I’ll do my best!)

I guarantee that I’m not the only one who wants this. If enough people want a slower moving JavaScript, it can happen.

Posted in javascript, open source | Leave a comment


I’m currently reading a book by Kyran Dale called Data Visualization with Python and JavaScript, and it’s super interesting. In my experience, it’s very unusual to find a fully bilingual programming book. This is a great example. Most technical books, for better or worse, focus exclusively on one programming language.

I’m still in the early pages, but I find the comparisons of Python and JavaScript really interesting. This is stuff I mostly know, but for some reason it’s fascinating to see it spelled out systematically and comparatively.

The tools described in this book are also very interesting to me. Long-time readers of this blog probably know that I have an ongoing interest in data visualization in both Python and JavaScript. I think this book hits the sweet spot between “stuff I already know” and “stuff I still need to learn”; it’s at the right place in the learning curve to be very constructive for me.

Anyhow, the second edition of the book is very new, so it’s (pretty close to) the latest info! Highly recommend.

Posted in books, javascript, learning, python | Leave a comment

Code4Lib 2023

Code4Lib 2023 wrapped up today. I attended in person this year, as it was nearby, in Princeton, New Jersey. As always, it was really great. One of my favorite things about this conference is that I always go home feeling a lot more optimistic about my profession.

I was happy about the large number of newcomers at the conference this year. Having new faces in the room is really important for maintaining the vibrancy this community.

Also, I’m (finally) starting to feel like less of an outsider at Code4Lib. I’ve attended 4 conferences; presented at one of them; participated in the Slack; wrote an article for the journal; and even recently became an editor of the journal. You’d think I’d feel at home by now, but it has taken a long time. Maybe what has happened is that the importance of the social connections I’ve made are finally starting to overcome the impostor syndrome I started with.

Posted in code4lib, conference, imposter syndrome | Leave a comment

Modern JavaScript on campus

JavaScript has changed a lot over the years. Old browsers are not equipped to handle new syntax. ES6 (in 2015) was a major change. That was a long time ago. But unfortunately, on our campus, we still have browsers deployed in labs that predate ES6.

Why is this? My guess is that old system images still get installed, without much consideration of the browser versions. And for some reason, the browsers are not permitted to auto-update. Why this is the case is mystifying to me, but I assume there are reasons.

This makes it hard on people building websites for our campus community. You can’t use modern JavaScript and expect it to work everywhere on campus. You can write old-timey JavaScript if you like, but this can be annoying to manage and maintain. There are very good reasons why we moved on from those old JavaScript ways.

Maybe you could write conditional code that accommodates old and new JS. This is possible, but becomes complicated quickly. Or you can lobby for newer browsers — this is probably the best solution — but you may face intractable campus politics, which can be very quickly dispiriting. At this juncture, on our campus, it seems like a hard problem to solve.

Posted in javascript | Comments closed
Need help with the Commons? Visit our
help page
Send us a message
Skip to toolbar