The Most Important Lesson From HTMX

Summary

The script discusses the common practice of building complex client-side applications that require excessive API calls and client-side logic, resulting in poor performance and security issues. It advocates moving back to server-side rendering using frameworks like Intercooler.js or HTMX, allowing developers to build expressive and secure apps without API churn. The core argument is that trusted server-side code avoids the security pitfalls of putting too much logic in the hands of the untrusted client.

Takeaways

• 😟 API churn from constantly changing UIs is a major pain point
• 😀 Increasing client-side expressiveness can reduce API churn
• 😨 But more expressive client-side APIs increase security risks
• 😟 Building robust security for expressive APIs is extremely hard
• 😊 Server-side rendering avoids client-side security issues
• 👍 Server-side code is trusted so you can give devs more power
• 🤯 HTMX lets you render HTML on the server to avoid client issues
• 🔒 Server-side rendering reduces the need for complex security
• 😃 HTMX and Next.js enable simpler full-stack applications
• ✅ Server-side solutions simplify development and improve security

Q & A

What is API churn and why is it a problem?

API churn refers to the constant tweaking and modifying of API endpoints to support changing UI needs. This leads to a chaotic situation with lots of ad hoc APIs that need to be updated frequently.

How can increasing client-side expressiveness help with API churn?

By increasing the expressive power of API endpoints through solutions like GraphQL, frontend developers have more control over how data is returned. This means the API can remain stable as UI needs change.

What is the main security concern with client-side expressive APIs?

Putting powerful and expressive APIs in the browser makes them accessible to potentially hostile users, not just front-end developers. So exhaustive access control needs to be implemented.

Why can giving front-end developers server-side rendering capabilities help?

On the server-side, code is trusted so developers can be given flexible data access without security concerns. Solutions like Intercooler allow server-side HTML rendering.

What is the core trade-off discussed in the article?

The article discusses the trade-off between API churn and security complexity. Increasing client-side expressiveness solves API churn but causes security issues.

What does HATEOAS stand for?

HATEOAS stands for 'Hypermedia as the Engine of Application State'. It's an architectural approach where HTML responses define the client-side application state.

How can server-side solutions like Intercooler help?

Solutions like Intercooler allow server-side rendering logic while avoiding client-side complexity. This provides flexibility without security issues.

What are the benefits of using HTMX?

HTMX allows server-side HTML rendering while keeping modern, interactive UIs. It avoids the need for complex client-side code and security models.

How do server components compare to GraphQL?

Server components render HTML on the server like GraphQL returns data. But server components avoid GraphQL's client-side security issues by running logic on the trusted server.

Why does the author recommend moving more logic to the server?

Server-side logic avoids client-side complexity, security issues, and chaos. It makes applications easier to build while empowering front-end capabilities.

Outlines

00:00

😮 The challenges of designing APIs for complex UIs

The first paragraph discusses the issues that arise when designing APIs to support complex and constantly changing user interfaces. As UIs evolve, APIs need to change frequently to meet their needs, resulting in API churn. This leads to chaotic and difficult to maintain APIs.

05:01

😱 The security risks of highly expressive APIs

The second paragraph highlights the security risks associated with highly expressive APIs like GraphQL that are exposed to clients. These put a lot of power into the hands of potentially malicious users and require complex security models to lock down access.

Keywords

💡API churn

API churn refers to the frequent changes and tweaks required in API endpoints to support changing UI/frontend needs. As the article states, letting UIs drive API design leads to chaotic, hard-to-maintain APIs. This is a key problem the video highlights.

💡client-side logic

Client-side logic refers to code that runs in the browser/on the client side. The video argues that heavy client-side logic requires complex security models to prevent access by hostile users.

💡graphQL

GraphQL is a query language that allows clients to request exactly the data they need. The video suggests graphQL and other generic APIs lead to complexity and security issues.

💡HTML rendering

HTML rendering means generating HTML markup on the server before sending it to the client/browser. The video advocates doing more HTML rendering server-side to avoid client-side complexity.

💡intercooler.js

Intercooler.js (now called HTMX) is a library for dynamically updating UIs using HTML. The video suggests it allows moving logic back to the server to avoid client-side problems.

💡security model

The security model refers to the system design and measures in place to control access and prevent abuse. More complex client-side logic necessitates more elaborate security models.

💡server-side code

Server-side code runs on the backend server. The video argues this is more secure since servers are trusted environments, unlike client-side browser code.

💡server components

Server components render UI markup on the server, before sending to client. The video suggests they avoid client-side complexity like security issues.

💡trusted environment

A trusted environment refers to places like servers where code can be trusted and given more access/power. Unlike browsers which can run hostile code.

💡UI/frontend developers

UI/frontend developers write code that runs in the browser and handles user interfaces. The video discusses challenges in providing them more power via client-side logic.

Highlights

Heavy clientside logic requires a tradeoff between API churn or an increasingly complex security model

Letting something that is constantly in flux like the UI determine the shape of your API causes API churn as you try to keep up

