[recursivedoubts]

What we need is for HTML to get going as a hypermedia again, to make the hypermedia architecture viable for a larger set of web applications. It's been stalled at anchors and forms (with only GET and POST!) for decades now. It's astounding how much we got built with just that.

I'm trying to show where it could go with htmx:

https://htmx.org

Hypermedia (in particular the uniform interface) is what made the web special and there's no reason HTML can't be improved as a hypermedia along the lines of htmx/unpoly/etc.

We don't need something new. We need to take the original concepts of the web (REST/HATEOAS/Hypermedia) seriously and push the folks in charge of HTML to do the same. Sure, browsers as install-free RPC client hosts works and is occasionally called for, but there is a huge gray area between "applications" and "documents", just waiting for a more expressive hypermedia.

[arbenpurben]

This. This gets us 98% of the way. The people that have to worry about the 2% are not you, because your web app almost certainly doesn’t need offline-first of FPS-like user interaction, so in 98% of cases, hypermedia + tech like htmx gets you 100% of the way.

For pete’s sake, just let your server serve html. Replace only the parts of the page that need to update… with html. From your server. The poor thing is just sitting there, idling, bored, borderline depressed because it doesn’t get much of chance to do what it is meant to do, which is, you know… serve. “But it serves JSON” … is like buying a Bugatti Veyron, just to park it in your garage and use its exhaust fumes to dry your clothes 6 days of the week, with a 2 minute drive around the block on Sundays.

[hutzlibu]

"“But it serves JSON” … is like buying a Bugatti Veyron, just to park it in your garage and use its exhaust fumes to dry your clothes 6 days of the week, with a 2 minute drive around the block on Sundays."

That is a very creative analogy, but not one I agree with.

My servers should do as little as possible. They should not serve files just for the sake of it, because they have all these shiny serving features.

And I like JSON as it is not as verbose as html and I can directly work with it in javascript. And then update my html where I need it locally.

If you prefer it differently, than this is fine. The web supports many ways.

[brtkdotse]

> My servers should do as little as possible.

Why? It’s not like they wear and tear?

[_448]

One advantage of pushing the computing on the user-side is that it reduces the load on the server: less requests, less processing and smaller request sizes. Thus it reduces the bill for the developers/companies :)

[GordonS]

The server load from a server-side rendered page vs an API call that returns JSON is... very minimal.

Unless you're building at great scale, it's such a negligible difference that it really shouldn't be part of your decision making process, IMHO.

[scrollaway]

[Edit: I don't want to get into this argument right now]

[hutzlibu]

"The server load from a server-side rendered page vs an API call that returns JSON is... very minimal."

That greatly depends how you designed your architecture and if you have just a simple webpage or a sophisticated webapp displaying data in various ways.

My main app is designed to work mainly offline, with bursts of data transfer. All the state is local. Sending html from the server would mean in my case, the server would need to know and keep track of all the user states and data.

[DeathArrow]

>One advantage of pushing the computing on the user-side is that it reduces the load on the server:

But we don't need complicated frameworks on the server, keeping track of changes in a shadow DOM and updating the real DOM afterwards.

The server will likely just use some html templates in which it will replace some variables with strings and numbers. Easy peasy, both for the server and for the developer.

[snomad]

Since all the clients have to do the work, doesn't that result in a net increase in electricity consumption? Since most electricity comes from fossil fuels doesn't that in net hurt our battle against climate change?

[hutzlibu]

Servers are probably a bit more energy efficient than most consumer devices, but in general it does not matter if you calculate it at A or at B. Somewhere it needs to be processed.

You were maybe thinking of processing once and then push it to thousands of clients? Those scenarios exists, but are the exception and not the topic here.

[brtkdotse]

So by spending thousands of dollars on developer time we can save dozens of dollars on server costs? ;)

[Xevi]

The developer time isn't higher than if it was server side rendered. And for some applications, like the ones I'm building, it would be impossible to do the work on the server.

[mvolfik]

I wouldn't say that it increases developer time. From my (sure, limited) experience of building both with Flask (Django-like, Python BE framework) and Svelte, the difference between developer time is negligable, if not in favor of building on the client - the component frameworks bring much more to the table, like scoped CSS, often better editor support for dynamic values in the HTML templates etc.

[hutzlibu]

