DEV Community

What's the hype about JavaScript?

Kolawole Emmanuel on January 08, 2022

Over the years, I have asked myself this question over and over again. Why use JavaScript? A little bit of background about this post. I started my...

Read full post

Eckehard • Jan 9 '22

Thank you much for your nice writeup!

Hopefully I can add another aspect to the role of JS. Here is my story:

I came across Javascript from a different perspective. I have been developing software on compiled languages (C++ and Delphi) for about 20 years. We had some really large applications based on an ecosystem of own components, lot´s of open source stuff and some commercial tools. Some Apps had more than 60.000 lines of own code, not counting the external libraries. With Delphi, it was absolute amazing, how easy it was to keep things running over years and constantly extending the cpabilities. Sometimes I found myself using codes I had written more than 20 years ago, that where still good and useful.

When I started to develop for the WEB, this was kind of a shock: a bunch of low performant and inconsistent tools, somehow patched together (That was at least my first impression). Why learn HTML, CSS, SCSS, JS, PHP, JQuery, Ajax, SQL, Angular/React, bootstrap, tailwind - all with different syntax and keywords - just to solve ONE task: build a website. This should be the future? Things went at least a factor 10 slower than before.

So, what to do? Learn to master all this different tools? Or look for a simpler, more consistent way? Whatever you do, run PHP, Webpack or React, finally you will need to run at least SOME Javascript. In fact, Javascript is the only element of webdesign, that can be used alone.

One big advantage here: Javascript has direct access to all browser elements via different API´s, like the HTML-DOM-Api, HTML5-canvas or even MIDI and other special purpose libraries. This gives you access to a fantastic (and free) ecosystem of useful tools, for nearly any field of application.

Javascript has still some serious shortcomings: most of all, there is no real chance to protect you code. You always need to deliver your sources somehow, to get things running. The object model lacks - compared to other languages - some elements and has some quirks (e.g. the extensive and irritating use of this) and so on. But bottomline, things are not too bad (and are getting better with every update). I expected much trouble from the lack of strong type checks, but this was not at all the case. If you change your style a bit, type errors can easily be avoided and the dynamic types in JS make some things really easier.

So, finally I decided to skip all other "languages" and use ONLY Javascript. You think, this is impossible? It is not. You will need some CSS, as this is the way, DOM elements are formatted. But you do not need HTML, because JS can directly work on the DOM. And most other elements of WEB design can also be performed using JS only.

peerreynders • Jan 11 '22

But you do not need HTML, because JS can directly work on the DOM.

HTML deserializes to the DOM so one could argue that the DOM and HTML are inexorably linked—most DOM objects expose an interface that is a superset of HTMLElement. So some people may actually find it easier to learn HTML before moving on to DOM scripting.

my JS-ONLY-approach.

Modern JS frameworks and the SPA approach in general already espouse a JavaScript first attitude. These approaches are popular and "successful" largely because most developers find them convenient (and familiar) but there is another perspective:

Dear Developer, the Web Isn’t About You

Before SPAs became the shiny object Progressive Enhancement presented:

Content is the foundation
Markup is an Enhancement (HTML)
Visual Design is an enhancement (CSS)
Interaction is an enhancement (JS)

Browsers are extremely fast/efficient at parsing HTML.
Browsers are extremely efficient at CSS based layout.
Both HTML parsing and CSS based screen layout can be done by the browser on threads (or cores) separate from JavaScript.
JavaScript has only access to one single UI thread. Additional threads have to be acquired via Web Workers and cross thread communication has to happen via postMessage.

Meanwhile there is an emerging trend in mobile devices to move to multiple low power CPU cores that may have low single thread performance.

Then there is the W3C Rule of Least Power: "Principle: Powerful languages inhibit information reuse."

Browser operation is based on the web's approach to fault-tolerance:

Prioritize content by shipping HTML first.
Only once data (content) has been secured, resources are spent on visual design.
Only after HTML/CSS have been processed, interactivity (JavaScript) becomes a concern
- Everyone has JavaScript, right?
- Why Availability Matters.

So in a sense JS-ONLY relies on the least stable/reliable technology in the "web fault tolerance hierarchy".

And ultimately even a "web application screen" is "content".

From that perspective shipping a fully rendered HTML/CSS page to the client is just shipping a pre-rendered screen that the browser can immediately render onto the client display before any JavaScript is even parsed or executed—the browser is acting as a heterogenous multiprocessor. Once the JavaScript is successfully loaded it can be used evolve "the content on the screen" in response to app visitor interaction or network events. Martin Fowler suggested the Segregated DOM in order to get away from the Big Ball of Mud that was typical of many jQuery applications at the time.

