Carson Gross — Return To Hypermedia: Solving Javascript Fatigue Using Fundamental Web Architecture

In the last decade, the Single Page Application (SPA) architecture and the JSON API has begun to supplant the original Multi-Page Application architecture of web. This has allowed much more sophisticated web applications to be built and the approach has been formalized by libraries such as React and Vue. In the last few years, however, we have seen the rise of an associated phenomena: Javascript Fatigue in which developers and development teams admit to being overwhelmed by the complexity of the SPA architecture.

Links

__________________________________________________

About Carson Gross

__________________________________________________

About the Conference
The Philly Emerging Technologies for the Enterprise (ETE) is the Mid-Atlantic's premier developer's conference: we bring world-renowned speakers, plus some local favorites to speak about bleeding-edge technologies being used today. Our talks are delivered by down-in-the-dirt engineers; high-level, big-picture folks like CEOs, CTOs, CIOs, SVPs; and architects. Our speakers are the founders of companies you know and love, and you'll learn new technologies from the people who created them: the core committers, pioneers, and leading trainers and authors.

__________________________________________________

About the Host

__________________________________________________

Our Sponsors

[datguy]

I think one of the most underrated, or even completely unstated benefit to this approach is not having to waste resources and time serializing JSON. A JS framework has to take a request, serialize to JSON, send the request, then the server has to deserialize, process the request, serialize the response, send to client, which then has to again deserialize it. This is probably the most expensive part of a request cycle outside of complex DB queries, and I assume would drastically cut down round trip times as now it's just: request -> string interpolation (templating) -> response, which is just instantly inserted into the DOM as it's just html. Brilliant.

[stukennedy]

this is so simple it's groundbreaking. I'm ashamed I've never considered this before after years of wrestling with FE frameworks and horrible build tools.
PLEASE make this the next HTML standard oh gatekeepers of the web!

[drew]

Great talk. I'm completely htmx-pilled, and excited to see where things go for the framework.

[systemsincode]

Could html standard and browsers be upgraded to support this kind of dynamic html ability without using js at all?

[adildalli]

Since I started developing for the web. I was always a big fan of the SSR approach ... May be because I am a java developer. Through the last decade, I saw how heavy the FE has become using new technologies that appear like mushrooms. Almost on every season there are new version, completely different than the former, new frameworks, new tutorials .... things that just added unnecessary complexity for something that built to make life easier (HTML and browser). It so funny to observe how people tend to think of the browser as virtual machine and build whole critical systems on it. I found out that something was going wrong and dedicated some time on research... Then found this wonderful concept which I am considering for migrating the whole applications FE in the future.

Can there be something like a Virtual Dom for htmx? So you do react-like Dom manipulation on the server and that automatically gets transmitted to the browser.

[directorserge]

That's the way the future HTML should look like. Otherwise, it will be outdated forever.

[kahnfatman]

The dialectics goes on: Thesis -> Antithesis -> Synthesis (which itself becomes a new Thesis)

[repotranstech]

On the Mobile a pwa will solve most of the issues.

[laughingvampire]

there is a javascript library called hyperscript, is a library that gives you helpers to use Rreact without the abomination of JSX

[laughingvampire]

the main problem is that we moved away from hypermedia for a reason, because it is a mess, and the reason is a mess is the same reason JavaScript and all of the web is a mess, the browser wars, and you can learn about this in the Brendan Eich interviews for instance Lex Friedman's interview with Brendan is great and gives lots of the context about the whole deal, to remind us all or learn what happen. Netscape vs Mosaic started all, Netscape alliance with Sun Microsystems which Sun had no Fs to give, they only cared about people getting to know Java Dabba Doo and then came the evil Microsoft with its strategy of "Embrace, extend, extinguish" and made IE.

HTML was never about hypermedia, the idea of hypermedia is also product of the browser wars, and HTML was just about hypertext, hence the acronym and hypertext is just formatted text + images. Video and audio support were product of the browser wars, originally created as plugins by Netscape and this is how Hypermedia was coined, then Microsoft came with its own way to extend things and then they introduced AJAX.

[laughingvampire]

html5 has given us the ability to have custom tags, is called web components, so this is just a web component library, I still prefer something like ReasonML or Rescript, a single programming language that hides the entire mess of the web from me and allows me to code in a single language using its great features to organize all the mess and by writing in this single language it compiles down to server side and browser and mobile.

[laughingvampire]

this guy also forgets is that during the browser wars, in the last stage, people tried to do this, you can still find some open source programs that do this "returning of -hypermedia- html from the server" and due to the browser wars html had different behavior in each browser and then people found it to be extremely error prone, then people made object mapping to reduce the errors, and then came Microsoft with its embrace, extend extinguish strategy to give us XML and people replaced HTML with XML, XHTML, XSLT because it was a standard and you wouldn't have to use custom HTML for each browser, and people adopted it and it was more complicated and then JSON came to save us all because it was not an SGML descendent nightmare because SGML family syntax is to cumbersome.

Another complaint of back in the day is that sending back HTML was a problem because you couldn't use software to edit html, like dreamweaver and all this other software use by designers

people forget that XHTML was renamed as HTML5, relaxed some of the syntax, and it was decided that HTML5 was going to be the last version and only new tags will be added to it without any big version release other than the year of the standard, which always has been the best way to version anything, the date.

[fennecbesixdouze]

This talk is just BS.

Take his very first example: the active search implementation. There is no uniform interface being described here, the client can't just use the results of the POST to "/search" themselves, they have to have a loaded up page with a # search-results element where they can stick the HTML fragment.

The client still needs to use its in-memory state to interpret interactions with the server. You are not "firmly in the realm of hypermedia" as Carson has (wrongly, historically) defined it here, you are firmly in the same realm as the "SPA frameworks" he's lamenting.

And to be quite clear, because this is just the same as the SPA approach, you won't get any of the benefits of pure HTML from this approach: the /search fragment you return from the server will still be entirely coupled to the parent element holding the "# search-results" div/element. So you won't get the "flexibility" pointed to by the page-by-page navigation approach. You also won't get the benefits of the uniform browser interface: all of the decisions (design and implementation) about how typing in active search should work with, for example, the browser history, the browser navigation buttons, etc, is still to be made. And of course, this approach certainly doesn't give you any kind of graceful deprecation or a functioning client with browser JavaScript disabled.

Returning html fragments and replacing targeted parts of the DOM is nothing remotely new, we've been doing that since AJAX was available. And attempting to define all interactivity declaratively in HTML with frameworks based on data attributes is nothing remotely new, we've been doing that since JavaScript was available. Both of these approaches have a proven track record of not being sufficiently flexible for delivering rich experiences. They have a very good track record for very quickly delivering "good enough" functionality, but paying customers have developed much higher expectations than "good enough".