Blog Discussion: What's the best modern JavaScript jQuery replacement?

Thank you, Sean, for this article—it really resonates with me! I spend a lot of time writing both client- and server-side JavaScript, so if I may, I’d like to share my perspective on removing jQuery from XbyK and its potential successors.

In the XbyK context, I see jQuery as an unnecessary, render-blocking dependency that only serves to hurt the LCP web vitals metric on live sites. Removing it is definitely a welcome improvement!

When it comes to replacing jQuery, I’m all for using vanilla JavaScript (and CSS). jQuery originally added syntax sugar for easier developer experience (DX) and helped address the lack of standardization across web browsers, which was a bit of a wild west back then. But the languages and browsers have matured so much now that jQuery feels mostly irrelevant. For those who still want that "syntax sugar" feel, Umbrella JS is a nice, lightweight alternative.

Frameworks like React, Svelte, and Vue.js, on the other hand, address different challenges—such as state management, reactivity, and templating—that neither jQuery nor vanilla JavaScript fully solve. Personally, I’d avoid using these in XbyK, as they’re generally better suited for web applications rather than websites.

In server-side frameworks like Next.js, SvelteKit, or Nuxt.js, I could only see these being used alongside an XbyK Headless channel serving data.

Then there are libraries like Unpoly, Swup, HTMX, and Alpine.js, which focus on specific interactive or visual functions, similar to how jQuery plugins once did. Some also bridge elements of state management, reactivity, and templating. For XbyK, these could be useful if you need to add a high level of interactivity. However, it’s important to choose wisely, considering factors like feature set, size, and ongoing support.

As for your question on priorities, I’d always put visitor experience first—making websites fast to load and accessible. When developing sites in XbyK, I’d lean on vanilla JavaScript as much as possible, adding external dependencies only when truly necessary.

I'm glad you found the post valuable. I pushed back on my instinct to fill the post with a bunch of example code, which took effort 😅. I hope that if developers are unfamiliar with all the approaches and technologies I mentioned they can research them further and maybe share their thoughts here like you have.

Question: when you use vanilla JavaScript do you ever use any non-rendering libraries? Small tools, or utilities - like day.js or web components?

As for your question on priorities, I’d always put visitor experience first

Great perspective!

When it comes to Web Components, I gave them a shot in the past but found the experience a bit cumbersome. Since then, I haven’t really thought about using them again—but maybe it’s time I revisit them.

As for the day.js library—this one is fantastic! It’s a utility library that makes working with the native Date API actually manageable for real-world use. If your site deals heavily with dates, I’d definitely recommend giving day.js a go.

Another example of area where vanilla JS isn’t exactly developer-friendly is handling cookies. That’s where a utility library like js-cookie can save the day.

The reason for using utility libraries is simple: you’d probably end up writing most of the methods they offer yourself. So, it just makes sense to use something that’s already built and tested.

What are your thoughts on using blazor for some of this?

Good question Chris!

Blazor

Blazor is a very interesting technology that will help ASP.NET Core continue to evolve and help .NET developers build and scale experiences on the web. It is likely the future of HTML rendering in the context of ASP.NET Core.

One of the biggest challenges with Blazor today is the winding road it took to get where it is now - offering a lot of features in a confusing package with leaky abstractions. This is most obviously seen in its different hosting models for ASP.NET Core (nevermind the desktop app options available for Blazor).

If you are building a web experience that would be well suited for a single-page application (SPA) approach with React/Vue/Svelte/Angular because it's highly interactive with lots of state management, then Blazor WebAssembly could help a team that is experienced in .NET/C# avoid having to learn a JavaScript framework - though they'd still have to learn Blazor WebAssembly, which is a deep topic in itself. They also would likely still have to use some JavaScript because it's a core web technology and almost impossible to avoid.

For experiences driven by a DXP like Xperience by Kentico, I think the best aligned option (in the near term) is using Razor components without the interactive Blazor infrastructure as a server-side rendering (SSR) solution.

But this also requires a deep understanding of how Razor components work because they use the same APIs when rendered statically on the server, interactive on server (via web sockets), or interactive on the client (via web assembly). This is the leaky abstraction. Razor components were initially designed for interactive UXs driven by a server or client .NET runtime. It just so happens that we can also use them for static HTML generation on the server.

Xperience

Now, what about Razor components combined with Xperience by Kentico? Well, Xperience is built on MVC (Controllers, Views, View Components and Tag Helpers) which means you can't easily combine its technology with Blazor/Razor components. You can render a Razor component inside a View component (ex: Page Builder widget), but you cannot render a View component (or Tag Helper) inside a Razor component. You also cannot route to a Razor component so you'll always have some MVC architecture (View and Layout) in your application even if you skip using the Page Builder.

This limitation means you can only use Razor components in specific situations while also requiring you configure your ASP.NET Core app to support them and train a team to know how and when to use them.

In the future (read: long-term future), Xperience will likely adopt Razor components as the primary rendering approach for website channels, they are not even supported yet - at least not today in Xperience v29.7.0.

Other thoughts

I personally would have loved to have seen a true component model for MVC but the closest we got was View Components and Tag Helpers and I can almost guarantee there will not be any more improvements to MVC rendering in future versions of ASP.NET Core.

Additional note: you'll see Razor components in Xperience "soon" 😉, just not in the context of websites (here's a hint).

I saw an article, 5 JavaScript Libraries You Should Say Goodbye to in 2025 which is very related to this posts's topic.

It's not surprising jQuery is mentioned as the #1 library in that article... but I found it reassuring that the article states many of the libraries in the list could be replaced by vanilla JavaScript because of how much the language and browsers have improved since these older libraries were created.