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

71–80 of 875 posts

Re: Htmx Is the Future

#71

Post by wrenky »

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…

> , 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

It brings a tear of joy to my eye honestly. The circle of life continues, and people always forget people are bad at programming (myself included).

Re: Htmx Is the Future

#72

Post by zamadatix »

pphysch wrote: post #55
zamadatix wrote: post #49

Earlier quoted context omitted.

I'm not sure adding a meter value output to the server side check to use it in both places is really more engineering work. Writing separate checks on the client and server side seems much more likely to create headache and extra work. That said, I could definitely see additional checks being done server side. One example would be actually checking the address database to see if service is available in the entered ad…

You misunderstand: the server only cares if your password is valid (boolean), not if it is "almost valid (0.7 strength)".

I understand the argument I just disagree that having a separate "bool isPasswordValid()" and "float isPasswordValid()" (really probably something that returns what's not valid with the score) function is in any way simpler than a single function used on both sides. Sure, the server may not care about the strength level but if you need to write that calculation for the client side anyways then how are you saving any engineering work by writing a 2nd validation function on the server side instead of just ignoring the extra info in the one that already exists?

Re: Htmx Is the Future

#73

Post by ivan_gammel »

aidenn0 wrote: post #12

> Managing state on both the client and server This is a necessity as long as latencies between the client and server are large enough to be perceptible to a human (i.e. almost always in a non-LAN environment). [edit] I also just noticed: > ...these applications will be unusable & slow for those on older hardware or in locations with slow and unreliable internet connections. The part about "slow and unreliable intern…

Fully agree with this comment. Also, client and server state are different: on the client you need only session state relevant to user journey, on server you keep only persistent state and use REST level 3 for the rest.

Re: Htmx Is the Future

#75

Post by lucidguppy »

HTMX brings new life to tech like django which can catapult MVPs into production asap.

Backend engineers are now able to write management tools and experimental products faster - and then pass the winning products off to a fluttr team to code for all environments. The backend could be converted into a django rest api if the code is properly refactored.

Re: Htmx Is the Future

#76

Post by hirako2000 »

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…

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 Angular, set to solve everything front-side. With modules not entirely tightly coupled but sort of to get the full solution.

And it did that.

Then we have outliers like React, which stayed away from trying to solve too many things. But the developers have spoken, and soon enough it became packed in with other frameworks. Gatsby etc. And community "plug-ins" to do that thing that dev think should be part of the framework.

And they did that, solved most problems from authentication to animation, free and open source sir, so that developers can write 12 lines of code and ship 3 features per day in some non innovative way, but it works, deployed in the next 36 seconds, making the manager happy as he was wondering how to justify over 100k in compensation going to a young adult who dressed cool and seemed to type fast.

Oh no! dependency hell. I have to keep things maintained, I have to actually upgrade now, LTS expired, security audits on my back, got to even change my code that worked perfectly well and deal with "errors", I can't ship 3 features by the end of today.

We need a new framework!

Re: Htmx Is the Future

#77

Post by benatkin »

recursivedoubts wrote: post #65
benatkin wrote: post #48

Earlier quoted context omitted.

It doesn't feel like hypermedia to me. It just feels like a vue-like language that is an internal DSL for HTML instead of an external DSL for HTML like svelte and handlebars. Hypermedia advances would be microformats and RDF and the like. http://microformats.org/wiki/faqs-for-rdf

it absolutely is hypermedia we generalize HTML's hypermedia controls in the following way: - any HTML element can become a hypermedia control - any event can drive a hypermedia interaction - any element can be the target of a hypermedia interaction (transclusion, a concept in hypermedia not implemented by HTML) all server interactions are done in terms of hypermedia, just like w/links and forms it also makes PUT, PAT…

Links and forms are the bread and butter of many frameworks.

Like with HTMX, SvelteKit and Remix forms won't function properly without the framework.

Re: Htmx Is the Future

#78

Post by emodendroket »

PaulHoule wrote: post #51
ladberg wrote: post #23

Earlier quoted context omitted.

I feel like you misunderstood the OP, they are claiming that Node allows you to reuse the same code to do validation on both the client and the server. By definition that means they are also doing server-side validation, and they are not relying on it being checked on the frontend.

As I see it though, node.js on the backend is not mainstream, most sites are still using JVM or other back ends. Using the same code for the front end and the back end is a dream that has been pursued in various forms but it isn’t mainstream.

Man... if you don't think node.js on the backend is mainstream at this point I don't know what to tell you. It's not even the hyped-up new thing anymore.

Re: Htmx Is the Future

#79

Post by themodelplumber »

Thanks for the reminder, I've been meaning to try it out. Just to get started, I asked ChatGPT to write an htmx app to show a 10-day weather forecast.

It described the general steps and seemed to be able to describe how htmx works pretty well, including hx-get and hx-target, etc., but then said "As an AI language model, I am not able to write full applications with code".

I replied "do the same thing in bash" (which I knew would be different in significant ways, but just to check) and it provided the code.

I wonder, is this a function of recency of htmx or something else? Do other htmx developers encounter this? I imagine it's at least a little bit of a pain for these boilerplate cases, if it's consistent vs. access to the same GPT tooling for other languages.

Re: Htmx Is the Future

#80

Post by bcrosby95 »

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 pro can be a con, and vice versa. The reason why you move to a SPA might be the reason why you move away from it. The reason why you use sqlite early on might be the reason you move away from it later.

A black & white view of development and technology is easy but not quite correct. Technology decisions aren't "one size fits all".

Post reply on HN