HN Theater @HNTheaterMonth

I love HTMX and similar technologies but I think GitHub is a particularly telling example of what can go wrong with these techs. The frontend is so full of consistency bugs that it's appalling: https://youtu.be/860d8usGC0o?t=693

One feature that's kind of difficult to emulate without Javascript is the ability to play media continuously while navigating with the back and forward buttons. Rich Harris talked about this at the 5 minute mark of his video on whether or not SPAs have ruined the web [1].

Youtube actually uses this capability specifically. If you add a Youtube video to a queue, it switches to a picture in picture mode where you can navigate while the video is still playing.

The only other technical challenge is handling animations between route changes. There's a browser api in progress (the shared element transition API) [2], that will allow animations during navigations without client side routing, but it still requires Javascript. Navigation animations are arguably just purely aesthetic though.

[1] https://youtu.be/860d8usGC0o?t=299

[2] https://developer.chrome.com/blog/shared-element-transitions...

I agree generally with the two types of experiences, but I'd also submit that there's no easy, clear deliniating line and it's much more of a spectrum between the two types. I really think some of the quirky magic of the web comes from this doc / app hybrid thing it supports and bifurcating them fully would be a mistake.

Rich Harris speaks towards that here: https://www.youtube.com/watch?v=860d8usGC0o

⬐ ordinaryradical

I think the spectrum is the right mental model, too.

E-commerce stores have different interactivity needs than blogs, which have different needs than documentation, which has different needs than dashboards, which have different needs than real-time collaboration tools, and on and on and on.

Much of the framework angst is around the assumption of a singular tool for all these varieties of interaction and the annoyance that comes with not acknowledging the trade-offs.

Plus the web itself is changing, so the breadth of this spectrum is increasing. Years ago, the ends might not have been very far apart but they are diverging more with each new use-case and app idea.

Don't forget SvelteKit / transitional apps!

Have Single-Page Apps Ruined the Web? | Transitional Apps with Rich Harris, NYTimes: https://www.youtube.com/watch?v=860d8usGC0o

hello, I am the author of this article

it is a response to a talk that Mr. Harris gave at JamStack entitled "Have Single-Page Applications Ruined the Web?":

https://www.youtube.com/watch?v=860d8usGC0o

in the article I show how a hypermedia-oriented (rather than javascript-oriented) library like htmx can address many of the usability concerns that Mr. Harris raises with MPAs, without abandoning the fundamental REST-ful architecture of the web for a more RPC-like javascript architecture.

⬐ flapjackfritz

I don't think a lot of the points in the article hit home for me.

On one hand you suggest the culture of complexity is overwhelming, when just a few paragraphs earlier you suggest that sql-tuning and redis caching are how to deal with some of htmlx's problems with latency. That seems highly complex. You have to make deep changes to the back-end and data persistence systems to solve a front end issue.

It feels like the article is trying to say you shouldn't use javascript frameworks in a lot of cases, but then it advocates for using htmx, which is a javascript framework, in those cases?

In my experience the issues people have in front-end come from using tools and frameworks incorrectly, because they don't understand the tradeoffs being made -- so they don't account for those tradeoffs in a reasonable way that eventually comes back to bite the team. Handing people a new JS library that is seeming to intend we completely avoid javascript and therefore the library itself, creating an incentive not to learn how it works.

⬐ naasking

> It feels like the article is trying to say you shouldn't use javascript frameworks in a lot of cases, but then it advocates for using htmx, which is a javascript framework, in those cases?

Htmx isn't a JavaScript framework, it's a hypermedia framework, and they're encouraging taking hypermedia as far as possible before dropping to scripting.

⬐ dang

I've changed the title above to try to say what the article is about, using your wording here (but edited to fit HN's 80-char limit). In cases like this we try to avoid references to personalities. (We also try to avoid acronyms where possible, which is why I said 'multi-page apps' instead of 'MPAs'.) If there's a better title, i.e. a more accurate and neutral one, we can change it again.

⬐ satyrnein

It seems like there are broadly 2 concerns: having rich interaction inside of a single "page", and smooth transitions between "pages". You seem to dismiss the latter in your article, but HTMX seems to support Turbolinks style functionality, correct? Can animations be layered onto that?

I did some experiments around on how to do animated shared element transitions (as well as reactive functionality) within a REST mindset here, if anyone's curious: https://dev.to/eshan/toward-the-postmodern-web-38h (you can just scroll to the embeds)

Ultimately, maybe the browser vendors will do something here, like Google's portal elements, for example. A lot of effort is being spent on that flash during page loads.

⬐ culebron21

Good luck with your effort! I started making web pages in 1998, in high school. Then years later finally got a job and worked for 7 years as web developer full-time, but after I saw Angular and React and tried making a project with them, I quit.

But even without SPA frameworks, a boilerplate for a simple project was insane: linters, assemblers, template frameworks, etc.

With React it was one notch more boilerplate, and yet after all that you had to write pretty much all the interactive UI still on your own.

⬐ tsuujin

Can you help clarify the difference between htmx and turbolinks (now just “turbo”) which has shipped with rails for years?

⬐ recursivedoubts

turbolinks takes over anchor navigation and "automagically" makes it use ajax

htmx (and intercooler.js, its predecessor which is 8 years old) is a lower level extension to HTML, allowing for targeting specific regions for replacement, using different events for triggering requests, etc.

