This post was written for Xperience by Kentico v29.6.0. Please consult the documentation for any feature or API changes when using a different version. Be sure to check the System Requirements in the product documentation.

Thanks to Xperience by Kentico's October 2024 Refresh the famous (infamous?) JavaScript library jQuery is no longer required in Xperience website channel experiences.

If we decide to take advantage of this enhancement, it naturally leads us to the question, "What is the best modern JavaScript replacement for jQuery?"

Let's consider some options below!

Wait, why not jQuery?

jQuery was launched at version 1.0 in 2006. It was designed to solve browser compatibility issues in the JavaScript language and the APIs exposed by browser. You can argue that problem is gone or at least so irrelevant most developers don't think about it day-to-day. 2006 was almost 20 years ago, things have changed a lot since then.

This is largely because of browser and language standardization. JavaScript has matured as a language by leaps and bounds and browsers are extremely powerful.

It's also one of the main reasons developers look beyond jQuery these days - its features aren't worth the 29.7 kb a visitor pays to download it.

In the past, jQuery's large ecosystem of plugins was one of its main benefits, but now they're also large for the value they bring, often unmaintained, and require you to structure your HTML with specific CSS to get everything to work correctly.

jQuery code suffers from the lack of co-location (more on that later) and has a tendency to grow into spaghetti.

Keep it simple - Vanilla.js

Given the state of JavaScript today it's not surprising that many developers choose Vanilla.js as their path to working with JavaScript in the browser.

Vanilla.js isn't a library or framework - it's just a joke to highlight how much you can do with JavaScript by itself, without a framework like React or Svelte. It's also a convenient label for the features of JavaScript you get out-of-the-box with your browser.

We use some Vanilla.js in the Kentico Community Portal. Combine JavaScript modules with dynamic import and you can do some pretty cool stuff, all without any extra JavaScript libraries.

The benefit of Vanilla.js is it can potentially reduce your JS file download size and time significantly (the fastest websites typically have very little JavaScript) and it encourages developers to learn the foundations of the language and what the browser provides.

Several years ago, Netflix shared a case study where they replaced their React code with vanilla JavaScript on an important landing page. Their main motivation was improving the performance and overall experience of the page for visitors. This is worth consideration for those of us who spend most of our time as martech engineers.

Just because you don't use a front-end framework doesn't mean you need to give up the developer tools you've come to enjoy. The Kentico Community Portal uses a Vite.js integration for ASP.NET Core so we still get a great local development experience and bundling and optimization for deployments.

That said, at some point you might end up designing your own mini-framework to manage the complexity of execution order, components, and dependencies. If you find yourself in this situation it might make sense to reach for one of the most popular JavaScript frameworks!

Front-end frameworks - React, Vue, Svelte, Angular

Pick your poison (or your antidote), the JavaScript ecosystem is full of front-end frameworks with a variety of features, architectures, ecosystems, communities, tooling, and even documentation.

React, Vue.js, Svelte, and Angular are all very popular options in 2024.

FYI: In a past life I was a front-end application architect focusing on Angular, attended many Angular conferences, and even presented at one. I even still maintain a TypeScript utility library 😅.

These frameworks have matured since they first came on the scene and have also achieved mass adoption and mindshare in the front-end and general web development ecosystems.

The value they bring to web-based projects is their ability to help developers build faster. They help teams scale, managing the complexity of their project as it grows.

If you haven't explored any of them before, your choice largely depends on your personal preferences. Do you like augmenting your JavaScript with HTML? Choose React. Do you like augmenting your HTML with JavaScript? Choose Vue.js, Svelte, or Angular. They all take very similar approaches to component-oriented project architectures, managing state and calling APIs, and integrating into your existing ASP.NET Core Razor rendered HTML in an Xperience by Kentico website channel.

Some of your decision will also depend on other libraries or ecosystems you would like to rely on for your project. Most often, your choice should be influenced by how much the framework improves your whole team's ability to build and evolve your Xperience by Kentico project over time.

There's an argument to be made for selecting React because it's the front-end rendering technology used by Xperience's administration UI. This would reduce the number of technologies your team needs to learn even if the React components and related code you write for Xperience's administration will rarely benefit the React you write for customer-facing website channel experiences.

The drawbacks of client-rendered HTML

