0% found this document useful (0 votes)
12 views5 pages

ProQuestDocuments 2024 05 23

HTMX is a JavaScript library that allows users to add interactivity to web pages using HTML attributes instead of JavaScript code. It supports features like form submission, loading content, and updating pages without reloading. The library handles interactions on the server side by rendering HTML markup in response to requests instead of JSON.
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
12 views5 pages

ProQuestDocuments 2024 05 23

HTMX is a JavaScript library that allows users to add interactivity to web pages using HTML attributes instead of JavaScript code. It supports features like form submission, loading content, and updating pages without reloading. The library handles interactions on the server side by rendering HTML markup in response to requests instead of JSON.
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 5

Intro to HTMX: Dynamic HTML without JavaScript

Tyson, Matthew

Enlace de documentos de ProQuest

RESUMEN (ENGLISH)
The user update in HTMX hx-target="this" hx-swap="outerHTML"> First Name: Joe Last Name: Blow Email:
[email protected] hx-get="/contact/1/edit" class="btn btn-primary"> Click To Edit hx-put="/contact/1" hx-target="this"
hx-swap="outerHTML"> First Name type="text" name="firstName" value="Joe"> class="form-group"> Last Name
type="text" name="lastName" value="Blow"> class="form-group"> Email Address type="email" name="email"
value="[email protected]"> class="btn">Submit class="btn" hx-get="/contact/1">Cancel If you look at the markup in
Listing 1, it is easy to see what is happening: the hx-swap property provides the HTML for the div before it is edited,
and outerHTML tells the framework how it relates to the dynamic content inside. The answer is easy: it uses server-
side rendering of the HTML for the edit markup and abstracts the form marshaling into the framework. To start, the
existing to-do items are output from Express with the command: res.render('index', { todos: filteredTodos, filter,
itemsLeft: getItemsLeft() }); This command uses the in-memory collection of to-dos and renders them with a Pug
template that is in the typical format, except it includes the special hx- properties that drive HTMX interactions. Tips
and best practices from developers * Python moves to remove the GIL and boost concurrency * 7 reasons Java is
still great * The open source licensing war is over Crédito: Matthew Tyson

TEXTO COMPLETO
HTMX lets you use an extended HTML syntax instead of JavaScript to achieve interactivity. HTMX gives you HTTP
interactions directly in the markup, and it supports many other interactive needs without resorting to JavaScript. It’s
an interesting idea that could end up influencing the way web front-ends work. Let’s see how HTMX is used and
what makes it so compelling.
What is HTMX?
HTMX has been around for some time, but it has been a bit of a sleeper project. Its recent acceptance into the
GitHub Accelerator may change all that. The basic idea is to take common use cases that require boilerplate
JavaScript-and-HTML interactions and just use an HTML syntax, without the JavaScript. Many interactions become
declarative with HTMX.
This already sounds promising, doesn’t it? Every web developer knows there are many common boilerplate cases.
Carson Gross, the creator of HTMX, says he’s hoping to "complete HTML as a hypertext, increasing its
expressiveness enough to make it a competitive alternative for more advanced, modern web applications.”
To get a quick taste, see this HTMX demo. Basically, we click on a button to enable editing the fields on the user
object. The data is actually PUT into a back-end endpoint. You can see the demo in Figure 1—notice the network
interaction in the bottom frame after you click Show.
[Image Omited]
Normally, this all would require JavaScript of some kind, no matter what framework you were using. HTMX turns the
interaction into two chunks of markup: one for the display UI and one for the edit UI, as shown in Listing 1.
Listing 1. The user update in HTMX
hx-target="this" hx-swap="outerHTML">
First Name: Joe
Last Name: Blow
Email: [email protected]

PDF GENERADO POR PROQUEST.COM Page 1 of 5


