this post was submitted on 27 Jun 2023
122 points (96.2% liked)
Programming
17025 readers
220 users here now
Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!
Cross posting is strongly encouraged in the instance. If you feel your post or another person's post makes sense in another community cross post into it.
Hope you enjoy the instance!
Rules
Rules
- Follow the programming.dev instance rules
- Keep content related to programming in some way
- If you're posting long videos try to add in some form of tldr for those who don't want to watch videos
Wormhole
Follow the wormhole through a path of communities !webdev@programming.dev
founded 1 year ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
Prioritizing developer experience is not the reason we use front-end frameworks. People expect the web to work like a desktop app (no page reloads). The initial request might take a little bit longer, but in the end a well written front-end app will feel faster.
The problem is that people don't worry about bundle size and cram every library off of npm into their website.
The solution is quite simple though: dogfood.
Developers must test their website on a dialup connection, and on a computer with only 2GB of RAM. Use remote machines for compilation-like tasks.
Totally, pretty much all browsers include a way to simulate network conditions. Chrome also includes a way to simulate CPU slowdown.
and yet the very fact that you have to go out of your way to enable them means people don't use them like they should.
Server rendered sucks ass. Why would I want to pay for an always running server just to render a webpage when the client's device is more than capable of doing so?
Centralization is just pushed because it's easier for companies to make money off servers.
You don't have to render everything on the server, a good hybrid is usually the way to go. Think SEO and initial response. I think lemmy-ui could will also benefit from it (google results)
Yeah, it will give you the best of both worlds, but at a fundamental level I still hate that I have to pay for an always running server just for SEO, if I can get away with it I'd much prefer a purely static site that has to have its content pages rebuilt when they change.
Because it's better to deliver a page in a single request, than to deliver it in multiple. If you render the page on the client you end up making a lot of requests, each one requiring a round trip and adding more and more delay.
Do users expect it, or do product owners expect it? Because from my experience, typical users dgaf if a site is a SPA or is SSR as long as it's functional and loads quickly. When we did user surveys, the legacy Wordpress version scored just as well as the fancy schmancy React re-write. Only time SPA outscored a traditional web page is (obviously) heavily interactive components (e.g. chat, scheduling calendar)
My personal bane are SPA with fixed scrolling. I'm on a fucking desktop, stop treating me like a fucking monkey incapable of scrolling exactly to where I want and fading text in only while in focus
@variouslegumes @starman
You can get the benefits of fast page transitions no page reloads with turbo combined with a traditional server rendered stack.
https://turbo.hotwired.dev/