Hacker News Reader

Comment by Zenbit_UX | Hacker News Reader

I love when devs blow off SPAs because they think they're geniuses or above JS. You spun up a shitty 1995 style site that every menu on the toolbar triggers a page reload and patted yourself on the back. Congrats on sending the same html and css with every page load, I'm sure your low network speed users love it.

Eureka exclaimed the "full-stack" developer, who needs javascript!?

View on HN

> Congrats on sending the same html and css with every page load, I'm sure your low network speed users love it.

If only browsers could somehow retain the parts of a web page that did not change, like images and css and js, in some sort of local storage or cache.

You can probably express this without personal attacks

The HTML is probably smaller than the JavaScript blob.

If you can get the HTML within the same order of magnitude as JSON itself, then it's perhaps a compelling argument to ditch SPAs. The bandwidth delta would be minimal, and the development overhead would be much less substantial.

Note that this is how the web used to be. Small HTML markup.

We even started baking structured meaning into the HTML (Semantic Web, "Web 3.0") so that documents could be consumed like APIs. But then JSON and the platform giants put an end to p2p web payloads and rich document schemas. That was a mistake.

Probably you're not aware yet that there are also "modern ways" to do server side templates/html. Nowadays you have things such as Unpoly, Htmx, Hotwire, Livewire, etc which can be added incrementaly to any traditional MVC applications leading to an incredible reduction in the amount of work necessary to ship something robust if you're a single developer or in a small team.

SPAs can be great for large teams with different skills/profiles, and large companies with a lot of money though.

Unfortunately, this kind of discussion ends up turning into a knife fight these days here.

I tried using HTMX recently for mainly a CRUD app for personal use, with limited dynamic loading. Still felt the need to rely on JS(Jquery) for loading images and triggering refresh on list of items without full page reload[1].

Did a small A/B test from dev POV using Vue.js, as it is one of the more lighter frameworks. Ended up leaning more towards Vue.js, as had to do some non-conventional(from HTMX POV)[1] things for a simple CRUD app not relying on full page loads/refreshes. Hopefully there is another step in this evolution.

would you mind reaching out to let me know where htmx fell down for you?

htmx at bigsky dot software

or you can jump on the discord if that works:

https://htmx.org/discord

thanks for taking a look at htmx

You have Cache-Control and Expires headers for this. Old shitty 1995 style I know.

This is a harsh but correct take. Additionally separating your backend logic into an API makes it easier to write more clients for your service. This benefit can’t be overstated.

Sure it can. Such as implying "the only way you'd be able to separate your backend logic into an API is if your browser client uses it".

Even if I knew I needed an API and multiple clients with 100% certainty (and most products don't), I would still prefer to build my browser client deeply integrated without separating the backend logic. The benefits of having at least one platform with faster dev speed cannot be overstated.

Ya, it all really comes down to the problem you’re solving and what makes sense for the task at hand. The point I was trying to get across in my other reply to you is that sometimes the thing that makes the most sense is an SPA (even if it’s less performant, or takes a little longer to build).

If your HTML-generating code interfaces with a clearly-defined internal API, then your JSON API can be just a thin layer that authenticates the user and provides an HTTP front-end to your internal API.

Essentially, your web "client" is now the HTML-generating server-side code instead of a JavaScript app. Other clients are unaffected and can work the same as they otherwise would.

I've never worked with a web application where the requirements of the "customer facing API" and the "drives the web application API" (or the "drives the mobile application API", "drives the internal admin app API", etc.) matched for very long, if ever. Customers will usually need a small subset of the API that your web app does, the authentication will likely be different, you will need to make optimizations in your web app fetching that will be highly tuned to your specific use case, and a whole bunch of other concerns that make the idea of your web application being driven off your public API unrealistic.

Reply on news.ycombinator.com