Comment by benrutter
20 days ago
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?
https://news.ycombinator.com/item?id=32976978
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.
I would recommend comparing to
https://next-faster.vercel.app/
NextFaster feels faster than McMaster IMHO
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.
~$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#...
1 reply →
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.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.
> does anyone have a good example of a large website built without all this bloat?
How about this one?
Don’t think it counts
Why not?
4 replies →
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.
> Nobody was ever fired for choosing React. But everyone can get fired when they're working on a React app.
Beautifully put.
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.
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.
photopea.com is entirely written in JavaScript and as far as I know, it doesn't use any fancy JS framework.
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.