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

421–430 of 875 posts

Re: Htmx Is the Future

#421

Post by fridgemaster »

willio58 wrote: post #364
brushfoot wrote: post #10

I use tech like HTMX because, as a team of one, I have no other choice. I tried using Angular in 2019, and it nearly sank me. The dependency graph was so convoluted that updates were basically impossible. Having a separate API meant that I had to write everything twice. My productivity plummeted. After that experience, I realized that what works for a front-end team may not work for me, and I went back to MPAs with J…

Angular is falling off hard in the frontend frameworks race. And I totally agree about how the boilerplate and other things about Angular feels bad to work with. Other frameworks are far easier to build with, to the point where a 1-person team can easily handle them. React is being challenged but still has the biggest community, it's a much better place to start than Angular when evaluating frameworks like this. All…

Angular 2 works fine out of the box, and already provides a good architecture that noobs struggle to come up with in "freestyle" solutions like React. Angular's bi-directional binding is way superior and simpler to use vs React's mono-directional binding: you can just use bound variables, no need to do complicated setState or use abominations like Redux. Vue also has bi-directional binding. Essentially there are many alternatives that are superior to React, which is where it is mostly because of fame and popularity.

Re: Htmx Is the Future

#422

Post by guggle »

obpe wrote: post #3

It's kinda funny to me that many of the "pros" of this approach are the exact reasons so many abandoned MPAs in the first place. For instance, a major selling point of Node was running JS on both the client and server so you can write the code once. It's a pretty shitty client experience if you have to do a network request for each and every validation of user input. Also, there was a push to move the shitty code fro…

> a major selling point of Node was running JS on both the client and server so you can write the code once

Yes... but some people like me just don't like JS so for us that was actually a rebutal.

Re: Htmx Is the Future

#423

Post by dial9-1 »

PaulHoule wrote: post #277
v0idzer0 wrote: post #234

Earlier quoted context omitted.

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.…

Ouch! I’ve worked in two kinds of organizations. In one of them when there is a ‘small’ ticket from the viewpoint of management, one programmer is responsible for implementation but might get some help from a specialist (DBA, CSS god, …) In the other a small ticket gets partitioned to two, three or more sub teams and productivity is usually reduced by a factor more than the concurrency you might get because of overhe…

it's called resume-driven development

Re: Htmx Is the Future

#424

Post by rmbyrro »

nawgz wrote: 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…

> _Yes, better quality software usually packages a bit more complexity._

That view (+quality = +complexity) is actually flip sided, isn't it? [1]

[1] https://www.infoq.com/news/2014/10/complexity-software-quali...

Re: Htmx Is the Future

#425

Post by imbnwa »

callahad wrote: post #414
simplotek wrote: post #410

Earlier quoted context omitted.

> For instance, a major selling point of Node was running JS on both the client and server so you can write the code once. What? No. The whole point of Node was a) being able to leverage javascript's concurrency model to write async code in a trivial way, and b) the promise that developers would not be forced to onboard to entirely different tech stacks on frontend, backend, and even tooling. There was no promise to…

That's the reasoned take, and yet I have strong and distinct memories of Node being sold on the basis of shared code as early as 2011. Much of the interest (and investment) in Meteor was fueled by its promise of "isomorphic JavaScript."

I mean...look at these timestamps from 7-9 years ago[0]

[0]https://hn.algolia.com/?dateRange=all&page=0&prefix=true&que...

Re: Htmx Is the Future

#426

Post by rmbyrro »

runlaszlorun wrote: post #145
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…

Just started using HTMX on a new project and have been a big fan. I’d go so far as to say that it’s the best practical case for the theory of hypermedia in general. Like others have mentioned, this is the sort of thing that prob _should_ be in the HTML spec but, given what I’ve personally seen about the standards process, I have little expectation of seeing that. Thx again!

How would this be in HTML standard if it requires JS to work?

Re: Htmx Is the Future

#427

Post by jdthedisciple »

IshKebab wrote: post #400
jdthedisciple wrote: post #397

This puts all the computational load on the server. Imagine 10s of thousands of clients requesting millions of HTML fragments be put together by a single server maintaining all the states while all the powerful high end computing power at the end user's fingertips goes completely to waste. Not convinced.

Most users these days are probably using phones, not high end computers.

Most phones have more computing power than all of NASA did in the 80s.

I was specifically thinking of modern smartphones in fact, which are pretty damn fast at executing a little bit of JS.

(Though I agree that some of the bloated bundles resulting from modern frameworks or their poor usage definitely go to far)

Re: Htmx Is the Future

#428

Post by janosd »

I can still remember the horrors of page state. The server would keep track of what the client has and only send HTML fragments to the client. Early-days ASP, Prado and the likes did this and it was a terrible idea. HTMX sounds very much like that, but the packaging is nicer. Ultimately, the problem is that sometimes you need to update more than just the tiny, well-defined part that is the todo list and several parts of the UI need to change when a request is made. By which I mean this happens all the time. The road to hell is paved with todo list implementations as a proof that a system works and is good. Please show me a moderately complex login system with interlinking interfaces implemented in this.

Re: Htmx Is the Future

#429

Post by Glyptodon »

cutler wrote: post #360
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…

Wasn't Ember the idiomatic choice before React? I don't remember Angular being that popular with Rails devs generally.

I definitely associate it (Angular) with Python BE devs for some reason.

Re: Htmx Is the Future

#430

Post by jdthedisciple »

mixmastamyk wrote: post #412
jdthedisciple wrote: post #397

This puts all the computational load on the server. Imagine 10s of thousands of clients requesting millions of HTML fragments be put together by a single server maintaining all the states while all the powerful high end computing power at the end user's fingertips goes completely to waste. Not convinced.

This avoids unnecessary computation at the client, it does not substantially add to the burden of the server. Which would need to be reconciled regardless of the markup format used over the pipe. Alpine is available for local flair.

I don't know but adapting UI to reflect the edit state of a todo seems like a classic client responsibility imho, not unnecessary.

What's unnecessary to me however is sending bytes thousands of miles across the wire to some server to do the same.

Post reply on HN