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

Htmx Is the Future

quii.dev

Post reply on HN
Print view View original

321–330 of 875 posts

Re: Htmx Is the Future

#321

Post by hdjjhhvvhga »

marcosdumay wrote: post #294
hirako2000 wrote: post #76

Earlier quoted context omitted.

I have no love for unnecessarily bloated dependency graphs, but we can't have the cake and eat the cake too. Next.js for example, comes packed with anything and everything one might need to build an app. Sitting on the promise of hyperproductivity with "simplicity". Plus, is made of single responsability principles set of modules, kind of necessary to build a solve-all needs framework. And it does that. A bit like An…

Back in the late 90's and early 00's, armed with the experience of C, C++, Bash, and Perl, everybody knew it very clearly that "batteries included" is the correct way to create development tools. I don't know about the current fashion of minimalism comes from. It doesn't bring simplicity.

> C, C++, Bash, and Perl

While I agree with your comment, lumping these together somehow doesn't seem fair. As for C and C++, it took decades to develop package managers, and we can't still say we have standard ones (but I feel Conan is a de facto standard PM for C++).

Bash, on the other hand, should never have 'batteries included' because in this case the batteries are the rest of the system - coreutils and the rest. An Perl had CPAN quite early on, in the early nineties iirc.

Re: Htmx Is the Future

#322

Post by jgoodhcg »

recursivedoubts wrote: post #199
jgoodhcg wrote: post #186

Earlier quoted context omitted.

I've spent almost my entire career working on react based SPAs and react native mobile apps. I've just started playing around with HTMX. > no good story for what happens when one component in a tree needs to update another component in the tree HTMX has a decent answer to this. Any component can target replacement for any other component. So if the state of everything on the page changes then re-render the whole page…

> do I want my api to talk in html https://htmx.org/essays/splitting-your-apis/

One great thing about your docs is the anticipation to concerns.

Re: Htmx Is the Future

#323

Post by diegof79 »

While HTMLX makes some interactions easier for developers without JS experience, the primary issue in web development is that the browser was not designed for apps. It evolved unevenly from a document navigation platform, and many things we do in web development today are hacks due to the lack of a better solution.

In my opinion, the future of the web as a platform is about viewing the web browser as an operating system with basic composable primitives.

HTMLX adds attributes to HTML using JS, and the argument about "no-JavaScript" is misleading: with HTMLX you can write interactions without JS, but HTMX uses JS. But, as it forces you to use HTML constructs that will work without scripts (such as forms), the page will fall back. It doesn't means that the fallback is usable.

The custom HTMLX attributes work because the browser supports extensions of its behavior using JS. If we add those attributes to the standard HTML, the result is more fragmentation and an endless race. The best standard is one that eliminates the need for creating more high-level standards. In my view, a possible evolution of WASM could achieve that goal. It means going in the opposite direction of the article, as clients will do more computing work. In a future like that, you can use HTMLX, SwiftUI, Flutter, or React to develop web apps. The biggest challenge is to balance a powerful OS-like browser like that with attributes like searchability, accessibility, and learnability (the devtools inspect and console is the closest thing to Smalltalk we have today)...even desktop OSs struggle today to provide that.

Re: Htmx Is the Future

#324

Post by incrudible »

I take the opposite side of that bet. Always bet on (more) Javascript. Dealing with HTML sucks, and we want as little of it as possible, otherwise we would not have invented generations of frameworks to make it manageable. The lasting success of React shows that we have converged on how to do that. Moving back to MPAs is always something that bored engineers want to do. Users generally do not care.

Moreover, REST APIs - and I mean the simple ones people actually want to use, none of that HATEOAS BS - are ubiquitous for all sorts of interactions between web and nonweb clients. Are you going to ship an MPA as your mobile apps, or are you going to just use REST plus whatever clients make sense?

It also makes a lot of sense in terms of organization. Your backend developers probably suck at design, your frontend developers suck at databases.

Re: Htmx Is the Future

#325

Post by afavour »

robertoandred wrote: post #316
afavour wrote: post #312

Earlier quoted context omitted.

No, it’s like saying you’ve been provided with a calculator but may, if you wish, create your own calculator with some parts provided. No guarantee it adds numbers together correctly.

Why would anyone choose to create and use their own unreliable calculator instead of what came installed?

…that’s the point being made

Re: Htmx Is the Future

#326

Post by tsuujin »

doodlesdev wrote: post #317

No it's not. Honestly, the fact that this website displays like shit without JavaScript enabled is ironic considering it uses HTMX. Please just use the damn full-stack JS frameworks, they make life simpler, just wait for WebAssembly to allow us to have full-stack Rust/Go/whatever frameworks, and then you can abandon JavaScript, otherwise you get the mess of websites like this one where the developer has not written J…

> Please just use the damn fullstack JS frameworks, they make life simpler

Strongest possible disagree. I’ve been doing web dev for a long time, and the last 10 years has seen a massive, ridiculous increase in complexity across the board.

I personally took my company back to good old server rendered apps with a turbolinks overlay because I was sick of dealing with the full stack frameworks, and we saw a huge increase in productivity and developer happiness.

