Knockout and jQuery front ends
We work on large front ends built between 2010 and 2016, making them stable enough to change with confidence and replacing them screen by screen where that pays.
What you probably want to know first
- Can you support our existing application?
- Yes, provided you hold the source code or can obtain it. Knockout and jQuery are still maintained, so nothing forces you off them. Support is harder where the front end has no tests and no build step, because every change is checked by hand, and where leaks and race conditions make faults hard to reproduce.
- What happens in the first assessment?
- A short call, then read access to the code and, where possible, the hosting environment and database. We build the application, run automated analysis and read by hand the parts that matter. You get a written report and a walk-through call. Where the back end is .NET Framework, the fixed-price .NET upgrade assessment covers that side.
- What access do you need?
- Read access to the source code and, where possible, read-only access to the hosting environment and the database. Nothing changes on the live system: we work from a copy of the code, and where we look at production it is with read-only access. A confidentiality agreement can be signed before anything is shared.
- What sets the cost and the timescale?
- The size of the code base and the number of separate applications, whether we can see the hosting and database as well as the code, unusual or mixed technology, and whether there are tests. Stabilising is sized by what the measurements show. Replacing screens is sized by how many you choose to replace, and there is no need to finish.
- What have you done with systems like ours?
- We have worked mostly on the Microsoft stack since 2012, and most of the systems we maintain were built by someone else. The Logtek case study describes taking over a custom asset management application, moving it to the cloud and maintaining and extending it since. The rest of our case studies are on the site.
Front ends from before the current frameworks
Between about 2010 and 2016, before React, Angular and Vue became the usual choices, rich web applications were assembled from separate libraries. jQuery handled the page and the AJAX calls. Knockout bound data to the screen through observables. RequireJS loaded the modules. A commercial suite such as Kendo UI supplied the grids, schedulers and pop-up windows.
Applications built this way can be very large, and many are the main interface to a business system. None of this is out of support: Knockout and jQuery are still maintained open-source projects. The problem is the state the applications have reached after ten or more years of changes.
What tends to go wrong
- Memory leaks. A view model that subscribes to an observable, a message bus or a document-level jQuery event, and never unsubscribes, stays in memory after the user leaves the screen. Widgets that are never destroyed do the same. The application slows as the day goes on.
- No build step. Files are served to the browser as they were written. Nothing checks the code first, so a mistyped property name is found by a user.
- No tests. Logic sits in view models that run to thousands of lines with no automated tests, so every change is checked by hand, if at all.
- Race conditions. Data arrives, widgets initialise and bindings apply in an order that depends on network timing. A dropdown bound before its data has loaded works on the developer’s machine and fails for some users.
- Slow first load. Without bundling, the browser requests modules file by file.
- Hard to hire for. Few developers now choose to work with these libraries.
Your options
Stabilise. Add browser tests around the main workflows, find and fix the leaks, remove the race conditions, and introduce a build step with linting and bundling. This is often enough. The application stays on the same libraries but becomes predictable to change.
Replace screen by screen. Screens that change often, or that users find hardest, are rebuilt in a modern framework and call the same server API. Old and new sit side by side behind one sign-in. There is no need to finish: screens that are stable and rarely touched can stay.
Keep the admin screens and build user-facing screens fresh. Many systems have a complex administration side used by a few staff and a simpler side used by many customers or members. The admin side stays, stabilised. A new, lighter application that works on phones is built for everyone else, against the same API.
How we approach it
We measure before we change anything. Error logs show which faults users actually hit. Memory is recorded over a long session to find the screens that leak. Usage figures show which screens matter. That evidence, more than anyone’s opinion of the code, decides what to fix and what to replace.
Tests come next, because without them neither stabilising nor replacing is safe. Leaks are then fixed by giving every screen one consistent way to dispose of its subscriptions, handlers and widgets when the user leaves it, which is more reliable than chasing them individually.
Where screens are replaced, the first step is a clean boundary: a server API both front ends can call, and shared sign-in. That is the staged method we describe under legacy software modernisation. If the stabilised application then needs ongoing care, that is software maintenance. For front ends on a framework that really is out of support, see AngularJS, and for other causes of a sluggish system, see slow software.
Talk to us
Describe the system and what you need. You will hear back from someone who can answer technical questions.
Discuss your Knockout front end 0800 433 7990What we do with Knockout and jQuery front ends
- Find and fix memory leaks
- Subscriptions, event handlers and widgets that are never released are tracked down and disposed of properly.
- Add tests around key screens
- Browser tests cover the workflows the business depends on, and unit tests cover the logic in view models.
- Introduce a build step
- Linting, bundling and minification, so that mistakes are caught before release and pages load fewer files.
- Fix race conditions
- Screens that fail now and then because data, widgets and bindings load in an unpredictable order are made to load in a fixed one.
- Replace screen by screen
- New screens are built in a current framework against the same API and sit beside the old ones.
- Build new user-facing screens fresh
- The admin screens stay as they are while a new, lighter front end is built for everyday users.
How we stabilise and replace
Measure
We record which screens are used most, where the errors come from and how memory behaves over a working session.
Put tests in place
Automated browser tests are written for the main workflows before anything is changed.
Stabilise
Leaks, race conditions and the most frequent errors are fixed, and a build step is added.
Draw the line
We agree with you which screens stay on the existing libraries and which are worth rebuilding.
Replace the chosen screens
Each is rebuilt in a modern framework against the same API and released on its own.
A good fit when
- The application gets slower the longer a browser tab stays open.
- Bugs come and go and cannot be reproduced on demand.
- A change to one screen breaks another, and there are no tests to catch it.
- You want a modern, mobile-friendly experience for customers without rewriting the admin side.
Probably not for you if
- The front end is small; rebuilding it outright is cheaper than stabilising it.
- The application rarely changes and nobody is complaining; leave it alone.
Questions we are asked
Are Knockout and jQuery out of support?
No. Both are still maintained open-source projects, and nothing forces you off them. The issue is practical: applications built this way tend to be large and untested, each change carries risk, and fewer developers know the tools.
Why does our application slow down during the day?
Usually memory leaks. In a single-page application, a screen that subscribes to an observable, a message bus or a page-level event and never unsubscribes stays in memory after the user leaves it. Each visit adds another copy. After a few hours the browser is holding many dead screens, all still reacting to events.
Do we need to rewrite the whole front end?
Rarely. Stabilising the existing code often removes most of the pain at much lower cost than a rewrite. Where screens are replaced, it is done one at a time, starting with those that change most or that customers see.
Can a new framework run alongside Knockout?
Yes. A new screen can be mounted inside the existing page, or served as a separate application under the same address with shared sign-in. Both call the same server API, so data and business rules are not duplicated.
Which framework should the new screens use?
React, Vue and Angular are all reasonable. Vue binds templates to data in a way Knockout developers will recognise, which can help an existing team. The choice matters less than keeping to one framework and having a clear boundary between old and new.
Tell us about your system
Say what it does, what it is built on and what is worrying you. We will reply with what we would look at first and whether we are the right people to help.