Replacing JavaScript

In the design of this new, declarative interface, we need to consider both the good and the bad sides of JavaScript.

JavaScript is a wonderful tool for providing a dynamic way of interacting with a webpage. It is great for changing the style of a page on the fly, for crafting dynamic menus and forms and for updating the page without having to refresh – all in all, it is an indispensible cornerstone of useful web apps.

But there’s a catch. Above all, what’s dangerous about JavaScript is that it is executed without the user’s knowledge or consent. Sure, web developers are aware of it and, one might argue, consent to it by not disabling JavaScript, but the vast majority of users have little to no knowledge of the JavaScript being executed on their machines.

Another big problem are AJAX requests, which likewise often occur without knowledge or consent – potentially sending private, personal information to third parties, or (like certain online newspapers) draining the user’s bandwidth by downloading gigabytes of media in the background.

Even for the developer, JavaScript isn’t a particularily pleasant interface for the things it is designed for. It is constantly upheld as an example of a messy and inconsistent language, so hard to work with that people have developed several languages – CoffeeScript, TypeScript, ClojureScript et al. – that compile to JavaScript, all to avoid actually using JavaScript.

JavaScript is also weird because it is imperative, forcing the programmer to describe the means in which to achieve the desired result, instead of declaratively describing the desired result itself, like in HTML and CSS.

Any interface looking to replace JavaScript must try to retain as many of the good parts as possible, while removing the bad parts. This might sound like a difficult task – and it is – but, as this article will show, it is not impossible. In fact, it is perfectly realizable.

To be clear, what is being presented is not a programming language – it is only the idea of an interface, that might be implemented in the form of a separate language, or perhaps simply as a series of extensions to HTML and CSS.

The good parts of JavaScript listed above can be summarized into three pieces of fundamental functionality:

1. Dynamic HTTP requests (AJAX)
2. Dynamic DOM manipulation
3. Dynamic CSS rules

These three goals would need to be met by any serious JavaScript replacement. Moreover, our interface would have to meet them while avoiding any of the bad parts. The two latter pieces of functionality – dynamic generation of local HTML and CSS – cannot be particularily harmful to the user, but, as exemplified earlier, AJAX requests can be.

For this reason, the design of the interface for dynamic HTTP requests must be dictated by a principle of user consent.

The JavaScript framework Intercooler is an interesting project, much because of the philosophical foundation behind it (see this and this). With a few modifications, it turns out to be very compatible with the ideas presented in this article.

Most importantly, the framework extends HTML with this collection of attributes:

• ic-get-from
• ic-post-to
• ic-put-to
• ic-patch-to
• ic-delete-from

When put on an HTML element, these attributes describe the sort of HTTP request for that element to trigger, and their values describe where to direct that request.

It is easy to see how this would be useful for own ideas about user consent: when the user hovers over an HTML element with one of these attributes, the web browser would display a tooltip warning the user about the attached request.

The notion of automatically and dynamically updating the content of a webpage seems to go against the notion of user consent, but if we imagine that the interface proposed in this article would replace JavaScript completely, then removing the ability to automatically make repeated HTTP requests would seriously limit the usefulness of modern web apps – just imagine a web-based instant messaging app without automatic updates!

Fortunately, this problem can clearly and easily be solved by designing a standardized API for automatic updates, implemented by the web browsers, much like they have all implemented the Notifications API.

Just like the notifications, automatically repeated HTTP requests would be opt-in; this makes them fully compatible with the principle of user consent. Of course, just like notifications, the user’s choice for each site could optionally be remembered by the browser.

This would mean a web where users wouldn’t have to worry that their news site silently downloads gigabytes in the background, while their favorite web-based messaging service would work without any manual refresh.

When a user visits their favorite social network, their browser would present them with a dialog box, asking them whether to allow the webpage to make repeated HTTP requests in the background. The dialog box would inform the user of what type of request the page wants to make, to which address it would be made and, if applicable, what information (form data, for example) the request would include.

(For an interface based on Intercooler, another good idea would be for the dialog box, when hovered above, to highlight the element into which the response would be put.)

For an idea of what this dialog box would look like, compare the current dialog box for the Notifications API in Firefox:

Let’s put our theory into practice and take a look at what an interface for dynamic HTTP requests could look like.

With Intercooler as inspiration, HTML could be extended with the following attributes:

The interface would be used in the following way:

<a get="/status-updates" prepend="#status-feed" poll="2s">
  Update status feed
</a>
<div id="status-feed">
  <!-- Old status updates -->
