4 ms·

This radio selection is brilliant silly, especially because the end result is indecipherable from a vanilla css rqdio button. For some reason people keep going

This radio selection is brilliant silly, especially because the end result is indecipherable from a vanilla css rqdio button. For some reason people keep going back to complex UI and interactivity frameworks though, does anyone have a good example of a large website built without all this bloat? Asking because I've seen hundreds of small sites built with elegance and simplicity, and few large ones. Is it just inevitable that as a team size grows, someone introduces insanity? Do these tools solve an actual problem that I'm missing?

rustystump 9mo ago
Cant speak for shady lib specifically but yes as you grow you do find that default styling doesnt work or you want something which doesn’t exist. The crux tho is that this usually happens in what id call web apps and not websitess. Web apps are far more complex and powerful. It is a spectrum tho and sometimes websites grow into web apps which is why people oft over engineer early on.
yellow_lead 9mo ago
> does anyone have a good example of a large website built without all this bloat? How about this one?
- teaearlgraycold 9mo ago
  Don’t think it counts
  - rrr_oh_man 9mo ago
    Why not?
    - 946789987649 9mo ago
      I'm assuming they're asking for large in terms of complexity, not in terms of popularity.
      - deleted 9mo ago
        [deleted]
    - Levitz 9mo ago
      Because this site is only "large" in the context of userbase. It could be developed by a single guy in what, a week? Two tops?
      - Bishonen88 9mo ago
        With LLM? More like within Day(s).
hu3 9mo ago
https://www.mcmaster.com https://www.mcmaster.com 2022 post about it. 1400 points. ~500 comments: https://news.ycombinator.com/item?id=32976978 https://news.ycombinator.com/item?id=32976978
- benrutter 9mo ago
  Not the prettiest but absolutely amazing to use! I'm sure web devs are laughing at me right now, but I genuinely didn't realise websites with that many images etc could actually be that fast.
- diordiderot 9mo ago
  I would recommend comparing to https://next-faster.vercel.app/ https://next-faster.vercel.app/ NextFaster feels faster than McMaster IMHO
  - deleted 9mo ago
    [deleted]
  - jwxz 9mo ago
    ~$500 for hosting that site feels insane to me [0]. I feel like a single $10 VPS could handle that load. [0] https://github.com/ethanniser/NextFaster?tab=readme-ov-file#costs https://github.com/ethanniser/NextFaster?tab=readme-ov-file#...
    - another_twist 9mo ago
      The extra 490 saved isnt worth the optimization. headache
  - hu3 9mo ago
    Can't agree. That website is much simpler. Just a static list of images and text. There's no complex, dynamic filter. And no special rendering per type of item. It's a glorified tumbler since the only dynamic part looks like the shopping cart. Everything else is pre-rendered from what I saw in code. For static content like that I would have used Astro which is the golden standard.
SwiftyBug 9mo ago
photopea.com is entirely written in JavaScript and as far as I know, it doesn't use any fancy JS framework.
stevepotter 9mo ago
We went out of business, but I made a web app for videographers to collaborate during production. Same things as frame.io. This was over 15 years ago. Frontend was pretty vanilla except relied heavily on jQuery. The main section of the app allowed you to commend on specific frames in a video. The code is split up amongst multiple files. Here is one: https://github.com/StevePotter/Takeoff/blob/main/Takeoff.WebApp/scripts/app-productions-details-videodetails.js https://github.com/StevePotter/Takeoff/blob/main/Takeoff.Web... Look at any of the sibling `app-productions-details*.js` files. Combined they formed a single interface. It was dicey. But damn the interface was snappy. I mean, instant. Code would have been much less these days but probably nowhere near as responsive.
mb2100 9mo ago
As company size grows, managers want to settle on a "standardized" tech stack that doesn't get in the way when they want to hire and fire people at will. Nobody was ever fired for choosing React (or IBM). But everyone can get fired when they're working on a React app.
- rrr_oh_man 9mo ago
  > Nobody was ever fired for choosing React. But everyone can get fired when they're working on a React app. Beautifully put.
