> Some SPA implementations of SPA throw away progressive enhancement (a notable and noble exception is Remix). Therefore, you must have JavaScript turned on for most SPAs.
Is this really the future?
Htmx Is the Future
41–50 of 875 posts
Re: Htmx Is the Future
#42Personally 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.
Re: Htmx Is the Future
#43I'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…
>Imagine some cool feature like... collaborative editing. What are you gaining by writing something like that in java/type-script rather than like rust and webassembly? To me javascript is in a sort of uncanny valley where you probably want to be either making a real app and compiling it to wasm or using something like htmx.
> rather than like rust and webassembly
WASM can't even interact with the DOM, how exactly are these languages positioned better to give me access to a ton of UI primitives?
The backend can be a fast language, certainly, but the browser is a premier UI platform... and it's powered by JS...
To me, Rust developers thinking they know how to build UIs is the real uncanny valley. What they produce looks like it should work, but the more you look at it, the more you realize they don't know what UX stands for
Re: Htmx Is the Future
#44It'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.
> The real reason that SPAs arose is user analytics.
Can you go into that a bit? I don't really understand what you mean.
Re: Htmx Is the Future
#45I like how the cons of SPA are "you have to manage state" and "clients have to execute code".
I mean, aren't these baseline "get computers to do stuff" things?
Re: Htmx Is the Future
#46It'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 the hype about javascript on the server (node) being front-end devs didn't have to know/learn a different language to write backend code. Not so much writing code once but not having to write Javascript for client-side and then switch to something else to write the server-side.
I remember it being both and then some...
[edit: both comprising shared code between client and server, as well as, reduced barrier to server-side contribution, and then some including but not limited to the value of the concurrency model, expansive (albeit noisy) library availability, ...]
Re: Htmx Is the Future
#47Earlier quoted context omitted.
> 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, tha…
The first SPA I wrote, I wrote in React for my use and for the use of friends. I spent about 3 days getting it working and then 3 months getting it to usable performance on my phone. There were no analytics, no binary data (100% text), just a bunch of editable values and such. I ended up having to split it up into a bunch of tabs just to reduce the size of the vdom.
Re: Htmx Is the Future
#48i am the creator of htmx, this is a great article that touches on a lot of the advantages of the hypermedia approach (two big ones: simplicity & it eliminates the two-codebase problem, which puts pressure on teams to adopt js on the backend even if it isn't the best server side option) hypermedia isn't ideal for everything[1], but it is an interesting & useful technology and libraries like htmx make it much more rele…
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
Re: Htmx Is the Future
#49Earlier quoted context omitted.
I have never heard this before. Can you elaborate on the differences? What do you validate on the client side that you don't on the server and vice versa?
Some validations require capabilities that you don't want/need the client to have. There are also validations that can improve UX but aren't meaningful on the server. Like a "password strength meter", or "caps lock is on". Religiously deploying the same validations to client and server can be done, but it misses the point that the former is untrusted and just for UX. And will involve a lot of extra engineering and un…
I'm not sure adding a meter value output to the server side check to use it in both places is really more engineering work. Writing separate checks on the client and server side seems much more likely to create headache and extra work.
That said, I could definitely see additional checks being done server side. One example would be actually checking the address database to see if service is available in the entered address. On the other hand, there really isn't any waste here either. I.e. just because you write the validation in server side JS doesn't mean you MUST therefore deploy and use it in the client side JS as well, it just means you never need to worry about writing the same check twice.
Re: Htmx Is the Future
#50If your project consists of a todo list, these tools will do the trick. but they are useless for projects with larger and more complex needs. and yes, there may be cases where it doesn't work in frameworks like nextjs and you need to apply hacky solutions. but I don't see even libraries like nextjs being so self-praising. Come on, folks, there's no point in praising a small package that can do some operations through…
You can always incrementally add dynamic features using web components when HTMX and similar things aren't a good fit. It doesn't have to be either HTMX or JS-first frameworks. Our industry's fixed mindset of JS/React vs. Hypermedia (e.g., HTMX/Hotwire/Unpoly) needs to change.