Nah, they weren't a mistake, at least not in isolation. Much of modern software development is a mistake, generally speaking. When you look at it that way, SPAs only failed in the sense that Object-oriented Programming failed, as well as the failure of various design patterns, microservices, write-once-run-anywhere, test-driven development, decentralization... I can go on and on with the number of engineering and computer-sciencey crap that never really lived up to its promises.
SPAs only suck as much as we suck. Just admit that SPAs are like any other tool, and if we're going to swing back to apologizing for goto-statements (something I don't necessarily disagree with) then we can't at the same time act like SPAs are a mistake in and of themselves. We collectively continue making mistakes and instead of owning up to our collective lack of craftsmanship, we are blaming the tool.
Only when we shed the mindset that informs us that computer "science" is actual science might we then be in enough touch with reality that we seriously impose some standards upon ourselves to address our clumsiness.
We suck pretty bad. SPAs are often the default because that is what the framework dictates and nobody trusts a JavaScript developer to delivery any kind of quality product without some epic massive framework, including ourselves. This is the standard for hiring, performance, and delivery and nobody dares deviate. If its not an NPM package written by an anonymous stranger or an API on the framework its not an option. We don't trust each other and management doesn't trust us, so let the framework dictate our every decision.
Doesn't every other science field work pretty much the same way though? We make mistakes, we iterate, we make new and better mistakes. It may be too obvious in software cause it's easy to create stuff and iterate very fast cause there aren't so many natural constraints. Someone may even argue that this is what makes software also an art.
TDD, or rather the effort behind TDD, failed because its proponents couldn't help but preach it as a cornucopia of solutions with the insistence that it's appropriate for every circumstance. When you are familiar with the domain of a problem, TDD makes a lot of sense. For the project I'm working on now where I'm effectively learning at just about every step of the way, and said project is intended for very few users, it's highly questionable if I could have benefited from TDD. Even when I'm not doing something unusual, TDD doesn't always make sense.
Any research that currently exists around TDD is of poor quality and proves little, but TDD fanatics (not sure how many of them exist anymore though) speak like there's objective evidence in their favor. And some call this sort of thing "science"?
By the way, when I mentioned science, I was specifically referring to the concept of "computer science", of which there has been very little actual use of the scientific method in our lifetimes. Computer science is of course a legitimate area of study; if our heads are still so in the clouds that we are still calling it a "science" then it's no surprise that we're continually losing touch with the very technologies we create.
TDD also shot itself in the foot with this (IMO toxic) insistence that the tests are the documentation, which is a nice principle to keep in mind, but I've never seen it come close to replacing actual documentation. A simple comment block describing the why of a function is always better than scrolling through tests and reconciling inconsistencies with the mocks that were used. And yeah, I know that TDDing isn't really about "mocking", but let's face it [...].
Perhaps the worst thing of all is that TDD is founded on a somewhat dishonest implicit premise, which is that if you aren't TDD'ing then one must be either not writing enough tests or are writing inferior code because one is writing tests after development. TDD fanatics, in particular those freshly inducted into the cult, often think it's either TDD or nothing, and if you're not TDD'ing one particular part of an app then you're not following "standards". Maybe TDD is fine as a form of guard rails when you're a junior developer, but by the time you're a high mid-level and in touch with reality then you're going to intuit whether a unit of work will actually benefit from TDD.
TDD isn't bad at all in terms of its mechanics. It's a great idea, and I've used it many times. In fact I even TDD'd an entire web app that handled payment processing from start to finish. The part about TDD that "failed" was this belief that it is actually a generalized solution that needs to be applied everywhere, which lead to it both being misapplied as well as dismissed when it becomes apparent that those promises of better and easier code/process/readability often don't magically manifest.
This is really the story behind just about every failed idea related to our field, not just TDD. SPAs were supposed to make pages snappier because it meant server responses to different user actions would require fewer bytes and no page refreshes. Instead of viewing SPAs as a tool with a purpose, people had to treat SPAs as the end-all-be-all of frontend development and a way to do everything, and now the world is stuck with many SPAs that are likely worse than if they were done as regular webpages.
SPAs only suck as much as we suck. Just admit that SPAs are like any other tool, and if we're going to swing back to apologizing for goto-statements (something I don't necessarily disagree with) then we can't at the same time act like SPAs are a mistake in and of themselves. We collectively continue making mistakes and instead of owning up to our collective lack of craftsmanship, we are blaming the tool.
Only when we shed the mindset that informs us that computer "science" is actual science might we then be in enough touch with reality that we seriously impose some standards upon ourselves to address our clumsiness.