It is all a question, of how big you want to scale it.

[sodapopcan]

Eeeeeeexactly

[nsonha]

> For pete’s sake, just let your server serve html

You do realize this means all the user data has to be sent to the cloud? Which is what we want to escape? Hypermedia was created for bots for discoverability, I don't know why anyone would think this is an user-centric concept.

[pphysch]

HTMX is fantastic. Today I built a proof of concept in Django+HTMX+D3.js. Fully reactive, interactive, HTML-first widgets with no npm nor "build" stage. Do anything with good ole HTML templates and just HTMX and D3!

[tachyon6]

I’d love to see the demo! I’m in the process of building something similar

[dgb23]

Htmx is very well designed library and I‘ve been using it more and more. It’s great to have it in my toolbox.

The reason it, and the many other cool libraries can exist is borne out of the strength of the web, namely a solid, accessible foundation of protocols and formats with extensibility via JavaScript.

This last part is incredibly important, because it gives us enough power to create and explore new things, while the web standards can conservatively adopt new capabilities.

The web is working as intended, and while there are many issues and lacking areas (which htmx illustrates beautifully), we can take a step back and appreciate how amazing and empowering a platform it is.

[recursivedoubts]

agreed, fielding specifically mentions scripting as an optional constraint in section 5.1.5 of his dissertation, "Code on Demand":

https://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arc...

and it has proven to be an incredibly flexible aspect of the web

however, I would note, currently that scripting ability is being used mainly to replace the original hypermedia model of the web (with RPC-style JSON-based applications) rather than enhance it as a hypermedia

we'll see if we can change that

[acabal]

I've always been shocked that HTML forms only support GET and POST and there's zero interest in supporting more HTTP methods in forms even in 2022. If forms supported the whole range of HTTP methods we could have a user facing web that's identical to a REST API, with different Accept and Content-type headers. Imagine how much development time we could save if forms supported DELETE and PUT!

[majormajor]

Does that save us much time? In the systems I've worked on, the problems of deletions and edits aren't HTTP verbs, they're wild, complex business rules around authentication, authorization, auditing, etc.

[recursivedoubts]

it's incredible that we got WebGL, Web Assembly and a million other things that are neat, but not really crucial to a proper hypermedia implementation, but they can't give us DELETE, PUT and PATCH in HTML, even though they are sitting there in HTTP just staring us in the face!

the irony is that DELETE, PUT and PATCH are used today almost exclusively in non-hypermedia JSON data APIs

crazy world!

[bawolff]

That's pretty silly. This is like claiming the world would be fundamentally different if we used <em> instead of <b>. Anyone who thinks this is remotely useful is already doing it by either using ajax or by just overloading POST. We do not save development time by renaming a concept.

[dragonwriter]

> Imagine how much development time we could save if forms supported DELETE and PUT!

not much; while you need a little (easily reusable) JS code to use and handle responses to other methods, it's such a tiny fraction of the dev effort that goes into web apps that it makes no meaningful difference.

It would be nice if HTML forms supported other methods for completeness, but it wouldn't save all that much real-world development effort.

[Devasta]

The W3C attempted to improve HTML forms with xForms, but the browser vendors are deathly afraid of anything XML based so it never got implemented.

These days HTML is really only viewed as a payload carrier for your JS application so doubt that'll ever change either.

[DeathArrow]

You know you can update or delete a resource by using GET or POST?

[zzo38computer]

You can, but it is not the proper way to work HTTP.

[anoy8888]

Am I the only one who is not excited by this new web idea ? As a web developer, we have to deal with framework and library major reinventions every couple of years and now you are telling me that you are going to reinvent browser rendering engines that we need to develop and test and then also your crappy reinventions . Thanks but no thanks . Please just build on top of giants . Not reinvent everything all the time .

[fredrikholm]

New idea? Hypermedia is from 1965, and has been a thing since 1991; HTML. recursivedoubts HTMX library is cutting edge 2005 technology.

To add to both of your arguments, "JS-routers" like SvelteKit/NuxtJS/NextJS are literally reinventing server side rendering for the client to then call the actual server to get data ... to render HTML.

HTMX, LiveView, Livewire, Hotwire etc are escape hatches back to sanity.

[Tade0]