</div>

As you can see, such an extension of HTML goes a long way. Implementing this small number of attributes is likely sufficient for replacing AJAX in a majority of the cases. For some people, it does require a new way of thinking – but as explained on the Intercooler homepage, this might actually be a better way of thinking, more compatible with the philosophy of REST and, incidentally, that of HTML itself.

That is: not only would this extension to HTML be a replacement for AJAX that is safer, more trustworthy and more user-friendly – it would be developer-friendly as well, because it goes with the grain of the web, unlike JavaScript, which has always gone against it.

Before we move on, I should say that it is also worth looking at the Intercooler interface to the History API as a future source of inspiration.

I know, I know! What does Prolog have to do with CSS? How could it possibly serve as inspiration for our interface? I will explain.

The truth is that, unlike those that extend HTML, it is quite difficult to find JavaScript projects that aim to extend CSS in a dynamic way. Perhaps this is because HTML is more obviously extensible, thanks to its XML-like syntax, but whatever the reason may be, this leaves us with little inspiration for our own extension to CSS.

We have to find it elsewhere – so let us think about what we need to implement, and whether there are any similar projects we can think of and be inspired by.

An important insight is the need for conditional CSS rules. If we could write a rule, but stipulate that it only be applied under a certain condition, we could eliminate much of the need for JavaScript.

This is where Prolog comes into the picture. It is a logic programming language that is practically built upon conditions. The following code describes under which conditions that the relationship between a grandparent and a grandchild holds:

grandparent_grandchild(Grandparent, Grandchild) :-
  parent_child(Grandparent, Parent),
  parent_child(Parent, Grandchild).

That reads: the relation “grandparent-grandchild” holds for any Grandparent and Grandchild – if the relation “parent-child” holds for that Grandparent and some Parent and the “parent-child” relation also holds for that same Parent and the Grandchild.

Imagine if we could do the same with CSS: to stipulate, for example, that the rule #menu { display: block; } be applied when #menu-button:hover is true. Such simple conditions don’t really require any Prolog-like implementation, but what about more advanced conditions?

As an example, let’s take this very page.

Let’s take a piece of JavaScript code and convert it to CSS, extended with a plausible (but by no means set in stone) syntax. The following JavaScript is a sample from this webpage, highlighting the current section in the Table of Contents as the user scrolls through the page:

window.addEventListener('scroll', function(event) {
    var links =
        document.querySelectorAll('#text-table-of-contents a')
    links.forEach(function(link, i) {
        var anchor = link.getAttribute('href')
        var section = document.querySelector(anchor)
        var sectionTop = section.getBoundingClientRect().top

        if (sectionTop - 10 <= 0) {
            if (i > 0) links[i-1].classList.remove('active')
            link.classList.add('active')
        } else {
            link.classList.remove('active')
        }
    })
})

(The .active CSS class applies rgb(255, 248, 212) as the background and var(--select-color) as the color.)

Converted to our extended CSS, this is what the equivalent could look like:

#text-table-of-contents a[href="#" $id]:last-match {
    background: rgb(255, 248, 212);
    color: var(--select-color);
} while [id=$id] { y-rel <= 0; }.

The syntax introduces a couple of things:

The CSS rule above could be put into words in the following way. It applies to the “:last-match” out of all a elements inside #text-table-of-contents whose attribute href consists of the concatenation of # and some variable $id – but only while there exists any element whose id is $id and whose y position, relative to the viewport, is less than or equal to 0.

Whenever the browser finds any elements matching the selector in our while condition (that is, is an element that has an id and whose relative y position ≤ 0), it will recognize that the $id variable can be equal to the id of either one of those elements. For all possible values of $id, it will apply our rule – but remember, our rule concerns only the last match, so it will only be applied to the last element. While you’re reading this section, that element’s href is #css-examples.

The complete explanation might be a little long, as I also needed to introduce the concepts behind the syntax, but the actual code is short and understandable, once you have become comfortable with the interface. As demonstrated, it is possible to achieve a whole lot, with only a limited number of additions to the regular CSS syntax. What’s more, the code is clearer than the equivalent JavaScript code, and it is more declarative, describing what the designer wanted and not how they wanted it.

Of course, simpler things would be simpler:

#nav .menu { display: none; } /* default rule */
#nav .menu { display: block; } toggled by #menu-button:active.

In this example, we extend the syntax further with the toggled by condition. Another plausible condition type would be on, which would enable the rule after the condition has been met, but would not disable it once the condition ceases to be met.