Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Htmx 4.0, the first JavaScript library to release exclusively on the Game Boy

swag.htmx.org

Post reply on HN
Print view View original

201–210 of 216 posts

Re: Htmx 4.0, the first JavaScript library to release exclusively on the Game Boy

#201

Post by andrewaylett »

andrewaylett wrote: post #100
zelphirkalt wrote: post #93

What I don't like about Htmx is, that it is still a JS framework, without good automatic fallbacks for a noscript situation. This leads to web devs thinking it would be great to do all the things in Htmx, even if all they have is a static page with static content. Just recently I looked at hosting an old school forum. I don't want to load all the PHP and MySQL baggage on my server or even run it in docker, so I looke…

Indeed. And the amusing/disappointing/frustrating thing is: my next.js site works if you turn off JS . Links are server-rendered as links, HTML is server-rendered as HTML. If you visit one of the tools that run on the client then they won't work, but the pages that could be static content? They're static content. Or at least they were, until I started using cache components the other week, and I'd not noticed they'd…

OK, while the fix was pretty easy (stopping wrapping static content in Suspense), actually getting it deployed was delayed :P. But it's fixed now.

Re: Htmx 4.0, the first JavaScript library to release exclusively on the Game Boy

#202

Post by throw2ih020 »

robertoandred wrote: post #174
throw2ih020 wrote: post #152

Earlier quoted context omitted.

I'm replacing existing third-party applications which have complex JavaScript frameworks with my "in house" apps using HTMX + mostly just HTML+CSS for most pages and functionality. i.e. I'm not introducing a layer, I'm replacing one. Why not just use html without HTMX you ask? With HTMX I don't have to reload the entire page to navigate, which is especially helpful for making the app responsive even on low bandwidth…

You said you added a new Go templating layer.

Sorry, I don't follow? I'm just using the templating from Go's standard library. That part replaces existing server-side components of the old applications.

Re: Htmx 4.0, the first JavaScript library to release exclusively on the Game Boy

#203

Post by yawaramin »

troupo wrote: post #197
yawaramin wrote: post #192

Earlier quoted context omitted.

The htmx website is full of demos showing how htmx works. Htmx is a JavaScript framework. Unsurprisingly, some of these demos don’t work when JavaScript is turned off. This thread is getting absurd now.

A reminder. I was told things just work: https://news.ycombinator.com/item?id=49071380 And now you're repeating what I already said and somehow pretending it's an argument with something I didn't say.

No, you were told ‘the things work’, with progressive enhancement. Like many frontend things, progressive enhancement isn’t automatic with htmx. But it’s relatively easy and best of all works with any web server, not just JavaScript backends. Your criticism is basically that it’s not perfect, so it’s worthless. No, it works great for many use cases. And your judgement is clouded by your biases.

Re: Htmx 4.0, the first JavaScript library to release exclusively on the Game Boy

#204

Post by yawaramin »

troupo wrote: post #196
yawaramin wrote: post #191

Earlier quoted context omitted.

You must be joking, React Flight Protocol for RSC is literally a new RPC system that comes with its own set of brand-new vulnerabilities. But sure, adding a couple of HTTP headers, which were designed for exactly this kind of use case (adding metadata to requests and responses), is a bridge too far.

Because 1) React is the only framework out there and b) that somehow absolves HTMX or makes anything I said untrue

Ok, take a look at the other popular frontend frameworks out there and tell me with a straight face that they don’t have their own mini-DSLs:

https://docs.solidjs.com/concepts/control-flow/conditional-r...

https://vuejs.org/guide/essentials/template-syntax.html

https://angular.dev/guide/templates#differences-from-standar...

None of which work with JavaScript turned off (unless you have a JavaScript backend and you wire it up to serve HTML).

The criticisms I’m seeing here are all things that are accepted without question in other frameworks but when htmx does it, suddenly it’s too much.

Re: Htmx 4.0, the first JavaScript library to release exclusively on the Game Boy

#205

Post by andy800 »

KronisLV wrote: post #184
SpaceNoodled wrote: post #113

Earlier quoted context omitted.

The server SHOULD do the rendering. It's a SERVER, not a give-me-a-bunch-of-bloated-junk-and-make-me-do-it-myself-er.

