> I do, however, think they generally scale (developer-scale, not performance-scale) better than any multi-page system I've ever worked on.
I've never understood this opinion. To me it seems like you're forcing such complexity that you _need_ focused developers. That by definition scales far worse than having all cross functional team of developers that can work on the view layer and the data layer (by virtue of the view layer being easy enough all developers can understand it).
It's touted quite frequently ime that it's better to have front-end engineers and back-end engineers and that to me just feels flat on its face wrong.
I'm not claiming there are no benefits to SPAs, of course. I'm just saying I don't understand the opinion that claims it scales better with development cycles.
Hear hear! I don't think the assertion that SPA's are faster to build / more scalable holds up to much scrutiny.
1. SPA's still require some back end to render the initial page / payload.
2. SPA's cannot be trusted, so you need to duplicate things like validations.
2a. "But you can just do an ajax call to validate records on the back end, and get a json response!" — how's that any more performant than just doing a traditional page load? With pjax or turbolinks, the performance difference between these options is even closer.
I remember a decade ago, when there was a management demand to get rid of the "page load", and our quick and (very) dirty solution was to simply load the next page with ajax as HTML and simply replace most of the body with the body of the loaded page. It was hardly any faster (we measured), but everyone insisted it was suddenly blazing fast. The psychological effect of avoiding the visual artefacts of a page load was large enough that it was mostly sufficient.
We eventually did some minor optimisations - returning smaller parts of the page, and replacing more precise sub-parts of the DOM. We had some other small pieces of JS on the pages too, but for the most part just having the server render everything replacing large chunks was good enough.
I'm both of these developers, and I don't think either part is complex or all that difficult. I have no problem bouncing from backend to frontend in the course of implementing a feature and I don't find my mental stack getting smashed in the process. If your developers aren't cross-functional in exactly the way you describe, I think you probably hired insufficiently skilled developers. ;)
To me, it's more that every HTML templating solution I've ever seen kinda sucks for composition beyond a very basic "insert blob here", whereas TSX--don't write plain JavaScript, kids--does a lot to address that. It's more that commingled views/controllers and the actual logic of the application causes separation-of-concerns issues (and yes, you can write better code, but people don't). And it's more that for any nontrivially successful thing I'm probably going to either need to provide an API or a mobile client--which are the same thing--and so I might as well get it out of the way to start.
In a way, it's the microservices argument. You don't make microservices because of performance, you make them because it forces less skilled developers to do (more of) the right thing and allows those less skilled developers to parallelize better. So it is with tooling like React in an SPA and an API-driven backend. But, and unlike microservice-all-the-things, I find myself able to crank out more involved features, faster, using React and talking to a backend API in something like Swagger than dealing with postbacks and string-manipulating my way to HTML output. So I think there are wins on both ends.
I don't think there's a production application out there not using an entire toolchain for their client side code. I'm not saying it's _too_ hard for people to be cross functional. I'm saying it's hard enough that companies often times make an artificial separation.
I don't agree with the microservice comparison because the separation of view/data layers could more easily exist with a back-end rendered application. It only exists more readily with front-end rendering because the complexity is so much higher that you find specialists in that field who can only work with that stack. The separation is purely artificial and driven by increased complexity.
I've never understood this opinion. To me it seems like you're forcing such complexity that you _need_ focused developers. That by definition scales far worse than having all cross functional team of developers that can work on the view layer and the data layer (by virtue of the view layer being easy enough all developers can understand it).
It's touted quite frequently ime that it's better to have front-end engineers and back-end engineers and that to me just feels flat on its face wrong.
I'm not claiming there are no benefits to SPAs, of course. I'm just saying I don't understand the opinion that claims it scales better with development cycles.
reply