alt Hacker News> What happens if a very simple page needs tiny bits of data from numerous objects? It's slow as all hell, and now your page takes 10 seconds to load on mobile. If you just rendered it server-side, all the data is in reach and you just... use what you need.
You went on a long tirade against REST, which nobody mentioned. Just ... write an endpoint returning the data you need, as JSON? But write it once, instead of once per view variant?
> Just throw that in HTML, boom, 100 lines of code.
Now you need the exact same data but displayed differently. Boom, another 100 lines of code? Multiply by the number of times you need that same data? Boom indeed, it just blew up.
> Now you need the exact same data but displayed differently. Boom, another 100 lines of code? Multiply by the number of times you need that same data? Boom indeed, it just blew up.
It isn't 2004 anymore - all of the server-side frameworks have components.
Except, now instead of using serialization and JSON, it's a real API. In code. I can click and go to definition.
> Just ... write an endpoint returning the data you need, as JSON? But write it once, instead of once per view variant?
What you just said directly contradicts itself.
If each view variant needs slightly different data, or ordering, or whatever, we now need to make N APIs. Or we don't. And now we're back at square one and everything I said is valid.
The more modular and reusable your API is, the less performant it will be and the more bugs it will introduce. I'm all for the God API that has 1 million endpoints each doing one specific thing. But it seems nobody else is, so instead we get the fucked ass RESTful APIs that are so bad and lead to such overly complex code were pushed to write critical CVEs to avoid them (looking at you, NEXT)