cloverich 9mo ago
Its because everyone can see UI, and many have strong opinions on it. Its always the first tragedy of the commons. In a typical tech company built on compromise, fighting the complexity is a fools errand.
port11 9mo ago
One major reason for this, in my past experience, is that designers push for heavily customised components. If you go back to them with “why not use the default radio button with a bit of styling?”, I’ve yet to work with a designer that would relent, the specs are always for crazy UI work.

rustystump 9mo ago

Cant speak for shady lib specifically but yes as you grow you do find that default styling doesnt work or you want something which doesn’t exist. The crux tho is that this usually happens in what id call web apps and not websitess. Web apps are far more complex and powerful. It is a spectrum tho and sometimes websites grow into web apps which is why people oft over engineer early on.

yellow_lead 9mo ago

> does anyone have a good example of a large website built without all this bloat? How about this one?

teaearlgraycold 9mo ago
Don’t think it counts
- rrr_oh_man 9mo ago
  Why not?
  - 946789987649 9mo ago
    I'm assuming they're asking for large in terms of complexity, not in terms of popularity.
    - deleted 9mo ago
      [deleted]
  - Levitz 9mo ago
    Because this site is only "large" in the context of userbase. It could be developed by a single guy in what, a week? Two tops?
    - Bishonen88 9mo ago
      With LLM? More like within Day(s).

hu3 9mo ago

https://www.mcmaster.com https://www.mcmaster.com 2022 post about it. 1400 points. ~500 comments: https://news.ycombinator.com/item?id=32976978 https://news.ycombinator.com/item?id=32976978

benrutter 9mo ago
Not the prettiest but absolutely amazing to use! I'm sure web devs are laughing at me right now, but I genuinely didn't realise websites with that many images etc could actually be that fast.
diordiderot 9mo ago
I would recommend comparing to https://next-faster.vercel.app/ https://next-faster.vercel.app/ NextFaster feels faster than McMaster IMHO
- deleted 9mo ago
  [deleted]
- jwxz 9mo ago
  ~$500 for hosting that site feels insane to me [0]. I feel like a single $10 VPS could handle that load. [0] https://github.com/ethanniser/NextFaster?tab=readme-ov-file#costs https://github.com/ethanniser/NextFaster?tab=readme-ov-file#...
  - another_twist 9mo ago
    The extra 490 saved isnt worth the optimization. headache
- hu3 9mo ago
  Can't agree. That website is much simpler. Just a static list of images and text. There's no complex, dynamic filter. And no special rendering per type of item. It's a glorified tumbler since the only dynamic part looks like the shopping cart. Everything else is pre-rendered from what I saw in code. For static content like that I would have used Astro which is the golden standard.

SwiftyBug 9mo ago

photopea.com is entirely written in JavaScript and as far as I know, it doesn't use any fancy JS framework.

stevepotter 9mo ago

We went out of business, but I made a web app for videographers to collaborate during production. Same things as frame.io. This was over 15 years ago. Frontend was pretty vanilla except relied heavily on jQuery. The main section of the app allowed you to commend on specific frames in a video. The code is split up amongst multiple files. Here is one: https://github.com/StevePotter/Takeoff/blob/main/Takeoff.WebApp/scripts/app-productions-details-videodetails.js https://github.com/StevePotter/Takeoff/blob/main/Takeoff.Web... Look at any of the sibling `app-productions-details*.js` files. Combined they formed a single interface. It was dicey. But damn the interface was snappy. I mean, instant. Code would have been much less these days but probably nowhere near as responsive.

mb2100 9mo ago

As company size grows, managers want to settle on a "standardized" tech stack that doesn't get in the way when they want to hire and fire people at will. Nobody was ever fired for choosing React (or IBM). But everyone can get fired when they're working on a React app.

rrr_oh_man 9mo ago
> Nobody was ever fired for choosing React. But everyone can get fired when they're working on a React app. Beautifully put.

cloverich 9mo ago

Its because everyone can see UI, and many have strong opinions on it. Its always the first tragedy of the commons. In a typical tech company built on compromise, fighting the complexity is a fools errand.

port11 9mo ago

One major reason for this, in my past experience, is that designers push for heavily customised components. If you go back to them with “why not use the default radio button with a bit of styling?”, I’ve yet to work with a designer that would relent, the specs are always for crazy UI work.