Re: Htmx Is the Future

#327

Post by com2kid »

wwweston wrote: post #283
com2kid wrote: post #167

Earlier quoted context omitted.

> The SPA broke it... Back button broken and a buggy custom implementation is there instead? Check. MPAs break back buttons all the damn time, I'd say more often than SPAs do. Remember the bad old days when websites would have giant text "DO NOT USE YOUR BROWSER BACK BUTTON"? That is because the server had lots of session state on it, and hitting the browser back button would make the browser and server be out of syn…

> "DO NOT USE YOUR BROWSER BACK BUTTON"? Yeah, state mutation triggered by GET requests is going to make for a bad time, SPA or MPA. Fortunately enough of the web application world picked up enough of the concepts behind REST (which is at the heart of all web interaction, not just APIs) by the mid/late 00s that this already-rare problem became vanishingly rare well before SPAs became cancerous. > going back to change…

> It's not only EVER done, it's regularly done. Perhaps you should interrogate some of the reasons why.

Content in the app is reloaded, sure, but the actual layout and business logic? Code that generally changes almost never, regenerated on every page load?

I know of technologies that are basically web wrappers that allow for doing that to bypass app store review processes, but I'd be pissed if an alarm clock app decided to reload its layout from a server every time I loaded it up!

The SPA model of "here is an HTML skeleton, fill in the content spaces with stuff fetched from an API" makes a ton more sense.

The application model, that has been in use for even longer, of "here is an application, fetch whatever data you need from whatever sources you need" is, well, a fair bit simpler.

Everyone is stuck with this web mindset for dealing with applications and I get the feeling that a lot of developers now days have never written an actual phone or desktop application.

> But more to the point, if it's bad, SPAs seem to frequently manage to bring the worst of both worlds, a giant payload of application shell and THEN also screen-specific info, all for reasons like developer's unfortunately common inability to understand that both JSON and HTML are perfectly serviceable data exchange formats (let alone that the latter sometimes has advantages).

I've seen plenty of MPAs that consist of multiple large giant mini-apps duct taped together.

Shitty code is shitty code!

Re: Htmx Is the Future

#328

Post by doodlesdev »

tsuujin wrote: post #326
doodlesdev wrote: post #317

No it's not. Honestly, the fact that this website displays like shit without JavaScript enabled is ironic considering it uses HTMX. Please just use the damn full-stack JS frameworks, they make life simpler, just wait for WebAssembly to allow us to have full-stack Rust/Go/whatever frameworks, and then you can abandon JavaScript, otherwise you get the mess of websites like this one where the developer has not written J…

> Please just use the damn fullstack JS frameworks, they make life simpler Strongest possible disagree. I’ve been doing web dev for a long time, and the last 10 years has seen a massive, ridiculous increase in complexity across the board. I personally took my company back to good old server rendered apps with a turbolinks overlay because I was sick of dealing with the full stack frameworks, and we saw a huge increase…

Hotwire is appropriate (I imagine you're not using actual Turbolinks which has been deprecated) with RoR or whatever stack you want, I agree it's great developer experience (despite Ruby and Rails being painfully slow haha).

I wonder which full-stack JS framework you used that you thought made life harder? One of the things that gets me mad is the idea of putting it all in one single box, as React is indeed very (needlessly) complex and so can be other libraries, but that doesn't mean the paradigm of JavaScript front-to-back is fundamentally flawed.

edit: Something else I should've added to my comment is that the HTMX approach is terrible if you ever need more than just the web-client (i.e. a mobile app, native or otherwise) since you will now have to implement an API anyway, which you could've done in the first place by taking the usual approach to development.

Re: Htmx Is the Future

#329

Post by booleandilemma »

recursivedoubts wrote: post #39

i am the creator of htmx, this is a great article that touches on a lot of the advantages of the hypermedia approach (two big ones: simplicity & it eliminates the two-codebase problem, which puts pressure on teams to adopt js on the backend even if it isn't the best server side option) hypermedia isn't ideal for everything[1], but it is an interesting & useful technology and libraries like htmx make it much more rele…

I use htmx on my personal site and I love it so much. Thank you!

Re: Htmx Is the Future

#330

Post by goodSteveramos »

v0idzer0 wrote: post #234
PaulHoule wrote: post #179

Earlier quoted context omitted.

I remember that all the web shops in my town that did Ruby on Rails sites efficiently felt they had to switch to Angular about the same time and they never regained their footing in the Angular age although it seems they can finally get things sorta kinda done with React. Client-side validation is used as an excuse for React but we were doing client-side validation in 1999 with plain ordinary Javascript. If the real…

It really wasnt about client side validation or UX at all. You can have great UX with an MPA or SPA. Although I do think it’s slightly easier in an SPA if you have a complex client like a customizable dashboard. Ultimately it’s about splitting your app into a server and client with a clear API bounday. Decoupling the client and server means they can be separate teams with clearly definied roles and responsibilities.…

There is no reason other than poorly thought out convenience to make the webbrowser/webserver interface the location of the frontend/backend interface. You can have a backend service that the web server and mobile apps all get their data from.
Post reply on HN