Why JavaScript Is Blamed for a Broken Web

TL;DR

JavaScript is not inherently responsible for the web becoming slow, fragile, or bloated. The stronger explanation is that modern sites often perform complex, interactive work, while poor engineering, advertising, analytics, tracking, and unnecessary architecture can create bad experiences. Client-side JavaScript can provide immediate feedback and reusable components, but it should be applied according to what a website or application actually needs.

Transcript

JavaScript is terrible. It's absolutely ruined the web. I miss the days where I could just go to a website and read the text on it. It didn't have to deal with things like interactive pages, actually useful applications and features, and the occasional popup or ad. I'm being a bit sarcastic. This article is not. According to Jonno, JavaScript broke... Read More

Key Insights

• JavaScript is not presented as the sole cause of bad websites. The critique identifies advertising, analytics, tracking, poor engineering, and unnecessary complexity as plausible reasons that pages become slow, unstable, bloated, or frustrating, even though JavaScript may be the mechanism through which some problems appear.
• Modern web applications are fundamentally different from static content pages. A blog or marketing page may need little interactivity, while email clients, conversational tools, and video communication products require dynamic interfaces, device access, data retrieval, and application-like behavior that plain HTML documents cannot provide alone.
• Reusable components can make shared interface changes easier. A navigation bar implemented once through a framework can be updated centrally, whereas a site composed of many separate files may require the same change repeatedly, making the blanket claim that frameworks always create extra maintenance complexity difficult to sustain.
• Client-side rendering can provide immediate visual acknowledgment after a user clicks. Even when an operation still needs permissions, device processing, or remote data, the interface can change at once and display progress near the action, reducing uncertainty about whether the click was successfully registered.
• Loading indicators do not necessarily create the underlying delay. They can represent real work such as retrieving information, requesting permissions, or interacting with a device, and they give users feedback while that work finishes. Removing the indicator would not automatically eliminate the operation or its duration.
• Server-rendered navigation can feel unresponsive when feedback appears far from the clicked control. A loading bar at the top of an otherwise unchanged page may leave users uncertain, encouraging repeated clicks that can submit additional requests and generate unintended duplicate activity.
• Web development became more complex because websites began doing more complex things. The response rejects the idea that developers adopted interactivity merely for their own benefit, arguing that dynamic behavior emerged to support experiences beyond reading text, completing a form, and waiting for a full-page reload.
• Technology choices should follow the product's requirements rather than a universal rule. Mostly static pages can favor simple delivery, while highly interactive applications may reasonably depend on extensive client-side JavaScript. Problems arise when implementation complexity is poorly matched to the actual experience users need.

Questions & Answers

Q: Why is JavaScript blamed for making websites worse?

JavaScript is blamed because many modern pages load slowly, render erratically, behave poorly on mobile devices, and hide their content behind large amounts of client-side code. The response agrees that these experiences are common but challenges the causal claim. Advertising, analytics, tracking, poor engineering, and overengineered architecture can all produce similar problems, so the presence of JavaScript does not establish that JavaScript itself caused them.

Q: Did JavaScript alone ruin the modern web?

JavaScript alone did not ruin the web according to the video's argument. It is a tool used both for valuable interactive features and for implementations that become bloated or fragile. The condition of a website depends on what developers build with it, how much complexity they introduce, and whether advertising, analytics, tracking, or poor technical decisions interfere with performance and usability.

Q: Why do modern web applications need JavaScript?

Modern web applications use JavaScript to provide dynamic behavior without requiring a complete page reload after every action. The transcript points to email, conversational, and video communication experiences as products that do more than display documents. Such applications may update interface state, retrieve data, request device permissions, and react immediately to user input, making client-side execution an important part of their functionality.

Q: Are JavaScript frameworks always unnecessary complexity?

JavaScript frameworks are not always unnecessary complexity because they can organize shared interface elements into reusable components. If a developer needs to update a navigation bar appearing across many pages, changing one component may be easier than editing numerous separate files. The video's position is that complexity should be judged against the application being built, rather than treated as automatically wasteful whenever a framework is involved.

Q: Why can client-side rendering feel faster?

Client-side rendering can feel faster because the interface responds at the location of the user's action as soon as a control is clicked. The underlying task may still require data, permissions, or device processing, but immediate feedback confirms that the interaction was received. By contrast, waiting for an entirely new server-generated page can leave the existing screen unchanged and make the application appear unresponsive.

Q: Do loading spinners make web applications slower?

Loading spinners do not inherently make an application slower. They often communicate that real work is occurring, such as retrieving data, obtaining permissions, or interacting with a device. The transcript argues that loading does not always mean waiting for a server response. A brief indicator can therefore improve clarity by showing that an operation started, even though it cannot remove the time required to complete that operation.

Q: Why can server-rendered page navigation confuse users?

Server-rendered navigation can confuse users when clicking a control leaves the current page visually unchanged while a loading bar appears elsewhere, such as at the top of the screen. The user may not know whether the click registered and may click again. According to the transcript, those repeated actions can submit more requests or generate additional operations, even when server rendering is technically fast.

Q: When should a website use extensive client-side JavaScript?

A website should use extensive client-side JavaScript when its required experience includes rich interaction, immediate state changes, device access, permissions, or frequent data retrieval without full-page reloads. The transcript contrasts these applications with blogs and marketing pages, which may need much less code. The appropriate amount of JavaScript therefore depends on the product's actual behavior, not a blanket preference for either static or client-side rendering.

Summary & Key Takeaways

• The argument begins with a genuine problem: many websites load slowly, render unpredictably, perform poorly on mobile devices, and bury content beneath JavaScript. The response accepts these failures but disputes their alleged cause, pointing instead toward advertising, analytics, tracking, poor engineering, and inappropriate architectural decisions as major contributors to the web's decline.

• JavaScript frameworks and components can reduce maintenance effort when interfaces contain shared elements such as navigation bars. Changing a reusable component in one place can be simpler than editing many separate files. The claim that modern development always requires several engineers and elaborate deployment systems is therefore treated as an organizational failure, not an unavoidable technical requirement.

• Interactive applications have requirements that static documents do not. Tools resembling email clients, video meeting platforms, or conversational applications must update interfaces, request permissions, communicate with devices, and retrieve data without reloading every page. Client-side rendering can acknowledge clicks immediately, while carefully placed loading indicators clarify that longer operations remain in progress for the user.