I mean a radically different view is that the SERVER should just give you the data and process your requests, without necessarily caring much about what you are - a browser or some other automated system, or a desktop client, where each has vastly different preferences on how the content might get displayed or used. With that approach, a clear API in the middle and a SPA on the client side makes a bunch of sense (as…

You're correct that it's a matter of the developer's view, or philosophy. The issue I have with "just give you the data" is that requires the server to encode the raw data somehow, most often JSON, send it down the wire just to have the client un-encode it, store it, and populate HTML elements with it. Meanwhile server-based templating is exceptionally lightweight and fast (especially when compiled) and so converting the raw data directly to HTML on the server via templates tends to be faster and lighter and cleaner, as "state" (not counting ephemeral or stylistic attributes) is maintained in a single place.

You make a good point that different clients may represent the data differently, although again that's easy to handle on the server by using a header or other identifier of the client, and using the appropriate template.

There isnt a definitive right or wrong, both approaches can work but the reason HTMX has found a following is that lots of developers are tired of the complications and difficulties that SPA frameworks seem to introduce, and reverting back to a server-based philosophy is allowing them to be more productive.

Re: Htmx 4.0, the first JavaScript library to release exclusively on the Game Boy

#206

Post by tracker1 »

masfoobar wrote: post #163
hi_hi wrote: post #128

Earlier quoted context omitted.

> it's completely unlocked new ways of building software for the web, especially if you use a server-side templating language. Could you please expand on this point. As a “greybeard” web dev from the 2000’s era, I’d like to understand if your “unlocking” is my “that’s how it originally worked, get of my lawn”?

Yes - how you likely built websites in 2000's era (possibly with Classic ASP or PHP4 .. maybe Perl?) is the sort of websites we are addressing with HTMX. It's bringing us back to that sort of web development but with modern tools and technology. For the server side, we can use modern languages with better templating for html. For the client, with htmx, you can do a lot of javascript such as ajax calls (load, trigger,…

FWIW, there is some decent tooling options for C# with Razor + HTMX that are worth looking at. From JetBrains and others.

Re: Htmx 4.0, the first JavaScript library to release exclusively on the Game Boy

#207

Post by troupo »

yawaramin wrote: post #203
troupo wrote: post #197

Earlier quoted context omitted.

A reminder. I was told things just work: https://news.ycombinator.com/item?id=49071380 And now you're repeating what I already said and somehow pretending it's an argument with something I didn't say.

No, you were told ‘the things work’, with progressive enhancement. Like many frontend things, progressive enhancement isn’t automatic with htmx. But it’s relatively easy and best of all works with any web server, not just JavaScript backends. Your criticism is basically that it’s not perfect, so it’s worthless. No, it works great for many use cases. And your judgement is clouded by your biases.

Let's see the fuller context:

>> Which is also besides the point of discussing whether or not HTMX invents its own templating, DSL, and requires the server to be aware of HTMX to to work properly. reply

> The things work, albeit with a full page load. As one of the ancestor comments said: progressive enhancement.

Oh. It turns out things don't work, neither on HTMX's own site, nor on most sites built with it.

Why do you keep arguing theory when reality is right there for anyone to see?

> Your criticism is basically that it’s not perfect, so it’s worthless.

No. My criticism is that HtMX authors and proponents keep presenting HTMX as something it objectively isn't despite actual verifiable reality.

I literally said what I mean in my first comment which started this pointless thread.

As I said in a sibling comment:

At this point I'm tired of pointless arguing with reality-denying people. Adieu.

Re: Htmx 4.0, the first JavaScript library to release exclusively on the Game Boy

#208

Post by troupo »

yawaramin wrote: post #204
troupo wrote: post #196

Earlier quoted context omitted.

Because 1) React is the only framework out there and b) that somehow absolves HTMX or makes anything I said untrue

Ok, take a look at the other popular frontend frameworks out there and tell me with a straight face that they don’t have their own mini-DSLs: https://docs.solidjs.com/concepts/control-flow/conditional-r... https://vuejs.org/guide/essentials/template-syntax.html https://angular.dev/guide/templates#differences-from-standar... None of which work with JavaScript turned off (unless you have a JavaScript backend and you wi…

