3 ms·
Knowing that the target audience for this is developers (for the most part), the decision to make it a javascript application in the first place instead of rend
by luord 6y ago
Knowing that the target audience for this is developers (for the most part), the decision to make it a javascript application in the first place instead of rendering from the server seems like overkill, at least IMO.
Maybe it's just me, but I don't really care about fewer page reloads or having multiple animations and interactivity. I understand why those can have an impact on end users and so I do think that SPAs have their place, but I'd much rather the interface was rendered from the server and worked through links if it means it'll work faster. In fact, half the time I'm not even using the web interface; I'm using the SDKs.
- arcturus17 6y agoSSR wouldn't mean it'd be faster because it could have still been coded like spaghetti. You sound reasonable and I'm not directing this to you in particular, but there is a clear bias on HN that SPA sites are inherently slower or less performant, which is not true at all. Either can be fast or slow. The debate around SPA and SSR is so heated and centered on the front-end bit that people forget that UX performance depends a lot on the server. Websites are client-server systems regardless of the front-end architecture. I'd wager that the case of GCP is no different and that the perceived slow UIs are caused by problems all across the stack.