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

571–580 of 875 posts

Re: Htmx Is the Future

#571

Post by narag »

cromulent wrote: post #515
narag wrote: post #502

Earlier quoted context omitted.

A "this doesn't look like an email-address, did you mean... Stop right there. I'm tired of receiving mail from people that gave my email address as if it was their own. Never ever accept an email address unless you can instantly confirm it's valid sending an email and waiting for an answer . If the user can't access their email on the spot, just leave it blank and use another data as key. I wish they included that in…

I think this is the point of the client side check though - if the user makes a typo (e.g. gamil.com) then the client side validation can prompt them to check, before the server sends the validation email and annoys the owner of the typoed address.

My point is that it doesn't matter if some arbitrary string looks like an email address, you need to check.

If it isn't valid the server won't annoy anyone. The problem is that the address is valid. And not theirs, it's mine.

The moment the users need to be careful, they will. Make the problem theirs, not mine.

"Sorry sir, the address you provided returns error" or "haven't you received the confirmation email YET? really? there are other customers in the line" and see how soon they remember the right address, perfectly spelled.

Even big ass companies like Paypal that have no problem freezing your monies, allow their customers to provide unchecked email addresses and send income reports there. (here)

Re: Htmx Is the Future

#572

Post by rektide »

wwweston wrote: post #42
rektide wrote: post #2

Personally I believe strongly in thick clients but this is a pretty neat demo anyways. I see a lot of resemblance to http://catalyst.rocks with WebComponents that target other components. I think there's something unspoken here that's really powerful & interesting, which is the declarativization of the UI. We have stuff on the page, but making the actions & linkages of what does what to what has so far been trapped i…

> the declarativization of the UI Yes! There's always going to be some range of client behavior that's difficult to reduce to declarations, but so much of what we do is common that if it isn't declarative we're repeating a lot of effort. And in general I think you're describing a big part of what made the web successful in the first place; the UI-as-document paradigm was declarative, accessible, readable, repeatable.

Thank you! Yes and!:

> but so much of what we do is common that if it isn't declarative we're repeating a lot of effort.

We're not only repeating effort, we're also using artisinal approaches to wiring things up. Hand writing handlers is repeated work with low repeatability; there'll be a variety of forms & ways & places people end up writing similar-ish handlers, & creating the data model to pass all the references/targets around.

Being more declarative is not only less work, it also ought be much higher quality, more predictable, to have a lot less vagueries of implementation. It'll make it much easier to comprehend & maintain. Less work, for more repeatable/consistent outcomes.

Re: Htmx Is the Future

#573

Post by _heimdall »

lakomen wrote: post #552
recursivedoubts wrote: post #190

Earlier quoted context omitted.

https://htmx.org/essays/hateoas/

I hate HATEOAS with a passion. Yet another useless Java gimmick with no support other than 1 single framework, Spring Boot. If htmx has anything to do with HATEOAS it's going to be ignored out of principle.

Mind sharing why you have such strong opinions on HATEOAS?

Is you problem that there aren't many implementations of it today or concerns with the architecture itself?

Re: Htmx Is the Future

#574

Post by charrondev »

respondo2134 wrote: post #566
charrondev wrote: post #460

Earlier quoted context omitted.

I work at a company that makes a very clear distinction between API and View layer. Our API spans 200+ endpoints. We have 6 backend and 6 frontend developers. As far as iterations go it’s very rapid. Our work teams are split into 1 backend and 1 frontend developer. They agree on an API spec for the project. This the contract between them and the frontend starts working immediately against a mock or very minimal versi…

This is a pretty popular approach, and I use it sometimes, but "agree on an API spec for the project" does gloss over how challenging and time consuming this can be. How many people here have ever gotten their API wrong? (raises hand). There's still a lot of ongoing coordination and communication.

Oh certainly. It’s pretty rare to get things exactly right on the first try. For this reason we hide new endpoints from our public open api spec and documentation until we are satisfied that some dust has settled on them a little bit.

Still you only have to get it mostly right. Enough to get started. This only starts to become a huge problem when the endpoints is a dependency of another team. When you’re in constant communication between the developer building the API and the developer building the client it’s easy to adjust as you go.

