URL-Driven State in HTMX

Post by naasking » Thu, Jul 31, 2025, 4:34 AM UTC

bob1029 wrote: post #160

naasking wrote: post #144

Earlier quoted context omitted.

Some dangers with injection attacks if you don't santitize inputs correctly, but this is probably faster than most templating languages like razor.

There are a lot of ways to manage this problem. My preferred path is to wrap interpolated fields with HttpUtility.UrlEncode() when I know a user can touch it and there are plausible reasons for allowing 'illegal' characters at form submit time. In terms of performance, it is definitely faster. The amount of time it takes to render these partials is negligible. You'd have to switch up your tooling to measure things in…

Post by chuckadams » Thu, Jul 31, 2025, 1:01 PM UTC

const_cast wrote: post #159

chuckadams wrote: post #132

Earlier quoted context omitted.

The browser gives you a full-blown programming language with a rich API, but it seems a lot of people avoid that in favor of smushing together a static view on the server side with little more than string interpolation.

HTML templating isn't just string interpolation, Its a whole templating engine. It's not like JSX, which is fake templating. Server side frameworks have real templating. Plus, you have to convert data to HTML somewhere. If you're using react you do this typically on the front end. You traverse and read JSON and convert it to HTML... Just like you would in PHP. Just, on the front end.

    $foo = '>>>>';
    ?>

Post by const_cast » Thu, Jul 31, 2025, 3:40 PM UTC

chuckadams wrote: post #173

const_cast wrote: post #159

Earlier quoted context omitted.

HTML templating isn't just string interpolation, Its a whole templating engine. It's not like JSX, which is fake templating. Server side frameworks have real templating. Plus, you have to convert data to HTML somewhere. If you're using react you do this typically on the front end. You traverse and read JSON and convert it to HTML... Just like you would in PHP. Just, on the front end.

> You traverse and read JSON and convert it to HTML It gets converted to DOM nodes, and there is zero HTML source involved when using a component toolkit. Whereas in PHP, you can do things like this and it won't make a peep: $foo = ' >>>>'; ?> Other template engines like twig or blade will at least escape it by default, but of course have a syntax for interpolating it raw, otherwise they wouldn't be very useful as te…

Post by naasking » Thu, Jul 31, 2025, 5:20 PM UTC

ebiester wrote: post #174

naasking wrote: post #172

Earlier quoted context omitted.

That's not a use case, that's an implementation. What is the end user actually getting with this architecture that can't be obtained by the server-side one? Offline functionality is the only differentiating feature.

For ArcGIS? Have you ever used that? A similar system would be Figma - how do you build a server side Figma?

Post by chuckadams » Thu, Jul 31, 2025, 7:51 PM UTC

const_cast wrote: post #175

chuckadams wrote: post #173

Earlier quoted context omitted.

> You traverse and read JSON and convert it to HTML It gets converted to DOM nodes, and there is zero HTML source involved when using a component toolkit. Whereas in PHP, you can do things like this and it won't make a peep: $foo = ' >>>>'; ?> Other template engines like twig or blade will at least escape it by default, but of course have a syntax for interpolating it raw, otherwise they wouldn't be very useful as te…

I haven't seen a project that uses PHP for templating in many, many years. PHP backends use a templating engine, not PHP. They also feature components. Its the same level of abstraction as JSX but you also get type checking.