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

11–20 of 875 posts

Re: Htmx Is the Future

#11

Post by duxup »

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 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 using old ColdFusion... it is faster for somethings.

Really though there's so many advantages to different approaches, the important thing is to do the thing thoughtfully.

Re: Htmx Is the Future

#12

Post by aidenn0 »

> 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 internet connections" is not specific to SPAs If anything a thick client provides opportunities to improve the experience for locations with slow and unreliable internet connections.

[edit2]

> If you wish to use something other than JavaScript or TypeScript, you must traverse the treacherous road of transpilation.

This is silly; I almost exclusively use compiled languages, so compilation is happening no matter what; targeting JS (or WASM) isn't that different from targeting a byte-code interpreter or hardware...

--

I like the idea of HTMX, but the first half of the article is a silly argument against SPAs. Was the author "cheating" in the second half by transpiling clojure to the JVM? Have they tested their TODO example on old hardware with an unreliable internet connection?

Re: Htmx Is the Future

#13

Post by loloquwowndueo »

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 that. On the server, you can use your language of choice to generate complete or partial HTML responses to be sent and then put in the right places on the page by JavaScript (htmx) running on the browser.

Re: Htmx Is the Future

#14

Post by biorach »

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…

> Is this suggesting writing any language we want in the browser?

Nope, server

Re: Htmx Is the Future

#15

Post by nawgz »

I'm sorry, but these arguments are so tired.

> SPAs have allowed engineers to create some great web applications, but they come with a cost:

> Hugely increased complexity both in terms of architecture and developer experience. You have to spend considerable time learning about frameworks.

Yes, better quality software usually packages a bit more complexity.

SPAs are popular, just like native apps, because people don't like jarring reloads. Webviews in native apps are panned for a reason; turning your whole app into a series of webviews would be stupid, right?

> Tooling is an ever-shifting landscape in terms of building and packaging code.

I've used these 4 libraries to build apps since 2015:

* React * MobX * D3 * Webpack

The only one I have had pain with is react-router-dom, which has had 2 or 3 "fuck our last approach" refactors in this time. And I added TypeScript in 2018.

PEBCAK

> Managing state on both the client and server

It's a lie that a thin client isn't managing state; it's just doing a static, dumb job of it.

Imagine some cool feature like... collaborative editing.

How would you pull that off in HTMX?

> Frameworks, on top of libraries, on top of other libraries, on top of polyfills. React even recommend using a framework on top of their tech:

Yes, React is famously not a batteries-included library, while Angular is. But, as addressed, you need about 3 other libraries.

Besides, did you know: HTMX is also a framework. Did you know: HTMX also has a learning curve. Did you know: HTMX forces you to be able to manipulate and assemble HTMLstrings in a language that might not have any typing or tooling for that?

Anyways, I've said enough. I should've just said what I really think: someone who can't even get their nested HTML lists to actually indent the nesting shouldn't give advice on building UIs.

Re: Htmx Is the Future

#16

Post by onion2k »

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…

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, which in turn reduces the surface area of things that they can get wrong. A perfect framework would give the developer all the resources they need to build an app but wouldn't expose anything that they can screw up. I don't think that can exist, but it is definitely possible to reduce places where devs can go astray to a minimum.

And, obviously, that can be done on both the server and the client.

I strongly suspect that as serverside frameworks (including things that sit in the middle like Next) improve we will see people return to focusing on the wire transfer time as an area to optimize for, which will lead apps back to being more frontend than backend again. Web dev will probably oscillate back and forth forever. It's quite interesting how things change like that.

Re: Htmx Is the Future

#17

Post by jimmaswell »

I've made my personal website something of a hybrid SPA. WithJS enabled it only loads and replaces the relevant portions of the page, but a page renders fully from PHP going to it directly.

Relevant code:

https://github.com/ldyeax/jimm.horse/blob/master/j/j.php

https://github.com/ldyeax/jimm.horse/blob/master/j/component...

The JS would be a bit more elegant if script tags didn't need special handling to execute on insertion.

The experience is very seamless this way - I'm very pleased with it. It's live at https://jimm.horse - the dynamic behavior can be found clicking on the cooking icon or N64 logo.

On reading the article, I'll definitely make use of this if it becomes well-supported. It does exactly what I wanted here.

Re: Htmx Is the Future

#18

Post by pphysch »

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…

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.

Re: Htmx Is the Future

#19

Post by obpe »

zelphirkalt wrote: post #8
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. It's a pretty shitty client experience if you have to do a network request for each and every validation of user input. Node does not absolve from this. Any important verification still needs to be done on the server side, since any JS on the client side cannot be trusted to not be manipulated. J…

>Node does not absolve from this. Any important verification still needs to be done on the server side, since any JS on the client side cannot be trusted to not be manipulated. JS on the client side was of course possible before NodeJS. NodeJS did not add anything there regarding where one must verify inputs. Relying on things being checked in the frontend/client-side is just writing insecure websites/apps.

Yeah, that was my point. With Node you can write JS to validate on both the client and server. In the article, they suggest you can just do a server request whenever you need to validate user input.

>Basically most of any progress in bandwidth or ressources is eaten by more bloat.

In my experience, the bloat comes from Analytics and binary data (image/video) not functional code for the SPA. Unfortunately, the business keeps claiming it's "important" to them to have analytics... I don't see it but they pay my salary.

Re: Htmx Is the Future

#20

Post by traverseda »

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.
Post reply on HN