Hacker News Reader

>We recently deployed an entire SaaS only using server-side rendering and htmx [2] to give it an SPA-like feel and immediate interactivity where needed. It was a pleasure to develop, it's snappy and we could actually rely on the Browser doing the heavy lifting for things like history, middle click, and not break stuff.

I'm glad we're coming back to server side rendering with some JavaScript for interactivity, but from about 2005 - 2015 this was simply known as web development. You didn't need to worry about breaking the back button or middle mouse or command clicks because they just worked.

I feel like with React, we made the actual JavaScript code simpler at the expense of everything else in the system becoming way more complex.

Depends on what you build. I find a REST server + client side rendered frontend quite simpler to grok than a server side rendered page. Mostly because the separation between UI and data is really clear and all of the CLI interfacing comes free as well. There is certainly a way to split this well with SSR, but it's also easier to fall into the trap of tightly coupling the parts.

Sure, but you can just as easily fall into the trap of massively over-engineering your client-side rendering because you just grab packages off the shelf for every little thing instead of going "it's a little bit more work, but there is no reason to any of this when the browser already does this", like ending up with a 100kb bundle for what is effectively just a standard form that would work better, with less code, if it just used a normal form with built-in validation for almost everything, with the final acceptance/rejection determined by the api endpoint.

It really depends on which SSR approach we're comparing to which client-rendering approach, and who you're optimizing for.

I have fond memories of creating images with Grunge fonts in some pirated copy of Photoshop and then positioning them with HTML tables and Dreamweaver.

Those were good times in a lot of ways!

Also I may be an outlier, but IMO grunge as a textural expression still benefits lots of contemporary design projects. In fact if you know how to work within broader principles of design, maybe you stop caring as much about what's current, because that's just one of many outcomes that may or may not be appropriate for the message...

This is how I learned web development. Don't forget photoshopping the glossiest buttons possible. Not sure if that fad was before or after the grunge.

Gloss was a trend in the mid 2000s, if I remember correctly—around the same time that AJAX started becoming really popular

Web 2.0. Such a bright outlook in those days :)

It spilled over into the real world as well. I remember every electronic device being glossy black.

> After some years however, consensus amongst designers formed that what they've created was a pile of illegible garbage

Really? Citation needed?

I guess I have never heard graphic designers say anything about David Carson except that he's one of the most innovative and influential designers in the past 30 years. IMO his graphic design was amazing and perfect for the context (music and surf magazines). I loved getting my monthly issue of Raygun and marveling at what neat designs they had done this time.

The decline of it is pretty easy to explain: the same thing that killed print altogether also killed print music magazines (i.e. the internet).

You might want to give the two first sources I've linked a visit. Both mention David Carson, and the Raygun magazine.

The sentiment I paraphrased was stated by designer Maximo Vignelli, although he didn't single out David Carson.

I've spent a lot of time thinking about getting back to what I find a healthier set of trade-offs in development and healthier product. I lile this idea that the current pushback against modern JS trends is simply backing up and setting out again in a new, hopefully better direction.

I'm invested in Elixir and there are some interesting, different trade-offs being made there for highly interactive things with Phoenix LiveView. And there is the Lumen compiler to potentially in the future not need JS as one could write Elixir to get WASM for the interactivity needed.

My bet is still mostly on server side rendering and static as much as possible. Current JS does have the JAMstack ideas that I find a healthier direction.

I began developing apps the "old-fashioned" way over a year ago. My day job is React but for my side businesses, it's all PWA and Rails. Light React/Vue (depending on my mood) when I need a fine-grained interaction or a slick animation.

What animations are you doing that you need JavaScript for these days?

To me SPAs were useful for one thing: to establish that JSON is the only blessed format for FE-BE communication.

Back before the age of SPAs we had those "dynamic" apps which updated parts of the DOM by firing requests to the backend, getting a piece of rendered HTML and just throwing it there.

It was an absolute nightmare to maintain and I'm happy we're past that.

As for server rendering, I've been getting good results with Sapper.js [0]. Here's an example of a webcomic page I started doing for a friend of mine, but it never took off:

https://dev.chordsandcordials.com

It's a pure HTML static web page, which started off as a server-side-rendered app, but with Sapper's export tool I didn't actually need to deploy the backend, since the content of each page is deterministic with respect to the URL.

My friend is not technical, but understands what FTP is and is able to edit a JSON file, so that's how we went about this.

[0] https://sapper.svelte.dev/

> Back before the age of SPAs we had those "dynamic" apps which updated parts of the DOM by firing requests to the backend, getting a piece of rendered HTML and just throwing it there.

> It was an absolute nightmare to maintain and I'm happy we're past that.

Yeah, this model was adopted by noted failure GitHub and look where it got them.

Many successful businesses are a nightmare to maintain and the fact that they are successful doesn't make them less like that - if anything it makes them more like that.

Hell, I used to work for one such business, namely CKEditor.

I doing almost the same. Spit out regular html made by templating on the server side and spice it a little with vue. Is so little that I could change vue anytime.

I actually really like this htmx library on the surface, will give it a spin soon.

Not sure why you think browser history and middle click don't work on SPAs.