3 ms·
If you can do server side great: do it. The difficulty is accurately predicting how much JavaScript you'll end up writing. If your client-side JavaScript is com
by ng12 6y ago
If you can do server side great: do it. The difficulty is accurately predicting how much JavaScript you'll end up writing. If your client-side JavaScript is comparable in complexity to your SSR you'll eventually end up with the worst of both worlds.
- mattmanser 6y agoIs it really that difficult? If a client tells me what they want built, I bet I'd be able to roughly guess how much js there's going to be, probably within a few hundred lines for a, say, 3 month project. The larger the project, the large the margin of error, but still, it's really not that hard for the vast majority of work we do. Or at least I do, e-commerce, enterprise apps, etc.
- sgarman 6y agoThat sounds logical if you are doing client work with a defined scope. From personal experience working in the startup world, which I imagine a lot of posters on here are, you don't always know what you are building or what the end game is.
- blakehaswell 6y agoI'm not sure that's such a huge problem. HTTP routing provides a wonderful architectural seam so that we can use different solutions for different domains like `/profile` and `/document-editor`. We can create rich client-side experiences without creating a monolithic SPA. And as long as we make sure we have those architectural seams we have the flexibility to decide.
- ng12 6y agoOrganizing my HTML into pages is the easy part. The hard part is the rich client-side experience: things like building a sortable/filterable table with a rich datetime picker where the data is displayed dynamically in a chart with zoom/pan capabilities. That's why I build SPAs: I've already bit the bullet to get highly dynamic client-side code, it's just as easy to construct my pages client-side as well.