The notion of progressively transforming content structured by the DOM tree to represent the relevant client application state is very different from drawing pixels on a canvas to be blasted as a frame onto the client screen.

Any attempt to make web application development more like native application development is going to incur undesirable trade-offs especially as native applications don't have to operate under the same physical constraints that web applications do.

The reputation of the web as the most hostile development platform in the world has to come from somewhere.

It should be noted that previous attempts to "fix the web"

ActiveX
Java Applets
Flash
Silver Light

ultimately failed. The concern is whether the web will survive the shift to mobile while the average JavaScript payloads keep increasing.

Responsible JavaScript:

Eckehard • Jan 12 '22

Hy peerreynders,

Initially the web was invented to display text with some "decoration", so called "hypertext". But as the displays at CERN these days had only green letters on a black screen, html does not even know a color attribute.

People on the internet always tried to push the limits. If not, we would still use green letters on a black screen.

CSS was invented to make the WEB more colorful, and some scripting was added to make it more responsive. Today, people start to use WEB-technology for application development. And this changes the focus a bit.

If I just wanted to display a text, shipping a fully rendered HTML/CSS page to the client was surely a good solution. But If I want to build a calculation tool or write a MIDI-app, html is possibly not the defining factor.

From the view of an application developer, using html is far from ideal. HTML is rendered to build the DOM tree, but you have no direct access to the elements. You will need some ID´s to search for DOM elements, and these ID´s are always globally scopled. That is really bad news for a programmer. And I will need a variable to store the element reference. So, for every DOM element I get two Identifiers in my program: The ID and a variable. This doubles my effort compared to creating the elements from within JS.

So, there are different task that need different tools. I found the JS-only approach very helpful in some respects, but this is surely not the solution to any problem.

peerreynders • Jan 12 '22

From the view of an application developer, using html is far from ideal.

Agreed - especially coming from developing native or desktop application development. But what about the practice of a "splash screen"? It's a native workaround to give the user something to look at while the application gets its stuff together before it is capable of drawing anything coherent on the display.

With Server Rendering there is no need for a splash screen - the visitor gets to see "the screen" almost immediately. Interactivity depends entirely on how much JavaScript needs to be parsed and run before the UI thread can respond to events from the DOM objects.

So "far from ideal" is a judgement entirely from the developer perspective - the app visitor would rather see the screen for orientation rather than having to wait for yet another splash screen to go away.

Application development is a means to an end - the end being that there is an application that can be used.

For example Ebay's Async Fragments: Rediscovering Progressive HTML Rendering with Marko describes how they flush a single HTML response multiple times just to give visitors earlier views of the page.

This doubles my effort compared to creating the elements from within JS.

So its OK to accommodate your preference for the occasions where you are developing the application and in return later make all the app visitors wait while JavaScript gets downloaded and parsed?

The typical visitor response:

53% of mobile site visits are abandoned if pages take longer than 3 seconds to load.

And the process you're describing only happens while you bootstrap the client side logic against the already rendered page.

To be sure it's a different way of working compared to native application development but that is the entire point of the discussion—that web development is nothing like native app development because native apps operate in an entirely different (highly collocated) environment.

So, there are different task that need different tools.

Correct. And developing applications running on a specific local native platform versus on some indeterminate browser loading from and talking to servers half a planet away requires radically different engineering approaches.

I found the JS-only approach very helpful in some respects,

Sure, as do many others—largely because it's more convenient from a developer perspective. But browser engines are more than just their JavaScript engines. Not using the HTML parser and CSS layout engine to the best of their capabilities is going to leave too much work for that single JavaScript UI thread.

CSS was invented to make the WEB more colorful, and some scripting was added to make it more responsive.

In some ways that's extremely dismissive of CSS's capabilities. Altering the visual presentation of content is meant to enhance (or de-emphasize as the case may be) the information conveyed. That's not something they teach in programming classes. It doesn't help that CSS operates on the principle of a Rules Engine to identify the sections of the markup(/DOM) it applies to - which it about as far away from imperative programming as one can get.

Also "responsive" is typically used to express how the page/screen layout "responds" to various display sizes and geometries—which is what CSS is responsible for—which has been made considerably easier with FlexBox and Grid. For native applications one typically has to use Layout Managers instead.

Scripting adds interactivity and automation of browser resources.

