Live data from Hacker News

Htmx Is the Future

quii.dev

251–260 of 875 posts

Re: Htmx Is the Future

#251
post #15

I'm sorry, but these arguments are so tired. > SPAs have allowed engineers to create some great web applications, but they come with a cost: > Hugely increased complexity both in terms of architecture and developer experience. You have to spend considerable time learning about frameworks. Yes, better quality software usually packages a bit more complexity. SPAs are popular, just like native apps, because people don't…

> Imagine some cool feature like... collaborative editing.

In my opinion, the whole point of the article and for everyone who is backing htmx is that SPA frameworks are too complex (and a liability) for solo/small teams or projects that don't need `collaborative editing`(or other advanced stuff).

Re: Htmx Is the Future

#252

You know, nobody likes this argument, but desktop is still just better. Yeah, yeah, the updates, security issues, I get it, but the tools are simple better, render faster, better functionality/complexity ratio, less gnashing of teeth.

Desktop on which OS? Using what GUI framework? The web is a single platform, but the desktop developer experience seems to vary wildly depending on the OS. I'm genuinely curious what OS and tooling you use that you find so much better, because every time I've tried desktop development I eventually give up and go back to the web. It might be because Linux support is always a requirement for me.

> which OS?

The one you want to run your software on.

> what GUI framework?

Assuming you aren't making a game, each OS has a different answer. Making an iPadOS or macOS app? I'd probably go with SwiftUI. Linux? I'm partial to GTK. Windows? Probably WinUI (although I also still like MFC extended with raw Win32 API calls).

There are cross platform tools, but none of them are very good. If you want to make something really great, target the most important OS and make the absolute best thing you can with the native features of that OS. Follow the conventions of the platform and you get a lot of stuff (like accessibility features) for little effort.

> The web is a single platform

I agree. The web as presented by the browser is its own distinct platform. A well written web app will almost always use more battery, memory, CPU, and network bandwidth than a similar well written native app. Sometimes, despite all the problems with web technologies, the web is where something belongs.

I'm still a big believer in the personal computer. The web takes power from individuals and is a step back to the days of dumb terminals and centralized computing.

Re: Htmx Is the Future

#253
post #45

I like how the cons of SPA are "you have to manage state" and "clients have to execute code". I mean, aren't these baseline "get computers to do stuff" things?

Why do things in two places when you can do it all in one place? This isn't limited to computers, but unless you are getting specific benefits, it isn't wise to continue with a SPA approach.

We had the same and worse problems with "thick clients" that came before the web grew. With the right requirements, team, tools etc., you could sometimes build great apps. This was incredibly difficult and the number of great apps was relatively small. Building with earlier server-side web tech, like PHP, isolated everything on the server and it was easier to iterate well than with the "thick clients" model.

SPA reinvents "thick clients" to some degree and brings back many of the complications. No one should claim you can't build a great SPA, or that they have few advantages, but the probability of achieving success is frequently lower. Frameworks try to mitigate these concerns, but you are still only moving a closing some of the gaps and the probability of failure remains higher. Depending on the app you can move the success metrics, but we often end up fudging on items like performance.

We get to a point where there is current model is fraying and energy builds to replace it with something else. We end up going back to old techniques, but occasionally we learn from what was done before.

I find that it's surprisingly rare for people with 1-2 years of experience to be able to give an accurate overview of the last 10 years of web development. A better understanding of this history can help with avoiding (or targeting) problems old timers have encountered and complain about in comments.

Re: Htmx Is the Future

#254

Earlier quoted context omitted.

> A password strength metre is only going to give attackers hints at the passwords you have in your system No, it's not. A password strength meter just shows you the randomness of an input password, it doesn't have anything to do with passwords already in the system.

I'd agree with both takes on that it depends on the meter. Ones which truly approximate password entropy work like you say, however, for some reason, the most common use of such meters is to show how many dartboard requirements you've met while ignoring the actual complexity. When this common approach is used you combine "password must be 8 characters or more" with things like "password must have a number, symbol of…