There's also an argument to be made for not using React...

The JavaScript frameworks mentioned above all have their own server-side rendering solutions.

But, none of these are designed to work with ASP.NET Core. They provide the best developer experience when they are responsible for and own the full web application stack.

There was React.NET, which some of you might be familiar, as a way to bring server-side rendering of React to ASP.NET Core but that project is no longer receiving updates now that React has evolved beyond being just a front-end component library.

These frameworks will render their HTML on the client-side, once all the JavaScript of the framework, any other libraries you include, and your application are parsed and executed by the browser. This could take awhile, especially on slower or congested mobile connections. While the browser waits, there's often nothing for the visitor to do or even see!

Even though these frameworks have a positive impact on developer productivity, they can have a negative impact on customer experience.

  • SEO - large amounts of client-side rendering typically has negative impacts on SEO
  • UX - client-side rendering can cause Layout Shift which makes websites less accessible and difficult to use
  • Speed - requiring lots of JavaScript for website experiences uses up your performance budget and can increase the challenges with SEO and UX
  • Accessibility - fast websites might not be accessible, but slow websites are definitely not accessible and regulation requiring accessibility could be at odds with client-side rendering. Achieving high accessibility might require more work with these frameworks.

Xperience by Kentico's use of React

Since Xperience by Kentico's administration UI is rendered client-side with React, are these also drawbacks for that scenario? Well, generally no. The use case of an administration UI is very different than a website for a large (often anonymous) audience using many device types and a wide spectrum of internet connection quality.

  • SEO - Xperience's administration requires a login and is not indexed by search engines, so SEO is not important.
  • UX - Layout shift can even be a problem in Xperience's administration, but it is more of an application than a website - it's an interactive UI. Users have expectations their actions will cause the UI to change. Xperience also uses animations to reduce the number of quick shifts of UI elements.
  • Speed - Xperience uses a loading screen to indicate that (among other things) JavaScript is being downloaded and executed. Once the UI is up and running the browser caches everything and only small bits of code are needed after that, making everything snappy.
  • Accessibility - by providing Xperience developers with a suite of React components they can use to build out administration UIs, Kentico can focus on accessibility and let you focus on features for your stakeholders. This works because marketers want the Xperience administration to have a consistent look and feel, while they want each of their website experiences to be unique for their brand, design, and messaging.

HTML first JavaScript - HTMX and Alpine.js

A third option is to try JavaScript libraries that augment the existing HTML generated by ASP.NET Core Razor from Xperience by Kentico's web page templates or Page Builder components.

These kinds of libraries are typically integrated into your HTML through custom attributes and other syntax that, in our case with Xperience by Kentico, is written directly in the Razor code.

With this approach you have all the benefits of server-rendered HTML - SEO, UX, performance, accessibility - and you can enhance your HTML to provide a more interactive UX without large frameworks.

Here are some libraries that follow this approach and their total download size in kilobytes.

I wrote a blog post about Kentico Xperience 13 and Alpine.js several years ago that is still very relevant today.

Another benefit of this kind of library with server-rendered HTML is co-location, which is technique of keeping related code and behavior organized in the same areas of a codebase.

With the libraries above you leverage most of their behavior by adding attributes to your HTML. You don't need to solve many of the problems inherit with jQuery.

  • Is there any JavaScript that depends on the HTML I'm editing?
  • Which HTML attributes are safe or unsafe to change? Classes, ids, custom attributes?
  • How can I find the JavaScript connected to some HTML in my codebase (and vice-versa)?
  • How do I communicate the connections between HTML and JavaScript to my team?

By adding JavaScript behaviors as custom attributes on HTML (and not CSS classes) you can safely modify that HTML without having to worry, "What might break if I make this change?" because these two parts of your application are co-located.

The Kentico Community Portal uses both Alpine.js and HTMX.

Speaking of co-location, developers also benefit from it when using utility CSS frameworks like Tailwind.

Wrap up

We only covered 3 options to replace jQuery in this post but there's plenty more and you can even mix and match to suite your needs.

What's your priority, developer experience or visitor experience? Do you need to scale to a large amount of complex JavaScript driven UX or are you focusing on enhancing your HTML with some interactive behavior?

Or... maybe you just stick with jQuery - if it's not broken why fix it? 😅