Today, people start to use WEB-technology for application development. And this changes the focus a bit.

Sure but that intent doesn't affect the laws of physics that are responsible for the constraints that servers, networks and browsers have to operate under. One has to distinguish between

the desire to work as if one is just developing a native application that runs locally VS
creating a user experience of an "application" running on the browser while actual processing is highly distributed.

The idea of the SPA dates back to a time were the web was largely consumed on desktops with high single thread performance.
Due to budget mobile the pendulum is swinging back.

The other issue is the "default assumption" is that everything has to be an "application":

CHI 2014 Scott Jenson Keynote: The Physical Web
"So, the technology tiller here is the fact that applications are effectively going to be holding us back."

We're still stuck in the mindset of monolithic applications from stationary desktop computers rather than exploring alternative approaches more optimally suited to the constraints and possibilities of the web.

Eckehard • Jan 12 '22 • Edited

Hy peerreynders,

you should not use a hammer to drill a hole. But does this mean, hammers are useless?

There are lot´s of slow static pages out, that not even are able to show a splash screen. The fact that you know some bad people does not mean, all people are bad. Theoretically it is faster to build a page, that prints "hello world" in html, as html is rendered first.

<body>
   Hello world
</body>

You can do this in Javascript too, which - i have to admit that - looks a bit nasty:

<body>
<script>
    document.body.appendChild(document.createTextNode("Hello world"))"
</script>
</body>

But what happens, if you want to add 1 Mio times hello world?

Start to render your page on the server and go to bed?

In Javascript, this would be:

<body>
<script>
    for (let i = 0 to 1000000)
        document.body.appendChild(document.createTextNode("Hello world"))"
</script>
</body>

So, which one ist faster? You can even print the numbes out or do some fancy math as you like.

I mentioned, webdesign was not my first target, but as I had no CMS available, I created some web pages using the JS-only-approach. The page renders all content dynamically without any html. It was relatively easy to create using some OOP programming techniques and took me only some hours to set up (the technical part, not the content).

See the result here.

The page is NOT optimized for loading speed, as it grabs all libraries at once. This could easily be done better. The full page load takes about 0.6s depending on the network speed, so, i did not add a splash screen....

peerreynders • Jan 13 '22

There are lot´s of slow static pages out

Static pages are the fastest there are. So if static pages are slow, CSR pages will suffer from the same consequences usually in an exacerbated fashion.

Everything else being equal an SSG blog (which could use something like netlify CMS) will always beat a (non-cached) WordPress based blog which has to access the database and generate the rendered page on every request. It's the same difference between a compiled language and an interpreted language - a compiler can do a lot of work ahead of time.

So, which one is faster?

Unless you control the client device it's unlikely that it's the CSR version.

On the server (which in theory you control) you can

use more powerful hardware
use a faster language/framework
and then use compression which will generate a minuscule payload
or start streaming/flushing the response early so that the browser will fill the view port with the first batch while the rest is still streaming.

Meanwhile you have no idea what level of computing power the client device has:

You are essentially blocking the UI thread from being able to do anything until you rendered all 10^6 nodes (and realistically you should be building the subtree separately before attaching it to document).
Aside: The RAIL model budgets 50ms of processing for any one input event irrespective of the computing power of the client device.

The page renders all content dynamically without any html.

The discussion isn't whether it's possible but whether it's desirable.

and took me only some hours to set up.

So it's desirable from the developer perspective - no argument there.

JavaScript has become the largest bottleneck of web performance

The JavaScript first/only mentality reminds me of The Free Lunch is Over—C++ developers stuck in the forgiving mental model of a single thread, unwilling to break the work into isolated but communicating, concurrent tasks. The web equivalent is to load all the work onto the UI thread (i.e. JS) while not delegating work that can be done by the HTML parser or layout engine (which run as native code rather than as JavaScript).

The full page load takes about 0.6s

WebPageTest puts it about 4.6 seconds for "Mobile, Fast 3G"

Just in the Chromium emulator: low 3G + low end mobile + no caching ~ 17s.
Performance breakdown:

loading 85ms
scripting 7234ms
rendering 769ms
painting 537ms
system 2398ms

for a page that has largely static content.

Now lets not kid ourselves, for the 1.8MB one page HTML spec

loading 12322ms
scripting 1071ms
rendering 165554ms
painting 12228ms
system 23841ms

but at least I could read what was already loaded while it was still loading (for 3.2 minutes).

It's clear you don't feel like you are trying to sit comfortably while balancing on a three legged stool with two legs sawed off …

