51–60 of 225 posts
This comment thread is a little funny because every single HN thread outside of this one rants super aggressively about webpages that don't show any content before JS loads, but this thread has managed to collect the opposite group together for once because React's docs have updated to stop actively recommending tools that force that problem to happen.
I don't understand the pivot back to SSR. Tearing down and standing up the entire DOM and page memory between navigations is just unnecessary work. Little things like maintaining scroll position in the page's navigation bar meaningfully improve usability and are only achievable with a SPA-based approach. This doesn't discount the challenges of building SPAs: bundle sizes, performance, etc. can be concerns if not mana…
the biggest problem with SPAs is none of the devs making them seem to remember how nice it was to open different pages of a site in different tabs. it's all horribly phone/tablet centric. middle-clicking doesn't even pop links in new tabs because they break basic browser features. you're lucky if you can even tell what's a real link and what's just going to rearrange your current page.
There are a myriad of reasons why I prefer SPA to server rendered content for most applications. The main exception is if I have a public facing, unauthenticated application that I need indexed, I'll go for SSR. Off the top of my head, here are benefits to SPA: - I can just serve a few static files from a CDN. Every user gets the same client. - Most requests made by the application are actually smaller. I'm just load…
Earlier quoted context omitted.
SPAs, microservices, nosql (Redis), and serverless are all still alive and well, they just aren’t a hammer for all problems like (some) people treated them originally. Nerds getting overexcited about new tech is an old story and it will continue to happen indefinitely as much as we like to smug post about it. IDK about GraphQL since I’ve not used it but I’ve read lots of stuff recently about frameworks/ORMs working t…
That's exactly my point.
Plus not all of it is merely overexcitement/immaturity either, small companies and small dev teams often try to keep their toolsets small and eventually end up pigeonholing stuff into tech that doesn’t fit, until they get time/resources to do it properly. Some things are more obvious in retrospect.
The vast majority of the software world is still pretty conservative when you look beyond HN and Twitter.
Hype driven developers/marketers believe the only type of websites that exists are those which need indexable content for SEO purposes. More news at 11
Earlier quoted context omitted.
A lot of people still mix jQuery and React in the same parent project. Mostly just via legacy support when using existing serverside frameworks but still sometimes having the fallback easy DOM/event stuff is just easier when you need to get it done (keeping the HTML/views isolated from each other of course so you don’t mix concepts). It doesn’t sound pretty but they can serve dual purposes. I don’t know enough about…
I am sure you can do something with it… But htmx is all about replacing server rendered html with server rendered html partials. I would like to see what reacts vdom does when you keep ploping some partials into DOM it thinks it controls.
There are a myriad of reasons why I prefer SPA to server rendered content for most applications. The main exception is if I have a public facing, unauthenticated application that I need indexed, I'll go for SSR. Off the top of my head, here are benefits to SPA: - I can just serve a few static files from a CDN. Every user gets the same client. - Most requests made by the application are actually smaller. I'm just load…
I don't understand the pivot back to SSR. Tearing down and standing up the entire DOM and page memory between navigations is just unnecessary work. Little things like maintaining scroll position in the page's navigation bar meaningfully improve usability and are only achievable with a SPA-based approach. This doesn't discount the challenges of building SPAs: bundle sizes, performance, etc. can be concerns if not mana…
the biggest problem with SPAs is none of the devs making them seem to remember how nice it was to open different pages of a site in different tabs. it's all horribly phone/tablet centric. middle-clicking doesn't even pop links in new tabs because they break basic browser features. you're lucky if you can even tell what's a real link and what's just going to rearrange your current page.
I’m surprised the criticism is still ubiquitous: it’s either 5+ years out of date or some people run into these terrible sites a lot for some reason.
I don't understand the pivot back to SSR. Tearing down and standing up the entire DOM and page memory between navigations is just unnecessary work. Little things like maintaining scroll position in the page's navigation bar meaningfully improve usability and are only achievable with a SPA-based approach. This doesn't discount the challenges of building SPAs: bundle sizes, performance, etc. can be concerns if not mana…
You might be talking about what the JavaScript community has started to call “MPA,” which doesn’t seem to have converged on a clear meaning but seems to usually imply that some or all page navigations do involve a trip to the web server and an HTML response.