[HN Gopher] State is hard: why SPAs will persist
___________________________________________________________________
State is hard: why SPAs will persist
Author : DeadNeurons
Score : 67 points
Date : 2022-05-29 17:13 UTC (5 hours ago)
(HTM) web link (nolanlawson.com)
(TXT) w3m dump (nolanlawson.com)
| henning wrote:
| > I'll go for the more performant solution, even if it's awkward
| or unintuitive.
|
| He said the quiet part loud. D'oh!
|
| If the APIs being called are slow as shit, your SPA won't be any
| faster than just refreshing the entire page. Actually, you have a
| new problem, since unless you add loaders/skeleton components, it
| will look like nothing is happening in the app. This is what has
| happened on every SPA I've worked on.
| dustymcp wrote:
| Or you design your components around this concept, its not
| really a hard problem to solve.
| henning wrote:
| Thank you for demonstrating that solving a problem you don't
| have creates a problem you definitely do have.
| nathants wrote:
| everything is fine. people need to chill.
|
| if you don't have a good sdlc[1], build one. if you're in an
| environment where that is impossible, change environments.
|
| there's never been a better time than right now to build software
| of all sorts.
|
| no excuses.
|
| 1. https://news.ycombinator.com/item?id=31546615
| bitemealienboi wrote:
| Ofcourse SPAs will always be around. In most programming, there
| are no concepts of "pages". Sure you have windows and dialogs and
| sections but all those elements maintain state.
|
| The controversy between SPA and MPA is simply due to the fact
| that HTML and the World Wide Web was never designed for dynamic
| applications in the first place. It was designed to serve static,
| linked resources.
|
| All of the controversies in web development, and the hundreds of
| differing frameworks each with their own opinions on the Right
| Way To Do Things (tm) is the result of attempting to fit the
| square peg of dynamic application development into the round hole
| of web design.
|
| MPA paradigms attempts to match Web concepts as they were
| intended, while SPA paradigms attempt to design programs are they
| are designed with other toolkits, languages and environments
| (while not being truly compatible with web)
| scotty79 wrote:
| SPA often has pages. And pages are actually wonderful concept
| that should have migrated to desktop apps but it didn't
|
| Ability to point to specific place in the UI of a desktop app
| with a short link would be so great.
|
| Although we got something similar or even better with
| Ctrl+Shift+P in VSCode.
| miiiiiike wrote:
| Hello folks and welcome to round 986 of the Least Interesting
| Conversation on The Internet. If you're just joining us, SPAs are
| great when they're necessary and MPAs are good too. And that's
| the game. The series stands at 986 ties. Thanks for tuning in and
| we'll see you again tomorrow for rounds 987, 988, and 989.
|
| I don't know how many times I can read the same article from a
| different (or same) author. They're apples and oranges. Scroll
| position restoration is really the only thing that has ever given
| me problems in an SPA. Really, come up with a browser model that
| can restore my scroll position when I hit back and I'm good.
| GaveDrohl wrote:
| This guy lost me after listing his biases. If your approach or
| the technology requires you to work at that low of a level, then
| we're doing something wrong. We should be abstracting complexity
| away, not depending on being knowledgeable of the inner working
| of things, like browser specific tricks (unless necessary).
| legulere wrote:
| All abstractions are leaky, some more, some less. Knowing what
| stands behind the abstraction is usually very helpful, even
| when most of the time using the abstraction you don't have to
| think about it.
| dustymcp wrote:
| I say pick your battles, some things you use way more than
| others understanding the inner workings of your most used is
| very helpful, you cannot know it all!
| [deleted]
| oblib wrote:
| It made sense to me, though he maybe could have offered some
| clearer examples of SPAs and MPAs that are better suited to
| those approaches.
| Vinnl wrote:
| He used to work on the performance of IE/Edge, as well as
| PouchDB, so that explains his biases.
| hypertele-Xii wrote:
| Who do you think is going to successfully abstract complexity,
| if not the people knowledgeable of the inner workings of the
| underlying platform?
|
| Those people age and die, as well; Don't want to find ourselves
| in the position of high abstraction that nobody living
| understands anymore. Therefore it's vital to the health of the
| techosystem that _some_ people approach it from the bottom up.
| tmcw wrote:
| Hope this kind of thinking becomes the norm! There are different
| tools for different problems, and SPA-like architectures are a
| good fit for a bunch of hard problems.
| Mo3 wrote:
| As much as I agree with you, I don't think it will. Unaware
| identification with the mind is rampant and black-and-white
| thinking as a consequence as well. It's going to take a long
| time until these patterns resolve slowly.
| dang wrote:
| Recent and related:
|
| _The balance has shifted away from SPAs_ -
| https://news.ycombinator.com/item?id=31459316 - May 2022 (444
| comments)
| polote wrote:
| If we renamed "SPA" to "using a framework for the frontend" we
| may be able to stop having so many of these discussions. What is
| a "page" in an app like Tiktok ? Is Tiktok a SPA or just a single
| page with an app inside it ?
| ratww wrote:
| Not really, we can't. You can still use a framework for the
| frontend in an MPA website (and you can have an SPA without a
| framework, although that's rarer), so the distinction still
| makes sense.
|
| FYI: Tiktok seems to be an SPA with routing and SSR.
| samwillis wrote:
| The current SPA vs MPA debate is conflating multiple things, when
| really I think the current trend isn't a move away from SPAs,
| it's a move towards server side rendering. Server side rendering
| is completely compatible with a SPA architecture, thats exactly
| what tools like Hotwire/Turbolinks and Livewire are doing, and in
| many ways makes it easer and more light weight.
|
| I believe the current frustration is with having to build APIs as
| a bridge between your backend and frontend with many of these JS
| SPA toolkits. With a server rendered "html on the wire" type
| architecture you don't need to build flexible apis. No need to
| plan ahead what you need, no more separate API authentication (at
| an object level), fewer moving parts in your stack.
|
| I think the future (for a large subset of website/apps) are
| frameworks that take a "hybrid" component approach, where you are
| defining in one place your sever and client code. If you open up
| a simple automatic bridge on the component level between back and
| frontend you remove an awful lot of leg work from building a
| site.
|
| There is always going to be a need for all these different
| architectures though, there will never be "one true solution".
|
| (Disclaimer, I'm building a hybrid component toolkit called Tetra
| http://tetraframework.com, so I'm somewhat biased)
| em-bee wrote:
| the API is exactly why i love SPAs.
|
| remember _the good old days_ when desktop applications were
| common?
|
| to me, creating an SPA feels exactly like writing a desktop
| app.
|
| i have a backend that does everything i need for a server, and
| i write a client, that accesses that server through its API.
| it's very clean and easy to manage. in my case i haven't been
| doing any backend coding for half a decade, because there is
| nothing left to be done. i just write client after client after
| client that does whatever is needed, using the backend as
| storage for state and data. it's so easy now. i can write
| multiple different clients that access the same data. i don't
| even have to write browser based clients. i can actually write
| true desktop clients, and they too are able to access the same
| data through the same API. need a mobile frontend? no problem
| either.
|
| in fact even for applications where an SPA is supposedly not
| suitable, i am still going to make it an SPA because otherwise
| i'd have to create a new backend instead of reusing the one i
| already have.
|
| so for me an SPA is now the cheapest, most efficient way to
| build any webinterface.
|
| so yeah, SPAs will persist.
| planarhobbit wrote:
| Just seeing the thread frequency of anti-SPA stuff on HN makes me
| shake my head. I don't get the viscerally negative reaction. I
| think people are pidgeonholed in their jobs to whatever framework
| someone picked and they feel powerless to change it and it's the
| wrong tool for the job, I don't know. I've done everything from
| manually crafting http packets to SSR to SPAs. Our current apps
| are spread out between basic SSR stuff, Blazor, Angular,
| React/Node, and so on. I've yet to sit down and have a (pardon
| the word usage) temper tantrum over any of these. I've had to
| poke my head in and maintain each thing at least a little bit.
| Nothing is going to be perfect, and requirements changing means
| every N years you need to re-evaluate not just the FE, but the
| architecture and inter-app communication strategy, caching
| mechanisms, etc etc.
| Taywee wrote:
| Personally, I have a negative reaction because we have an app
| that is used regularly by only a couple hundred users,
| developed by three programmers. The move to even a partial SPA
| with modals took forever, and we already had a completely
| unnecessary microservices architecture for potential future
| scaling that we still have never needed after 10 years
| (decisions I rallied against, but I was out-voted).
|
| Now we have an app that we depend heavily on, where more than
| 90% of the processing is just 10 different Rails apps chatting
| with each other on the same machine (all talking to the same
| database server, of course), 90% of bug fixes are related to
| the bespoke SPA architecture or microservices (where operating
| without caching is impossible for performance reasons, but
| caching is constantly causing problems), modals behave really
| weirdly on mobile, we spent months just re-implementing things
| that just worked out of the box with the MPA, like history and
| sharable URLs, and every single new feature has loads of more
| care that needs to be taken.
|
| A lot of this could have been avoided by going with a proper
| framework, or doing things the right way, or doing more
| research, but it also could have been avoided by just keeping
| our boring web app boring, and not jumping into trends that
| can't reasonably be maintained at our scale.
|
| I see the value in things like SPA and microservices, but I've
| personally seen the pitfalls in doing them just to do them, and
| being unable to reverse the decision once it's already
| happened, because the real pain didn't become apparent until
| much later. A lot of people might have the same experience.
| zelphirkalt wrote:
| Every day staples like browsing history, middle click /
| control click a link to open in new tab, back function,
| forward function, bookmarkability of specific "subpages" (in
| quotes, because SPA) are the first things to fly over board
| in 90% or more of SPAs, which do not have to be SPAs in the
| first place. Then developers either ignore all of those
| things, living with the illusion, that this is not impacting
| UX, or they have to introduce even more dependencies, that
| aim to fix those very basic things, which by default are
| broken.
|
| This is one of the main criticism I have for SPA. If you go
| SPA, it is your responsibility, to make it work at least as
| well as a traditional website.
|
| The other criticism is, that I expect to at least have a
| noscript block, telling me about a website not working
| without JS. And not some nonsense about my browser not being
| supported. No, it should admit, that the website was created
| in a way, that does not work without JS. It should be honest.
| But that is often too low level for SPA frameworks, so that
| the devs of the website cannot be a*ed to build that into
| their SPA. They throw around "web components" (actually react
| components, or any other framework components, because often
| you cannot copy paste them into another framework, which is
| not based on the framework, you implemented them for, because
| they are not standardized), but are unable to include a
| simple noscript tag.
|
| Basically most SPAs introduce JS as a must have dependency,
| but if I allow it to run on the page, I first have to trust
| some random code, and I will have opted into high CPU loads
| for things I do not need. How often I have experienced 100%
| of a core being used just by scrolling or for some silly
| animation no one needed or some hover effect. No one is
| testing these sites properly or speaks up in those
| organizations about the unprofessionalism that are apparent
| in the resulting websites.
|
| Some websites manage to get it right and to make everything
| work, probably, but usually I just close the tab, when again
| I only see a white screen with nothing on the page, instead
| of going through the pain of allowing their 10 CDNs to
| actually make it work, so I am not so likely to see that SPA,
| which does everything right and allows me to use an SPA like
| any normal website.
| boredtofears wrote:
| I wonder how many other hypergrowth stage startups besides my
| own are currently in a state where "legacy" codepaths are
| handling 90%+ of the bulk traffic while developers spend all
| their time on the other 10%.
| drewcoo wrote:
| > used regularly by only a couple hundred users > completely
| unnecessary microservices architecture for potential future
| scaling
|
| It sounds like the problem wasn't architectural decisions at
| all. The problems listed are from engineers trying to build
| for growth that didn't happen. You can probably complain
| about those because they're your bailiwick.
|
| The root cause is not the engineering side of the house,
| though. What happened to the predicted growth? A decade ago?
| scotty79 wrote:
| If that was Angular 1 I admire your patience. It felt like a
| such a step back crossed with layers of unnecessary ad-hoc
| complexity.
|
| Everything else on your list is perfectly fine.
| gadflyinyoureye wrote:
| My aversion to SPAs is due to working with non-SPA tech in the
| past. While portal systems got by with little need for JS for
| anything other than client side validation. The sever would
| work the business logic and render a view. This was fast,
| simple and understandable. SPAs require tracking state on the
| client side, and probably on the server side. Then you add SSR
| which often dictates your server side tech (mostly Node). Now I
| can't use Go or Java.
|
| As a result I have a complex build and deployment process
| (relative to templates packed away in a Jar) for little
| velocity benefit.
| vdnkh wrote:
| The HN hivemind hates JavaScript, mostly because they believe
| that complexity on the web is a problem self-inflicted by eager
| "framework devs" continuously chasing the "new shiny", which in
| their mind invalidates any legitimate engineering credibility
| or progress.
| [deleted]
| RHSeeger wrote:
| My negative reaction to SPAs is as a user, not a developer.
| There are so many places where SPA behavior runs counter to my
| intuition as a user (breaking the back button being the single
| most glaring issue) that I just don't like them in general.
| Sure, all these places _can_ be fixed with enough code; but
| they shouldn't need to be. Unless the application is one that
| clearly benefits from being implemented as a SPA, it shouldn't
| be one.
| gorono wrote:
| Back buttons work on SPAs
| mpolun wrote:
| robertoandred wrote:
| Breaking the back button is not SPA behavior.
| RHSeeger wrote:
| While I agree that the back button _should_ work in an SPA,
| it's common for it not to. And it's common for other
| functionality to break. It's not hard to fix that and, for
| a well engineered SPA, such things typically do work.
| However, it _is_ extra work and it _does_ get missed. As
| such, SPAs tend to have more issues than non-SPAs. As such,
| as a user, I tend to prefer non-SPA implementations unless
| there is a strong reason that the SPA makes more sense.
| trivialsoup wrote:
| Not only is it not implicitly SPA behavior, as you say,
| good back button behavior design is actually _hard_ in a
| app setting. And you can't generally "get it right" -- no
| matter what you do, in a sufficiently complex scenario
| (which... that's why you built an SPA, right?) users will
| disagree about what the back button should do!
|
| Generalized anti-SPA sentiment is silly. Saying "bad
| implementations correspond with SPA" is true but also silly
| because there's not as much to get wrong in non-app
| settings which admit a "traditional" approach. It's like
| the xkcd observation about heat maps and population
| density.
| icedchai wrote:
| It's very common in poorly engineered SPAs. "Built in"
| browser functionality often has to be reimplemented.
| Mo3 wrote:
| Bad developers are still not a valid argument against
| SPAs.
| dempseye wrote:
| That's like saying bad trapeze artists are not a valid
| argument for safety nets.
| layer8 wrote:
| It sort-of is if bad developers are less likely to wreck
| havoc with MPAs. Also, I don't think that back-button
| breakage automatically indicates incompetent developers
| (although I tend to swear at them).
| Taywee wrote:
| Why not? "You have to reimplement a huge amount of
| current and future behaviors that just work for MPAs" is
| definitely an argument against SPAs. That's extra work,
| extra potential for bugs, extra potential for
| accessibility problems.
| RHSeeger wrote:
| If it is more common for functionality to be broken in an
| SPA than in a non-SPA, then that most certainly _is_ a
| valid argument against SPAs (from a user perspective).
| It's not an argument that all SPAs are bad. Rather, that
| I prefer non-SPA implementations because I can generally
| assume that it will have fewer bugs/annoyances in using
| it.
| hansvm wrote:
| It's a common behavior in SPA that's uncommon elsewhere.
| Kind of like how buffer overflows aren't C behavior.
| asddubs wrote:
| breaking "open in new tab" annoys me far more (and also seems
| to be way more common)
|
| that and the fact that SPAs, not intrinsically, but often are
| so sluggish
| rektide wrote:
| > _Just seeing the thread frequency of anti-SPA stuff on HN
| makes me shake my head. I don't get the viscerally negative
| reaction._
|
| In general, commenting as a medium is a breeding grounds for
| dissent & doubt. Some because thatcs natural, that a stance
| attracts the anti-stances, serves as a place for contrast.
|
| There's a lot of general anti stances that can just never ever
| be dealt with & killed though. That's an issue, imo
| anstructural one: if someone mentions docker you bet your ass
| three people will chime in to ask why docker, can we do without
| docker?
|
| We're finally no longer having to endure the same endless
| griping about how awful pulseaudio was, we've been through the
| conversations enough times & know the refutations & enough
| people enjoy the vastly-more-powerful and user-configurable
| than all alternatives capabilities it grants. And pipewire
| iterated & refined, somewhat proving the concept & api was good
| enough & worthy. Progress eventually shined theough. But other
| tech still is beset:
|
| BTRFS still attracts wide manners sof casual slander. Systemd
| feels like it's turning the page, that we're starting to route
| & rebuff the endless endless tide of complaints & griefing and
| sometimes there can be peace when systemd gets mentioned
| somewhere, but there's still a sizable chance any give little
| systemd mention turns into a slugfest.
|
| Each tech has to endure years & years of it's haters. The
| haters have more time & energy, & Bullshit Asymmetry Principle
| makes just asking a short disruptive question blow up into a
| vast fog of disinformation & nonsense back & forth. Doubt is
| just, structurally, easy & cheap, & hard to escape from. It's
| successful memetically in propogating, in confusing, in
| disuading. The shouting class has a huge advantage. Doers &
| believers have much harder jobs & their vigilance & it requires
| careful finess to cut clearly through bullshit without getting
| too much on yourself.
|
| > _I think people are pidgeonholed in their jobs to whatever
| framework someone picked and they feel powerless to change it
| and it's the wrong tool for the job_
|
| Yes for sure. The web has heavily undergone heavy
| industrialization, with jquery & backbone kind of warm up acts,
| young adult years, then a rapid rapid acceleration of
| expectations & demands, more formalized tools, more deliberated
| architectures. People miss the simpler stringing shit together.
| And there's tons of concerns we've had to start accepting in,
| as we grow big, as we raise expecations & add developmemt
| pressures. You point this our yourself:
|
| > _Nothing is going to be perfect, and requirements changing
| means every N years you need to re-evaluate not just the FE,
| but the architecture and inter-app communication strategy,
| caching mechanisms, etc etc._
|
| I also think, the web used to be a cross-roads of different
| languages & technologies. I've always championed & celebrated
| the rise of JS, but JS uber alles (over all) was never my
| desire. Even within JS, we're only just starting to see some
| re-diversification & re-exploration in a an after-React world;
| we'd really monocultured out & a lot of older princples (url
| routing, rest) got kind of kicked over, unmooring the platform
| from it's roots & things that made it hackable & legible. We're
| both semi-monocultural, but we also dont bundle in all the
| answers, to the many facets that need to be considered, and
| there's less other people trying other ways in this mid-
| industrailizarion phase, fo learn from & pluck easier ways of
| doing from.
| outime wrote:
| You're not alone. SPAs have their place, they're not
| alternatives to fully SSR pages - they're simply different.
| There are other examples of such visceral reactions here, for
| example K8s.
|
| I personally don't bother discussing these things anymore here
| as a big portion of the HN crowd just dislikes it and there
| isn't much left to reason about despite having countless
| examples of nice implementations around the world.
| asabla wrote:
| I share your experience as well. Sometimes a SPA doesn't make
| sense, and others it may be the only viable long term solution
| to keep things maintainable.
|
| I just use whatever makes sense for whatever problem I'm trying
| to solve
| ratww wrote:
| I don't disagree with you in general, but I don't think it's
| fair to characterise the sentiment as purely simply anti-SPA.
|
| There's a lot of people that dislike the SPA-as-default
| movement, where simple websites could be written in a more
| traditional manner. Add that with a lot of people that dislike
| the fact that native applications are being replaced by lower-
| performance web-tech ones.
|
| But we still see a lot of love for PhotoPea, for example. And I
| don't think anyone with anti-SPA ideas believes that things
| like Google Maps and Google Docs should be rewritten as SSR or
| something. And even the Electron haters admit that VSCode is a
| great piece of software.
___________________________________________________________________
(page generated 2022-05-29 23:01 UTC)