Earlier quoted context omitted.
> A bug in one "page" of the app can cause the whole application server to go down. That doesn't seem like a valid issue. If a bug in a single page could take the application down then the same could be said for the API powering the front-end. > If you leverage client-side rendering then it's easier to decouple your front-end from the back meaning you can take advantages of things like segregated micro/serverless ser…
> That doesn't seem like a valid issue. If a bug in a single page could take the application down then the same could be said for the API powering the front-end. What? The previous poster said coupling frontend / server tightly will result in crash of both if there is a server bug. Your response is that a bug in an unattached API could happen? Of course a bug in your API could crash your API. But at least then it's j…
You probably don't need a single-page app
291–300 of 522 posts
Re: You probably don't need a single-page app
#292I'm more interested in the future of "you probably don't need a native app" . It feels like browsers are closing the gap pretty well with things like IndexedDB, offline features, WASM, etc. Still a ways off, but seems like it's getting there. I do worry, though, that it's not really in Apple's or Google's best interest to move that along.
Native will always be the best solution... Because it's native.
Re: You probably don't need a single-page app
#293MVC 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.
Re: You probably don't need a single-page app
#294Earlier quoted context omitted.
> i.e. all the user navigation is done within the app UI, not the browser UI Not sure if that's what you mean here, but when this breaks the “back”, “next”, “refresh”, “bookmark” or “share URL” features of my web browser (among others), I hate whoever has been responsible of the design as much as I've hated Flash in the past.
have you not used a client-side router in like 5 years? you just plug one in and BAM browserHistory, etc.
Re: You probably don't need a single-page app
#295Earlier quoted context omitted.
> i.e. all the user navigation is done within the app UI, not the browser UI Not sure if that's what you mean here, but when this breaks the “back”, “next”, “refresh”, “bookmark” or “share URL” features of my web browser (among others), I hate whoever has been responsible of the design as much as I've hated Flash in the past.
I'll offer the distinction is rather you're using a "web site" or a "web app". A web site should never break your browser. A web app should be able to run in "Full Screen" mode without needing to use the web browser UI.
Re: You probably don't need a single-page app
#296Earlier quoted context omitted.
Sorry, I don't have the complete context - SSR stack, app architecture, load times etc. So, I'm not in a position to comment on your SPA migration. But, I'd like to share thoughts from my current situation. We have a flagship product written in web forms (started in 2006). It's a big solution. Performance has always been a challenge with it. While I'm not proposing a complete rewrite into SPA, due to - migration requ…
> My proposal is to switch to json objects for information exchange between server and client. We'll get the benefits similar to SPA without rewriting for it If I understand your approach correctly, I often do something similar, but with modern ASP.NET Core MVC apps. Basically, I have a tiny bit of JavaScript that 'intercepts' all form POSTs and submits them using AJAX instead. Another tiny bit of JavaScript can then…
They. Could. Not. Get. Over. The. Fact. The. Pages. Reloaded. After. Each. Request. No matter how many times we said "can we focus on making sure the underlying math is right and then polish the UI?"
So I finally snapped and implemented that exact same thing. That shut them up enough that they just started disappearing when they were asked for info. I suspect the project had enterred the phase where they were out of money and/or realized they were trying to swallow a bigger task than they could handle themselves.
Recently, I saw Turbolinks [0] which looks like the same concept with way more panache.
Re: You probably don't need a single-page app
#297I used to feel that way, then I met a one javascript developer in particular who really made me see it differently. I won't get into those here, I just want to tone down the "probably don't need" into a "don't necessarily need". As a predominant back end developer, I do feel that the complaints from the article are due to inexperience or misunderstanding: 1. stateless requests: You don't have to cache any state by de…
Here is the talk: https://www.youtube.com/watch?v=PFwUbgvpdaQ
Re: You probably don't need a single-page app
#298Earlier quoted context omitted.
> My company (4,500+ people) ordered all products in their portfolio (~12 web apps) to migrate to SPA front ends about a year ago as a way to stand out from our competitors, and boy has it been painful. 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 examp…
You overlooked this part: > Not only that, but extending these UIs will take more time in the future than their SSR versions due to the added complexity of the front end frameworks
Re: You probably don't need a single-page app
#299Agree with the article. I find server views to be substantially easier to work with. But more importantly, I also find server view rendering to be a faster, better UI experience. It's really frustrating having to wait several seconds for a SPA to load, or to have unexpected behavior when clicking the browser back button, or failing completely because some random hunk of JS garbage errored out, and it's one of the big…
Re: You probably don't need a single-page app
#300Agree with the article. I find server views to be substantially easier to work with. But more importantly, I also find server view rendering to be a faster, better UI experience. It's really frustrating having to wait several seconds for a SPA to load, or to have unexpected behavior when clicking the browser back button, or failing completely because some random hunk of JS garbage errored out, and it's one of the big…
Thank you for pointing the real issue with SPAs: they deliver awful user experience. It's quite telling how this fact is missing from the article and from most of the discussion here. We're a bunch of self-referential techies who've lost connection with reality.