htmx is closer to hotwire.dev, which 37signals recently released, but again is lower level and a more straight-ahead extension of HTML

⬐ chias

As someone who has been developing websites for 15+ years and who stumbled across HTMX a year or two ago, I want to add a couple things here:

One really really nice thing about HTMX is how easy it is to "spruce up" a UI. You say "this part of my website could really do with some active content" and you start thinking about xmlHttpRequest and callbacks and and JSON and all that and you think "does it really need sprucing?". But with HTMX it's usually just adding a couple hx- attributes and maybe a couple serverside lines and you're done.

Another really really nice thing about HTMX is how easy it makes it to make things degrade gracefully. Javascript enabled? Get your beautiful ajax. No Javascript? Get a good experience in the "traditional" model. In anything else I've ever seen, if you want that experience, you need to write your UI twice (and usually in two different languages / models).

So basically it drastically lowers the bar for making nicer experiences on top of a solid MPA. Especially if you're a solo developer, this basically means that you end up producing better UIs "for free".

⬐ IshKebab

I think React with SSR gives you that experience with the added bonus that you can use nice isolated and reusable UI components. The downside is you are forced to use JavaScript/Typescript for basically everything. Fortunately Typescript is a pretty decent language overall.

Also there are some systems trying to do the same thing but using Wasm (e.g. Percy).

Rich Harris would probably frame this article's take as "traditionalist" — someone who cares about the traditional benefits of the web platform and sees the flaws in modern frameworks. The problem is of course that there are also benefits to modern frameworks for users as well as developers. Rich does a good job finding a middle way through both in this talk:

Have Single-Page Apps Ruined the Web? | Transitional Apps with Rich Harris, NYTimes https://www.youtube.com/watch?v=860d8usGC0o

We are fully into React with lot's of legacy code, but today SvelteKit looks very promising... Here, Rich Harris, the guy behind Svelte tells about SvelteKit and transitional apps concept: https://www.youtube.com/watch?v=860d8usGC0o

Looks like another contender for transitional apps[1], all for it!

[1] https://www.youtube.com/watch?v=860d8usGC0o

Interesting (semi-related) video here from the graphics editor of NYT: https://www.youtube.com/watch?v=860d8usGC0o

Those interested in this debate really need to watch a very fantastic presentation on this exact topic: "Have Single-Page Apps Ruined the Web? | Transitional Apps with Rich Harris, NYTimes" [1]

[1] https://www.youtube.com/watch?v=860d8usGC0o&list=PL58Wk5g77l...

This video actually does a pretty good job of explaining the state of web today. He goes into why frameworks that stream html as updates are insufficient. The GitHub UI for example does this and its full of inconsistencies. https://youtube.com/watch?v=860d8usGC0o&feature=share

⬐ thro1

[For SPA] 'you will need a JS framework'

Incorrect.

It has been and can be done without JavaScript as well - with frames, it wasn't because of some z-index problem (so you needed JS to rewrite from hidden iframe) then XMLHttpRequest happened, isn't because lack of knowledge how to properly use them.

⬐ dmitriid

> [For SPA] 'you will need a JS framework'

> Incorrect.

How to say "I haven't listened to the talk" without saying "I havent' listened to the talk".

The accompanying commentary to that slide is "Here's a non-exhaustive list of thing people will tell you are terrible about SPA: You will need to load a bloated JS framework. It's always bloated, of course."

And then he goes on to explore the validity of these claims ("They are largely valid").

⬐ nullbytesmatter

You need to enable JavaScript to view this comment.

⬐ thro1

It has been and can be done without JavaScript as well - with frames, it wasn't because of some z-index problem (you needed to rewrite from hidden iframe) then XMLHttpRequest happened, isn't because lack of knowledge how to properly use them.

⬐ FractalHQ

Svelte is already the perfect language / framework for me… but I am really looking forward to added support for partial hydration. Although… the code generated by the Svelte compiler is so unbelievably small and fast that any additional optimization from partial hydration will likely be highly negligible.

⬐ sieabahlpark

No, but search engines which can't understand SPAs do.

⬐ ehnto

I wouldn't say they have ruined the web, but they are often tone deaf to the context of the web. They often don't serve the same roles as a traditional website does and as a consumable document they are often closed and rigid.

I think they are often tonedeaf to how bad their UX can be as well. Contless SPAs feel like they were developed expecting zero network latency, and so they end up performing incredibly poorly in the real world, jiggling around, stuck in intermediate states, it gets very frustrating. To say nothing of their raw performance issues.

⬐ ravenstine

The current state of SPAs is just a symptom of an overall illness the web is suffering from. SPAs just happen to introduce some annoyances that lazy and inexperienced programmers don't avoid, often defeating the point of SPAs.

The average SPA is not only written to experience zero latency but are poorly written from an efficiency perspective. They are often doing tons of procedures under the hood in order to support generalized programming when in actuality they could get by with a lot less framework code (Svelte in part demonstrates this in a positive way). Programmers waste so much time figuring put frameworks that they shirk proper exception handling, handing off complex tasks to the server, or giving the user cues as to what to expect.

Most SPAs don't even need to be SPAs. If all the meaningful state belongs on a server then the app is better off being a traditional web site with progressive JavaScript enhancement. Not only does that free frontend code to be more UI centric but it also means JavaScript wouldn't be required. It amazes me how many blog sites don't work at all with JS turned off. That shouldn't be any more acceptable than it would have been to implement a blog entirely in Flash back in 2005.