4 ms·
Yes you actually do. At the very least you should build your web app with technology that makes it fairly trivial to move over to an SPA. MVC is a mistake. Rea
by kadendogthing 8y ago
Yes you actually do. At the very least you should build your web app with technology that makes it fairly trivial to move over to an SPA.
MVC is a mistake. Read that again. MVC is a mistake. It's not a good paradigm to write web applications in.
SPA's are not complicated. They do not take longer to build. They defacto are often way more responsive than any server side monolith that gets built. Because developers who buy into an archaic and broken "MVC" systems typically do so because its "easier" for them, but it's easier because they're not willing to think about whats being written in the first place, and that's a recipe for a bad app no matter how you write it.
Inevitably you will end up hacking your "simple" MVC app to meet perfectly reasonable, ubiquitous client requirements regarding user experience. Because the paradigm isn't fit for base level requirements.
A few years ago my entire job was completely based around consulting for these types web applications. Inevitably you get these developers that think they're wise by going "we're just going to do it with MVC" -- and after a few months of use it becomes completely obvious that the dev team can't meet any kind of modern requirements for the web application. The existing web app is slow (but it's "fast" to the developers), buggy, and the worst part for the business is it takes forever to write features for. Eventually these companies get so frustrated they look to the outside.
To recap, when you build a "traditional" MVC app this typically means a few different things:
1) It's written in a toolchain that's fairly niche to "back end" developers; severely limiting the pool of talent that company can hire to maintain the web application moving forward. In a fair number of cases the company will have a front end team and a back end team. And sometimes all that back end team does is update views so the JS developer can do their thing. So expensive for something so small.
2) You will end up writing a mass of JS anyways, but the JS will mostly revolve around dealing with the fact that the server side templating language controls the original output of the web application. At worst, this means that a lot of devs like to sprinkle bits of HTML inside the JS. So now your templating is strewn across multiple languages and locations. The JS is typically bad because these are "real" developers who don't like JS.
3) Because of 2, there will also be a mess of server side code purely written to massage data into the server side templating language and an analogous set of code just for the JS side of things.
4) Because of 2 and 3, the app because buggy and oddly slow (though again, the devs that wrote it will only look at the original output timing and not the actual life time performance of the application).
5) Because of all of the above, the company has now spent an enormous amount of resources for a fairly shitty app that no one likes to use nor maintain.
My primary focus for these companies was to build a baseline SPA. And then over the next couple of months guide them through creating new features.
And this wasn't a one off thing. I had an entire job based around fixing the sins of the company's internal developers who are costing the company money while not delivering, costing the company money making the application way more complicated than it needed to be, and costing the company money by forcing the company to hire a specific subset of developers familiar with their MVC toolchain.
Stop circle jerking about MVC apps. They were ugly in the first place and continuing to claim that's how we should build web apps is an erroneous position purely fueled by stubbornness on the part of developers.
Here's my benchmark for an SPA: You can either build your entire site using static generation, or you need to structure your web app as an SPA (or prepare to do so in the original implementation). That is the threshold in the current landscape. If you can't get away with doing a statically generated site then you're not going to have fun writing your site with backend MVC framework. At the very least the company's finances definitely won't.
- a_wild_dandan 8y agoI really wish I could upvote this twice. Tacking on features to a traditional MVC app causes orders of magnitude more technical debt and buggy, tightly-coupled, unmaintainable or extensible spaghetti code. React et al. didn't pass through a membrane from another reality for the sole purpose of annoying devs with more stuff to learn -- they're elegant, powerful solutions to the rapid growing pains and requirements of our modern web. The SPA pattern of completely separating front-end & back-end concerns is seemingly taking over the world for very good reason.
- kadendogthing 8y agoYep. Developers take their choice and then externalize all the costs to the company; even though the company has put an immense amount of trust and financial power in them. It's actually absurdly disgusting once you run the numbers. I've directly compared projects before and after over a 1-2 year period and the devs claiming that these "MVC" apps are better for users, the company, or anyone else besides themselves are actually arrogantly delusional. They write these apps, and either leave or then sit there in the company and blame everyone else but themselves. But hey, at least the problem exists. It allowed me to make a ridiculous amount of money and invest it wisely. shrug