49 ms·
I've always felt that it was a bit of an odd decision to put all of one's eggs in a basket that you don't own or meaningfully control (the client). The client's
by kitsunesoba 5y ago
I've always felt that it was a bit of an odd decision to put all of one's eggs in a basket that you don't own or meaningfully control (the client). The client's basket will need to hold some of your eggs sometimes, that's unavoidable in some cases, but it makes perfect sense to put as many of your eggs in the basket you do control (your back end).
- spion 5y agoI always felt the opposite was odd. Server side rendering felt like an odd hack due to the limitations of the platform. Imagine all you had was a PDF reader - then it would make sense to construct an application by building PDF files which contain links to other PDF files. But otherwise, why not write an actual client program that maintains its own UI state and have the server take care of what it does best - provide the data? Would you build a CLI (ncurses style or otherwise) application by fetching the TTY codes to render the current screen from a server for most user interactions?
- kitsunesoba 5y agoThat makes sense when the client is always a known quantity, but such is not the case with the web. While you can get an idea of what the majority of your target audience is running, there's always going to be some percentage that will be left out when writing client code for the majority browser only. There's always going to be client situations that you can't predict much less write for, and in those cases more server-heavy solutions tend to do better.
- lolinder 5y agoIs a traditional desktop client really a better-known quantity than a web browser these days?
- jmbwell 5y agoThe more your app can run client-side, the lower your bills server-side.
- ConsoleTVs 5y agoAnd yet all client-side frameworks like next.js, remix and others are literally moving to server again, making you even more tied to serverless stuff.