> SvelteKit/NuxtJS/NextJS are literally reinventing server side rendering for the client to then call the actual server to get data ... to render HTML.

It's all done in one call - at least in Svelte. You can even render all this into a fully static site.

Meanwhile htmx and the like is the same idea that was popular 15-ish years ago, which died for good reasons.

[recursivedoubts]

the reason it, that is the idea of hypermedia, died was because you weren't able to achieve the same level of interactivity as you could with javascript-based applications, even back in 2005

this was due to the fact that HTML stopped advancing as a hypermedia, as I say in my original comment

htmx and other libraries are attempting to address that by pushing HTML forward as a hypermedia, which allows you to implement more sophisticated user interfaces purely in hypermedia terms:

https://htmx.org/examples/

the hypermedia idea itself is extremely innovative and interesting and, at some level, today's javascript applications are new iterations of an even older idea: client-server based RPC applications, as we built back in the 1980s

[DeathArrow]

>the reason it, that is the idea of hypermedia, died was because you weren't able to achieve the same level of interactivity as you could with javascript-based applications, even back in 2005

But I neither want nor need much interactivity in Web sites. Interactivity is for applications and applications are much better on desktop or mobile than on the Web.

[codethief]

> HTML stopped advancing as a hypermedia

Nitpick: "media" is plural. The singular is "medium".

[cassepipe]

Curious about those good reasons. Care to elaborate ?

[Tade0]

The chief reason was organisational - you needed full-stack developers for just about anything and they had to specialize in your stack - especially the language used on the backend.

While there's no shortage of frameworks on the frontend, it's all still JS/TS, so everyone is using the same idioms.

Other problems:

1. 1:1 mapping of endpoints to presentation. Common cases where this blows up:

A. A list of items which looks different depending on the context or has different styles of presentation switchable via buttons.

B. Two or more different data sources, combined in different ways.

Now you need endpoints for each context(A) or combination(B), which makes a mess in your cache. You also send way more data this way - especially if your users tend to fidget(A).

2. Inherently slow. You either replace whole parts of the DOM - which triggers a massive reflow or you make smaller changes by comparing new and old HTML in which case you need to parse both versions and deduce what changed and how.

Unfortunately since this is all just HTML you don't have object references to the data that was used, so you can't employ some of the neat performance tricks modern frameworks use, like detecting a row swap.

3. HTML elements with state, e.g. a canvas, video/audio, file upload input or even a textarea with a selection. You have to store this state somewhere, but sometimes (like with a "tainted" canvas) you can't access it at all due to security reasons, so now you have to cut around it when you're updating.

Selection is especially a piece of work, because browser implementations differ significantly to this day.

[malloryerik]

Maybe what was a "good reason" 15 years ago isn't anymore, namely the lack in those days of WebSockets and, if I'm correct, widespread Server Sent Events?

[seydor]

I don't think the reasons were good

[thestepafter]

I have been reading a lot about HTMX and planning to develop an app in it on top of a JSON API. With that being said do you know if any open source apps that do authentication on top of a JSON API using HTMX? I’m having trouble conceptualizing the structure and flow of data from just reading the docs. Primarily around maintaining state between pages. (Looking to use JWT for authentication.)

[egeozcan]

htmx is designed to work with a HTML API. Everyone here seems to love it, I found it forces terribly complicated routing and templating and IMHO projects grow towards unmaintainable very quickly. I'm saying this as a person who really tried hard to like it.

You can perhaps use Alpine.js plus sprinkle htmx here and there, to have the best of both worlds, at least on paper. Didn't try this myself.

[recursivedoubts]

i'm old enough to remember when everyone here hated it ;)

[egeozcan]

I used intercooler.js (the predecessor of htmlx) a lot to sprinkle interactivity on top of static pages. Back then I remember the attidute was positive for it too. Not for building proper web apps though...

[knighthack]

HTMX has been one of the best libraries I've used to date. Love it to bits.

[recursivedoubts]

:) glad to hear you are finding it useful

[jacobr]

Instead we get Web Components, where HTML is an afterthought. Only years later are we getting things like Declarative Shadow DOM. You’re always expected to write custom JS for every single component on your page, instead of doing something like “add this functionality whenever you see the `foo` attribute on any HTML element”

[agumonkey]

There's also ergonomics voids in the document approach. Humans don't just use documents, they do higher order things.