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

31–40 of 875 posts

Re: Htmx Is the Future

#31

Post by traverseda »

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…

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

What are you gaining by writing something like that in java/type-script rather than like rust and webassembly?

To me javascript is in a sort of uncanny valley where you probably want to be either making a real app and compiling it to wasm or using something like htmx.

Re: Htmx Is the Future

#32

Post by tomca32 »

onion2k wrote: post #16
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…

But that isn't because of the technology, it's because all the devs writing shitty MPAs are now writing shitty SPAs. If this becomes popular, they will start writing shitty MPAs again. Nothing about this technology will stop that. This is only sort of true. The problem can be mitigated to a large extent by frameworks; as the framework introduces more and more 'magic' the work that the developer has to do decreases, w…

Unfortunately, developers often write code in a framework they don't know well so they end up fighting the framework instead of using the niceties it provides. The end result being that the surface area of things that can go wrong actually increases.

Re: Htmx Is the Future

#33

Post by vp8989 »

1) "Web application development" doesn't happen in a vacuum. Often it happens in contexts where the "backend" is also consumed by various non-web applications. In those contexts, collapsing the frontend and backend back into 1 component is less of the slam dunk than it's made out to be in this post.

2) The missing piece is how you can achieve this "collapsing" back of functionality into single SSR deployable(s) while still preserving the ability to scale out a large web application across many teams. Microfrontends + microservices could be collapsed into SSR "microapplications" that are embedded into their hosting app using iframes?

Re: Htmx Is the Future

#34

Post by pphysch »

obpe wrote: post #21
pphysch wrote: post #18

Earlier quoted context omitted.

Client side validation is for UX. Server side validation is for security, correctness, etc. They are different features that require different code. Blending the two is asking for bugs and vulnerabilities and unnecessary toil. The real reason that SPAs arose is user analytics.

I have never heard this before. Can you elaborate on the differences? What do you validate on the client side that you don't on the server and vice versa?

Some validations require capabilities that you don't want/need the client to have.

There are also validations that can improve UX but aren't meaningful on the server. Like a "password strength meter", or "caps lock is on".

Religiously deploying the same validations to client and server can be done, but it misses the point that the former is untrusted and just for UX. And will involve a lot of extra engineering and unnecessary coupling.

Re: Htmx Is the Future

#35

Post by 727564797069706 »

Pet_Ant wrote: post #4

The problem is that these kind of approaches require more upfront thought, which produces less now, and pays off later... and only if maintained by people in tune with the original design. I've seen this architectures quickly ruined by 'can-do' people who butcher everything to get a feature done _and_ get a bonus from the management for quick delivery.

In my experience, these 'can-do' people can (and usually will) butcher anything, be it MPA, SPA or TUI.

This seems like the real problem we need to solve, but not sure how?

Re: Htmx Is the Future

#36

Post by giraffe_lady »

duxup wrote: post #11
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…

I often work on an old ColdFusion application. It's amusing that for a long time the response was "oh man that sounds terrible". Now it is "oh hey that's server side rendered ... is it a new framework?". The cycle continues. I end up writing all sorts of things and there are times when I'm working on one and think "this would be better as Y" and then on Y "oh man this should be Z". There are days where I just opt for…

I also switch back and forth between two large projects written in different decades and it definitely gives an interesting perspective on this. Basically every time I'm in php I go "oh yeah I see why we do react now" and every time I'm in react I go "oh right I see why php still exists."

Re: Htmx Is the Future

#38

Post by zelphirkalt »

obpe wrote: post #19
zelphirkalt wrote: post #8

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. It's a pretty shitty client experience if you have to do a network request for each and every validation of user input. Node does not absolve from this. Any important verification still needs to be done on the server side, since any JS on the client side cannot be trusted to not be manipulated. J…

>Node does not absolve from this. Any important verification still needs to be done on the server side, since any JS on the client side cannot be trusted to not be manipulated. JS on the client side was of course possible before NodeJS. NodeJS did not add anything there regarding where one must verify inputs. Relying on things being checked in the frontend/client-side is just writing insecure websites/apps. Yeah, tha…

> In my experience, the bloat comes from Analytics and binary data (image/video) not functional code for the SPA. Unfortunately, the business keeps claiming it's "important" to them to have analytics... I don't see it but they pay my salary.

Similar to my experience. So glad I uBlock Origin a lot of unnecessary traffic. At some point it is not longer good taste, when the 5th CDN is requested, the 10th tracker script from random untrusted 3rd parties loaded ... All while neglecting good design of a website, making it implode, when you block their unwanted stuff. Not rare to save more than half the traffic, when blocking stuff.

Re: Htmx Is the Future

#39

Post by recursivedoubts »

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 relevant for modern development

we have a free book on practical hypermedia (a review of concepts, old web 1.0 style apps, modernized htmx-based apps, and mobile hypermedia based on hyperview[2]) available here:

https://hypermedia.systems

[1] - https://htmx.org/essays/when-to-use-hypermedia/

[2] - https://hyperview.org/

Post reply on HN