But even all the popular JS frameworks, no matter how lightweight, had to concede that "client-side only rendering" isn't enough and eventually added SSR, further complicating applications. To my knowledge Marko is the only one that operates server-first using JavaScript to build on the server rendered HTML.

Reference to any reader:

Eckehard • Jan 13 '22

Yes, i know, bumblebees cannot fly...

peerreynders • Jan 13 '22

🤔

As somebody already pointed out that's a bit out of date.

"Client side only rendering" is an idea that had its heyday some years back (AngularJS (2009), React (2013)) when the web was still primarily consumed through desktop browsers - where it worked "well enough" for a time.

The "optimized for mobile" HTML-first / just-in-time JavaScript approach is currently being used by Qwik.

Qwik is interesting not because it's new and shiny but because it seems to make an effort to respect the constraints of the (mobile) web.

Qwik Todo Demo on StackBlitz

It uses an entirely different architecture compared to any of today's popular JS frameworks.
It is squarely aimed at highly interactive eCommerce sites, not "web applications in general", to create something that works "well enough" to displace the need for device specific native (eCommerce) applications.
Strictly speaking Qwik does not concern itself with the "client-side application" as a whole but only the UI and its visual components. It's entirely possible that they want to leave the option open of putting the "non-visual client side application" in a web worker instead.

So, for every DOM element I get two Identifiers in my program: The ID and a variable. This doubles my effort compared to creating the elements from within JS.

That's why Qwik will do that work for you.

It's unclear whether Qwik (or something like it) will be the "next big thing" but its approach seems to be a good fit for a certain category of next generation mobile web applications.

Eckehard • Jan 14 '22

I feel this discussion is going a bit beyond the scope and it is not very polite to take over a post. So, maybe we should start a new thread about the future of webdesign somewhere else.

This post was about the advantages (or possibly disadvantages) of Javascript, not about slow networks. IF "JavaScript has become the largest bottleneck of web performance", this was real serious. It is just not what I currently can see.

Let be serious about JS performance. I had real concerns about that, and if the performance was just that bad, I never hat thought one second about using JS to build applications.

WebPageTest puts it about 4.6 seconds for "Mobile, Fast 3G"

Maybe you have heard that 3G was switched off (at least in germany)? We are also not supporting windows XP anymore, but who cares? I checked the page on the oldest devices I could get, a 10 year old mobile phone, my oldest tablet and others, but none of the devices was nearly as slow as mentioned. Indeed, the bottleneck is 3G, not the JS performance. But with a slow web, any interaction will be slow, regardless of the technology.

YES, we should care for poor performance. And YES, maybe QWIK is the next big thing in webdesign. But todays mobile devices are far from being slow, my daughters smartphone has more memory than my laptop. Why should we not make use of this power? You can do more with a browser than looking on websites.

(again: Please stay on topic. I really like to learn about new trends in web design and performance, but maybe we start a new post on that? Thank you very much!)

Kolawole Emmanuel • Jan 9 '22

Wow!!!
Your entrance into JS is an interesting one. I hope it inspire more people to maximise the opportunity JS has to offer.

Thanks for your comment!

Eckehard • Jan 10 '22

Hy Emmanuel,

If you like to see where my "entrance" has guided me to, check out some examples of my JS-ONLY-approach here.

Best regards

Kolawole Emmanuel • Jan 10 '22

Wow.

This is impressive! I love them.

Thanks for sharing.

Ingo Steinke, web developer • Jan 10 '22

As a front-end developer, I still don't really understand why to use JavaScript in the backend or anywhere else outside of the browser. While it has come a long way, it's still incomplete, inconsistent, and, when it comes to web development, unnecessarily imperative.

Before CSS, people used to code hover styles using JavaScript in HTML attributes:
<img onMouseOver="this.src='image1.gif'" onMouseOut="this.src="image0.gif" src="image0.gif">.

Now we are able to do a lot of styling and UI logic descriptively using markup and style sheets, but some developers seem to prefer to code everything in JavaScript, and only JavaScript, instead. In the end, they don't, and they have to invent another language that abstracts their JavaScript DOM manipulations to pseudo markup (JSX) that looks a lot like ... well, HTML?

I agree that JavaScript is versatile and flexible and it's a good idea to learn!
And (especially if you know a strongly typed language like Java) take a look at TypeScript or at least use JSDoc and a strict linter, so you can use JS in a way that actually works and avoid the many pitfalls like "1" + 1 = 11.