The state of modern Web development and perspectives on improvements

Key Takeaways

• WWW is built on top of REST principles.
• Modern Web development violates REST principles.
• Pure HTML is not suitable for modern web development.
• HTML can be improved with declarative fetch requests, DOM block replacements, and loading code on demand.
• WASM can replace JavaScript in browsers when it provides more functionality to the runtime.

Website development has seen multiple approaches during the 23 years of the World Wide Web's (WWW) existence. In this article, I review the principles of WWW, the current state, and the problems of modern Web development. Ultimately, I will present multiple proposals to improve Web development considerably.

Resource representation

Standardizing World Wide Web

In 1988 a remarkable event happened in the World. Engineers connected European networks with the North American continent via Internet Protocol (IP). The Internet immediately received growth in independent interconnected networks, mostly between scientific institutes.

Tim Berners-Lee, a British scientist at CERN, saw high demand for communication standardization and, in 1989, invented the World Wide Web (WWW). The work included the standard for HTML as markup language to present the information, HTTP protocol to send and receive data, and the Web client to communicate with servers and process the markup language.

Roy Thomas Fielding was working on the HTTP protocol improvements and, in 2000, gathered WWW and HTTP ideas in his famous dissertation Architectural Styles and the Design of Network-based Software Architectures. Chapter 5 contains the essential principles under the “Representational State Transfer” name, or REST for short, which includes the following points:

• It is the client-server architecture where web clients (browsers, robots) communicate with servers.
• The communication must be stateless in nature. Every request from a client should contain all the required information to process the request. This constraint allow to build reliable and scalable systems.
• To improve network efficiency, any request can be cached.
• Components should have a uniform interface. For example, to use HTTP for communication, even though other transfer protocols might work faster for a specific representation in some cases.
• The system should work with the layered architecture. A layer can be a proxy.
• Code-On-Demand. REST allows client functionality to be extended by downloading and executing code in the form of applets or scripts… However, it also reduces visibility, and thus is only an optional constraint within REST.
• A resource is located in a URI and is represented to a client via a standard media type. A web client only knows how to process the media type. For example, for a browser to display a PNG media type, there is no need for a JavaScript code. To display a PDF file a browser does not need to run some special JavaScript code. The same is true for processing and displaying the HTML media type.

The code-on-demand, with JavaScript, Java Applets, Flash ActionScript, or WASM, is optional in REST. This is a crucial fact in web clients.

The ultimate representation form of a resource should be understandable by a robot. An AI agent should be able to find the information and edit a resource without human interaction and prior knowledge except how to process standard media types.

Modern REST violations

Violation of the optional code-on-demand principle

Today, the idea of optional code-on-demand execution in Web sites, in most cases, is violated.
W3C introduced Web Components to extend HTML tags but made it entirely dependable on JavaScript. All modern Client-Side libraries, like React.JS, Angular, Vue.JS, are built with JavaScript. Sun Microsystems introduced Java Applets based on JVM. Adobe presented Macromedia Flash with a browser extension. Microsft made it possible to run reduced .NET applications in a browser with the Silverlight extension and recently introduced Blazor, which compiles C# code to WebAssembly and executes it on the client side.

The frameworks mentioned do not allow a page interaction without a code being executed in a browser. The exception is Svelte.Kit, which tries hard to make a web page interactive even with disabled JavaScript.

Violation of the resource representation principle

Modern websites pursue the mobile application development style. A web client downloads pages as mobile screens and then makes Remote Procedure Calls (RCP) to a server, usually provided as JSON API endpoints. The application knows how to modify a resource by calling a specific method and what structure of JSON should be sent and returned. This implies a tough coupling of a screen to a backend.

In contrast, with the REST approach, a browser displays a fresh representation of the resource, including dynamically retrieved actions for editing. For example, the HTML version <form action="/post-api"><input name="lastname"><button type="submit">Submit<button><form> is a page representation that itself contains the required structure for an action. A web client also does not know what the response will be and in what format. A server will decide about the subsequent representation, possibly redirecting a web client to a new page.

Reasons for violation

Developers step aside from the optional code-on-demand principle with a straightforward requirement - users want to see rich interfaces. Pure HTML does not allow building applications such as Google Mail, Google Sheets, or Google Docs, not to mention the code necessity for 3d web applications. Even if some HTML extensions will be added to HTML v.6, developers need to add custom client-side validation behavior, for example, to a phone input format (mask) per country:

Developers violate the resource representations principle because it is easier to think in the Remote Procedure Call paradigm. Also, coupling a webpage to a JSON API does not appear as bad in practice as it might sound. Modern browsers often refresh the pages with inactive tabs.
The problem with JavaScript, or EcmaScrpit, to be precise, is its speed. It is a text code that should be parsed and interpreted by a browser. In the next section, I will show how web development may be accomplished pleasingly for users and developers.

Better Future for the World Wide Web

Best performance with advanced HTML requests

The best speed a web client can achieve is by transferring small data and not executing code-on-demand at all.

The next proposals from Hypermedia Systems and HTMX can be implemented in the future HTML version:

