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

301–310 of 875 posts

Re: Htmx Is the Future

#301

Post by optymizer »

pwpw wrote: post #248

What is the simplest way to host a website closer to barebones HTML, CSS, and a bit of JS with reusable components like nav bars? My experiences handling those manually leads to too much overhead as I add more pages. SvelteKit makes things fairly easy to organize, but I dislike how the user isn’t served simple HTML, CSS, and JS files. Ideally, I don’t want to use any framework.

It's called PHP and you can host it anywhere, or if there's nothing dynamic going on, run it on the files on your computer and upload the generated HTML/CSS/JS files to an S3 bucket.

    src/index.php
    ---------
    
    
    Hey look ma, we're back to PHP
    
    
    
      
Don't forget about PHP - a hypertext preprocessor!

    
    
    
    
    
    src/navbar.php
    ----------
    
        
          Home
          About
        
    


    Makefile to generate a static site:
    -----------------------------------   
    dist/index.html: src/index.php

    dist/about.html: src/about.php

    dist/%.html: src/%.php
          @mkdir -p ${dir $@}
          php $ $@

Re: Htmx Is the Future

#302

Post by robertoandred »

afavour wrote: post #181
robertoandred wrote: post #165

Earlier quoted context omitted.

No it doesn't and no you don't. Every modern SPA framework has solved that problem long ago.

Right, so you agree: you have to reimplement it. You can just use a framework to do so. It might be news to folks to learn that every single SPA framework has solved the problem entirely because it's really not an uncommon experience to have your browser history broken by a SPA. I believe that most frameworks implement the API correctly. I also believe a good number of developers use the framework incorrectly.

That's like saying you have to reimplement assembly arithmetic, you can just use the Calculator app to do so.

Bad websites are the results of bad developers, not the tool. You can have your history messed up by any kind of website.

Re: Htmx Is the Future

#303

Post by jonahx »

recursivedoubts wrote: post #39

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

Out of curiosity, have you used hyperview? Do you consider it production ready?

Re: Htmx Is the Future

#304

Post by mtlynch »

infogulch wrote: post #231
mtlynch wrote: post #129

Earlier quoted context omitted.

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.

The attacker doesn't have to compromise the backend to achieve XSS.

Suppose your website displays user-generated content (like HN posts). If the attacker finds a way to bypass encoding and instead injects JS, then without CSP, the attacker gets XSS at that point. With CSP, even if the attacker can get user-generated content to render as JS, the browser will refuse to execute it.

My understanding of htmx is that the browser would still refuse to execute standard JS, but the attacker can achieve XSS by injecting htmx attributes that are effectively arbitrary JS.

Re: Htmx Is the Future

#306

Post by redonkulus »

vosper wrote: post #299
redonkulus wrote: post #286

We've been using similar architecture at Yahoo for many years now. We tried to go all in on a React framework that worked on the server and client, but the client was extremely slow to bootstrap due to downloading/parsing lots of React components, then React needing to rehydrate all the data and re-render the client. Not to mention rendering an entire React app on the server is a huge bottleneck for performance (can'…

> We've been using similar architecture at Yahoo for many years now. At all of Yahoo? I imagined such a big company would have a variety of front-end frameworks and patterns.

Nope, not all. Yahoo homepage, News, Entertainment, Weather all use this architecture. Yahoo Mail uses a React/Reduct architecture on the client. Other Yahoo properties with more complex client-side UX requirements are using things like Svelte or React. It's not a one size fits all architecture at Yahoo, we let teams determine the right tools for the job.

Re: Htmx Is the Future

#307

Post by Bellend »

MisterSandman wrote: post #183
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…

Angular is nototiously bad for single developers. React is much better, and things like Remix and Gatsby are even better.

I'm a single developer and its fine. (5 years in).

Re: Htmx Is the Future

#308

Post by xutopia »

Wether it is Htmx or Phoenix/Liveview or Hotwire/Stimulus we're seeing a shift in the industry towards augmented HTML rather than throwing away all RESTFUL routes. REST is elegant and this approach is very powerful as well.

Re: Htmx Is the Future

#309

Post by elliottinvent »

scoofy wrote: post #53
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…

I use htmx on my current project, and it's like a dream. I'm happy to sacrifice a bit of bandwidth to be able to do all the heavy lifting in python. On top of that, it makes testing much much easier since it turns everything is GET and POST requests. I'd add a couple features if I were working there (making css changes and multiple requests to multiple targets standard), but as it stands, it's a pleasure to work in.

Hop on the Discord, a very active and collaborative community: https://htmx.org/discord

Re: Htmx Is the Future

#310

Post by amiga-workbench »

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

I mean, I'm using Laravel Livewire quite heavily for forms, modals and search. So effectively I've eliminated the need for writing much front-end code. Everything that matters is handled on the server. This means the little Javascript I'm writing is relegated to frilly carousels and other trivial guff.

Post reply on HN