361–370 of 395 posts
Earlier quoted context omitted.
Lower cost, better use of hardware, better scalability, easier debugging, more robustness to failure, etc etc
It's unclear that any of those are true if you need to maintain a distributed build system.
You don't maintain jekyll today...
Do I live in a parallel universe where building SSR/SPA sites with Next.js is somehow incredibly complex? I know below the abstractions there is complexity, but building SSR rendered SPA's today with something like Next.js has never been more simple. I think web development has taken a huge leap forward where we now have stable tooling, a strongly typed language with TypeScript and top notch boilerplate free state ma…
Next.js is easy peasy and lovely and wonderful until you need to mix in validations + translations + authentication + authorisation + calling upstream APIs with user's credentials + ... That's when you realise using what would be a perfect framework for building landing pages might not be the best one to build a full web application.
Earlier quoted context omitted.
Is it believed that you'll do less overall compute and bandwidth if you use serverless functions to execute (parts of your) client, in place of sending static bundles to the client and letting them execute it? I don't really get SSR. Isn't it more desirable to have more of the compute required to render the client done by the client machinery? I view this both as true in corporate and public web scenarios, surely it'…
Doing something fully on the client is a nice idea, if your users all have fast connections, high processing power, and are all visiting from a desktop instead of a mobile device. As soon as you have anyone visiting on a mobile device, and particularly on a mobile network, it's far superior to render it on the server.
HN is not full of front-ends, I can tell that much.
Earlier quoted context omitted.
The idea of using a "framework" in a language that gets completely reloaded on every new request doesn't make sense - at least I thought a framework was something that wrapped your own code and presented an event loop, etc. You'd want a "library" if you just wanted to improve on the original low quality PHP database connectors and such. But PHP developers always did seem to have inappropriate jealousy over unrelated…
I'm not sure why you've been downvoted. Anyone who has ever seen a Laravel stack trace will surely have been appalled at the number of stack frames that sit below their own code, and all that machinery is loaded on every single request. It's truly shocking. PHP isn't Java and shouldn't be treated as such.
Earlier quoted context omitted.
It’s not so unusual. My employer has a product line of ~40k products, in ~45 markets, with ~2 languages per market, which gets you to 3.6m product pages immediately, and that’s leaving aside any other pages.
That's fair, but I bet you're not using a static site generator to produce your PDPs. (Or, if so, I'd love to read an engineering blog post about it! Static PDPs would be a solid optimization in a lot of ways, and while I'm no longer in a role where that could be directly useful, it'd still be interesting to find out what challenges a team overcame and how in the course of getting there.)
This setup is not particularly unusual for a microfrontends environment I don’t believe.
Earlier quoted context omitted.
I'm not sure why you've been downvoted. Anyone who has ever seen a Laravel stack trace will surely have been appalled at the number of stack frames that sit below their own code, and all that machinery is loaded on every single request. It's truly shocking. PHP isn't Java and shouldn't be treated as such.
I know what you're saying... but using Java as the counterexample? I'm still reading the stacktrace from a Java error I raised in 2003.
I'd hope new stuff is also CGI-based and restart on every request, otherwise you're asking for security issues (like leaking another user's info Heartbleed-style).
Earlier quoted context omitted.
That's fair, but I bet you're not using a static site generator to produce your PDPs. (Or, if so, I'd love to read an engineering blog post about it! Static PDPs would be a solid optimization in a lot of ways, and while I'm no longer in a role where that could be directly useful, it'd still be interesting to find out what challenges a team overcame and how in the course of getting there.)
Most content on our PDPs are statically pre-rendered, yes. Some stuff we obviously can’t of course (e.g. some of the recommendations that are based on your personal behaviour), and those tend to be mini-SPAs. We save from having to re-render everything if, say, a menu item changes, by compositing page fragments at a CDN level and caching the result for a shorter amount of time. This setup is not particularly unusual…
It's probably about as far as the concept can reasonably be taken; in theory I could see something more like "true" SSR with some probably complex hydration, but the engineering time would likely make it uneconomic to pursue what would likely be marginal benefit.
I'm convinced SSR is only a thing because of Lighthouse scores. Client-side rendering with client-agnostic REST APIs is a fantastic architecture. But noooooooooo we can't have nice things
SSR would make HN better under load when logged in, for example. When logged in you would get the cached versions like a logged out person, and then wait for user-specific content (and if it never renders, you can always just read).