I find a key part of a workflow like this though especially if you have multiple teams is to have a lead/architect/staff developer or whatever you may call it be the product owner of the API.

You need someone ensure consistency and norms and when you have an API covering functionally as broad and deep as the one I work on, it’s important to keep in mind each user story of the API:

- The in house client using the API. This generally means some mechanism to join or expand related records efficiently and easily and APIs providing a clear abstraction over multiple different database table when necessary. - The external client, used by a third party or the customer directly for automation or custom workflows. The biggest thing I’ve found helps these use cases is to be able to query records by a related field. For example if you have some endpoint that allows querying by a userID, being able to also query by by a name or foreignID passed over SSO can help immensely.

Re: Htmx Is the Future

#575

Post by emodendroket »

8organicbits wrote: post #545
emodendroket wrote: post #82

Earlier quoted context omitted.

I don't understand why that should be the case. There are a lot of checks that end up needing to be repeated twice with no change in logic (e.g., username length needs to be validated on both ends).

Input validation checks are such a small part of the codebase; it feels weird that it would dictate the choice of a server-side programming language. Server-side python is very capable of checking the length of a string, for example. One challenge is that you've got to keep the server-side and client-side validations in sync, so if you'd like to increase the max length of an input, all the checks need to be updated.…

I don’t disagree that if this is your sole reason for picking a language it is not a great one. But it is a benefit nevertheless. And obviously we can express more complex rules in a full-on programming language.

Re: Htmx Is the Future

#576

Post by emodendroket »

petepete wrote: post #542
emodendroket wrote: post #340

Earlier quoted context omitted.

That seems like it’s resolved by waiting for a focus change event.

Not really. GOV.UK Design System team have done lots of research into this and their guidance says: > Generally speaking, avoid validating the information in a field before the user has finished entering it. This sort of validation can cause problems - especially for users who type more slowly https://design-system.service.gov.uk/patterns/validation/

Not seeing how that’s inconsistent with evaluating when the user goes to the next field.

Re: Htmx Is the Future

#577

Post by adrr »

detaro wrote: post #431
ragall wrote: post #388

Earlier quoted context omitted.

A SPA can track the mouse cursor, as well as stealing form content that was left unsubmitted.

an MPA can use javascript that does exactly the same.

You don’t even need JavaScript. CSS has Hover attribute and you can use it to fire beacons.

Re: Htmx Is the Future

#578

Post by adrr »

ragall wrote: post #388
adrr wrote: post #125

Earlier quoted context omitted.

I don't understand how spa is different than vanilla web app in terms of user analytics? A beacon is a beacon. Whether its img tag with a 1x1 transparent gif or an ajax call. Also validation is usually built on both client and server for the same things. Like if you have a password complexity validation. Its both on UX and the server otherwise it will be a very terrible UX experience.

A SPA can track the mouse cursor, as well as stealing form content that was left unsubmitted.

Htmlx has a type ahead attribute that you can add to form elements and send the contents to an endpoint without the user explicit submitting the form.

Re: Htmx Is the Future

#579

Post by beezlewax »

PaulHoule wrote: post #179
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 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…

But you can download another node package from npm to delete those other npm packages: npkill. For whatever reason this is as they say in the javascript world "blazingly fast"

Re: Htmx Is the Future

#580

Post by adrr »

pphysch wrote: post #111
blowski wrote: post #44

Earlier quoted context omitted.

> The real reason that SPAs arose is user analytics. Can you go into that a bit? I don't really understand what you mean.

HTML gives very limited tools for tracking what a (potentially JS-less) user is doing. There are various tricks, like "link shorteners" and "magic pixels" that allow some tracking. But if you want advanced tracking, like tracking what a user is focusing on at a particular instant, you need to wrap the whole document in a lot of JS. SPA frameworks came out of AdTech companies like Meta, and I assure you it wasn't beca…

You can do all that with vanilla html. Cursor tracking, scroll tracking. With HTMLX it makes it trivial.

React isnt a SPA framework. It’s a component framework. It has no router or even state management. ExtJs is an Mvc framework in JavaScript and can be used to create a full spa app without additional libraries. It also came out in 2007. There is also ember that also predates react and is another mvc framework by the people who did rails.

Post reply on HN