Increasingly expressive endpoints put power not just in frontend devs' hands but also potentially hostile users

Context sensitive field level security is needed on every field returned by an API to properly secure expressive endpoints

There's a tension between empowering frontend devs with expressive APIs and the security headaches this causes

On the server side, code is trusted so developers can have complete flexible data access without security issues

Generating frontends on the server avoids client side security complexity and API churn issues

HTMX and server components replace the need for complex security models required by graphQL and expressive endpoints

HTMX and server components are the future of full stack development by avoiding client side security issues

Replacing APIs with endpoints that serve HTML solves the API churn and security tradeoff issue

HTMX is the rediscovery of hypermedia as the engine of application state where HTML defines app state

Moving more application logic to the server makes everything easier and makes frontend developers more capable

The security models required by graphQL and expressive endpoints already feel antiquated compared to HTMX and server components

There are more things to know with HTMX and server components but those things are simpler and result in better software

Should more application work move to the server than is being done today?

Transcripts

I talk a lot about how much I love HTML

not specifically like an HTML file or

the HTML syntax but the power of sending

static markup from the server to the

client there A lot of times where you

might want to send updated UI to the

user without having to make them refresh

the whole page there's also a lot of

things you probably want to do when a

user clicks a button that can't be done

on their computer so you're going to

need the server to be involved in those

things anyways what I've seen as a

result is a lot of applications that

send giant Json payloads to the user

once they've done something on the

client and then the JavaScript parses

that data transforms that into some new

markup and then renders it on the page

often very slowly the JavaScript

necessary to do all of this stuff gets

massive to the size of tens of megabytes

for some websites and the resulting

performances what you would expect not

great thankfully we're starting to see a

revolution where we're moving away from

these giant Json payloads and towards

sending markup to the user when it makes

sense but this isn't a new Revolution

this is actually something that the HTM

X team has been pushing hard for a while

all the way back when they used to be

called intercooler JS they tried to warn

us but now we're finally hearing it what

we're talking about here is a response

to a great tweet from Z the CTO of

Sentry which was joking about how we got

tricked into using graphql while I do

think graph Q has a lot of benefits

there are negatives too and that's the

joke here is a lot of people were using

it when they shouldn't be but these

continued abstractions where you were

building more and more complex API

Solutions so the client could get the

info it needed this became a very fast

slippery slope and graphql emphasized

how slippery that slope had gotten the

HTM X team replied with a link to a blog

post from

2016 about this where they tried to warn

us and for those who don't know

intercooler was the old name for HTM X

so let's take a look at this blog post

because I love it and I think it's more

relevant now than it's ever been before

the API churn to security tradeoff tldr

heavy clientside logic requires a

trade-off between API churn or an

increasingly complex security model the

problem a recent article by Jean jaac de

BR titled why I no longer use MVC

Frameworks sparked a long and

interesting discussion on Hacker News

which crystallized a fundamental problem

I see with the current Trend towards

heavy client side logic and web apps

here is the start from that article

where Jean jaac lays out the problem the

worst part of my job these days

designing apis for front end developers

the conversation inevitably goes as Dev

so this screen has data elements XYZ

could you please create an API with the

response format

XYZ me okay I don't even argue anymore

projects end up with a gazillion apis

tied to screens that change often which

by Design requires changes in the API

and before you know it you end up with

lots of apis and for each API many form

factors and platform variants to

summarize if you are designing Network

API endpoints for a front end you will

end up tweaking and modifying the API to

support your UI needs in an ad hoc and

often chaotic manner by letting

something that by its nature is

constantly in flux and fiddly that is

the UI determine the shape of your API

you end up thrashing it around trying to

keep up for the remainder of this

article I will refer to this problem as

API churn that's an important piece to

remember API churn is the enemy that

we're fighting with all of this so

what's the solution the solution is if

you're committed to that client side

increase the expressiveness of the API

available on the client side okay so

what does that mean means you must begin

surfacing more and more generalized data

access and mutation functionality on the

client side you see this General query

languages like graphql replacing

multiple rsh in ad hoc API endpoints

with fewer more expressive endpoints is

going to be thought of as a move towards

something like SQL on the client side I

don't like comparing it to SQL but I get

what they're trying to say by increasing

the expressive power of endpoints you

the API designer no longer need to worry

about getting an API just right rather

the frontend developer has control over

how and what is returned or what is

modified and your API stays stable as

the UI needs change sounds great but

wait a second there's a problem with

this solution problem these increasingly

expressive endpoints is that you're also

putting them not just in the hands of

your front end de but also the hands of

potentially hostile users the browser is

about the least secure Computing

environment I can imagine and anything

that the front end devs can do can also

be done by a hostile user like this

graphql query if you don't make this

really secure you're going to have users

able to hit it and get info they

probably shouldn't like salary this is

terrifying and a lot of graphql stuff

wasn't set up properly I have a video

about how putting your logic in your

database is terrifying and the reason a

lot of people were stuck doing things

