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

111–120 of 875 posts

Re: Htmx Is the Future

#111

Post by pphysch »

blowski wrote: post #44
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.

> 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 because they had limited engineering resources.

Re: Htmx Is the Future

#112

Post by s1k3s »

Love articles like this because I know there's some manager somewhere who will read this and force it upon their team without having any idea if it's good or not. And in 3 years we'll have people from those teams complaining about HTMX because it's not suited for their projects.

The future is whatever works best for your use-case.

Re: Htmx Is the Future

#113

Post by CSSer »

tomca32 wrote: post #32
onion2k wrote: post #16

Earlier quoted context omitted.

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.

Most companies unfortunately don't let developers adequately explore solutions or problem spaces before committing to them either. The ones that dominate do, but that's also because they often have the resources to build it from the ground up anyway.

The average mid-sized business seems to have internalized that code is always a liability, but they respond by cutting short discovery and get their just deserts.

Re: Htmx Is the Future

#114

Post by tempest_ »

giraffe_lady wrote: post #36
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…

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.

Re: Htmx Is the Future

#115

Post by 0xbadcafebee »

I just want Visual Basic for the web man. Screw writing lines of code. I want to point and click, drop complex automated objects onto a design, put in the inputs and outputs, and publish it. I don't care how you do it, I don't want to know any of the details. I just want to be able to make things quickly and easily. I don't care about programming, I just want to get work done and move on with my life.

At this rate, when I'm 80 years old we will still be fucking around with these stupid lines of code, hunched over, ruining our eyesight, becoming ever more atrophied, all to make a fucking text box in a monitor pop some text into a screen on another monitor somewhere else in the world. It's absolutely absurd that we spend this much of our lives to do such a dumb thing, and we've been iterating on it for five decades, and it's still just popping some text in a screen, but we applaud ourselves that we're so advanced now because something you can't even see is doing something different in the background.

Re: Htmx Is the Future

#116

Post by avisser »

traverseda wrote: post #20
mikece wrote: post #7

"You can use whatever programming language you like to deliver HTML, just like we used to." Is this suggesting writing any language we want in the browser? I have wondered for a couple decades why Python or some other open source scripting language wasn't added to browsers. I know Microsoft supported VBScript as an alternative to JavaScript in Internet Explorer and had it not been a security nightmare (remember the w…

It is not suggesting running arbitrary languages in the browser. It's basically Ajax.

Commenting on "It's basically Ajax": Yes, and it's also a return to the basics of a browser. Making HTTP calls (Hypertext Transfer Protocol) to get HTML (the aforementioned Hypertext) and rendering it is the core thing that browsers do. It's both necessary and sufficient to being a browser.

Re: Htmx Is the Future

#117

Post by benatkin »

renerick wrote: post #106
benatkin wrote: post #77

Earlier quoted context omitted.

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.

HTML forms absolutely do function without htmx since it's a part of browser standard. By default, htmx sends forms using same content type as browser does (application/x-www-form-urlencoded). The server will receive same requests, as if the browser sent them and can differentiate by presence of HX-Request HTTP header.

That's the properly part. If you make a form and the output is supposed to go in a particular place and it doesn't (hx-swap), then it isn't functioning properly. The degree to which it is improperly functioning depends on the UI and the user. In many cases it's improperly enough that it may as well either work or not work.

Re: Htmx Is the Future

#118

Post by tomhallett »

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…

have you seen any interest by the browsers to build htmx features as experimental browser features, with the goal of htmx features becoming browser standards?

When looking at the various options, I always enjoyed your architectural choice of htmx being an extension of html, for that very reason. Similar to "phonegap" hoping that the phonegap code base would get smaller and smaller as mobile browsers built more of those features natively. :)

Re: Htmx Is the Future

#119

Post by mtlynch »

jeremyjh wrote: post #66
mtlynch wrote: post #58

I really want to switch over to htmx, as I've moved away from SPAs frameworks, and I've been much happier. SPAs have so much abstraction, and modern, vanilla JavaScript is pretty decent to work with. The thing that keeps holding me back from htmx is that it breaks Content Security Policy (CSP), which means you lose an effective protection against XSS.[0] When I last asked the maintainer about this, the response was t…

Alpine is a lightweight client side framework, not really at all equivalent to htmx.

I'm not sure what you mean. htmx and alpine.js are both client-side frameworks. To me, they seem to have similar goals and similar functionality.

What do you see as the difference?

Post reply on HN