# Why JavaScript Client-Side Architectures Hinder Public-Sector Service Sites

DevFeed: [Why JavaScript Client-Side Architectures Hinder Public-Sector Service Sites](<https://devfeed.tech/articles/reckoning-part-3-caprock-26544.md>)

Original publisher: [Read original article](<https://infrequently.org/2024/08/caprock/>)

Author: Alex Russell

Published: 2024-08-14T00:00:00Z

Content type: opinion

Language: en

Sources: [Alex Russell](<https://devfeed.tech/sources/alex-russell.md>)

Topics: [JavaScript](<https://devfeed.tech/topics/javascript.md>), [Web Development](<https://devfeed.tech/topics/web-development.md>), [Single-page application (SPA)](<https://devfeed.tech/topics/spa.md>), [Architecture & Design](<https://devfeed.tech/topics/architecture-design.md>), [Front end](<https://devfeed.tech/topics/frontend.md>), [web applications](<https://devfeed.tech/topics/web-applications.md>)

Tags: [architecture](<https://devfeed.tech/tags/architecture.md>), [frontend](<https://devfeed.tech/tags/frontend.md>), [javascript](<https://devfeed.tech/tags/javascript.md>), [performance](<https://devfeed.tech/tags/performance.md>), [public-sector](<https://devfeed.tech/tags/public-sector.md>), [scalability](<https://devfeed.tech/tags/scalability.md>), [webdev](<https://devfeed.tech/tags/webdev.md>)

## AI overview

This opinion article argues that JavaScript-heavy, client-side-rendered architectures make public-sector service sites more complex, expensive, and difficult to operate. It says slow networks and low-end devices amplify the performance costs for users, while HTML-first progressive enhancement can improve scalability.

## Source excerpt

Other posts in the series: Reckoning: Part 1 -- The Landscape Reckoning: Part 2 -- Object Lesson Reckoning: Part 4 -- The Way Out Contents Complexity Perplexity Carrying Capacity Should This Be An SPA? The Pits Aftermath Last time, we looked at how JavaScript-based web development compounded serving errors on US public sector service sites, slowing down access to critical services. These defects are not without injury. The pain of accessing SNAP assistance services in California, Massachusetts, Maryland, Tennessee, New Jersey, and Indiana likely isn't dominated by the shocking performance of their frontends, but their glacial delivery isn't helping. Waits are a price that developers ask users to pay and loading spinners only buy so much time. Complexity Perplexity These SNAP application sites create hurdles to access because the departments procuring them made or green-lit inappropriate architecture choices. In fairness, those choices may have seemed reasonable given JavaScript-based development's capture of the industry. Betting on JavaScript-based, client-side rendered architectures leads to complex and expensive tools. Judging by the code delivered over the wire, neither CalSAWS nor Deloitte understand those technologies well enough to operate them proficiently. From long experience and a review of the metrics (pdf) the CalSAWS Joint Management Authority reports, it is plain as day that the level of organisational and cultural sophistication required to deploy a complex JavaScript frontend is missing in Sacramento: Dora Militaru | Performance culture through the looking-glass It's safe to assume a version of the same story played out in Annapolis, Nashville, Boston, Trenton, and Indianapolis. JavaScript-based UIs are fundamentally more challenging to own and operate because the limiting factors on their success are outside the data center and not under the control of procuring teams. The slow, flaky networks and low-end devices that users bring to the party define t