Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

>while it's probably not reasonable to optimize for them

it's not an optimization, it's a best practice on the web. server side render and use javascript for progressive enhancement.



The web has moved on from progressive enhancement. Current practise is client-side HTML rendering.


No, no it hasn't. Just because there are a bunch of terrible front end developers trying to push that notion doesn't make it true. Any half way competant front end developer will be able to create sophisticated websites that are usable for the vast majority of their users and they'll be using something like progressive enhancement to do it.


Client rendering doesn't have to be so bad... I actually did do it as an optimization back in the dialup days. React is pretty nice, and if you really want to reduce payload, you can build against inferno or preact for similar results at a smaller payload, but since React packaged JS is usually less than a single moderately sized image, it's really less of an issue.

Although that doesn't mean to go ahead and throw in lodash + underscore + ramda + jquery + jquery extensions all on top of react/redux. Just because you're using a modern framework, doesn't mean it needs to be huge. You can build a basic app with preact and min+gz hitting a total size around 20-30kb.

Yes, that's more than server-rendered simple AMP-style html... on the flip side, you don't have to round trip for every screen either. It's also a LOT smaller than some of the behemoths out there, and even then, a lot of the time Images are the biggest hit in bandwidth.


That’s really not true for the majority of sites, in particular nearly every document site. There’s no one blanket fits-all best practise, but in general using a SPA is hurting a significant majority of users.


Unfortunately.


I find it really fortunate. SPAs can use much much less data for the same content, which is a big plus when you're on a data-limited connection, as most users in the developing world are. If you spend much time on a site they also demand less CPU and thus less battery life (vdom updates are less intense than new page renders), which helps when you're on a mobile connection, and they feel much more responsive when you're on a high-latency connection, which you are again if you're in the developing world or on mobile. Server-side rendering feels like getting a faster and lighter initial load in exchange for heavier, slower, more battery-draining usage overall.


> Server-side rendering feels like getting a faster and lighter initial load in exchange for heavier, slower, more battery-draining usage overall.

If and only if you do the SPA right. Compare Twitter (slow to load, slow to interact with, battery-draining, issues with maintaining scroll position, and all of these get worse the farther you scroll down) to the SPA version of https://mobile.twitter.com/ (fast to load and interact with) to the static version of Mobile Twitter (even faster, no infinite scroll, works on Dillo).


That's fine for SPAs, what sucks is how many other sites are built that way. :/




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: