🎞️ Videos → The Rise of HTML Over the Wire

Introduction and Welcome0:00

I hope you guys have great experience for this conference. I love seeing you in offline event like this, after years of pandemic. Let me introduce myself. My name is Riza. I'm co-founder of Hacktiv8, coding bootcamp in Indonesia. Today I will talk about HTML over the wire. There is a new concept, not so new, but maybe you haven't know that.

History of Web Page Rendering0:35

But before that, let's roll back the time

to see the history how web page render. And then we go to the present, we talk about multi-page application and single-page application. And then hopefully we can go to the future with HTML over the wire.

Early Web Rendering (1990s)1:03

How the page rendering history? At the beginning of web in 1990s,

this is the real static web. There is link, blink, and marquee, right? You create HTML with your bare hand, with Notepad,

without syntax highlighting. And then there is a code editor like FrontPage or Dreamweaver. What you see is what you get. You can drag and drop a button, a table, something like that. And then when you save your file in your desktop or your computer, then you have to transfer via FTP.

And when user access your website, it's actually they read the file that you save from server and web browser will render the page. That's in 1990s.

Dynamic Web and Browser Wars (2000s)2:11

In 2000s, web getting dynamic.

For example, this is early days of Twitter. It's not real time yet. You have to refresh to get a new data, right? At this era, Internet Explorer and Firefox is the OG of web browser. And the late 2000s, specifically 2008,

Google fork the engine from WebKit or Safari, as we know it, and make a Google Chrome. The main selling point of the browser is multi-process browser. So you can running something in background, so the browser will getting more powerful.

Mobile Web and the Dawn of Frameworks (2007-2010s)3:08

And a year before, Apple also introduced the iPhone, the first iPhone. There is no App Store yet. So if you want running an app or you like some website, you can open it in Safari Mobile and you add to home screen, like we do now for progressive web apps.

The Rise of Client-Side Rendering and Its Challenges3:38

We go to 2010s.

The trend that Google Chrome started continue and browser getting more powerful. But web application is also getting more complex.

You can book hotel or flight.

You can view some users' videos with YouTube. You can listen to the music and everything else. Collaboration also happen in this browser, in your browser, like Google Docs or even Figma.

So to do that, we believe that all the changes

should happen in the client, in the browser. So at first server just send the blank HTML like div with ID root, without any content. And then the client will fetch the data and update the page.

In this era, also known as a frontend framework as Angular, React, Vue, and others was born.

Information Overload and the Limits of Client-Side Rendering5:11

And then web app getting more too dynamic. We got data from everywhere. And information overload. Maybe for some users, browser is not good enough, not powerful enough. Because maybe we open it on our mobile with limited internet connection.

So the experience is not the same for all users. Different from desktop, tablet, mobile, and maybe low-end device. And meanwhile, JavaScript framework getting more size.

And sometimes bloated. And our apps become like this: unresponsive, janky, and not a good user experience.

The Problems with Single-Page Applications6:09

We welcome to Spinnageddon era.

So turns out, single-page application that we introduced in 2010s is giving us a new problem. First, complexity. Logic, we have logic both in server and the client. State also in the server and in client.

Authentication. Reactivity. Compiler, transpiler, getting more complex. If you have try how to config with webpack,

you know what I mean.

SEO, search engine optimization issue as well, not so good for single-page application. Then single-page application usually break the back and forward navigation. And looks like with our frameworks, we are going away from web standards. Like we have to use this component called link. We have anchor, why we use link? There's a reason, but we are going away from web standard.

The Shift Back to Server-Side Rendering7:39

Then in this era, there are new wave of frameworks

like Next.js, Nuxt, Astro, Qwik, SvelteKit,

and React also develop React server component. So it's like the trend going back to the server side, not the client side.

Evolution of Server-Client Interaction8:07

As conclusion, we are going from this: if we request some file, server will return the file. And then if the client asking for one route, /about,

and then there is a backend for dynamic page. Maybe they query the data and they send back as HTML, and the web browser will render the page.

And then the client will be working more hard than server for single-page application. So if the client request, the server will send the blank HTML. And usually a spinner, and then the client will ask for new data, and there is your webpage. So you need to wait for data to arrive first, and then you can browse the application.

Meta Frameworks and Their Role9:19

And last but not least, we have a framework, meta framework. The difference from single page application and meta framework is just the initial page. So, at first, they don't send you blank HTML. They send you HTML plus data and they will render. And after that, it's almost the same. Depend on the meta framework and the feature that you use, you can use multi-page application as well. You can use as single page application as well. So, if the data changes, the client will request the data

and the data will send with type JSON

and the client will re-render the page accordingly.

What is HTML Over The Wire?10:12

Now, what is HTML over the wire? It's an alternative to create a dynamic

and interactive server render web application. So, the rendering part will be on the server.

It utilize the server to render the page and send HTML or a representation of HTML through HTTP protocol or WebSocket. You got fast first loading pages, speed and responsiveness associated with single page application without the complexity of front-end framework. You keep the state on the server. It's more simpler. You remove the data transportation and serialization like REST API. You don't need REST API, GraphQL, or even gRPC. You just serve from the server.

Benefits of HTML Over The Wire11:12

What is the benefit? First, it's server focus. So, server generate and send HTML or a representation of HTML or the whole page. It's up to you. Then, this allow developers to focus on server side, working primarily in server side language that you are familiar with. You like Python, you can use Python. You like PHP, you can use PHP. Offer better SEO, of course, and simplify state management. Because state management just happen in the server side, not in the client side. And the logic as well. Server will generate the dynamic page.

Browser just render the HTML and CSS with a little bit JavaScript if needed.

Server-Centric Approach and Reduced Client Complexity12:11

The server will do what it's best. It's for calculating, for rendering, and the browser will re-render the page.

It reduce the complexity of client JavaScript framework. If you write application that the user

will use for lower end device or IoT, it's also good use case because the processing will be on the server, not on the client. You don't need to maintain both server code and client code base. You just write your application in the server. Better backward compatibility if you support older browser and faster initial page loads due to reduce JavaScript payloads. And we can also make the application that works just with HTML and CSS.

JavaScript if necessary. And we can also create a real-time application. So, when data changes, the server will send the HTML through the wire and the client will re-render the page if necessary.

Rather than sending the raw data and to be processed on the client side. No need to transport data like I said before, REST API or GraphQL or gRPC or another transport layer.

Drawbacks of HTML Over The Wire13:52

But it has some drawbacks, of course. Because it's server focus,

maybe you need more resource for the server. The load for server will increase. But compare to the client heavy app,

it's depend on our server, not depend on our users. Our user will have the same or similar experience for the app because the hard work on the server.

It's challenging to implement robust offline functionality compared to single-page application. We need more reliable network connection for smooth user experience because every time user request some data or some page, it will contact the server and server will send the HTML. And the latency can also affect responsiveness especially for user with slow connections. And because this is a new concept, we have limited third-party libraries. Most of the time, we have to build ourselves or wrapping another library and may need time to adapt and adopt new technique and new tools.

Positioning HTML Over The Wire: UX vs DX15:17

If you draw where the positioning of the concept

with multi-page application, we can develop less complex app, less complex code, but the user experience could be better. With single-page application, if we done right, we can have a good or great user experience, but not so good developer experience. If we done right. That a big if.

And HTML over the wire in the between. So user experience is good enough for most of the cases, but we can use it without the complexity of development process.

Phoenix LiveView: A Pioneer in HTML Over The Wire16:14

The first framework that explore this idea is Phoenix LiveView.

Phoenix is batteries included web framework for functional programming language called Elixir. You can get fast first load pages speed and responsiveness that associated with SPA without the complexity of the front-end framework. You can keep the state on the server. You can write mostly your business logic on the server without having touch the client-side code.

Phoenix will send the HTML part through WebSocket. So we can push the data if data changes from the server, not from the client.

Frameworks and Libraries for HTML Over The Wire17:09

This is some of the framework or libraries that you can use for HTML over the wire. There is Hotwire from Ruby on Rails, inspired by LiveView. Then also Laravel invented Livewire.

So you can write your front-end code with PHP.

If you need more agnostic solution, you can use HTMX, the meme framework,

or Unpoly, UnpolyJS and Deno Fresh, a framework called Fresh from Deno team. You can use this approach as well.

Demo 1: Simple Dashboard with HTMX and Hono17:58

So for the demo, I will create something like a dashboard, a simple dashboard. You can see on the browser or on the client. So when we hit the URL,

it will go to the server, ask for some statistic and it will give you an HTML response. And the page will render. That's it. And the connection, HTTP connection is finished. Then when user interact with our app

for example like on click, then the server will send a new HTML, then the client will re-render. Let's see in an action.

Demo 1: Code Explanation19:08

Okay, this is the app. Yeah.

The statistic were from the backend from my laptop. You can see the CPU load, memory use, and uptime.

This is the data that sent.

This is the stats we hit to get statistic.

This is the HTML. You can see the headers. This is HTML. And it render, okay? Then if we click and we update, a new stats will send from the browser. Sorry, from the server. And it will re-render. This is HTML as well. You can see the statistic over here like CPU usage

14.43% and anything else. Okay. Let's see the code. This is the code. I'm using HTMX and Hono. So Hono is a web framework like Express in Node.js.

We've got a layout and we use the layout for rendering the layout and we use route root route slash

and render the initial stats which is all zero, right? When we refresh, start from zero and then the data will come. Okay, now we see the templates. This is the layout. We see the body and the content. The content itself is on the render stats function. And this is the HTML that get sent from server to client.

You can see in here like CPU usages or memory and uptime. Okay.

What interesting is when you use HTMX, you got a new property from HTML like 𝚑𝚡-𝚐𝚎𝚝

or 𝚑𝚡-𝚙𝚘𝚜𝚝 or 𝚑𝚡-𝚙𝚊𝚝𝚌𝚑. And you define the 𝚑𝚡-𝚝𝚊𝚛𝚐𝚎𝚝 which is for my case will replace the content or the child of the body. And when it triggers, it triggers when on load. So when we change this to every 1 second,

it will re-render every 1 second.

Okay. It change every 1 second. There is new stats HTML.

Okay. Let's change back.

That's the demo number one.

Demo 2: Real-time Dashboard with Elixir and Phoenix LiveView22:15

Now, we level up a bit. We will send the HTML through WebSocket. We can use HTMX as well, but we have to use third party library or extension in HTMX. But in this demo, I will show you the Elixir Phoenix version with the same application. But the difference is we send the data through WebSocket. So at first almost the same. We have client that does both ask something to the server and server will send HTML initial page. And then when user click something or click update

button, it will use the WebSocket to update the page.

Let's see the Elixir version.

Demo 2: WebSocket Communication and Code Overview23:17

Okay. This one, the Phoenix version. You can see, it's almost the same. The difference is there is a WebSocket connection

that sends data back and forth from the server to client and otherwise. So when we update the click the update button, it will send the data like event, type click.

Like this. The event name is update. And it will send the data. The response.

Zero. Not this. Let's see again. Okay, this is one. The response, Phoenix reply. The response is so Phoenix will send the diff or the changes only, not all HTML in form of JavaScript object like this. So the diff is just number one is 29.1, this one. This is not changing, so the server will not sending that. This is changing like 10,000.

And uptime also changing. Okay. Let's see the code. This is the code. So the Phoenix LiveView have at least two function,

the mount function.

We set the initial state here like CPU usage, model, count, memory usage, and uptime. And then we need one more which is render function.

This is our HTML or templates. Then we show the variable or the state here like CPU model and CPU usage.

And if we click button update, it will trigger

the update event. We need to define the function called handle_event. Oops.

In this one. And we update the statistic with the new data.

Right? And if we do something similar like the HTMX version before, we can update every 1 second. But this time, the server will tell that we need a timer every 1 second. It will trigger a tick event that we handle here.

Same as handle_event that will call the update stats. So if we save and we see, this is now update every second.

Thank you.

Okay.

Summary and Key Takeaways26:38

Let us back to the slide.

In summary, there is a great alternative to create dynamic and interactive server-rendered web app. It offers faster first loading page and responsiveness that we used to be on a single-page application without the complexity of front-end framework. As you can see in the demo, we haven't touched, we haven't write any JavaScript client, right? So we just focus on the server side. We keep state on the server like the old days like request response era. And no data transport needed. And we can focus on the server and back-end focus web development. That's it. This is HTML over the wire. I hope you enjoy my talk.

How many times we got?

15 minutes. Okay. If you like, I have some feedback form. If you want to give some feedback for me for this session, you can scan the QR code or you can visit feedback.riza.world.

Okay.

And you can fill out the form like a small kind of

form like this. I open as well.

Wait. Yeah. When you fill the form, it will show on the screen and on your phone as well in real time. This is using Phoenix and Elixir as well. You can see the code on the right-hand side. You can click the GitHub button if you want to see the code. It will broadcast every update that after you send the data and save to the database, and the database will or the back-end will send the updates to all our screen.

Oh, nice. Thank you. So many.

Okay. I think that's it for me. If you want to follow me on social media, you can go to GitHub or LinkedIn, YouTube, and Twitter.

Thank you very much for your time. Okay. Thank you so much, Riza. Thank you so much.