This doesn't seem like a problem of "MVC vs SPA".

The same problem would occur if you were ordered to rebuild 12 apps written in Rails ( or whatever full-stack MVC framework) in a different one, like Django, for example. You'd experience the same pain.

The story of rewriting Netscape comes to mind and a few others. Point being, not much value in rewriting something that works in different language.

Unless your app is big enough to have separate developers/teams for backend and frontend. In this case I'm relatively convinced by the argument that it allows you to decouple the two, so that all they need to agree on is the API.

Do you disagree? If so, how come?

Only if you go the SPA route.

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.

Really though, this is a dead horse. SPAs are just a tradeoff like everything else in engineering. We trade the simplicity of a monolith for the ability to parcel out work efficiently between large disparate teams of frontend/backend engineers.

I strongly disagree. The fact of the matter is frontend tech debt is just SO MUCH cheaper than backend tech debt.

If all you need to do to is refactor or port over a SPA and leave the existing API alone, you've sidestepped so much pain it's unreal.

If you started out with "simple" form requests instead of an API, the backend is pretty much guaranteed to be an undisciplined mess. Wrong place to cut corners.

Hip new frameworks like"

I have my own company developing products. Some for our own, some for clients. I count my money. Why would I give a flying fuck about what is "hip"?

The only thing that matters is how much it costs me to develop solution assuming it satisfies all the constrains imposed by client's specs. The difference makes a profit and this is what I am after.

I use SPA when I need real business application and it needs to be delivered in a browser. If SPA becomes too big I make it dynamically load a pieces of needed functionality upon request. By nature is is still SPA and dynamically loaded parts tend to stay in browser's cache anyways. When I need a website I make plain website. I do not turn one into the other.

As a frontend dev this has always been my stance, but I’ve been consistently shunned for it.

How much of that was naïveté vs. misaligned incentives I’m not sure.

In any case, these thing always leave me with the feeling the industry is getting way too saturated with script kiddies. It just feels immature, and the culture that’s grown around web dev seems to reflect that. Or more likely I’m just bitter and old.

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.

MVC all the way, because otherwise you're never going to finish it. Doing a separate backend + SPA is an insane amount of work compared to a traditional full stack framework. Just thinking about validations (both server and client) make my brain hurt. Also you'll have to rewrite the frontend before even finishing it given how fast the landscape changes.

And even being a small team and not just yourself, I'd only think of an SPA if 1) You need an offline first experience, or 2) You don't have full stack engineers at hand and you only have backend people which don't want to touch JavaScript and frontend people which only want to work with JavaScript..... but this is more of a people problem than technical one.

I've done a lot of Django in the past, then a lot of SPAs for the last 6 ~ 8 years, and now I'm back to Laravel + Livewire and I'm living in a dream right now. Everything is so easy that I feel I've been cheated the last few years.... so much time and money (from my employers) wasted...

This is very similar to the NoSQL arc. Some people at prestigious places posted about some cool problems they had, and a generation of inexperienced developers started that they needed MongoDB and Cassandra to build a CRUD app with several orders of magnitude fewer users, transactions, or developers. One of the biggest things our field needs to mature on is the idea of focusing on the problem our users have rather than what would look cool when applying for a new job.

The SPA obsession has been frustrating that way for me because I work with public-focused information-heavy sites where the benefits are usually negative and there’s a cost to users on older hardware – e.g. the median American user has JavaScript performance on par with an iPhone 6S so not requiring 4MB of JS to display text and pictures has real value – but that conflicts with hiring since every contractor is thinking about what’ll sound “modern” on their CV.

I think that's funny because there some to be a ton of backenders that can't do frontend at all. And then they want to look down on FE when they can't do it themselves? It's not just basic HTML and CSS if you're building a complex app.

I do both (FE & BE) so... I've seen it all and enjoy it all. Not sure one is easier than the other.

If I were building a mostly static site, I can reach for htmx, if I am building a spa (b2b back end) I can grab react.

What happens when you're building something that does BOTH. The tooling isnt really there to support this. You end up with something that isnt good at either and 4 times harder to work with... It feels like we have gone backwards at that point.

The SPA criticics from the article and this thread have repeatedly said that their issue is not with building things that need the benefits an SPA architecture brings. The criticism is that the majority of SPAs are harmed by that architecture because it is the industry default and being used when it isn't appropriate.

Untrue. I work at a company that's swapped out the frontend and then later the backend. I had to work on both of the projects because, and I can tell you without a any doubt in my mind that they were both equally challenging (for different reasons, but that's beyond the point).

In my experience frontend-only (or frontend-focues) devs tend to underestimate backend work, and the the backend devs are equally guilty of doing the same about frontend work. Everyone thinks they've got it the harderst. ¯\_(?)_/¯

Or you could just shift your backend expectations and adapt to the different needs. If you're doing an SPA because you want an app-like experience and very decisively not a website-like experience, your backend should be as simple and stupid as possible and not force you into a model like MVC; you shift much of the complexity to the frontend when you go from website to SPA. You know, like it would if you're writing a desktop app or a mobile app that uses an API. Because it's an application, not a website.

You could pull the 99.999% number out of wherever, but the truth is that many things we used to do as websites are better off as apps. My bank's website is better off as an app, the social networks I use work better as apps. Hacker news doesn't. Blogs don't. Online newspapers don't. It all depends on the amount of interactiveness needed and how much better the experience is with access to real-time information streaming and quick UI responses based on things other than data loads.

And as dreadful as Javascript dependency hell is, it's objectively better than Python dependency hell since it's had a passable package manager for much longer than Python (and even then, most Python devs still don't use or even know of Poetry) so the ecosystem is better aligned to modern software development expectations. You're just used to one variation of hell, and don't want to learn a new one.

Try to understand modern frontend needs before assuming newer frameworks are shit at everything and that everything related to it sucks. They might be shit at the specific thing you're doing, and some lessons seem to have been forgotten when things were redesigned.

What hasn't changed however, is how most software development sucks, and the fashionable things that were done under terrible standards (devs and/or management) have changed, but are still done by the same terrible standards so you still have shit results.

> VueJS is the only framework that allows you to progressively enhance something like a Flask based website in the most natural jQuery-like way.

No. You're just allergic to build tools because you have not enough knowledge of them. Probably because, from what I've been led to believe from your comment, most of your experience seems to be with Python. All your described problems ultimately stem from there.

If there's one thing I envy backend developers it's the fact that they don't receive even half the requirement changes the front-end does.

But I would refrain from pushing as much logic to the server as possible - it's never the better experience for most users in comparison to striking a balance between having it all on the server vs the client.

This resonates with me. I'm a backend (sometimes fullstack) dev and can't fathom how FE-devs keep doing what they do, especially if UX is designed by someone else as well.

I would suggest getting yourself into a small backend/platform team. The problems/challenges tend to be more diverse/less cookie-cutter.

Argumentum ad populum. That's not an indicator of something being better. I do like using the modern SPA frameworks for well, (web)apps but I strongly disagree with using them in every case.