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

341–350 of 875 posts

Re: Htmx Is the Future

#341

Post by treeman79 »

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…

Yep. I was in a type 1 startup. Stuff got done fast.

Company forced us to type 2 using Angular. projects thar used to take a couple of days for one person became multi month efforts for a dozen developers across three teams.

Re: Htmx Is the Future

#342

Post by stanmancan »

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…

Have you taken a look at Elixir/Phoenix? I've recently made the switch and I find it incredibly productive as a solo developer.

Re: Htmx Is the Future

#343

Post by austinthetaco »

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.

according to the latest stackoverflow developer survey, NodeJS is extremely common and used quite a bit more than things like ASP.net (https://survey.stackoverflow.co/2022/#most-popular-technolog...)

Re: Htmx Is the Future

#344

Post by courgette »

no_wizard wrote: post #173
duxup wrote: post #11

Earlier quoted context omitted.

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…

ActionScript is basically ES6 too isn't it?

Older than that, flash already received the apple coup de grace a little while ago when ES6 was release.

Re: Htmx Is the Future

#345

Post by nirav72 »

themodelplumber wrote: post #79

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…

Was it with gpt 3.5 or 4?

Re: Htmx Is the Future

#346

Post by ratorx »

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…

Or even skip the DSL and use JS for both client and server, just independently. Validation functions can/should be simple, pure JS that can be imported from both.

Re: Htmx Is the Future

#347

Post by courgette »

BiteCode_dev wrote: post #93
hirako2000 wrote: post #76

Earlier quoted context omitted.

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

Django comes with a lot: auth, caching, csrf protection, an orm, the admin, form workflow, templating, migrations, i18n, and yet doesn't come with thousands of deps.

I maintains a side project in Django since 5+ years now.

The scope has been reduce to almost nothing. I have spend like 20h on it in 2022. But it still being used.

Django helps by how boring and solid it feels.

A similar project in node would probably not build anymore

Re: Htmx Is the Future

#348

Post by wibblewobble124 »

dfabulich wrote: post #56

People were making this prediction ten years ago. It was wrong then, and it's wrong now. This article makes its case about Htmx, but points out that its argument applies equally to Hotwired (formerly Turbolinks). Both Htmx and Hotwired/Turbolinks use custom HTML attributes with just a little bit of client-side JS to allow client-side requests to replace fragments of a page with HTML generated on the server side. But…

we’re using htmx at work, migrating away from react. the technique we’re using is just rendering the whole page, e.g. we have a page where one side of the screen is a big form and the other side is a view on the same data but with a different UI, updating one updates the other. we’re using the morphdom swapping mode so only the things that changed are updated in-place. as a colleague commented after implementing this page, it was pretty much like react as far as “pure function of state.”

Re: Htmx Is the Future

#349

Post by fredrikholm »

tgbugs wrote: post #102

I first encountered the principles behind htmx in its precursor intercooler.js. Those principles really resonated with my distaste for complexity. Amusingly I found out about htmx itself when rereading https://grugbrain.dev and it all clicked! htmx is crystal that trap internet complexity demon!

Irony that they're all made by the same person!

Re: Htmx Is the Future

#350

Post by robertoandred »

afavour wrote: post #325
robertoandred wrote: post #316

Earlier quoted context omitted.

Why would anyone choose to create and use their own unreliable calculator instead of what came installed?

…that’s the point being made

The point that bad websites are the result of bad developers, not the tools?
Post reply on HN