Readit News logoReadit News
alethiophile commented on Ask HN: Why do you all think that Htmx is such a recent development?    · Posted by u/Akronymus
SahAssar · 2 years ago
What you are missing is that the pitch is well-done and the audience seems to mostly ignore the web-native (or lighter alternatives than a full react framework approach).

HTMX is a wrapper around old functionality pitched to devs that learned that frontend "really, really needs" all the complexity. It's being used by people who never needed all that complexity for tasks that didn't need a whole frontend stack.

Of course it fits them better than the alternative that they have heard about being the only modern way to build apps (a massive frontend stack where the framework isn't even a framework anymore so we built another framework around it).

The thing that htmx users often miss is that you can have most of those nice things without pulling in htmx, htmx is definitely not right for most use-cases, htmx itself is quite the large JS dependency (and you still need to write JS to use it properly), it's not "just hypermedia", and on and on.

Personally I think the solution-space that HTMX fits in is extremely narrow between normal HTML/CSS/JS and "fuller" frontend apps (hopefully built on lighter stacks than the current react meta).

alethiophile · 2 years ago
Personally, I would say that if you are doing DOM updates via AJAX calls that return HTML, HTMX is just the correct way to do it. (Unless you're using some other solution already for other reasons and it also includes that functionality.)

Sure, you could do the basics of that workflow with twenty lines of your own JS, and save a dependency. But that's the kind of thing that is generally very unscalable, because unless you're very disciplined it quickly becomes a mass of spaghetti. The virtue of HTMX is more in how it channels and limits your code, than in the new capabilities it grants you (which were all in common use as of 2005 or whatever).

alethiophile commented on Unpoly is what Hotwire should have been   randomwik.org/posts/unpol... · Posted by u/shouldcode
sublinear · 2 years ago
If you want to call it a stack, a simple nginx or apache web server hosting web pages and being the gateway to the backend.

The backend is usually non-negotiable legacy stuff in my experience, but you can add your own layer of business logic in node or python gluing all those other endpoints together.

I don't really care about the frontend frameworks used as long as they're truly frontend frameworks. That build should live its life as a folder of static html/css/js on a web server.

What I'm saying is that this was a solved problem a very long time ago going back to almost the beginning of the internet with CGI (as long as your output response from those scripts were xml or json). Any attempt to deviate from this architecture will be, as you say, a rat's nest. All forms of server side rendering are terrible.

The meaningful depths of full stack are past that gateway and can go all the way down to kernel modules if it has to, but it usually doesn't. Frontend is the surface and should stay on the surface. Javascript should not be used deeper than nodejs. Nodejs should not be used to render html. Nothing should render html on the backend. Who is this not obvious for? What year is it?

alethiophile · 2 years ago
Why is it better to render JSON on the server, read that JSON in a separate client app that you also have to write, and then do a bunch of manual DOM calls in Javascript, rather than rendering HTML on the server and letting the browser's blazing-fast compiled HTML parser turn it into DOM for you?
alethiophile commented on How bad are satellite megaconstellations for astronomy?   leonarddavid.com/blinded-... · Posted by u/belter
p_j_w · 2 years ago
The cost of getting those into space is a relatively small part of the overall cost. The amount of cost benefit one of these telescopes would see just to the cost reductions gained specifically because of Starlink are insignificant.
alethiophile · 2 years ago
The cost of launch is small-ish compared to the total program cost, but the limitations on launch condition the engineering requirements in ways that inflate the engineering costs. JWST had to be built as an insane on-orbit autonomous origami project because its mirror couldn't fit in a fairing unfolded. Repeat for ten thousand other decisions that are made in order to optimize weight or volume.

If you can launch a hundred tons to orbit for $5M, you can just make a huge dumb cheap telescope and throw a dozen of them up there. Quantity covers a multitude of sins.

alethiophile commented on HTML Web Components   blog.jim-nielsen.com/2023... · Posted by u/goranmoomin
joshstrange · 2 years ago
> But I believe this whole "anti-react" movement isn't talking about such usecases, but rather against defaulting frameworks and building using them 'from the ground up', where trully all the website actually need is the "sparkling of interactivity on top"

We absolutely don't have shared language for these things and we aren't always talking about the same things. The thing is there are just vanishingly few places where you only need a "sparkling of interactivity on top". Yes your blog probably doesn't need a full framework, nor does your news site (which is just a blog++) or your marketing web page. But so many other things really do or things break down quickly. Also what your web site needs today might not cover what it needs tomorrow. I've seen a number of "web admin"/backend control panels (customer-facing for config) start simple then grow until they start to collapse under their own weight with just added jQuery as needed. Sure, at the start, htmlx/jQuery might cover all you need but soon you are building custom UI to represent business logic/ideas and managing with that gets very unwieldy. The people that say "all you need is the built-in HTML elements" are living in a fantasy land, try using the default date/time picker and get back to me.

I'm sure there are things I'd agree with the anti-react crowd on (places you don't need a framework) but all their examples are incredibly contrived and feel like the "TODO app examples" you often see for frameworks or learning a language. They don't even scratch the surface of what's needed for complicated apps, they are great to show off the simple things but it seems like the anti-react/anti-framework crowd thinks those simple examples are all you need and that's just silly.

At the end of the day I'll admit I reach for a framework earlier than I absolutely need it and that's because I've built 10's and 10's of sites (web apps) from the ground up and eventually you either use a framework or you end up creating a shitty version of one. So yeah, day 1 I might not need Vue but day 100 I'm sure glad I have all of Vue to build on.

alethiophile · 2 years ago
> The thing is there are just vanishingly few places where you only need a "sparkling of interactivity on top".

I would say it's precisely the opposite.

Say 97% of work done by web pages and web apps in practice boils down to "render some data available on the server as HTML, then show it to the user". For these cases, putting what amounts to an entire GUI framework written in Javascript on the frontend is massive, bandwidth-sucking, performance-killing overkill.

There are absolutely exceptions. Google Sheets exists. But your project is probably not Google Sheets.

alethiophile commented on Poll: Is the rise of Htmx another episode of over-hyped JavaScript libraries?    · Posted by u/ahmedfromtunis
arethuza · 2 years ago
Yes - I can see why that particular comparison makes sense. However, not sure if that was the standard (or even most common) way of using jQuery whereas with HTMX it's pretty much the only option you have?
alethiophile · 2 years ago
It's definitely a really imprecise usage.
alethiophile commented on Poll: Is the rise of Htmx another episode of over-hyped JavaScript libraries?    · Posted by u/ahmedfromtunis
arethuza · 2 years ago
"it's a glorified/bastardized jQuery"

I'm struggling to see why you would compare jQuery and HTMX?

alethiophile · 2 years ago
I assume "jQuery" here is being used as a metonym for the old frontend style where you would use the jQuery AJAX and DOM functions to query HTML fragments and swap them in. This is only really related to jQuery in that it used jQuery utility functions; under modern conditions you would just use fetch() and querySelector() etc to do the same thing.

It's true that the core concept of HTMX is very simple, and you could probably reimplement any given particular use case in a few lines. However, it is in fact a big advance over the manual HTML-fragment style, precisely because it abstracts over the particulars. Standardizing on a particular, good design is an important benefit even if the functionality of the code is easy.

alethiophile commented on HTML First   html-first.com/... · Posted by u/tonyennis
joshghent · 2 years ago
The author raises some interesting points.

But these arguments seem a little tired now. Does a customer actually care what technology you use - absolutely not. If react is easier for you, go for it. If that’s HTMX - fine.

What matters is speed of delivery of new features. And react has huge amounts of support (and a large developer base) that makes development quick and cheap.

I’ve never understood these html purist arguments. As if React/Vue/Angular are desecrating this pure text language.

There are other issues of far greater importance - accessibility, multi-language, browser consistency, sane defaults and easy tooling.

alethiophile · 2 years ago
The customer probably cares if your app takes five seconds to load because of the resource size, or reliably pegs a CPU core whenever you're using it.

Of course, neither of these things are guaranteed in a React app. But they're definitely way easier to back into by accident.

alethiophile commented on HTML First   html-first.com/... · Posted by u/tonyennis
moritzwarhier · 2 years ago
I once built a project-tailored combobox using Alpine.js - this is about where it breaks down.

It worked, it was a lot of fun to write because it went really fast, even with some bells and whistles. Whole thing was my escape hatch when datalist attribute didn't work. It also worked well.

Alpine JS feels like a simpler version of Vue 2 without a build step and without any of the complex or confusing stuff (and of course with a focus on HTML not rendered by JS).

But when I saw what this turned into as a BE colleague copied it to the next form, making some adjustments... oh my, I prefer external and reusable JS (or a JS-first approach to templating, like React) any day.

Still, Alpine is really awesome for minimal interactions and simple JS.

When working outside React, it's hard not to miss it for the simplicity of doing everyday stuff inline in the HTML.

alethiophile · 2 years ago
Alpine is primarily designed to be reused via server templating. You use a single template per component to do the in-HTML side, using the server template's facilities to handle variations as necessary. Then you can factor out complex common behaviors into Javascript using Alpine.data.

It definitely does have a maximum size of project it's suitable for. In particular, it's thoroughly individual-component-based; changing anything outside the component requires tacking on non-native hacks, and doing a full interactive app with it would be a painful exercise. But for adding simple interactivity to a primarily server-rendered web page, I've found it to be quite useful.

alethiophile commented on The Plumber Problem   hypercritical.co/2023/08/... · Posted by u/zdw
analog31 · 2 years ago
Hindsight. You learn more things later, that allow you to look back on the past.
alethiophile · 2 years ago
How often do you learn new things later that, even as transmitted through untrustworthy media, allow for clear falsification of the former media presentation?

This isn't zero but it's not very common either. Usually, the domain in question is sufficiently subtle that you can't make a rigorous prediction from an untrustworthy media presentation at all; thus, the media accounts are effectively unfalsifiable (unless you go out and seek personal experience).

alethiophile commented on The Plumber Problem   hypercritical.co/2023/08/... · Posted by u/zdw
analog31 · 2 years ago
And yet we manage to keep ourselves reasonably informed. I subscribe to one of the major papers, and avail myself to a variety of mainstream sources. I can count on the fingers of one hand the times, over multiple decades, that I've ever looked back on an issue and felt that I had actually been misinformed. "You made one tiny mistake so your entire organization is discredited" would have been an unreasonable reaction.

So I think that Gell-Mann Amnesia, while amusing, is overblown.

alethiophile · 2 years ago
Regarding a topic that you never come into personal contact with, your entire knowledge of it throughout your life will be media-mediated. How, then, would you ever learn what you had been misinformed of?

u/alethiophile

KarmaCake day244August 16, 2017View Original