Why be optimistic about JavaScript?
🌐

Why be optimistic about JavaScript?

Created
Dec 20, 2022 03:28 PM
Last Updated
Last updated April 13, 2023
Owners
Tags
development
web
2022
Status
Complete
JavaScript is a popular programming language that is widely used by developers. It can be run on various platforms, such as browsers, servers, and edge devices. Despite its quirks and flaws, JavaScript has gained widespread adoption due to its presence in most web browsers, its extensive collection of tools and libraries, and the growing popularity of TypeScript. As a result, developers can use their knowledge of APIs like Request and Response across different platforms.
 
The web platform has seen significant advancements in recent times, including improvements to browser, server, and edge support. A key factor contributing to this progress is the establishment of common APIs, or standards, that are supported across different platforms. This allows web developers to learn a particular interface once and use it in various environments. This post will explore the latest enhancements to the web platform in these areas.
 

JavaScript: In the Browser

Web developers today spend less time writing vendor-specific JavaScript or vendor-specific CSS selectors than ever before.
if (/Trident\/7\./.test(navigator.userAgent)) { // The user's browser is Internet Explorer 11 } /* This code uses a regular expression to test the navigator.userAgent property, which contains a string representing the user's browser and version. The regular expression checks for the presence of the string "Trident/7." in the user agent, which is a unique identifier for Internet Explorer 11. If the regular expression returns a match, it means that the user's browser is Internet Explorer 11. You can then execute any code that you want to run specifically for Internet Explorer 11. Note: This code will only work for Internet Explorer 11. To detect other versions of Internet Explorer or other browsers, you will need to use different techniques. */
We’ve escaped the word of padding hacks for maintaining an element’s aspect ratio:
@supports not (aspect-ratio: 16/9) { .aspectRatio { overflow: hidden; padding-bottom: 56.25%; height: 0; } }
Two converging trends are making this possible:
☠️
The death of Internet Explorer: Now that IE 11 is officially retired, web developers can write less vendor-specific CSS, leading to smaller stylesheets and fewer hacks.
〰️
Browser engine alignment: The three major browser engines (Chromium/Chrome, Gecko/Firefox, and Webkit/Safari) now have the best cross-browser support for JavaScript, CSS, and Web APIs we’ve ever seen. Kudos to the Interop project.
Although perfect cross-browser compatibility may never be achieved, recent improvements in this area have been significant and promising. The alignment of browser engines has the potential to save a significant amount of time for developers, who previously may have spent considerable effort addressing obscure bugs specific to certain browsers.
As an example of the benefits of this alignment, consider the case of a framework developer attempting to create a reusable image component that helps other developers optimize image performance. In the past, it was difficult to ensure that the component could handle tasks such as loading images without disrupting layout, maintaining aspect ratios, and minimizing the impact on initial page load times due to image size and weight, while still being compatible with a variety of major browsers. As a result, developers may have chosen to overlook these issues or used frameworks that generated code with numerous abstractions to address them.
<span> <-- needed to maintain aspect ratio <span> <-- needed to maintain aspect ratio, CSS padding hacks <img src="" style="" /> <-- inline styles to prevent layout shift <noscript>...</noscript> <-- JS needed for IntersectionObserver </span> </span>
It’s a different story in 2022. There’s cross-browser support for: aspect-ratiowidth/height attributes to prevent layout shift, native image lazy-loading , and pure CSS/SVG-based blur-up image placeholders. The above code can drop the wrapping elements and work without runtime JavaScript needed.
<img alt="A kitten" decoding="async" height="200" loading="lazy" src="https://placekitten.com/200/200" style="aspect-ratio: auto 1 / 1" width="200" />

JavaScript: On the Server

Isomorphic JavaScript, or code that can be executed on both the client and server, has long been a goal for many web developers. This would allow them to learn once and use their knowledge in a variety of contexts. However, in the past, there was a lack of alignment between Node.js and the web platform, which made it difficult to achieve this goal.
For example, the browser had the Web Fetch API for fetching data over HTTP, but prior to Node.js 18, there was no built-in solution for this task on the server. Developers had to use packages like node-fetch or undici, which had similar but slightly different APIs, causing confusion and additional work. This lack of alignment meant that tools like Next.js needed to include polyfills to enable developers to use the fetch API on both the client and server.
With the release of Node.js 18, these issues have been addressed, and developers can now use APIs like Request, Response, and many others on both the browser and server. This is a result of closer collaboration between browser vendors and companies that build server infrastructure to provide a standardized set of APIs that can be used across all platforms, including edge computing. Overall, this development is a positive step towards the goal of isomorphic JavaScript and will likely lead to increased efficiency and productivity for developers.
 

JavaScript: At the Edge

Edge computing, the often misunderstood and newest target for running JavaScript, has had the least standardization of the three (browser, server, edge).
It’s helpful to think about edge as the highest level of abstraction, where you’re spending all of your time on business logic.
notion image
Edge computing is a type of computing that involves processing data closer to the source, rather than in a centralized location such as a server or cloud. This approach can result in faster data processing and reduced latency.
Edge compute infrastructure requires a smaller subset of the Node.js API surface area in order to maintain efficiency and cost-effectiveness. By choosing to use this subset of APIs, which are also supported in the browser, developers can take advantage of consistently fast cold boot times and more cost-effective compute workloads.
An example of this approach is the use of Vercel Edge Functions, which are designed to run JavaScript code on the edge. These functions have a similar syntax to Node.js, making it easy for developers who are familiar with this platform to write code for the edge. Other edge computing platforms, such as Cloudflare and Deno, also offer similar capabilities. Overall, the use of a consistent set of APIs across different platforms allows developers to write JavaScript code that can be executed in a variety of contexts, including the edge.
export const config = { runtime: 'edge' } // Web standard Request API export default function handler(req: Request) { // Web standard URL API const { searchParams } = new URL(req.url) const name = searchParams.get('name') // Web standard Fetch API const req = await fetch('https://...', { body: { name } }) const data = await req.json() // Web standard Response (.json is new) // https://github.com/whatwg/fetch/issues/1389 return Response.json(data); }
💸
Here’s the kicker: it’s not just about the infrastructure. It’s about the frameworks that are embracing these same Web APIs and helping thousands of new developers learn once and write everywhere.
This code could work with Next.js. Or SvelteKit. Remix. Fresh. Or the next, new web framework that builds upon the same set of standard APIs.