like that is because they have these

generic API layers that don't know

enough about the intent of how it's

being used to first off expose data

correctly but more importantly to

authenticate the user properly to make

sure they should or shouldn't have

access to that data it's utter chaos and

I've seen so many code bases drowning in

this particular style of mess and oops

you had better darn well not show that

information so now you have to build

context sensitive field level security

so on every query on every field in

every query you have to work really hard

to make sure your fields are properly

secured so now every single key being

returned by your API ever has to have

its own security model around it you can

see how chaotic and hard to maintain

that gets really

fast as I just said this is incredibly

complicated and when this security issue

was brought up on Hacker News the

response was it doesn't belong in the

spec it belongs in the implementation

but yes the reference implementation

graph qjs should probably be updated to

demonstrate Access Control at the time

the go2 example for graphql and web apps

was graph qjs and they didn't have data

Access Control implemented in it so

people just copy the default

implementation didn't have any security

which is terrifying I literally laughed

out loud when I read this this is a

major major issue and anyone who

considers increasing client side

expressiveness as the answer to API

churn needs to have a very good answer

for it I totally agree this isn't just a

security problem there's also so many

technical challenges in implementing

things in this way where it's just hard

to build and maintain a generic way to

get data to the client security is one

part design of the schema is one part

implementation details libraries you're

choosing all of this stuff gets really

complex really fast but what if there

was a better way this again is about

trust the core problem again is that in

putting more expressive tools in the

hands of your client side devs you are

also inadvertently letting them slip

into the hands of adversarial users

there is a fundamental tension therefore

between how much you can give your

developers and how much of a security

headache this power will turn out to be

in an Ideal World you will give your UI

developers everything they could

possibly need in an open and expressive

query layer and that would let them tune

the structure and return the data of a

query just so for those hot complicated

quer I that always end up dominating

system performance what if I told you

there was a place that exists where you

can do this such a place does exist it's

called the server side see where we're

going guys don't know if you expected

this but I just tricked yell into

watching yet another server components

video because this article could be

summarized as the arguments for Server

components and or how server components

replace graphql they solve this problem

really really well you see on the server

side code is trusted you can give your

developers a completely open and

flexible data access and and update API

because you to a first order

approximation trust them give them the

power of say a structured query language

and that's totally fine it's not even

controversial when you do that because

that power isn't going to the user it's

just in the layer between the HTML the

user sees and the server that has that

data when you give your frontend devs

the ability to generate their front ends

on the server a lot of these problems go

away really fast and it's funny that I'm

bringing this up because a lot of the

reason people are so hesitant with the

new server component model and the new

nextjs model is they think it's less

secure and they don't trust frontend

devs to do it right the harsh reality is

these backend devs have gotten so good

at these security models because they're

a necessary evil in order to use

something like graphql while yes front

and devs need to think a little bit

about security Now the benefit that

comes with it is they don't have to

think about security anywhere near as

much and we're not building these crazy

chaotic systems so that you can add one

additional key to your query on the

client side the solution to the problem

with the solution so if you want to

avoid this API churn and security

complexity trade-off is's a great way to

do it move things back to the server

side one way to do it without

sacrificing modern web usability is to

use something like intercooler into do

your HTML rendering and domain Logic on

the server in a trusted environment

you'll also get a lot of other benefits

from this approach hate without tears a

programming model that you likely

already have close to a decade of

experience with and so on this is an old

article and my audience probably doesn't

have a decade of experience with things

that were already old at the time seven

years ago but that point aside let me

know if you want me to do a hate OS

video because it's a pretty cool pattern

where do they actually say what it

stands for always forget the acronym

stands for hyper media as the engine of

application state so your HTML is

actually the thing that defines the

state of the page it's a really cool

pattern it's really nice seeing this

being rediscovered with a new error of

HTM X if you want a long video about

that let me know in the comments this

video isn't about that this video is

about the value of replacing your apis

with end points that serve HTML the core

point of this article is that in order

to make Dynamic front ends without

having the server run the HTML you now

have to deal with with a massive

security issue architecture issue and

utter chaos in order to increase the

expressiveness so client side developers

can do the things they need to do to

make good applications this is what's so

cool about this model and this is why I

think both HTM X and server components

are the future of how we build full

stack applications these security models

already feel so Antiquated and the

moment you start playing with either

HDMX or server components you're going

to realize just how much more complex

things were than they needed to be yes

there are more things you need to know

about well those things are simpler and

the result is better software so what do

you think are we being too aggressive

with the killing of apis or should we be

doing more work on the server than we

are today I'm obviously in favor of

moving more of the stuff to the server

it makes everything easier and it makes

frontend developers more capable of

delivering great software but how do you

feel about it let me know in the

comments and tell me if I should do that

ha to OAS video because something I want

to talk a bit more about if you want to

learn the truth about HTM X I'll pin a

video in the corner with that and if

You' already seen that or you're not

interested the video below should be

pretty good too thank you guys as always

appreciate you all a ton peace nerds