hx-get="/contact/1/edit" class="btn btn-primary">
Click To Edit
hx-put="/contact/1" hx-target="this" hx-swap="outerHTML">
First Name
type="text" name="firstName" value="Joe">
class="form-group">
Last Name
type="text" name="lastName" value="Blow">
class="form-group">
Email Address
type="email" name="email" value="[email protected]">
class="btn">Submit
class="btn" hx-get="/contact/1">Cancel
If you look at the markup in Listing 1, it is easy to see what is happening: the hx-swap property provides the HTML
for the div before it is edited, and outerHTML tells the framework how it relates to the dynamic content inside. The
editable version arrives as a form element that contains the x-put property, which identifies the PUT HTML method
and what endpoint to use.
The question becomes, how does HTMX achieve this “swap” and subsequent PUT without doing any JavaScript?
The answer is easy: it uses server-side rendering of the HTML for the edit markup and abstracts the form
marshaling into the framework. The JavaScript is still working behind the scenes. Essentially, we get a more
granular HTML syntax, which can just load segments instead of whole pages, and can submit Ajax requests.
This is an interesting example of the DRY principle in action. Even with something like React, there’s a certain
amount of boilerplate code that shuffles information from one form to another. Of course, HTMX hasn’t eliminated
that entirely, but it has shifted the work onto the server.
Server-side HTMX
Now let's consider the server side of the equation. There are examples of many server-side technologies using
HTMX because, as Gross says, HTMX is "back-end agnostic. It doesn't care what back end you use, so long as it
produces HTML.” To get a feel for how it works, let’s look at a TODO example that uses Express, along with the Pug
HTML templating engine. This example is an implementation of the classic TODO application.
To start, the existing to-do items are output from Express with the command:
res.render('index', { todos: filteredTodos, filter, itemsLeft: getItemsLeft() });
This command uses the in-memory collection of to-dos and renders them with a Pug template that is in the typical
format, except it includes the special hx- properties that drive HTMX interactions. For example, the form to POST
new to-dos is shown in Listing 2.
Listing 2. Form POST with HTMX properties
form(hx-post="/todos", hx-target="#todo-list", hx-swap="afterbegin", _="on htmx:afterOnLoad set #txtTodo.value to
''")
input#txtTodo.new-todo(name="todo",placeholder='What needs to be done?', autofocus='')
You can see here how the afterbegin attribute works to put the new content where it belongs in the list. The on htmx
scripting is an example of Hyperscript, a kind of simplified scripting language. It is often used with HTMX, but isn’t
strictly part of HTMX or required to use it. Essentially, on htmx is used here to handle setting the value of the input
form after the new to-do has been created.
As another example, Listing 3 shows the Pug template for the to-do edit.
Listing 3. Editing the server-side template in PUG
form(hx-post="/todos/update/" + todo.id)
input.edit(type="text", name="name",value=todo.name)
In Listing 3, the markup uses the hx-post property to indicate where to send the JSON for the edited to-do. The

PDF GENERADO POR PROQUEST.COM Page 2 of 5


takeaway from these examples is what I noted earlier: the server is responsible for providing HTML (decorated with
HTMX tags) in the right-sized chunks to fill the different parts of the screen that are required by the front end for its
various interactions. The HTMX client will place them where they belong based on the properties, and will also
handle sending the appropriate data for consumption by the services.
The endpoints responsible for receiving the data can operate like typical endpoints, with the distinction that the
response should be the necessary HTMX. For example, in Listing 4, you can see how the Express server handles
the POST to create a new to-do.
Listing 4. Handling to-do creation
app.post('/todos', (req, res) => {
const { todo } = req.body;
const newTodo = {
id: uuid(),
name: todo,
done: false
};
todos.push(newTodo);
let template = pug.compileFile('views/includes/todo-item.pug');
let markup = template({ todo: newTodo});
template = pug.compileFile('views/includes/item-count.pug');
markup += template({ itemsLeft: getItemsLeft()});
res.send(markup);
});
Listing 4 is a typical POST body handler, which takes the values off the form data and creates a new business object
with it (newTodo). However, it then uses the values to populate the Pug template and send that back to the client to
use as an insertion to the Todo list on the front end.
Other examples of server-side technology includes using HTMX along with Spring Boot with Thymeleaf in the Java
world and Spring Boot with Django in the Python world.
Client-side templating with HTMX
A variation on this pattern that is supported by HTMX is using a client-side template. This is a layer that runs in the
client and accepts JSON from the server, and does the markup translation there. When I asked Gross about using a
RESTful service with JSON, he indicated it was possible with client-side templates, but with the caveat that REST is
commonly misunderstood.
An inverse question, then, is how can we submit JSON to the server instead of the default form encoding? Once
again, there’s an extension for that; namely, JSON-ENC.
Conclusion
Contemplating HTMX causes a bundle of thoughts to arrive all at once. The upshot is that the notion is as beneficial
as the project itself. HTMX as a mature project may not wind up working precisely as it does today, but it has already
proved to be a helpful influence. The thing that is most compelling is the idea of handling all these very common
Ajax-style requests, which would normally mean using fetch() or something similar, with just an HTML property. This
is just simpler, cleaner, and keeps everything in one place. It’s very obvious what the markup does.
I’m more ambivalent about the server-side markup generation. Developers are so accustomed to dealing with JSON
for this purpose; bringing in markup just adds a step to the client creation. We’ve seen numerous server-side
approaches and they always seem to obfuscate the powerful trio of HTML, JavaScript, and CSS, which continues to
win out in the end. Maybe this time will be different. It’s a big pendulum to swing.
Of course, there is the client-side templating option, which leaves the server as a familiar JSON emitter. I tried
picturing how it would work in a big software project. Would it reduce overall complexity in a project at scale?
Gross has his own thoughts on complexity. You can see his thoughts come to bear in the design of HTMX. This

PDF GENERADO POR PROQUEST.COM Page 3 of 5


technology wants to simplify things by returning us to Hypertext as the state mechanism for web applications. This
example shows the idea at work. Using JSON as the protocol means making clients smarter, more complex, and
making the architecture less self-describing.
Maybe it could all work. If we avoided the inherent complexity by expanding the underlying language, HTML, to
actually handle modern requirements, like Ajax, we could return to a simpler time. The markup would once again be
the central data descriptor, and sufficient to describe the UI, as well as the data on the wire.
Next read this:
* Cloud computing is no longer a slam dunk
* What is generative AI? Artificial intelligence that creates
* Coding with AI: Tips and best practices from developers
* Python moves to remove the GIL and boost concurrency
* 7 reasons Java is still great
* The open source licensing war is over
Crédito: Matthew Tyson

DETALLES

Materia: Electronic mail; Best practice; Artificial intelligence; Syntax; HyperText Markup
Language; JavaScript; Software; Developers; Software industry; Java

Término de indexación de Asunto: Artificial intelligence Developers Software industry; Sector: 23721 : Land
negocios: Subdivision 51321 : Software Publishers

Clasificación: 23721: Land Subdivision; 51321: Software Publishers

Título: Intro to HTMX: Dynamic HTML without JavaScript

Autor: Tyson, Matthew

Título de publicación: InfoWorld.com; San Mateo

Año de publicación: 2023

Fecha de publicación: Sep 20, 2023

Sección: Software Development, JavaScript, HTML

Editorial: Foundry

Lugar de publicación: San Mateo

País de publicación: United States, San Mateo

Materia de publicación: Computers--Microcomputers, Computers--Computer Industry

Tipo de fuente: Revista especializada

Idioma de la publicación: English

PDF GENERADO POR PROQUEST.COM Page 4 of 5


Tipo de documento: News

ID del documento de 2866426393


ProQuest:

URL del documento: https://www.proquest.com/trade-journals/intro-htmx-dynamic-html-without-


javascript/docview/2866426393/se-2?accountid=14542

Copyright: Copyright Foundry Sep 20, 2023

Última actualización: 2023-09-22

Base de datos: Advanced Technologies &Aerospace Collection; ProQuest One Academic; ProQuest
One Business

Copyright de la base de datos  2024 ProQuest LLC. Reservados todos los derechos.

Términos y condiciones Contactar con ProQuest

PDF GENERADO POR PROQUEST.COM Page 5 of 5

You might also like