> The criticisms I’m seeing here are all things that are accepted without question

Who said they are accepted without question?

> when htmx does it, suddenly it’s too much.

No, when HTMX and its proponents claim things that are objectively provably false, it's too much.

Me: HTMX requires the server to be compliant with its DSL to work properly

You: no it doesn't. It's literally how content negotiation works! Thus admitting HTMX requires server to conform to HTMX to work properly>

Me: there are literal standard headers for content negotiation

You: but what about React, and other frameworks.

Are we talking about React? Or other frameworks? We are talking about HTMx and your and others' claims about it.

Me: HTMX is custom templates and custom DSL.

You: no it's not!

Me: yes, it is

Me: It's standards compliant custom attributes and custom DSL. Why don't you look at all these other frameworks.

At every step of your "argument" you keep confirming every word I'm saying while somehow presenting it as an argument.

Try to actually learn something about tech you so fervently defend and to see how uour claims rarely differ from marketing bullshit (that marketing bullshit is often peddled by HTMx itself, most other frameworks are much more honest).

At this point I'm tired of pointless arguing with reality-denying people.

Adieu.

Re: Htmx 4.0, the first JavaScript library to release exclusively on the Game Boy

#209

Post by yawaramin »

troupo wrote: post #208
yawaramin wrote: post #204

Earlier quoted context omitted.

Ok, take a look at the other popular frontend frameworks out there and tell me with a straight face that they don’t have their own mini-DSLs: https://docs.solidjs.com/concepts/control-flow/conditional-r... https://vuejs.org/guide/essentials/template-syntax.html https://angular.dev/guide/templates#differences-from-standar... None of which work with JavaScript turned off (unless you have a JavaScript backend and you wi…

> The criticisms I’m seeing here are all things that are accepted without question Who said they are accepted without question? > when htmx does it, suddenly it’s too much. No, when HTMX and its proponents claim things that are objectively provably false, it's too much. Me: HTMX requires the server to be compliant with its DSL to work properly You: no it doesn't. It's literally how content negotiation works! Thus adm…

Htmx functions fine with any standard HTTP server in basic cases: it’s just an HTTP request and response with an HTML fragment. For progressive enhancement cases you can follow a very simple strategy of checking the HX-Request header and rendering either a full page or a partial, and adding a Vary: HX-Request response header. There’s no material difference between this and the standard content negotiation we talked about. To the server this is the same logic with just different names.

Also I pointed out that HTML already has custom DSLs in many of its attributes, this is not some new thing that htmx invented.

Finally, it says directly on the htmx landing page that it uses attributes for its functionality, and directly shows examples of common ones. This is right on the landing page. You have to dig into the special syntaxes of the other frameworks I mentioned to understand the differences they introduce. So I firmly refute your claims of marketing bullshit and dishonesty :-)

Try re-examining your own biases, you are in strong reality-warping mode :-)

Re: Htmx 4.0, the first JavaScript library to release exclusively on the Game Boy

#210

Post by yawaramin »

troupo wrote: post #207
yawaramin wrote: post #203

Earlier quoted context omitted.

No, you were told ‘the things work’, with progressive enhancement. Like many frontend things, progressive enhancement isn’t automatic with htmx. But it’s relatively easy and best of all works with any web server, not just JavaScript backends. Your criticism is basically that it’s not perfect, so it’s worthless. No, it works great for many use cases. And your judgement is clouded by your biases.

Let's see the fuller context: >> Which is also besides the point of discussing whether or not HTMX invents its own templating, DSL, and requires the server to be aware of HTMX to to work properly. reply > The things work, albeit with a full page load. As one of the ancestor comments said: progressive enhancement . Oh. It turns out things don't work , neither on HTMX's own site, nor on most sites built with it. Why do…

You inferred ‘reality’ by looking at examples that agree with your argument and ignoring ones that don’t. This is not theory, we have actually built this stuff. We’ve been telling you this over and over again. A couple of hand-picked counter-examples doesn’t change that.

Good luck with your confirmation bias fallacies though.

Post reply on HN