5 ms·

I recently watched the "Helvetica" documentary that was posted here a few days ago [0], where they briefly mention "Grunge Typography" [1], a seemingly dead-end

I recently watched the "Helvetica" documentary that was posted here a few days ago [0], where they briefly mention "Grunge Typography" [1], a seemingly dead-end branch of typography that, for some strange reason, became pretty popular for a short period of time. After some years however, consensus amongst designers formed that what they've created was a pile of illegible garbage, and realized that there was no other way than completely dismiss that branch, go back to the roots, and evolve from a few steps back. I feel the same kind of consensus is slowly forming around ideas like SPAs, client-side rendering and things like CSS-in-JS. We saw the same happen with NoSQL and many other ideas before that. 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 personally highly recommend it and see myself using this approach in many upcoming projects. [0] https://www.hustwit.com/helvetica/ https://www.hustwit.com/helvetica/ [1] https://www.theawl.com/2012/08/the-rise-and-fall-of-grunge-typography/ https://www.theawl.com/2012/08/the-rise-and-fall-of-grunge-t... [2] https://htmx.org/ https://htmx.org/ (formerly "Intercooler")

dewey 6y ago
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.
- themodelplumber 6y ago
  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...
- binarytox1n 6y ago
  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.
  - sidpatil 6y ago
    Gloss was a trend in the mid 2000s, if I remember correctly—around the same time that AJAX started becoming really popular
    - brandonhorst 6y ago
      Web 2.0. Such a bright outlook in those days :)
    - encom 6y ago
      It spilled over into the real world as well. I remember every electronic device being glossy black.
clivestaples 6y ago
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.
- eatonphil 6y ago
  What animations are you doing that you need JavaScript for these days?
hoorayimhelping 6y ago
>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.
- yoz-y 6y ago
  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.
  - TheRealPomax 6y ago
    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.
trimbo 6y ago
> 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).
- purerandomness 6y ago
  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.
lawik 6y ago
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.
mamcx 6y ago
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.
Tiltowait-- 6y ago
These are people who are high in Openness, a personality trait. They are in love with new things. It does not matter if it is good or not, as long as it is new. They lose interest quickly and move on to the next new thing.
Tade0 6y ago
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 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/ https://sapper.svelte.dev/
- empthought 6y ago
  > 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.
  - Tade0 6y ago
    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.
robertoandred 6y ago
Not sure why you think browser history and middle click don't work on SPAs.
Apofis 6y ago
I actually really like this htmx library on the surface, will give it a spin soon.

dewey 6y ago

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.

themodelplumber 6y ago
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...
binarytox1n 6y ago
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.
- sidpatil 6y ago
  Gloss was a trend in the mid 2000s, if I remember correctly—around the same time that AJAX started becoming really popular
  - brandonhorst 6y ago
    Web 2.0. Such a bright outlook in those days :)
  - encom 6y ago
    It spilled over into the real world as well. I remember every electronic device being glossy black.

clivestaples 6y ago

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.

eatonphil 6y ago
What animations are you doing that you need JavaScript for these days?

hoorayimhelping 6y ago

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

yoz-y 6y ago
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.
- TheRealPomax 6y ago
  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.

trimbo 6y ago

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

purerandomness 6y ago
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.

lawik 6y ago

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.

mamcx 6y ago

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.

Tiltowait-- 6y ago

These are people who are high in Openness, a personality trait. They are in love with new things. It does not matter if it is good or not, as long as it is new. They lose interest quickly and move on to the next new thing.

Tade0 6y ago

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 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/ https://sapper.svelte.dev/

empthought 6y ago
> 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.
- Tade0 6y ago
  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.

robertoandred 6y ago

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

Apofis 6y ago

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