Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Disadvantages of Single Page Applications (2014)

adamsilver.io

Post reply on HN
Print view View original

101–105 of 105 posts

Re: The Disadvantages of Single Page Applications (2014)

#101

Post by qu4z-2 »

fizzbatter wrote: post #98
qu4z-2 wrote: post #58

Earlier quoted context omitted.

In all fairness, I thought early smartphones were pretty silly, and my opinion hasn't much changed. I also find people touting "progress" don't realise that a lot of the time they just mean "change". I mean, sure, if a new way of doing things is demonstrably better, by all means let's use it. But a lot of the time you're just swapping one (well-understood) set of tradeoffs and considerations for a new, less understoo…

Re:Progress Well, i sort of disagree. I agree that all progress isn't positive, but the problem is you can't really know that in the current timeframe. "progress" very often contains one (or more) steps back for every step forward. In the future, after the concept as matured, we will know if it is positive or not. But that is exactly how this works. Sure, we can only use well tested, well understood, and well functio…

That's a fair point. I mean, I try to avoid rushing onto "the new thing" just because (although I'm certainly guilty of it at times), but I guess I forget that the ratio of articles posted to HN isn't representative of what people are actually doing, because the well-understood methods are, well, understood, so they don't generate a flood of articles.

Re: The Disadvantages of Single Page Applications (2014)

#102

Post by spiffytech »

LoSboccacc wrote: post #85
freyr wrote: post #52

Earlier quoted context omitted.

I just wrote a post condemning the use of SPAs that emulate multi-page websites and basic browser functionality, but you provided an interesting counter-example. In fact, it goes to an extreme by being an "app" with minimal user interaction beyond basic navigation across pages. It is quite fast, which is nice. One of my concerns about SPAs that emulate MPWs is that you're sacrificing speed for complexity, which gener…

I'm building a multi page app that has a single page which is extremely complex (it's an image based marketing tool, the complex page is the visual editor) and I'm finding browser extremely finicky in their memory management. I don't know how making a real single page app could be possible for overly complex applications. More than once I managed to crash the chrome javascript engine in a way that could not be recove…

In you have code that can reliably reproduce this, you can get a nice check from Chrome's bug bounty, or maybe even find a hacker to help you into pwn2own.

Re: The Disadvantages of Single Page Applications (2014)

#103

Post by voidr »

EugeneOZ wrote: post #96
voidr wrote: post #75

Earlier quoted context omitted.

Maybe the MVC frameworks you used weren't the best, I can do everything on the backend and still have all the advantages that you described. It's not about where you execute your UI code, It's about how you structure your application. I've seen plenty more of SPA's become an unmaintainable spaghetti nightmare and also seen many non-SPA's work splendidly.

You can't do on the backend everything what SPA can. You simply can't manipulate views without page reload and if you want to do it by injecting JS into backend templates, it will be just mimicking of SPA on the server side, and it's the most ugliest thing what can exist - from the development point of view. I support parent comment and I can add: SPA split responsibilities between server side and frontend. It helps…

I recommend reading my comment again, it's not about what each approach can and cannot accomplish technically, it's about maintainability.

I can give examples of a lot of things that SPA's can't do, that's not the point.

I also don't think, you should either build everything on the backend or everything on the frontend, I consider both approaches to be equally bad.

SPA's do not help split responsibilities, I can easily give the SPA a low level Data API and start implementing data processing functionalities in the frontend.

SPA's don't help build services, good frameworks do.

SPA is a religion, cause it states 'Single Page'. What if I want to have an application with 2 or 3 pages just because it doesn't make any sense whatsoever to cram everything into 1 page? What if I can render a lot of stuff on the backend and be 100x more efficient and provide far superior UX?

I had a colleague once who wanted to do everything on the client side, he said that the SPA is the way to go. He got 6 months to prove his approach is good. He failed. His application was both slow as hell and nobody on the team could maintain it. So after he left it took me roughly 2 months to implement what he had in 1/5th of the code.

Re: The Disadvantages of Single Page Applications (2014)

#104

Post by ChicagoDave »

voidr wrote: post #103
EugeneOZ wrote: post #96

Earlier quoted context omitted.

You can't do on the backend everything what SPA can. You simply can't manipulate views without page reload and if you want to do it by injecting JS into backend templates, it will be just mimicking of SPA on the server side, and it's the most ugliest thing what can exist - from the development point of view. I support parent comment and I can add: SPA split responsibilities between server side and frontend. It helps…

I recommend reading my comment again, it's not about what each approach can and cannot accomplish technically, it's about maintainability. I can give examples of a lot of things that SPA's can't do, that's not the point. I also don't think, you should either build everything on the backend or everything on the frontend, I consider both approaches to be equally bad. SPA's do not help split responsibilities, I can easi…

I'm sorry, but my take on your comments is that you haven't actually been on any SPA projects (yet). Having been on several over the past two years, I have a clear understanding of the trade-offs, benefits, and complexities. I was very skeptical two years ago, but that skepticism has been mostly eradicated.

Sure, if you have bad programmers, no pattern will save you. But if you want speed, agility, and separation of concerns, SPA + services is currently the way to go.

Re: The Disadvantages of Single Page Applications (2014)

#105

Post by voidr »

ChicagoDave wrote: post #104
voidr wrote: post #103

Earlier quoted context omitted.

I recommend reading my comment again, it's not about what each approach can and cannot accomplish technically, it's about maintainability. I can give examples of a lot of things that SPA's can't do, that's not the point. I also don't think, you should either build everything on the backend or everything on the frontend, I consider both approaches to be equally bad. SPA's do not help split responsibilities, I can easi…

I'm sorry, but my take on your comments is that you haven't actually been on any SPA projects (yet). Having been on several over the past two years, I have a clear understanding of the trade-offs, benefits, and complexities. I was very skeptical two years ago, but that skepticism has been mostly eradicated. Sure, if you have bad programmers, no pattern will save you. But if you want speed, agility, and separation of…

I have been on SPA projects and I have made SPA's myself as well.

If you want speed, agility separations of concerns, MVC is the way to go. Most of the things you said are MVC and SRP, it has nothing to do with SPA, this is what I have been trying to explain. SPA stands for "Single Page Application", it doesn't specify anything beyond that, your code could be utter garbage with everything mangled together, and it's still technically a SPA. MVC on the other hand does specify how to organize your code.

I think the problem here is the SPA terminology itself and the way it's being used and marketed.

Post reply on HN