• Allow PUT, PATCH, DELETE to be declared in HTML actions in addition to the current GET and POST methods. Example:
  

  <form action="/contacts/1" method="DELETE">Delete</form>
  

• Allow actions to be triggered by any interactive element in addition to <a> and <form> tags. Example:
  

  <div action="/contacts" type="GET" trigger="mouseenter">
    Get The Contacts
  </div>
  

• Allow to replace partial screens or single elements with the result from a declarative request. This will allow to create the genuine REST API with HTML responses as described by Fielding in REST API must be hypertext driven. Example:
  

  <button hx-get="/contacts" action-target="#main">Get The Contacts</button>
  <div id="main">
    <p>This content will be replaced with the requested HTML result<p>
  <div>
  

• Allow declarative polling and web socket communications. Example:
  

  <div action="/messages" type="GET" trigger="every 3s"></div>
  

• Allow to encapsulate code close to the related component by following the Locality of Behavior principle. Example:
  

   <button>
      <script type="text/javascript">
        <!-- This code is relative only to the nearest button tag -->
      <script>
      <script type="wasm">
      <!-- Similar with binary WASM -->
      <script>
  <button>
  

Better performance with optional HTML requests

The Astro project makes it possible to download JavaScript code for a component only when it is visible on the screen or near scrolled. This feature can be included in the future version of HTML. Example:

<input id="my_input" type="text" placeholder="Name">
  <script type="text/javascript" 
  href="/input-behavior.js" 
  download="when-visible" 
  target="#my_input"></script>
<input>

Declarative HTML element state

Declaring a simple state in div, span, and button elements similar to form inputs will be helpful. State management is often used for block visibility. Example:

//HTML
<div id="popup" value="visible"></div>
<button 
  target="#popup" 
  actionType="valueChange" 
  actionValue="hidden">
  Toggle popup
</button>

//CSS
div[value="hidden"] {
  display: none;
}

Though modern browsers will soon support declarative popups and dialogs even without JavaScript with Popopover and Dialog, simple declarative state management will allow for providing more custom behavior.

Extendable native controls

Modern websites use custom UI elements for checkboxes, radio buttons, input elements, alerts, and dropdowns. Almost all of them are made with some CSS and JavaScript tricks, for example, in Bootstrap, Chakra UI, Material UI, ANT Design. Loading CSS and JavaScript for such components without special reduction customization often takes several hundreds of KB in size, plus time to parse and execute JavaScript code.

The better approach would be to allow customization of native browser components. Open UI introduced SelectList, which is already included in Chrome. The code for select customization without JavaScript can look like:

<selectlist>
  <button id=custombutton type=selectlist>
    <selectedvalue></selectedvalue>
  </button>
  <option>one</option>
  <option>two</option>
</selectlist>
<style>
selectlist:open #custombutton {
  background-color: green;
}
selectlist:closed #custombutton {
  background-color: red;
}
</style>

WebAssebmly with rich runtime

The WWW history shows that corporations cannot agree on one proprietary language for the Web. Sun Microsystems issued a lawsuit against Microsoft in 1997, complaining that JVM was not correctly implemented in Internet Explorer on purpose. Adobe pursued the Flash project with ActionScript until Apple, in 2008, decided not to include Flash in the iPhone Safari browser due to pure performance. Microsoft used its ActiveX extension in browsers that adapt Component Object Model (COM) with C++ and Visual Basic programming. Microsft Silverlight browser extension allowed to run code with a reduced .NET runtime. Google attempted to rescue browsers from JavaScript with Dart language.

Browser vendors make successful agreements contributing to the World Wide Web Consortium (W3C).

The recent contribution is WebAssembly (WASM), a binary stack machine supported in modern browsers. It is natively fast, and deliveries take less space than JavaScript code. There are some disadvantages to the current WASM state.

First is the size. Writing a server-side and client-side program is possible with Rust, and the resulting WASM package will be small enough. At the same time, Microsoft Blazor converts C# code to WASM, but the client delivery has to include the reduced .NET runtime, taking several megabytes for a script. The same is true for GoLang, even with an attempt to reduce the runtime delivery in TinyGo WASM. Developers want to work with their favorite languages, whether it is Java, Kotlin, Dart, C#, F#, Swift, Ruby, Python, C, C++, GoLang, or Rust. These languages produce groups of runtimes. For example, JVM and .NET have many common parts, Ruby and Python are dynamically interpreted at runtime, and all mentioned depend on automatic garbage collection. For smaller WASM packages, browser vendors can include extended runtime implementations, for example, by delivering a general garbage collector as part of WASM. Garbage collection support by WASM is currently in progress: WASM GC, .NET WASM Notes.

Second, WASM still manipulates DOM in a browser via JavaScript interop. Updating the DOM tree natively without a JavaScript proxy will be faster and require fewer CPU resources.

Conclusion

Web development stepped aside from the REST principles to provide interactivity for rich UI interfaces. A new HTML version with a declarative style for fetch requests can lead to ultra-fast websites. New WebAssebly runtimes may allow developers to program Client- and Back-end side code with a favorite language.