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

401–410 of 875 posts

Re: Htmx Is the Future

#401

Post by dsego »

berkes wrote: post #376
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…

Even worse: Client-side validation and server-side validation (and database integrity validation) are all their own domains! I call all of these "domain logic" or domain validation just to be sure. Yes, they overlap. Sure, you'll need some repetition and maybe, indeed, some DSL or tooling to share some of the overlapping ones across the boundaries. But no! They are not the same. A "this email is already in use" is se…

I think the main concern for frontend validation was before HTML5 came along with validation attributes. You can easily produce HTML input validation attributes from a Yup schema for example by using its serialization feature (https://github.com/jquense/yup#schemadescribeoptions-resolve...). Here is an example from some silly code I wrote a while back testing htmx with deno https://github.com/dsego/ssr-playground/

Re: Htmx Is the Future

#402

Post by Pet_Ant »

aidenn0 wrote: post #57
727564797069706 wrote: post #35

Earlier quoted context omitted.

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?

I suppose we could stop rewarding people for delivering features that customers want...

Or make them accountable for long term consequences. It’s no different than CEOs cutting R&D and calling a profit. Deferred bonuses till a 3 year post mortem would help.

Re: Htmx Is the Future

#403

Post by cutler »

tempest_ wrote: post #114
giraffe_lady wrote: post #36

Earlier quoted context omitted.

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

To be fair to PHP there have been quite a few improvements to the language in recent years. I even hear Laravel is pretty nice to use. I'll never know that stuff though because the PHP I generally encounter is 15 years old spaghetti.

PHP lost its identity with the release of PHP5 since when it is nothing more than an interpreted version of Java.

Re: Htmx Is the Future

#404

Post by nine_k »

I think it's the wrong article (pun semi-intended), HTMX is a future. React is a future. Svelte is a future. Even Angular is a future. They all have their specific strengths which define where they are more applicable.

There's no "the future" in this area, because demands are very different; a heavily interactive SPA like GMail or Jira has requirements unlike an info page that needs a few bits of interactivity, etc.

Re: Htmx Is the Future

#405

Post by cutler »

sidlls wrote: post #240
emodendroket wrote: post #78

Earlier quoted context omitted.

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.

Being not hyped up doesn’t mean it’s mainstream. Most backends are in Java, Go, or PHP. Python and Ruby take up most of those that aren’t. It’s rare to find node on the backend in comparison.

Go more ubiquitous than Node.js? In your dreams.

Re: Htmx Is the Future

#406

Post by emodendroket »

ZephyrBlu wrote: post #353
emodendroket wrote: post #235

Earlier quoted context omitted.

Right, you shouldn’t, but that means writing them twice. One of the selling points of backend JavaScript is the same validation code can run on both ends (obviously any validator that needs to check, e.g., uniqueness in a database won’t work).

Frontend and backend validation are usually not the same though. You won't be writing the same thing twice, you'll be writing different validations for each.

I think the frontend validations will, most of the time, be a subset of the backend ones, with many shared validation points.

Re: Htmx Is the Future

#407

Post by dtagames »

replygirl wrote: post #295
dtagames wrote: post #130

Earlier quoted context omitted.

This is not correct. SPAs and web components were pioneered by Google with the introduction of Angular. Later, Vue was invented by a previous Google employee who had worked on Angular. Finally, Facebook came up with React (it's a "reaction" to Angular) because they could not be seen using a Google product. If anything, SPAs make metrics harder because they hide the real behavior of the page in local JS/TS code and do…

your timeline is a bit off. facebook had react in production (mid-late 11) less than a year after angularjs went public, open-sourced it 18-24 months later (early 13), then evan started working on vue a few months after that (mid 13) and released early the following year

Thank you. I stand corrected.

Re: Htmx Is the Future

#408

Post by megalord »

lucasyvas wrote: post #209
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…

You're on the money with this assessment. It's all bandwagon hopping without any consideration for reality. Also, all these things the author complains about are realities of native apps, which still exist in massive numbers especially on mobile! I appreciate that some folks only need to care about the web, but declaring an architectural pattern as superior - in what appears to be a total vacuum - is how we all colle…

> to one very specific type of client is frankly stupid

However, I see this specific type of clients that need just basic web functionalities, e.g CRUD operations and build something basic more prevalent than those that need very instant in-app reactivity and animations and so on (React, and SPA ecosystem).

Nowadays that's exactly the opposite, every web developer assumes SPA as default option, even on these simple CRUD examples.

Re: Htmx Is the Future

#409

Post by dtagames »

traverseda wrote: post #399
dtagames wrote: post #227

Earlier quoted context omitted.

I work with SPAs with API calls every day. It definitely reduces the server interactions over computing everything on that side, and it gives fewer points of contact with the server about the user's behavior. For example, many clicks and other actions will not result in any server contact at all. I'm aware that they call it "reactive" but I'll stick with my rationale. There is no way they would use a Google product l…

I... don't believe you? Like looking at the network request of any SPA I've ever seen there's just tons of requests for even simple page loads. One for main content, one for profiles, one for comments, etc. In theory stuff like graphql helps but in the reality I'm living in SPA's hit multiple endpoints to get render even simple pages.

Definitely true, and mine do also. It's a side effect of the migration to microservices and away from monolithic endpoints.

Re: Htmx Is the Future

#410

Post by simplotek »

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…

> 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 write code once, anywhere. The promise was to write JavaScript anywhere.

Post reply on HN