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

231–240 of 875 posts

Re: Htmx Is the Future

#231

Post by infogulch »

mtlynch wrote: post #129
recursivedoubts wrote: post #69

Earlier quoted context omitted.

htmx can work w/ a CSP, sans a few features (hx-on, event filters)

My understanding based on the docs[0] is that htmx works with CSP, but it also drastically weakens its protection, as attackers who successfully inject JS into htmx attributes gain code execution that CSP would have normally prevented. Am I misunderstanding? If I can use htmx without sacrificing the benefits of CSP, I'd really love to use htmx. [0] https://htmx.org/docs/#security

I don't understand the concern. If your backend is sufficiently compromised to inject arbitrary js into sever responses then you've already lost, and I don't see how that's worse than serving a compromised App.js from the same server.

Re: Htmx Is the Future

#232

Post by BeefySwain »

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…

I keep seeing people talk about this, can someone create a minimum example of what this exploit would look like?

Re: Htmx Is the Future

#233

Post by foobarbecue »

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…

welcome to City Web Design, can a take a order

Re: Htmx Is the Future

#234

Post by v0idzer0 »

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…

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. This may be worse for small teams but is significantly better for large teams (like Facebook and Google who started these trends).

One example is your iOS app can hit the same API as your web app, since your server is no longer tightly coupled to html views. You can version your backend and upgrade your clients on their own timelines.

Re: Htmx Is the Future

#235

Post by emodendroket »

ZephyrBlu wrote: post #206
emodendroket wrote: post #82

Earlier quoted context omitted.

I don't understand why that should be the case. There are a lot of checks that end up needing to be repeated twice with no change in logic (e.g., username length needs to be validated on both ends).

You shouldn't have to wait until you submit something to get feedback on it. It's poor UX. Frontend and backend validations are also different. Frontend is more about shape and type. Backend is content and constraints.

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

Re: Htmx Is the Future

#236

Post by BeefySwain »

quest88 wrote: post #192

This is a weak argument. The article is demoing a TODO app talking to localhost. Almost any library, framework, or language is the future if this is how we're judging the future. > Working with HTMX has allowed me to leverage things I learned 15-20 years ago that still work, like my website. Yes, a website is different than a webapp and has different requirements.

> Yes, a website is different than a webapp and has different requirements.

The piece missing here is that most people do not stop to think which they are building before they reach for a JS heavy SPA framework and start spinning up microservices in whatever AWS calls their Kube implimentation.

Re: Htmx Is the Future

#237

Post by emodendroket »

PaulHoule wrote: post #230
emodendroket wrote: post #187

Earlier quoted context omitted.

Why make a round trip if you don’t have to?

Some kinds of validation really do need the round trip. If somebody is choosing a user name on a sign up for you do need to do a database lookup. If your back end is fast and your HTML is lean, backend requests to validate can complete in less time than any of the 300 javascript, CSS, tracker, font, and other requests that a fashionable modern webapp does for no good reason... It's true though that many back ends are…

Yeah, obviously if it requires I/O you can’t write it client side, but the argument here seems to be in favor of doing validation only server-side even when it could also be done client-side.

Re: Htmx Is the Future

#238

Post by kbenson »

jfvinueza wrote: post #225
RHSeeger wrote: post #61

Earlier quoted context omitted.

> We moved away for MPAs because they were bloated, slow and difficult to work with. SPAs have definitely become what they sought to replace. Plus we now get the benefit of people trying to "replace" built in browser functionality with custom code, either The SPA broke it... Back button broken and a buggy custom implementation is there instead? Check. or They're changing things because they're already so far from def…

Mail is not a good example. Why would you like to read a collection of documents through A Single Page interface? Gmail was a fantastic improvement over Hotmail and Yahoo, and it provided UX innovations we still haven't caught up with, yes, but MPAs are naturally more suited for reading and composing them. Overriding perfectly clear HTML structure with javascript should be reserved for web experiences that are not do…

Mail is good for a SPA because the main central view which shows the different items (emails) to view or take an action on is based on a resource intensive back-end request, so keeping that state present and not having to refresh it on many of the different navigation actions yields a tremendous benefit.

You could do some client side caching with local page data, but just keeping it present and requesting updates to it only is vastly superior.

Thats honestly one place SPAs shine, where there's a relatively expensive request that provides data and then a lot of actions that function on some or all of that data transiently.

Re: Htmx Is the Future

#239

Post by jksmith »

lolinder wrote: post #156
jksmith wrote: post #132

You know, nobody likes this argument, but desktop is still just better. Yeah, yeah, the updates, security issues, I get it, but the tools are simple better, render faster, better functionality/complexity ratio, less gnashing of teeth.

Desktop on which OS? Using what GUI framework? The web is a single platform, but the desktop developer experience seems to vary wildly depending on the OS. I'm genuinely curious what OS and tooling you use that you find so much better, because every time I've tried desktop development I eventually give up and go back to the web. It might be because Linux support is always a requirement for me.

Both Delphi and FreePascal (less so) support windows, linux, mac, android with the same codebase (or calls rather). The Delphi model has really set the standard for a robust desktop framework, since before most people started writing code.

Re: Htmx Is the Future

#240

Post by sidlls »

emodendroket wrote: post #78
PaulHoule wrote: post #51

Earlier quoted context omitted.

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.

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