If you Google 'password strength' the first result is https://www.passwordmonster.com/

This works like I described, it don't show 'dartboard requirements', only entropy. I think you've misunderstood what a password strength checker is. It's definitionally not a checklist like 'You need an uppercase letter, a lowercase letter, a number, a special character'. It's a tool which measures the strength i.e. the randomness or entropy of the password.

Re: Htmx Is the Future

#255

Earlier quoted context omitted.

A lot of misconceptions here. Google is an AdTech company par excellence. You don't need to do hacky URL tracking with SPAs. That's the point. >Also, fewer server interactions means fewer opportunities to capture user behavior or affect it at the server level. SPAs certainly do not have "fewer server interactions". What do you think an API call is? "React" comes from "reactive web app", not "reaction to a competitor'…

I work with SPAs with API calls every day. It definitely reduces the server interactions over computing everything on that side, and it gives fewer points of contact with the server about the user's behavior. For example, many clicks and other actions will not result in any server contact at all. I'm aware that they call it "reactive" but I'll stick with my rationale. There is no way they would use a Google product l…

An enterprise React app I am currently working with takes about 50 requests to fully render the app post-login. Switching to another view (no reload) takes another few dozen. That's a lot of "server interactions", pretty standard for SPAs, but YMMV.

Re: Htmx Is the Future

#256

Earlier quoted context omitted.

They're limited in some ways but they're just about powerful enough to do almost everything you'd need or want to do client-side without making a network request. In my opinion it doesn't make sense to try to fit in tons of complex validation logic in the frontend.

Why make a round trip if you don’t have to?

Why be on the internet at all? Why not distribute a desktop app that doesn't need any connectivity at all?

Re: Htmx Is the Future

#257
post #97

Earlier quoted context omitted.

back in the olden days a web browser was largely considered just a program to read documents stored on other systems that can be linked to each other sent over a simple stateless protocol. Then we started to be able to collect user input, then a hack was invented to maintain state between requst/response pairs (cookies), then a scripting language etc There are many use cases out there where not treating a browser as…

When do you want the browser to be anything more than a hypertext document viewer and why?

Roughly every time I can use something by just typing some words instead of downloading a .exe.

Re: Htmx Is the Future

#258
What's the business case, for them or for developers?

Ideas aside, the web app future belongs to those with the resources to sustain a response, or those who can restore the ability to capture/monetize developers and users in a closed system.

The scope of web apps is broad enough that many technologies arguably have their place. The open javascript ecosystem reduced the cost of creating candidates, but has no real mechanism to declare winners for the purpose of consolidating users, i.e., access to resources.

Careers and companies are built on navigating this complexity, but no one really has the incentive to reduce it unless they can capture that value.

I really appreciate Cloudflare because they are open about both their technology and their business model. They thus offer a reasonable guarantee that they can sustain their service and their technology, without basing that guarantee on the fact that they are a biggie like AWS, Microsoft, or Google (i.e., eating their own dog food, so we can join them at the trough).

The biggest cost in IT is not development or operating fees but reliance and opportunity.

Re: Htmx Is the Future

#259
I’m afraid htmlx might be repeating the same mistake that CORBA and DCOM made decades ago: pretending that latency doesn’t matter.

Yes you could make a CORBA or DCOM object almost indistinguishable from a local object, except for the latency when it was actually remote. And since it looked like a normal object it encountered “chatty” interface which exacerbated the latency cost.

Htmlx seems pretty chatty to me, which I’m sure works OK over the LAN, but what about the “real” internet?

Re: Htmx Is the Future

#260
post #228

meta: I love when htmx is highlighted in HN because the discussions branch into alternatives and different ways of doing web dev. It's very enriching to think outside the box!

Agree. I always find some interesting and new FE approaches/methodologies in these random HTMX threads and it’s awesome.
Post reply on HN