[HN Gopher] SPAs Were a Mistake
___________________________________________________________________
SPAs Were a Mistake
Author : andrei_says_
Score : 392 points
Date : 2022-03-02 15:35 UTC (7 hours ago)
(HTM) web link (gomakethings.com)
(TXT) w3m dump (gomakethings.com)
| crescentfresh wrote:
| I showed an interviewer a piece of something I built in a
| traditional page-per-view design, with some xmlhttprequest where
| appropriate, and a sprinkling of Vue where it added usability to
| some of the modal dialogs. Their only response was "why didn't
| you build it in React?".
|
| I stopped interviewing for front-end work since then. The
| landscape changes frustratingly too often.
| matchagaucho wrote:
| I'm still bullish on the potential for Web Assembly apps to
| overtake mobile binaries.
|
| And instead of _Single Page_ Apps, we 'll have just plain _Apps_
| that run in browsers.
| heurisko wrote:
| I would much rather program in any language that is compiled to
| web assembly rather than JavaScript.
| Dma54rhs wrote:
| Since I assume you know about it a bit more, what is
| realistically timeframe it could happen at best?
| matchagaucho wrote:
| No idea on timeline. But I'd speculate Apple has no incentive
| to cannibalize their AppStore ecosystem and make Safari more
| than a web browser.
|
| So Google/Chrome or Firefox are the only 2 players with
| enough incentive to make Wasm an Internet app standard.
|
| Or possibly the next Wasm-first, cross platform browser will
| come along with a Wasm AppStore?
| bluewalt wrote:
| I think one of the main reason SPAs are overused is because it's
| hard in 2022 for your users to wait after clicking on a link.
| Users are now used to instantaneous, especially since they all
| have a smartphone with apps on it. We, as web developers, try to
| give the best UX to users.
| gls2ro wrote:
| I agree with you and I think there are some good SPAs. In my
| case what makes me angry is opening a presentation website and
| seeing a loader because someone decided to make that a SPA.
| ramesh31 wrote:
| >SPA's suck! Here's my ad-hoc replacement architecture that you
| should totally just use!
|
| 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.
| aminerman wrote:
| Anyone can choose the tech stack, patterns, or whatever that he
| likes. But developers enjoy being absolutists, and deem something
| they don't like as a MISTAKE, or would tell you that the way they
| think is the ONLY way to think.
|
| You do your app the way you want depending on the Ux you want to
| provide, on the tech you enjoy implementing, on the patterns you
| like to follow.
| commandlinefan wrote:
| > Anyone can choose the tech stack, patterns, or whatever that
| he likes
|
| Maybe for personal projects, but 99% of us have to use the tech
| stack, pattern or whatever of our employer that was decided on
| (presumedly by some consensus at some point in the past).
| Publicly pointing out the flaws in what might have made sense
| then but might not make sense now is a Good Thing so that those
| flaws might be taken into consideration in the next round of
| consensus building.
| hinkley wrote:
| I don't understand what sort of cave trolls think I get to
| decide for me. Even as a lead I am making decisions based on
| the situation on the ground and those are informed by what
| people are comfortable with and what I can help them get
| comfortable with. It's a team activity.
|
| But every conversation has someone spouting off like these
| are experiments in a Petri dish. Petri dish projects don't
| matter. Haven't for a long time.
| root_axis wrote:
| Don't work for a company running a tech stack you don't like.
| seer wrote:
| One thing that I found working in a bigger organisation is just
| how well React encapsulates Design Systems. You can have a
| dedicated team of talented frontend engineers that builds a
| really solid design system, and then other folks building the
| actual user facing bits can use them, and everything will be nice
| and consistent across all the various apps.
|
| For example look at how well this has been going for Uber.
|
| Now this is certainly possible, and even relatively easy to do in
| server side frameworks, but as others have stated, its harder to
| make sure it works nice in all the various edge cases and visual
| flair that is required for end users, and keeping it all
| consistent and upgradable across the board.
|
| React (and I'd wager other component based approaches) shine
| there - its low level enough that you can implement anything with
| it, but still allow you to build complex things fast. And then
| are free to implement the actual business logic of the backend
| with the technologies of your choice. Even better various teams
| can do that in their preferred language, without the end user
| being affected by the difference.
|
| Throw in react native to make the styles transferrable to mobile
| apps and you have the perfect sweet spot for largish tech
| companies. And since those tend to be the more vocal ones, we get
| this, in my opinion largely deserved desire to build SPAs.
|
| Smaller teams / startups of coarse don't have those incentives,
| so they will understandably not have the same cost / benefit
| analysis.
| softwarebeware wrote:
| I'm not clear why the author thinks that "media sites, really"
| are the only SPA use case. Have they never used webmail (like
| GMail), map apps (like Google Maps), or social networks (like
| Twitter)?
| gls2ro wrote:
| I give you Google Maps is a perfect example maybe for SPA.
|
| But Gmail? Why do we need SPA for that? Receiving emails
| notifications could be websockets and clicking on email should
| go to a new page displaying the email. I dont know if the
| initial gmail was SPA or not, but the current version is very
| very slow and consumes a lot of memory to display some emails
| that worked even in terminal clients, remember Pine?
|
| The same for twitter? I anyhow have to press "Load 39 new
| tweets" to load the new ones so why is it a SPA? Just for that
| notification? If you would give me a twitter client where I
| need to refresh the page to load new tweets but works faster
| and consumes less memory I will happy use that.
| freeaccount wrote:
| aminerman wrote:
| tonyedgecombe wrote:
| You keep making this ad hominem attack without presenting any
| evidence.
| hinkley wrote:
| You're really enjoying that brush today.
| vangelis wrote:
| Don't be an asshole.
| Aerroon wrote:
| SPAs are just Flash 2.0, except it's not popular to hate on them
| like it was popular to hate on Flash websites.
| sigstoat wrote:
| webapps were a mistake.
| thepra wrote:
| I guess Blazor WASM is the elephant in the room. OOP as much as
| you want, js codebase required near to 0.
| thaway2839 wrote:
| The argument appears to be that browsers give you a lot of things
| for free that SPAs need to recreate.
|
| But that's not true in practice. In practice most SPAs are
| created on top of a handful of extremely well tested
| libraries/frameworks that do all the work for you that the
| browser would do in an MPA.
|
| That's not really a good reason that SPAs are a mistake.
| ChicagoDave wrote:
| Users do stupid things regardless of the implementation. The
| extra work to implement a SPA is worth it because you can swap
| material in and out on demand without constructing a complete new
| web page.
|
| 100% disagree with OP.
| me_me_mu_mu wrote:
| I had the pleasure (aka hell mode) of building a content site as
| a SPA because some non-technical manager kept pushing it (it was
| one of those companies).
|
| It was an insane task to meet all the SEO requirements, we ended
| up doing server rendered pages, and keep in mind this was years
| ago so there was not a whole lot of support or tutorials on how
| to do it.
|
| Oh well, I got paid to learn a bunch of new stuff so I can't
| complain :D
| nhoughto wrote:
| Not the reasons I expected
|
| I don't see Navigation as a main problem and it can be solved
| quite neatly, not that much more complex than a normal site. Was
| expecting something about bundle size etc.
| themanmaran wrote:
| Agreed. The blog doesn't seem like a very thought out
| examination, and I expect most of the HN replies are just
| debating the title.
|
| For me, the biggest con of SPAs is lack of SEO.
| bluetwo wrote:
| If it makes you feel better, SPAs were a mistake when they were
| all the craze in Flash. Also way before that in Director.
|
| In those two cases, they signified (or accelerated) the end of
| the useful lifespan of those languages.
|
| SPAs, like frameworks, always make some things easier and some
| things harder. As long as you stay within the lines of what is
| easy, you are good. As soon as you stray outside those lines, you
| get punished.
| nawgz wrote:
| "SPAs were a mistake"
|
| Meanwhile essentially every major tech property develops SPAs and
| users enjoy them far more than traditional hypertext web round-
| trip-every-change pages
| jmconfuzeus wrote:
| Big tech companies love wasting money and developing a SPA is a
| good way to do that.
|
| Whether users prefers SPAs or not is debatable. Amazon, Github,
| and Aliexpress aren't SPAs because poor usability will cause
| users to move to competitors. If Hacker news turned into a SPA,
| I guarantee that it would suck big time.
|
| SPA developers seem to be living in a tiny bubble oblivious of
| simple solutions to simple problems.
| nawgz wrote:
| > Github
|
| In what world is this not an SPA? I don't see page
| transitions hardly anywhere, except when you're switching
| from marketing material to repos maybe.
|
| Additionally, the fact that GitLab (which is devops/issue
| tracking/wiki/etc.) ISN'T an SPA drives me crazy every day. I
| have to wait for so many rerenders that could just be
| seamless loads, it's actually insane to me how unoptimized of
| a user experience it is, especially when my happy path is
| super clear with respect to what content I load.
|
| > SPA developers seem to be living in a tiny bubble oblivious
| of simple solutions to simple problems
|
| I think it's hilarious who you consider to be living in a
| bubble, and what simplicity really means. Client side
| interactions need to be smooth. Web applications are
| consistently and increasingly presenting meaningful user
| workflows that can be made more resilient and responsive with
| SPAs. I develop tools for dataflow/workflow editing,
| scheduling, visualization, etc., and the idea that these
| things can be made to feel good without a dedicated client
| layer is truly an archaic attitude.
| randomsearch wrote:
| Controversial opinion: SPAs are great and also SPAs are an
| admission that Java applets were along the right lines.
| EMM_386 wrote:
| My company wouldn't know it.
|
| I'm lead on a large Angular 13 app used by tens of thousands of
| companies, it works and it's very fast.
|
| I wouldn't call SPAs a mistake. I have 2+ decades in the industry
| and come from an ASP.Net / MVC background prior to Angular.
| frabjoused wrote:
| I can't agree with this. That list of 9 complexities are well
| abstracted by the most common library or framework for SPAs.
| Having done a lot of SPA development I can say routing is not
| anywhere up on the list of trouble spots you do encounter. State
| management is another story.
| kizer wrote:
| Here's the thing: so-called "JAM stack" apps are the cheapest to
| run, right? I realized this while I was thinking about how to
| create the cheapest site possible. Mainly, you want to minimize
| bandwidth. Well, SPAs are designed to do this. The site gets
| cached on the first hit, and runs usually JSON requests in the
| background after. So I think a big motivation for building SPAs
| is because they're cheap to host/run.
| gunapologist99 wrote:
| REST API's (literally, "Representational State Transfer", ReST)
| are a very nice match with SPA's, because now the browser is the
| sole source of truth for application state (and the server only
| has to produce some JSON data instead of entire HTML pages).
|
| Literally the _entire_ point of REST is that you don 't have to
| maintain server-side sessions, and you shouldn't. This also has
| benefits for scalable applications, in that you can transfer your
| running application to a cluster of servers on the other side of
| the world, and it'll still keep working.
|
| The trust boundary between the front and back ends can be a huge
| boon to security as well, and some things are literally
| impossible to do with a multi-page app, and you can still
| maintain URL parity with new actions in your page.
|
| That's why SPAs were, and are, great!
|
| That doesn't mean everything should be an SPA! A photo, news,
| blog, or recipe website might be better laid out as a separate
| page for each individual item. However, there are tons of other
| types of real applications that can only be built as an SPA.
|
| Are they unwieldy, sometimes hard-to-code and maintain, and
| sometimes result in a poorer experience? Yes, but that can also
| be true of a multi-page app, especially if you're trying to
| shoehorn an SPA experience into a multi-page app and want to
| maintain the same user experience as a user moves around within
| the app.
|
| A multi-page "app" isn't really an app anymore; it's a server-
| side app that is producing multiple pages. A single page app
| literally is running in the browser and only sending a bit of
| data back and forth with each user interaction. It's just a
| completely different model.
| cjalmeida wrote:
| This ship has sailed. SPAs shortcomings are widely known and
| addressed by frameworks.
|
| Whatever MPA alternative you bring will need to address other
| shortcomings. There will always be something quirky due to
| building applications in a technology designed for hypertext
| documents.
| bdcravens wrote:
| Many of those shortcomings were solved 15-20 years ago. Far too
| many SPAs are little more than old school request and response,
| GET and POSTs. I've literally had to drop into the dev tools
| console just to push through a page with 7 sets of radio
| buttons because Angular broke in some spectacular way, on a
| page that is and should be boring (prescription refill page).
| [deleted]
| antihero wrote:
| This article seems to be directed at dealing with people that use
| SPAs to make more content focused websites, which quite obviously
| are better made with the browser.
|
| However, for an application with a persistent UI, I fail to see
| how constant page loads and navigation just because "the browser
| can do this" make any sense at all.
|
| Even the example is a bit silly - SPAs that should be SPAs don't
| really have "links" per say, they will mostly have buttons, which
| will have a some sort of defined action. Perhaps these buttons
| will navigate to some other screen in the application, however,
| reloading all of the client side state every time one does this
| is absurd to say the least.
|
| Finally, from a technical perspective, having a clear separation
| of concerns by having code talk to an API as opposed to HTML
| being rendered on the server, you remove a lot of complexity.
|
| It feels like the people who write these articles don't actually
| remember how utterly shit the jQuery days were.
| gowld wrote:
| jQuery days were bad?
| viggity wrote:
| there were certainly people that committed war crimes with
| jQuery. Just like every other framework in existence. I yearn
| to return, honestly.
| horsawlarway wrote:
| Yeah - I think a lot of it might be developers who don't
| understand that SPA and caching go pretty much hand in hand.
|
| I'll admit that can make your life as a developer harder
| sometimes (to be blunt - caching is hard - full stop) but an
| SPA rendering from cache is basically a rocket compared to a
| server rendered page on a bad connection.
|
| Absolutely no one enjoys waiting 2-5 seconds after clicking the
| back button to see a page they were just on, but that's the
| reality of a server rendered app on a bad connection. An SPA
| with good caching does, in fact, feel like a native app - in
| lots of good ways.
| infensus wrote:
| >no one enjoys waiting 2-5 seconds after clicking the back
| button to see a page they were just on, but that's the
| reality of a server rendered app on a bad connection
|
| Wait, what. Don't basically all browsers nowadays keep
| previous pages in memory exactly not to do this?
| charcircuit wrote:
| >Absolutely no one enjoys waiting 2-5 seconds after clicking
| the back button to see a page they were just on
|
| This doesn't happen because the browser caches the last page.
| wackget wrote:
| If you read [his next blog
| post](https://gomakethings.com/how-to-make-mpas-that-are-as-
| fast-a...) you'll see he has lots of experience with
| architecting an advanced, cache-heavy multi-page application
| which works and behaves much like you describe.
| horsawlarway wrote:
| Yeah, interesting.
|
| I think that approach is fine if you have an application
| that's light on interactivity (like school curriculum or
| tutorial, in his case).
|
| And I agree 100% on the service workers (Seriously, I'm
| right there with him - they're magic). I would also
| recommend leaning more heavily on persistent storage
| (localstorage/indexdb) but I'm also trying to handle
| offline only cases.
|
| I think some of the advice falls down when you're genuinely
| trying to create an interactive experience. I probably
| won't expound much farther, since I really try to keep
| business out of HN, but... I write applications that have
| been used for following treatment programs in education
| environments - think speech therapy or ABA for autistic
| students, where the user is inputing data frequently - as
| often as once a second - and the UI is updating in response
| to calculations done client side, that influence the
| instructors program and plan in real time.
|
| It's a lot of screens, often customized locally on the
| application, and removing JS (or even just writing pure js)
| hurts a lot. That's... hard to do with minimal js. Really,
| really hard.
| aminerman wrote:
| He was just unable to follow and understand the trend, and
| thinks that therefore the whole industry made a MISTAKE :D
| barbarbar wrote:
| `
| vgel wrote:
| > Be kind. Don't be snarky. Have curious conversation;
| don't cross-examine. Please don't fulminate. Please don't
| sneer, including at the rest of the community.
|
| https://news.ycombinator.com/newsguidelines.html
| jaywalk wrote:
| First of all, this is uncalled for. Second of all, it's not
| even an SPA. Maybe do the slightest bit of research before
| slinging shit at someone?
| wackget wrote:
| >> He was just unable to follow and understand the trend, and
| thinks that therefore the whole industry made a MISTAKE :D
|
| That's not true, though. If you read [his next blog
| post](https://gomakethings.com/how-to-make-mpas-that-are-as-
| fast-a...) you'll see he has lots of experience with
| architecting an advanced multi-page application which works
| and behaves much like an SPA.
|
| It makes his anti-SPA post kind of redundant and a bit
| hypocritical, but he clearly knows roughly what he's doing.
| amackera wrote:
| I think it's just regular old click bait.
| antihero wrote:
| It does feel like the tiring contrarianism type of heading as
| opposed to a particularly well thought out article.
|
| In the same way I feel lesser able coders seem to dwell on
| shit-slinging against tech that is proven, works, and has
| solved innumerable problems when they bang on about how
| things were so much nicer with vanilla JS and how frameworks
| are lazy and slow or something, in order to cultivate a sense
| of superiority.
|
| Any well made tech has it's place, skill and experience are
| about knowing which tech should be used where.
| jdrc wrote:
| > However, for an application with a persistent UI, I fail to
| see how constant page loads and navigation just because "the
| browser can do this" make any sense at all.
|
| in the same way how re-rendering the screen in a 3D game for
| every frame does it. Or how you buy a new pair of jeans instead
| of meticulously learning how to patch the old ones. It solves a
| lot of problems even if it sounds suboptimal. It was the
| standard practice when computers and networks were much much
| much slower, therefore it cannot be that bad.
|
| I think SPA and their entire ecosystem give some sense of
| optimality to purists which is probably shortsighted and wrong.
| pictur wrote:
| I have always wondered how people gain this self-confidence.
| beardedman wrote:
| AtNightWeCode wrote:
| ANY modern site uses something like nextjs or any other static
| site generator. The q is then if you make the site isomorphic or
| not and how the need for dynamic content looks.
|
| There are no other viable options today for large professional
| sites.
|
| If you have the problems described in the article you probably
| are not using a web framework.
| mi100hael wrote:
| I think people have forgotten how easy it is to set up a
| traditional server-rendered site with Spring Boot or Django or
| whatever framework. These days I see people adding a SPA as the
| default starting approach, which adds an entirely separate
| additional tech stack & deployable to the mix when it's not
| usually clear why.
| TedDoesntTalk wrote:
| If you don't start with an SPA, you are looked at funny. Like
| maybe if you were to choose COBOL for the backend code.
| stevebmark wrote:
| Don't limit this to SPAs, include the Jamstack, which has all the
| same problems, and the false promise that if you can statically
| render a few pages or parts of pages and put them on a CDN,
| everything will be fast. It won't, because to load dynamic
| content, you still have to do a lot of work and talk to a (gasp)
| centralized API over the internet.
|
| SPAs and Jamstack favor developer convenience over end user
| experience. Let's have fewer loading spinners, and more SSR-by-
| default for pages with dynamic content.
| Graffur wrote:
| > developer convenience
|
| This is really, really important though.
| kizer wrote:
| But there's a cost savings, right? JSON requests for just the
| data necessary vs. sending the whole HTML page each time.
|
| Personally I'd prefer to develop a website the old-fashioned
| way, but I see that the bandwidth savings is a major point for
| SPAs and if you're running a business...
| stevebmark wrote:
| SSR by default, and then if you want, client side hydration
| and navigation so subsequent page loads happen in the client.
| However, the size difference between an HTML response and a
| JSON response is negligible, and HTML responses don't have to
| wait for Javascript to download, parse, execute, kick off off
| a request over the internet, get the data back, execute the
| result, and update the DOM. Browsers have literally decades
| of optimization to show HTML to users as fast as possible,
| and doing this in Javascript is fundamentally slower.
| simonw wrote:
| It's been so frustrating watch this play out over the past
| decade.
|
| I keep seeing projects that could have been written as a
| traditional multi-page application pick an SPA architecture
| instead, with the result that they take 2-5 times longer to build
| and produce an end-result that's far slower to load and much more
| prone to bugs.
|
| Inevitably none of these projects end up taking advantage of the
| supposed benefits of SPAs: there are no snazzy animations between
| states, and the "interactivity" mainly consists of form
| submissions that don't trigger a full page - which could have
| been done for a fraction of the cost (in development time and
| performance) using a 2009-era jQuery plugin!
|
| And most of them don't spend the time to implement HTML5 history
| properly, so they break the URLs - which means you can't bookmark
| or deep link into them and they break the back/forward buttons.
|
| I started out thinking "surely there are benefits to this
| approach that I've not understood yet - there's no way the entire
| industry would swing in this direction if it didn't have good
| reasons to do so".
|
| I've run out of patience now. Not only do we not seem to be
| learning from our mistakes, but we've now trained up an entire
| new generation of web developers who don't even know HOW to build
| interactive web products without going the SPA route!
|
| My recommendation remains the same: default to not writing an
| SPA, unless your project has specific, well understood
| requirements (e.g. you're building Figma) that make the SPA route
| a better fit.
|
| Don't default to building an SPA.
| rektide wrote:
| > _It 's been so frustrating watch this play out over the past
| decade.
|
| > _I keep seeing projects that could have been written as a
| traditional multi-page application pick a SPA architecture
| instead, with the result that they take 2-5 times longer to
| build and produce an end-result that's far slower to load and
| much more prone to bugs.*
|
| Its been frustrating seeing the webplatform _not_ play out,
| seeing so little growing in to SPAs, so little maturing.
|
| Url-based routing is heavily under-represented, tackes on only
| by the one or two blokes who happened to have some memory of
| web architecture. This clairifies the architecture both
| internally & externally.
|
| As bad a problem, single page apps being stuck, forever, at
| single-bundle apps is phenomenally sad. Splitting bundles into
| chunks as a manual development task is so hard, so bad. The
| goal of having web based modules almost made sense, almost
| happened, but we rafically underinvested in transport
| technology, cache-digest going undelivered. I continue to think
| js modules, with import maps- the key tech to making modules
| modular- is worth it, would help make our architecture so much
| better. There is mild extra time to first load, but worth
| it/small, & cached after.
|
| Again we're damned though. Years too late to try & see how
| excellent it would be to have something like react cached & AOT
| compiled as from a cdn. Because now privacy concern freak-outs
| mean this huge advantage of only needing to pull & potentially
| compile a js module once are gone: site-partitioning rules. We
| could have had better architecture, been using the language not
| absurd bundlers, and enjoyed high cache bit rates for common
| libraries. SPAs just didnt care, never tried at all, we all
| (almost all) did a horrible job & took way way too long (over a
| decade) to make modules modular g usable. There was so much
| hope g promise & such abaurd non-delivery, on the module front,
| on app archtiecture.
|
| HTTP3 and early-hints still have some promising hopes for
| accelerating our transports, making "just modules" a
| possibility & fast, without careful hand optimization. We could
| still do more to optimize bundles, have automated tools that
| analyze up front versus on-demand dependency bundles, build
| http bundles of these. But i hope eventually itcs mostly not
| super necessary to build webpackage (nor far worse, webpack)
| bundles.
|
| SPAs still have great potential. More so, now that we finally
| have some support tech for modules forming.
| rapind wrote:
| It's all about state management IMO. There are legitimate
| reasons to keep UI specific complex temporary state on the
| client that would be more complex (and slower) if the server
| needed to hold it. So an SPA or at least partial SPA in some
| situations does makes sense.
|
| But it does tend to become a hammer for every screw over
| time...
| polished85 wrote:
| I initially thought part of the appeal was offloading the
| workload to the front end, where your processing power scales
| infinitely with each user's device. Maybe the benefit turned
| out to be negligible, I'm not really sure. Can server costs be
| reduced by offloading the work to the front end?
| gnlrtntv wrote:
| They absolutely can, if your workload is ideal for this
| situation, but unfortunately, the most "expensive" (in terms
| of time, money, computing power, you name it) part of giving
| a user information is typically the filtering and collation
| of that information from a much larger pool of information --
| almost always a pool of information that is far too big and
| too private to just send to the client to sort through
| locally.
|
| Even in the most simple scenarios, you quickly find your
| limits. If you get data back, but it's paginated (and it
| almost always has to be, for basic reliability reasons as
| much as anything else), you can't be guaranteed to have the
| complete set of data in a given circumstance, so you can't
| perform operations like filtering, pivoting, or sorting that
| data locally. You have to ask the server to do this for you
| and wait for the response, just like we've had to in the
| past.
| somishere wrote:
| Dynamic loading of content is a feature of SPAs, but it's
| not a defining feature, nor unique. In fact, one defining
| feature of SPAs is the offline capabilities (service
| workers, caching, etc.), which sits at a bit of a tangent
| to database considerations like this.
| freedomben wrote:
| This was one of the appeals initially, and would certainly
| still be true if you were doing something very processor
| intensive that could securely be done on the client.
|
| Languages/runtimes have gotten faster and more optimized,
| while hardware has continued to move forward. It's also far
| easier now to add more backend instances using orchestrators
| like k8s, so it's less of a big deal to have to add replicas.
| somishere wrote:
| > Can server costs be reduced by offloading the work to the
| front end?
|
| I would say yes. One significant benefit of SPAs is that you
| can produce fairly complex applications without any server
| logic, only static hosting. The workload is essentially
| offloaded to the build process and the front-end. You still
| need to carefully consider the effect on e.g low powered and
| js-disabled devices ... but these are straightforward
| considerations.
| [deleted]
| finniananderson wrote:
| Totally agree.
|
| We built a product in ~5 months with real-time collaboration,
| extensive interactivity, Oauth, Stripe and Gmail integrations
| with a standard Ruby on Rails stack.
|
| It's rock-solid, performant, dead-simple and extremely
| productive to work with.
|
| Why're we throwing away years of learning to build unstable,
| complex and inaccessible applications?
| rapind wrote:
| One could argue rails is just doing a decent job of hiding a
| monstrous amount of unnecessary complexity from you for basic
| CRUD stuff. It's good at this... until it isn't. In the the
| whole ORM abstraction (not just in rails) is questionable.
|
| The way most of us would handle authorization in something
| like rails is a leaky abstraction, especially when we're
| usually backing onto postgresql which has very mature roles
| and permissions.
| whatshisface wrote:
| > _Why 're we throwing away years of learning to build
| unstable, complex and inaccessible applications? _
|
| 1. Smart people seek out difficult problems.
|
| 2. Difficult problems drive the creation of complex, niche
| tools, that bear cultural associations with the smart people
| who made and use them.
|
| 3. People who want to be smart seek out complex, niche tools.
| delusional wrote:
| I think you're somewhat right, but it's not the whole
| story. There's another pipeline that goes something like:
|
| 1. Technical software problems are more fun than difficult
| product problems
|
| 2. Programmers would rather solve fun problems
|
| 3. Programmers end up creating technically elaborate
| machines to solve simple (buy annoying) product problems
| fossuser wrote:
| I think it might be simpler?
|
| The more complex products are the only ones that typically
| have any documentation or up to date learning resources.
|
| You want to learn how to build a thing and this is the only
| thing that really exists, is up to date, and works.
|
| It may not be the right tool, but for someone new it's
| impossible to tell what the right tool is and people online
| are stereotypically obtuse and about anything tool related.
| heyitsanewacco wrote:
| lmao yeah pretty much. I'm moving from a low code shop to
| Node/Vue because I can't keep people. They all want to pad
| their resume, so I'm going to build at 2x the cost just so
| I can keep the projects going.
| whatshisface wrote:
| The level of Node/Vue isn't padding your resume in this
| industry, it's having a resume. Padding your resume would
| be... I don't know, Elm?
| diordiderot wrote:
| I think this is a midwit[0] take.
|
| Low: simple good
|
| Mid: optimized good
|
| High: simple good
|
| 0: https://knowyourmeme.com/memes/iq-bell-curve-midwit
| com2kid wrote:
| > And most of them don't spend the time to implement HTML5
| history properly, so they break the URLs - which means you
| can't bookmark or deep link into them and they break the
| back/forward buttons.
|
| The majority of routers for React, and other SPA frameworks, do
| this out of the box. This has been a solved problem for half a
| decade at least. A website has to go out of its way to mess
| this up.
|
| That aside,
|
| SPAs are great for a number of reasons:
|
| 1. You aren't mixing state across server and client. Single
| Source of Truth is a thing for a good reason. If you have a
| stateful backend, and your front end naturally has the state of
| whatever the user has input, you now have to work to keep those
| two in sync.
|
| 2. You need a beefier backend. A SPA backed by REST APIs is
| super easy to scale. nginx can serve up static resources (the
| JS bundle of the site) LOLWTF fast, and stateless REST apis are
| easy peasy to scale up to whatever load you want. Now you just
| have to worry about backend DB, which you have to worry about
| with non SPAs anyway.
|
| 3. Less languages to deal with. If you are making a modern site
| you likely have JS on the front end, so with SPA you have JS +
| HTML. With another backend framework you now have
| JS+HTML+(Ruby|Python|PHP|C#|...), and that back end code now
| needs to generate HTML+JS. That is just all around more work.
|
| I agree some sites shouldn't be a SPA, a site that is mostly
| text content consumption, please no. A blog doesn't need to be
| a SPA. Many forums, such as HN, don't need to be a SPA.
|
| But if a site is behaving like an actual application, just
| delivered through a web browser, then SPAs make a ton of sense.
| the_gipsy wrote:
| > The majority of routers for React, and other SPA
| frameworks, do this out of the box. This has been a solved
| problem for half a decade at least. A website has to go out
| of its way to mess this up.
|
| 99% of SPAs break history related features in some way.
| ozim wrote:
| 99% of people don't FRICKING care.
|
| Most of the users I have to deal with still have problems
| with double clicking.
|
| They don't understand basic browser features.
|
| They don't understand that they can set preferred language
| in their browser.
|
| History related features are not an argument in any way.
| freedomben wrote:
| I agree with all your points, but I think it's worth pointing
| out that those benefits you mentioned are largely _for the
| developers_. As a consumer I love a well-written SPA when the
| problem set calls for it, but most of the SPAs I have to use
| are garbage. I don 't fault the tech for that, although I
| suspect that a lot of those SPAs were created by "me too"
| people that just wanted to build a SPA. When React was in the
| pre 1.0 days, I did that, and several people on my team as
| well (so I'm not casting any stones here, just trying to
| state facts).
|
| Last time I bootstrapped a React SPA I don't think cra
| includes a router ootb.
| simonw wrote:
| "A website has to go out of its way to mess this up."
|
| I know it's supposed to be easier, but I keep seeing teams
| mess this up.
| WhitneyLand wrote:
| All of your benefits seem to come from using only rest APIs
| to drive to site. That alone can be done with any site, but
| SPA usually implies more.
| krisrm wrote:
| I always thought of the benefits of SPAs more as a separation-
| of-concerns thing. You can pretty effectively build a
| functional front-end web application and mock a set of back-end
| REST apis, while another team builds out a the back-end. There
| are absolutely tradeoffs, and being a good software engineer is
| about understanding where and when those tradeoffs apply.
| ar_lan wrote:
| That's not really unique to SPAs, right?
|
| I don't know much about front-end development but I imagine
| you can create a front-end that is both not an SPA, and not
| server-rendered.
| krisrm wrote:
| It's not about being unique, or what you can/can't do. You
| certainly can mock a front end with a ssr app, but it gets
| messy when you are building a rich client app and need to
| start sharing state back and forth.
| simonw wrote:
| That's definitely true at the organizational level, and it's
| an argument with some merits.
|
| In practice though, I've seen this backfire. You end up with
| the frontend team blocked because the API they need isn't
| available yet, and then the backend team gets blocked because
| they shipped the API but they can't use it to deliver value
| because the frontend team don't have the capacity to build
| the interface for it!
|
| My preference is to work on mixed-skll teams that can ship a
| feature independently of any other team. I really like the
| way Basecamp describe this in their handbook:
| https://github.com/basecamp/handbook/blob/master/how-we-
| work... - "In self-sufficient, independent teams".
| ngcazz wrote:
| that sounds like a mismatch between the architecture and
| how work is getting planned no? if the backend is in the
| critical path to delivering the user value of a feature
| then the backend and frontend engineers need to be
| developing (and testing) the feature together
| lazide wrote:
| They ALWAYS need to be building and developing the
| feature together or this happens. Decent API design
| without deep understanding of Client implementation or
| performance needs is nearly impossible.
|
| They generally should all be in the same team, but that
| often doesn't scale.
|
| Not having them in the same team pretty much never works
| well though either.
| evanweaver wrote:
| I know people for whom the traditional way of building a web
| app is completely foreign. I am curious how you would describe
| the concept and tools to someone who has never encountered them
| before outside an SPA architecture.
| craigkerstiens wrote:
| Hi Simon, why'd you pull me in ;)
|
| We recently went a rewrite of our frontend for
| https://www.crunchybridge.com from SPA to more "basic" request
| response app and couldn't be happier. Previously was SPA with
| React and we rebuilt from scratch with request/response using
| Node. In places we still leverage react components for re-
| usable frontend bits, but no more SPA and state management.
|
| As you've mentioned in some of your other threads on this, the
| state management and sync between the API team and the front
| end team just caused velocity to slow down. It took longer to
| ship even the most basic things. While we want a clean and
| polished experience, the SPA approach didn't really accomplish
| any of that for us.
|
| The rewrite was under 8 weeks of an app that had been built up
| over a couple years and we quickly recouped all that time in
| our new found velocity.
| Graffur wrote:
| That just sounds like poor performing developers to me. You
| don't need snazzy animations between states. Just not reloading
| the full page is a benefit.
| wooque wrote:
| I, as a user, hate them with passion.
|
| I regularly stumble upon stale data in SPAs, even in big names'
| like Linkedin, Jira, Github, etc. I wonder how the hell
| corporations with thousands of engineers, lot of them being
| brightest engineers in the world, can't make proper SPA.
|
| Can we just go back to server side rendered pages, with a bit of
| JS sprinkled in, please.
| Jcampuzano2 wrote:
| Interesting that you use Github as an example, when Github is
| not an SPA. So basically just admitting these problems aren't
| necessarily inherent to SPA's, but to the developers/teams
| building them. They may just be a bit harder to get right in
| SPA's.
| tmcw wrote:
| Github is not an SPA. They use the middle road of dynamically
| loading HTML snippets, using webcomponents, and lightweight
| JavaScript. Any problems you see with most of Github's
| interface should be chalked up to server-rendered pages with
| sprinkled JS.
| deergomoo wrote:
| > Github
|
| GitHub is a great example of a site that would benefit from
| actually being an SPA, imo. It _is_ server rendered pages with
| JS sprinkled in, and you can easily end up in the situation
| where parts that live update fall out of sync with parts that
| don 't. For example, being able to see that an issue is closed
| while the badge on the Issues tab still says you have one open.
|
| I share your general sentiment over the state of them though.
| It's not actually that hard to avoid breaking navigation
| buttons, having links open in new tabs correctly etc, so I
| don't know how it gets screwed up so much.
| jdrc wrote:
| the frustrating thing is that i rarely find a page that doesnt
| take at least 20 seconds to load, even if i only want to see an
| 100x100 image. This happens no matter how fast computer i use and
| it 's despairing
|
| The term "server-side rendering" gives me giggles every time
| shroompasta wrote:
| It's posts like these where I can feel the age of HN.
|
| For many developers, especially in startups, SPAs are all they've
| ever known.
|
| Now, I'm relatively young, but I'm old enough to know monolithic
| django before moving onto angular then onto react, and it is
| quite staggering what I'm capable of doing in SPAs as opposed to
| traditional web pages.
|
| You mentioned Soundcloud and Youtube, but you'd be lying to
| yourself if you think the list comes even close to even stopping
| there.
|
| How about fantasy drafts in DraftKings, Sleeper, or FanDuel?
|
| How about chess like chess.com or lichess?
|
| How about collab tools like Trello, Monday, or Asana?
|
| I wouldn't even dream of building these types of applications in
| a traditional web app
|
| The level of interactivity that is capable within SPAs makes
| applications like these seamless and snappy, and overall feel-
| good for the user.
| mattlondon wrote:
| Most of that navigation stuff is long-solved - e.g. Angular's
| router will do a lot of that.
|
| If you want to do a SPA without a modern library, then yes you
| will need to reimplement a bunch of stuff. But who would start
| from scratch? Unless you are doing something incredibly niche or
| tiny-tiny-tiny, just use Angular or React or whatever and don't
| worry about the minutiae.
|
| Of course there will now be people screaming at their screen
| about how this attitude is everything that is wrong with the
| modern web etc. I am sure they'll get over it one day, or just go
| use gopher/Gemini if not.
| teilo wrote:
| Use them where they make sense, and don't get religious about it.
|
| I recently wrote a site to track Apple-silicon-native audio
| software. It works great as an MPA. It's fast, organized, and
| easy to use.
|
| And the first thing someone offered as a suggestion was: "Why
| don't you use https://www.sanity.io/ for the content and nextjs
| or gatsbyjs for the front end?"
|
| I can't even.
| winslett wrote:
| SPA's #1 draw back is that you have to rebuild browser
| functionality inside of the browser.
|
| The browser natively handles internet connectivity, back /
| forward buttons, refresh buttons, URL management. Additionally,
| users have been trained to understand the responses, hit the
| refresh button, and use the back button. Browsers have gotten
| better at distinguishing between your internet being down and the
| website being down.
|
| Good SPAs have to rebuild all of that functionality.
| Zaskoda wrote:
| In my humble opinion, SPAs are not the fundamental mistakes. SPAs
| are applications. There's nothing wrong with having applications.
| The mistake was not maintaining a distinction between
| applications and content. The difference between a static
| document, a collection of hypertext documents, and a web
| application is very blurry. If it were less blurry, there would
| have been things we would have been able to do that we are not
| currently able to do.
| gherkinnn wrote:
| Most major frameworks do that. Barring some devs who navigate
| using onClick over a link despite having that option.
|
| Outside of some lasting mistakes made a decade ago, is this still
| an issue?
|
| On top of that, "SPA" is a misnomer, as many frameworks give you
| a hybrid anyway.
| udbhavs wrote:
| I don't know why routing is the sole focus of the article. In
| all my SPAs it has been a set up once and forget about it deal.
| No one is constantly reinventing the wheel there, the churn is
| in other areas like reactivity and state management.
| barrenko wrote:
| Zanfa wrote:
| I think one of the unsolved problems of client-side interactivity
| on websites is how difficult it is to add it just _a little bit_
| of extra client-side functionality to a traditional server
| rendered website. For example, recently I had to deal with photo
| uploads on a Rails app, which works fine out of the box at first,
| until you want to show progress bars and uploaded previews etc.
| Then you add a couple of client-side Stimulus controllers, maybe
| a Turbo frame here and there and it works, but then you get to
| browser navigation and you 're screwed, because none of this
| works if somebody were to submit the form, then navigate back.
| Now you have to implement lifecycle handling to account for
| navigation and once you're done, you've basically implemented a
| SPA, except it's broken into a mix of tightly-coupled Javascript,
| Ruby and ERB templates.
| beaconstudios wrote:
| Progressive enhancement was largely solved before SPAs became a
| thing. Its quite easy to enhance the client side incrementally,
| but SPAs started out as useful for full on Web apps and now
| everybody uses them by default for some reason.
| garyrob wrote:
| "I think one of the unsolved problems of client-side
| interactivity on websites is how difficult it is to add it just
| a little bit of extra client-side functionality to a
| traditional server rendered website. " I've started using
| django-unicorn lately and I'm hopeful that it may solve that
| problem for many use-cases.
| kaba0 wrote:
| It was probably never too beautiful of a technique, but JSF
| does solve this problem splendidly. You basically have a view-
| flow besides the usual ones and it can act in many of the ways
| SPAs can.
| CPLX wrote:
| Yeah can someone fix this please. I'm experiencing the same
| thing with a rails app I'm currently building.
|
| In all seriousness it feels like there must be an elegant way
| to do more responsive modern functions while keeping the core
| server rendering concept. It's 2022 after all. But no I don't
| know a good solution either.
| ysavir wrote:
| > Then you add a couple of client-side Stimulus controllers,
| maybe a Turbo frame here and there and it works fine, but then
| you get to browser navigation and you're screwed, because none
| of this works out of the box if somebody were to submit the
| form, then navigate back. Now you have to implement lifecycle
| handling to account for navigation and once you're done, you've
| basically implemented a SPA, except it's broken into a mix of
| tightly-coupled Javascript, Ruby and ERB templates.
|
| Where in this process did you need to start adding navigation
| via JS? Did that functionality _really_ require JS, or was it
| implemented that way just because other parts are JS, and the
| trend was continued? Could you have used Stimulus controllers
| to manage functionality on the page itself, but when it came
| time to navigate to a new page, just done a basic browser
| redirect?
|
| Saying that SPAs is a mistake doesn't mean that a strong
| dependence on JS or frameworks in a mistake. It just means that
| trying to make an entire site fit into a single page load
| introduces more costs than savings. You can still have pages
| controlled via React or Vue or Stimulus, but forgoing the
| router functionality.
|
| In my own apps, I use Vue and VueX to control page behaviors,
| but each URL is its own Rails page. For example, I have a
| search page that uses Vue and VueX to asynchronously load,
| filter, and display search results. Clicking on a result is a
| basic browser redirect, taking you to the result's page, doing
| a full Rails page load, and again using Vue and VueX to manage
| any dynamic state (any static content is rendered via ERB
| files).
|
| This has created a very clear and simple structure that allows
| each page to have any dynamic functionality it needs, but no
| complications from having to maintain navigation or browser
| history via JS. The browser already does that natively, and I
| get to spend my time working only on actual features--not
| recreating the browser's built-in functionality, or debugging
| my own take on it.
| Zanfa wrote:
| > Where in this process did you need to start adding
| navigation via JS? Did that functionality really require JS,
| or was it implemented that way just because other parts are
| JS, and the trend was continued? Could you have used Stimulus
| controllers to manage functionality on the page itself, but
| when it came time to navigate to a new page, just done a
| basic browser redirect?
|
| In my specific example, the navigation itself didn't happen
| through JS, but you need to hook into navigation APIs to
| handle backing into a partially-filled form after submitting
| to rebuild the UI to reflect the state before the user hit
| submit. To make things even more fun, Turbo/Stimulus
| (sometimes?) breaks bfcache in Safari & Firefox so they
| behave different from Chrome.
|
| Personally, I detest the vast majority of SPAs, especially
| the ones from Google, Facebook and Linkedin. Not even sure
| what they do to make them so horribly slow to use.
| ysavir wrote:
| Thanks for sharing! That helps me understand things better.
|
| > you need to hook into navigation APIs to handle backing
| into a partially-filled form after submitting to rebuild
| the UI to reflect the state before the user hit submit
|
| Was this a hard requirement for the feature or just a nice-
| to-have? I understand why you'd want that behavior ideally,
| but it also seems the sort of thing that adds much
| additional complexity for a problem that isn't (at least in
| my eyes) severe. Having people re-fill things isn't too
| much of an ask, I think, and if it's something crucial, it
| might be better served with a preview page that allows
| additional changes. Or a "Make changes" link that redirects
| to a page that can load from the submitted state. There are
| easier ways to handle it than manually controlling
| navigation.
|
| But yeah. If the behavior is a hard requirement from the
| business/product side of things, then using an SPA is no
| longer an architectural decision made for technological
| purposes, but is a feature requirement from beyond. And
| that's a whole different matter.
| Zanfa wrote:
| A little bit of both probably. Supporting it when
| navigating back is probably a nice-to-have, but
| persisting file upload previews etc through a form submit
| that might fail due to some unrelated ActiveRecord
| validation (maybe a blank field) is a must.
| timr wrote:
| > In my specific example, the navigation itself didn't
| happen through JS, but you need to hook into navigation
| APIs to handle backing into a partially-filled form after
| submitting to rebuild the UI to reflect the state before
| the user hit submit.
|
| I'm not sure I understand. The "conventional" solution to
| this is not to do it -- the reason browsers don't re-fill
| submitted forms is to prevent duplication. Give users the
| ability to post-backclick-repost and your DB will rapidly
| fill up with duplicate rows.
|
| If you do need to back-navigate to a page that has been
| submitted (say, to edit the submission w/o requiring an
| edit-specific URL), you have the server re-render the form
| with the filled values.
|
| If _that_ isn 't sufficient, you can always push your form
| state on the history stack using the history API, so even
| though this is a bad idea (IMO), you can still do it pretty
| easily without needing to resort to re-writing nav.
|
| I hate to say it, but I feel like a lot of this stuff had
| server-side solutions that _worked fine_ circa 2010, but
| have been almost completely forgotten.
| fuzzy2 wrote:
| But browsers absolutely do keep the form filled unless
| your HTML or JS says otherwise. Pressing back after
| submitting on a vanilla HTML form keeps all values in
| place. As it should.
| timr wrote:
| Not after a post. If you change the form method to get, I
| believe this is the behavior.
|
| There are tons of good reasons to prefer this behavior,
| aside from just avoiding duplicates. Think of login
| forms.
| fuzzy2 wrote:
| Yes, even after POST. Why not try it, right here, on
| Hacker News. The comment form uses POST. I post this
| comment and go back and my text is still in the input
| box.
|
| In fact, browsers even have re-submit built-in: Just
| press F5 on a page that was retrieved using POST. That's
| why so many sites use a redirect after POST.
| [deleted]
| timr wrote:
| Redirect after POST was a pattern created to bypass the
| warnings that (most) browsers emit on back-navigating
| after form submit, while still preventing double-submit
| (by redirecting to the GET):
|
| https://www.theserverside.com/news/1365146/Redirect-
| After-Po...
|
| It sounds like this warn-on-double-submit behavior is
| convention and not required, so maybe it has become more
| common for browsers to stop doing it.
|
| > Why not try it, right here, on Hacker News.
|
| OK, I did. HN does a 302 redirect on comment POST to the
| comment GET. When you back nav, you are seeing the
| response to a GET request to /reply?id=X
|
| (In other words, the form is re-rendered.)
|
| Edit: oddly, however, submitting on form rendered by GET
| /reply?id=X ends up creating a _new_ comment, so that 's
| just weird server logic. It might explain why you
| occasionally see duplicate comments on HN.
|
| Edit 2: _on backnav to a comment edit_ , the redirect is
| to GET /edit?id=X, which is a re-render of the edit form,
| the process I described in my OP. Not sure what's going
| on with the back-after-post...maybe a bug?
| fuzzy2 wrote:
| > When you back nav, you are seeing the response to a GET
| request to /reply?id=BLAH
|
| With the text you previously entered, which the browser
| restored. If it did not for you, you have non-standard
| settings like disabled caching. I can assure you that it
| behaves the same on Firefox for Linux, Windows, macOS and
| Safari on iOS: go back, form content is restored.
|
| In fact, the entire internet is full of people trying to
| get rid of this behavior.
| rk06 wrote:
| for simple cases, you can use alpine.js, petite-vue etc.
| However, if you are considering "routing", then it is no longer
| a "little bit".
| hombre_fatal wrote:
| Exactly. I've been in the position various times where I'm
| embedding a JS app on a page to help the user do something
| highly interactive, usually creating/editing content. And then
| as it's expanding to integrate with other things on the site, I
| start to wish more of the site was in the JS-app side of
| things.
|
| Sometimes I realize a SPA would have simply served the user
| better, and it doesn't necessarily take much to be in that
| predicament.
|
| Too many people hate on SPAs by, presumably, just imagining
| static read-only content like blogs and news. Though I'm also a
| bit tired of "SPAs suck amirite, HN?"
|
| Put the user first, consider the trade-offs that work towards
| that goal, and see what shakes out.
| michaelchisari wrote:
| Setting limits for future features to keep the code base
| clean and manageable is something developers could be more
| vocal about.
|
| Acquiescing to every demand product designers and management
| throw into the mix is what turns beautiful, easily-maintained
| codebases into nightmares.
|
| What people are talking about here is writing web apps as a
| series of small, tightly-coupled spas who manage state within
| very specific parameters. And that's a great way to build
| software. Until someone comes in and asks you to draw in the
| state from one section into two other sections. You have the
| choice to say a) no and explain why, to b) create a clever
| "glue" that will be hard to maintain and difficult to
| explain, or to c) take the time to refactor the code into
| something more general and complex to allow for the feature
| on a more abstract level.
|
| Guess which one almost always gets chosen.
|
| The upshot is this: The solution to front-end complexity may
| not be a technical one, it may not require a new framework or
| library. It may be a shift in what we expect out of the web.
| We could always temper our expectations in order to keep our
| code clean.
| themanmaran wrote:
| The end goal of writing code isn't always a "clean and
| manageable" codebase.
|
| Likewise the solution to SPAs isn't "say no to features".
| michaelchisari wrote:
| I'm aware, but the discussion about the failures of spas
| always center around their failures in maintainable code.
| So if one's issues with SPAs are codebases becoming
| unmanageable, the solution won't be technical, it's going
| to be managerial.
|
| A start would be devs communicating to product & design
| what the technical limits are to the current approach so
| that it informs their decisions.
| 9wzYQbTYsAIc wrote:
| > Exactly. I've been in the position various times
|
| This is why React is such a popular JavaScript framework of
| libraries.
| Closi wrote:
| I think the fundamental issue with SPAs is that it's building
| on multiple levels of technology that fundamentally weren't
| designed to support being a single page application.
|
| The browser <-> multiple pages paradigm is pretty much how
| the web evolved, so SPA's just end up being one giant hack to
| get everything working.
|
| UWP/WPF/any other desktop app framework demonstrates how easy
| developing a 'single page application' can be without all the
| cruft you have to add to make a SPA work because it's
| actually a sort-of-massive-workaround.
| hombre_fatal wrote:
| Well, the browser has certainly evolved past the point of
| SPAs being nothing but a hack. The browser has evolved into
| a heavily generalized application environment, as much as
| we may want to bemoan that. A good web client can surely
| demonstrate this.
|
| It's certainly true that you don't get to lean on built-in
| features like history support, but that's why you can now
| drive history with Javascript. And all sorts of other
| things. And if you're smart, you're using a solution that
| handles these things for you.
|
| Rich client development is always hard--on any platform--,
| and you always make concessions for the platform you're on.
| I certainly have to when I'm building iOS apps. But I see
| no reason for this to dissuade you if you can push a better
| UX to the user.
|
| As tried-and-true as server-rendered architecture might be,
| there are all sorts of things it will never be able to do
| no matter how much of a hack you think web client
| development might be. Software is a hack. And at the end of
| the day, your users may remain unconvinced when you preach
| about what the browser was "meant to do" when they begin
| coveting a richer experience.
|
| That's something that's often left by the wayside when we
| discuss these things. We talk about technical superiority
| and become prescriptive about what we think technology is
| for. While fun thought exercises as craftspeople, we too
| seldom talk about delivering value. If leaning into the
| historical nature of the browser supporting HTML pages over
| the wire helps you build a better experience, that's great.
| But that's not the only option you have today.
| kitsunesoba wrote:
| > Rich client development is always hard--on any
| platform--, and you always make concessions for the
| platform you're on. I certainly have to when I'm building
| iOS apps. But I see no reason for this to dissuade you if
| you can push a better UX to the user.
|
| I think the difference is how much you as a developer
| have to "fight" the platform. Having to implement history
| management yourself very much qualifies as "fighting" to
| some extent in my eyes... continuing with native
| platforms as an example, that sort of thing just isn't
| necessary in most cases - like with iOS, 99% of your
| "history" management comes for free with some combination
| of UINavigationController and view controller
| presentation, assuming the use of UIKit.
| somishere wrote:
| History management in handled by the browser in SPAs /
| javascript land too. Apologies if I misread the
| insinuation here.
| [deleted]
| emteycz wrote:
| At least since HTML5 and CSS3 and ES6 (so many years
| already) these technologies _are made_ for SPAs. There aren
| 't many better UI frameworks, and WPF isn't that by a long
| shot.
| sitzkrieg wrote:
| ok dont look up how long grid layout has existed in wpf
| emteycz wrote:
| Who cares? (I know btw I used to be a C# engineer in my
| previous life - I actually first used WPF when it was
| still beta)
|
| Here and now, WPF is much worse. Even Microsoft itself
| now invests into React Native.
| mananaysiempre wrote:
| I mean, grid layout has existed in Tk (the one with the
| Motif look) since the earliest version I can quickly find
| documentation for, 8.2 from August 1999; Wikipedia tells
| me that 'table', apparently an early version of 'grid',
| was introduced in July 1993, that is to say around the
| time Windows NT (and with it Win32) was officially
| released. (And of course plain Win32 never got it,
| seemingly because Microsoft decided they weren't in the
| business of selling toolkits despite USER being one.)
|
| The hard idea from the programmer's point of view is
| automatic layout, not grids; my impression was that Tk
| originated it (it certainly brought it to light), but now
| that I'm looking I'm not sure it wasn't already in Motif
| to some extent, so the roots of the idea might go down
| into the primordial soup of Project Athena and similar
| places.
| efdee wrote:
| In my opinion, UWP/WPF/aodaf makes it easy because it just
| doesn't implement the things a user is used to in a browser
| (bookmarkability, back button, ...).
|
| If you ignore those things in your SPA, much of the "cruft"
| is negligible.
| kaba0 wrote:
| This is pretty in line with grandparent's comment in that
| the browser was simply not made for this - aka SPAs are
| sort of a hack on the traditional page-based approach.
| mike_hearn wrote:
| Many desktop apps have back buttons, and of course mobile
| apps always have them. They're also more reliable; there
| is no desktop/mobile equivalent of the "warning: need to
| re-POST this form" problem.
|
| As for bookmarks, that's semi-right, but the web platform
| conflates the back button with bookmark-ability in ways
| that are quite confusing. If you want the back button to
| get the user out of your settings screen, then you must
| push a new URL onto the history stack using JavaScript,
| but then if the user bookmarks your site they'll bookmark
| the settings screen specifically even though that's very
| unlikely to be what they wanted. Non-web apps that have
| enough content to need something like bookmarks often
| implement a similar mechanism that's more predictable,
| albeit less general.
|
| The OPs article is really a common lament amongst web
| developers - they're (ab)using a tool that was never
| meant for what they're using it for. It's a real and very
| serious problem in our industry.
|
| The whole SPA vs multi-page dichotomy really emerges
| because the web doesn't have sufficiently rich, modular
| or low level APIs. If you look at non-web frameworks like
| iOS or Java then you get a huge number of APIs (usually
| classes) tackling the low levels of a problem, then more
| classes building on the lower levels to give you higher
| level solutions. Those classes can usually be customized
| in many different ways, so the amount of control a
| developer has is enormous. If you start with a high level
| helper class and find you can't customize it to meet your
| needs, you can reimplement it using the lower level
| building blocks.
|
| The web isn't like this. Web APIs are an absolute pigs
| ear of very high level function calls and classes
| designed in more or less random ways to quickly hack
| together a solution to whatever need a browser maker had
| at the time. HTML5 supports peer-to-peer video streaming
| and augmented reality but not a virtualized table view.
| In many cases it's obvious that little or no thought went
| into the APIs, e.g. XMLHTTPRequest has nothing to do with
| XML, you can open a URL for a custom URL handler but not
| detect if that URL will work ahead of time, nor even if
| opening that URL worked once you try it, and so on.
| Instead of starting with low level APIs and composing
| them into high level APIs, browsers start with high level
| APIs and then introduce entirely orthogonal low level
| APIs decades later, or never.
|
| These sorts of problems just don't occur when writing
| desktop apps with professionally designed frameworks -
| even in the rare cases that you hit some limit of the
| framework, you can (these days) just patch it directly
| and ship a fixed version with your app. If you hit a
| problem in the browser you're just SOL and have to hack
| around it.
|
| Our industry needs to reinvigorate desktop apps.
| Attempting to convert browsers into Qt/Java/.NET
| competitors has:
|
| a. Made HTML5 unimplementable, even by Microsoft. It's
| not so much a spec anymore as a guide to whatever Chrome
| happens to do on the day you read it (hopefully).
|
| b. Created tons of security holes.
|
| c. Yielded an atrocious and steadily decaying developer
| experience.
| vlunkr wrote:
| The other thing people who hate SPAs need to think about is
| that rendering blogs/news/static sites isn't a problem that
| developers really work on anymore. Businesses will just pick
| from the huge pile of existing CMSs or hosted solutions
| because it's easier and cheaper. So if you're wondering why
| all these developers are building SPAs, it's because we're
| building custom applications, not blogs.
| mattwad wrote:
| I feel like most people that hate SPAs never have to deal with
| this type of thing, or even only have to work on the backend.
| They just don't get it. Of course, if you're using a SPA for a
| static website, you're also doing it wrong but that doesn't
| mean SPA itself is a bad thing.
| simonw wrote:
| "They just don't get it"
|
| Believe me, I get it.
|
| I dealt with building these kinds of features for a full
| decade before SPAs became fashionable.
|
| Now I'm stuck here watching in frustration as people go all-
| in on SPAs because they didn't know how to solve these
| problems without them.
| rosenjcb wrote:
| I agree. These people hating on SPAs are mostly not frontend
| developers. They're backend devs that think returning an HTML
| page is all you need to do. Modern websites are very complex.
| WillPostForFood wrote:
| Or users who hate watching a whole application load to
| display some text.
| rosenjcb wrote:
| If the only purpose of your site is to load some text or
| an image, go use a framework with SSG like NextJS. Then
| you get fast websites without having to pretend that
| writing stateful updates (e.g. jQuery) to the DOM is fun.
| zippergz wrote:
| I'm living proof that it is possible to simultaneously hate
| SPAs and understand why they are popular. I've built and
| worked on a number of them, I don't have a better alternative
| to recommend, and yet I still hate them because I think they
| are a clunky solution to the problem. We need something
| better, but I'm not smart enough to come up with what that
| should be.
| kitsunesoba wrote:
| I don't think I'm any more smart when it comes to this
| particular issue, but my thought is that the answer
| probably has something to do with more primitives that are
| suited for web applications being provided by web browsers,
| so it's both easier to build a web app without some huge
| gangly framework and so frameworks have more to build on
| top of and less manual footwork introducing room for error.
| [deleted]
| embwbam wrote:
| I agree. I've been thinking about this lately, and have
| implemented something I think is interesting in Haskell.
|
| https://github.com/seanhess/juniper
|
| It's an implementation of Elm (imagine React if you're a JS
| dev), but all logic is executed on the server. State is passed
| back to the server whenever you choose to listen to an event.
| The view is then re-rendered and virtual dom diffed on the
| client. Non-interactive pages are just views. If you want them
| to be interactive, you add a Message an update function.
|
| I used it on a client project and it was pretty delightful.
|
| It probably isn't documented well enough yet to make total
| sense, but I think it's a step in the right direction.
| simonw wrote:
| This is what jQuery solved. It made it ridiculously easy
| (compared to not using jQuery at that time) to add a little
| sprinkle of progressively enhanced JavaScript to a page. It
| still works today (and you don't even need jQuery now, as
| browser standards have mostly caught up), but everyone seems to
| have forgotten how to do it!
| MourningWood wrote:
| teach me :)
| adfm wrote:
| HTMX lets you update the url with hx-push-url="true"
| jmconfuzeus wrote:
| Progress bars and previews are simply a matter of attaching an
| events to the http request and file input respectively.
|
| When someone submits a form and navigates back, don't you just
| re-display the empty form?
|
| If it needs to be a form bounded with the uploaded file (maybe
| as part of a wizard), then why not ask the server for it
| instead of storing client side state?
|
| Maybe using Javascript without a SPA looks hard because you're
| trying to avoid storing state on the server as well as bypass
| native browser features.
| pvorb wrote:
| Did you have a look at https://htmx.org/ ? I think it solves
| the "just a tiny bit of interactivity on an MPA" kind of thing.
| thr0wawayf00 wrote:
| This is my biggest gripe with the direction of Rails.
|
| I completely understand the historic reasons for wanting to
| keep JS to a minimum and stay within ERB/Ruby, but the JS
| component-driven UI pattern feels like the correct front end
| architecture for most commercial projects these days,
| especially now with better JS tools like Svelte, which feels
| like rails for the front end to me.
|
| I started playing around with InertiaJS recently and I
| absolutely fell in love with it. I was surprised to see how
| niche it still is because it's pretty much what I've dreamed
| what writing JS with Rails could be for the last 5 years.
| xwdv wrote:
| This problem you described is exactly why SPAs will continue to
| dominate over the traditional server rendered websites.
|
| Often when I see people arguing against SPAs, they are peddling
| trivial toy websites that don't do much and don't change much.
|
| When you need to build a serious application on the web with
| quickly growing feature sets and complex state management, just
| use a SPA. It's 2022.
| jmconfuzeus wrote:
| The Basecamp guys created Hey which is a mail app not
| implemented as a SPA. It's probably the fastest mail app I've
| ever seen while delivering around 40kb of javascript.
|
| If Hey is a toy app you then you must be working on some
| truly alien projects from the future or something.
| mdoms wrote:
| At the risk of a pile on, this is what jQuery was brilliant
| for. And frankly the native browser APIs have caught up enough
| that scenarios like what you want to achieve are simple to
| implement with just a script tag and a sprinkling of JS. I
| don't know what "Stimulus controllers" or "Turbo frames" are
| but they don't sound necessary.
| specialp wrote:
| Yes. Nobody should have to make a SPA to accomplish what
| JQuery did with sprinklings of JavaScript. JQuery was
| maligned because many people used it to make all XHR requests
| all over the place resulting in non-deterministic async
| behavior. JQuery was made to make adding small bits of JS
| easy and work in almost all browsers.
|
| Bringing in React and turning that non-deterministic events
| firing all over the place greatly improved that situation,
| but this has become if someone needs JS, bring in SPA
| framework. This is in spite of the browser world getting much
| better. So just as JQuery was used to make SPAs to bad
| effect, SPA frameworks have been used to do minimal JS
| actions in a bad way.
| te_chris wrote:
| Phoenix LiveView really does solve a lot of these problems.
| ordinaryradical wrote:
| I was just going to say this sounds like a great example of
| something that Elixir, LiveView, plus maybe a little
| Alpine.js could handle...
| myfavoritedog wrote:
| alskdjflaskjdhf wrote:
| Inertia [1] is an interesting project in this space that might
| solve some of your problems. I haven't used it, but I believe
| the general goal is to make it easy to "plug in" client-side
| frameworks (React, Vue, Svelte) into server-side views.
|
| [1] https://inertiajs.com/
| amelius wrote:
| Yes. The fitness of an architecture can be partially measured
| by looking at the cost of feature updates.
| dlisboa wrote:
| The problem is the mixing and matching of state management. In
| a traditional web app all of the state is in the back end, in a
| SPA all of the state is in the front end. When we share state
| in between the two it's often messy.
|
| To me the answer feels like it should be "traditional web app
| for most things, components-as-first-intended for some things".
| The simplest React example is just one component that abstracts
| presentation and logic. The only state is its own. It does not
| handle an entire web app as a SPA, no Redux, prop drilling,
| it's just the idea of a reusable component as an HTML tag. Same
| with VueJS and all. If we restrict ourselves to that we're in
| the good path.
|
| If there was already an HTML tag for your own specific problem,
| wouldn't you just use it in your traditional server-rendered
| app? A `<photo-upload url="/photos">` tag that does exactly
| what you want. Or a `<wizard pages=5 logic="com.domain">` tag.
| We should create just those components, either in
| React/VueJS/Whatever or in vanilla JS Web Components, and live
| with the rest as we used to.
|
| We're basically saying that some parts of our apps are too
| difficult to mix and match state management, and we should
| offload all of the state to one of the two sides. In some rare
| apps indeed all of the state should be on the front end, but
| the use cases for that are just not as big as they're made out
| to be.
| ithrow wrote:
| Agree, we just add React components here and there to server-
| side rendered HTML and it works great for us. The issue is
| most companies want separate teams for front-end and back-end
| and each team wants clear separation of boundaries and
| responsibilities between them.
| beebeepka wrote:
| Adding components here and there sounds like a simple app.
| Nothing wrong with that, if course.
|
| Different teams exist for a reason. I've deeply regretted
| working in "we have real Devs that can do it all"
| environments.
|
| It's not so much about boundaries as it is about
| competence. Or lack of it with
| [deleted]
| jkcxn wrote:
| Yes this is exactly right. What I've done in the past is use
| Django to return HTML with JSX mixed in, and have a super
| lightweight SPA frontend that just hydrates the react
| components on each load. You can also use form state to
| communicate back and forth with the server, where sending a
| response doesn't refresh the entire page, just a react render
| diff. With this you get the best of both worlds where your
| backend can do the heavy lifting where everything it needs to
| decide on the view is all in one place, and your frontend
| just comprises of really really generic JS components.
|
| I have a library I've been playing around with for 2 years
| now, I should package it up
| prmph wrote:
| Exactly, the best approach seems to be where the app is
| composed of traditional pages with server navigation between
| them, but each page is implemented as an SPA.
|
| This approach eliminates the need for a client-side router,
| keeps any centralized page state small, and improves the SEO
| and bookmarkability of the app.
|
| I have implemented this architecture in several projects, and
| it's effective
| trevex wrote:
| Isn't this basically what NextJS and NuxtJS provide, if you
| only leverage their static rendering?
| [deleted]
| hughrr wrote:
| The correct answer for this stuff, and it absolutely kills
| me saying this, is probably something like asp.net web
| forms.
| manigandham wrote:
| Why does it kill you to say that? It's the better and
| more productive option.
| hughrr wrote:
| Because I abandoned it thinking it was terrible. Then I
| spent a decade finding out how bad everything else was.
| chrisweekly wrote:
| Please, go learn about Remix (https://remix.run), it is
| the actual correct answer for this stuff.
| pphysch wrote:
| I don't understand why they choose an example -- a simple
| user dashboard -- that could be easily implemented as a
| traditional MPA. It seems like Remix is mainly for the "I
| learned to program with SPAs" audience.
| mattmanser wrote:
| Asp.net web forms absolutely sucked. They fundamentally
| misunderstood HTML and how the internet even worked.
|
| Modern Razor's pretty good (not Razor Pages, they also
| suck) which is probably what you mean.
|
| But it's not that much different from Rails, Laravel,
| Django, etc.
| hughrr wrote:
| Yes I mean the original version of it.
|
| I'd love to watch people attempt to implement some of the
| stuff I pulled off with that back in the day now.
| Occasionally, very complex data driven page flows are
| required and you could nail that entire problem domain
| trivially with them.
|
| There is a very large and well known company with a
| front-facing product used by millions of people which
| took 5 years pissing around with three different front
| end technologies to reimplement what we did in 3 months
| with that and it was slower and heavier and basically
| reimplemented web forms in python in the end.
|
| It broke the the www intentionally because it sucked. And
| it still does.
| manigandham wrote:
| What's wrong with razor pages? They're fantastically
| simple and productive.
|
| And WebForms wasn't a misunderstanding. It was a
| deliberate and brilliant design that brought WinForm
| developers and their experience to the web and allowed
| them to build complex web apps two decades ago that still
| work to this day.
| zerkten wrote:
| It's contextual. For me, WebForms fell down because it
| let the average web developer impose too many "costs" on
| internet-facing projects. A WinForms developer is a very
| specific kind of developer with a high focus on
| development of internal, or line-of-business (LOB) apps.
| WebForms also excelled at this, but brought more reach as
| people moved away from a preference for desktop apps.
|
| The height of WebForms coincided with an embrace of web
| standards and accessibility which flows into the Web 2.0
| era. You had to jump through a lot of hoops to achieve
| what was needed WebForms to get it to behave in a web-
| friendly way. The underlying .NET framework and base of
| ASP.NET (HttpHandler and HttpModule) was outstanding
| though.
|
| (I still build/maintain WinForms, ASP.NET, and WPF apps.)
| UglyToad wrote:
| Yeah, as much pain as it has caused me in the past I
| think the crucial realization Microsoft made with
| Webforms and maybe Blazor is that the stateless model of
| web is fairly crap if you are doing anything beyond
| displaying static text.
|
| For its time it was some cool tech.
| dlisboa wrote:
| I disagree with that. There's no real reason for each page
| to be a separate SPA, most likely only a small part of that
| page will be interactive, and most of it will be cacheable.
| Extracting only the interactive parts of a page into
| components is what I'm talking about. In some cases that'll
| be all of the page, but there are very few apps that meet
| that criteria.
| prmph wrote:
| Of course if only a small part of your app is
| interactive, then SPAs don't come into the picture in the
| first place.
|
| My point is that for very interactive web apps, this is a
| significantly better architecture that a huge monolithic
| SPA
| LAC-Tech wrote:
| I mean in this model, if each page is an SPA, then the
| line between an SPA and an interactive page is very
| blurry.
| LAC-Tech wrote:
| I've had this thought experiment before, but where I get
| stuck is - what happens when you want to share state
| between the pages? URL params, storing to indexedDB,
| sticking them in global variables - all viable solutions
| but all with their own issues.
|
| I'd be very interested to hear how you solve this, or if
| it's less of an issue than people might think.
| SinParadise wrote:
| >app is composed of traditional pages with server
| navigation between them, but each page is implemented as an
| SPA.
|
| I agree with this because you affirm my bias.
|
| Also because I've also had success implementing this
| structure. This makes sure that state of each page doesn't
| leak everywhere, which simplifies the state management.
|
| It also loads faster than a big SPA because you don't have
| to worry about bundle splitting!
| WillPostForFood wrote:
| Do you lose performance because each page has to load the
| SPA?
| unfocussed_mike wrote:
| Not if the SPA subsequently takes over, (internally)
| routing links it recognises. (Nuxt does this)
| prmph wrote:
| Not much, if you use dynamic loading for heavy
| functionality that may not be used.
| khimaros wrote:
| this seems to be approximately what https://htmx.org/ is
| trying to accomplish.
| dlisboa wrote:
| HTMX goes about it in the wrong way, in my opinion. HTML
| code should not carry state and logic. The moment you need
| something a bit more complicated than the common examples
| you're in HTML-attribute soup trying to use a real
| programming language.
|
| It's better to just write that as a component in React or
| Svelte or whatever. It's more testable, easier to
| understand, can carry state and logic just fine. It does
| mean you have to communicate in JSON for a small part of
| your app, but that is reserved to a few well known
| endpoints and components like a complex form.
|
| The penalty is loading React or some other lib just for
| that, but if used in this way the extra dependency isn't
| really a big deal as it's not your whole app. Just use
| React as a library for components the browser doesn't
| already provide.
|
| And by components here I should really clarify as
| "affordances". A "primary" button isn't an affordance, the
| browser already gives you a button element and CSS classes
| (or HTML attribute) for that. It doesn't give you a "multi
| page wizard with immediate validation" affordance, however,
| so that's a good candidate for a component.
| pier25 wrote:
| I think the best solution for this is just doing fullstack dev
| with SSR + partial hydration.
|
| The issue is that, so far, we haven't figured out how to have a
| good fullstack DX.
|
| Remix is probably one of the best attempts so far, but it still
| leans heavily towards being a very sophisticated renderer for
| the front end. The proof is you probably would not use Remix to
| create a 100% backend project with no front end. Same with
| SvelteKit or Next.
|
| Until fullstack frameworks get more serious about the backend,
| we will be in this weird limbo.
|
| In my current project I use Fastify as my main backend
| framework, and then use Svelte for SSR + hydration. I loose a
| lot of the frontend sophistication that SvelteKit brings to the
| table, but OTOH I have an amazing backend framework and total
| control and flexibility.
| camjw wrote:
| I feel like react-rails (https://github.com/reactjs/react-
| rails) is basically perfect for this. You just make the photo
| upload its own react component and render it as normal from
| your rails view. You basically encapsulate the small bit of
| complex state into a component and it doesn't infect the rest
| of your app with SPA.
| cdelsolar wrote:
| no they weren't, stop with these clickbait bad takes
| clivestaples wrote:
| I think SPAs were the best solution we had at the time and I
| enjoyed trying to build good UX with them. Yes, React started
| fresh and ended up driving me back to Rails because I'm just not
| smart enough. That said, I am really excited about Django w/HTMX,
| Rails w/ Hotwire, and Next and Remix with React. Particularly
| Remix.
| hinkley wrote:
| I can get good at a lot of things, but most of them (including
| half the ones I'm good at) really just aren't worth my time and
| energy.
|
| Ain't nobody got time for that is more often closer to the
| mark. But anything that requires hypervigilance is eventually
| going to make you look dumb. Just don't let them put "human
| error" on the RCA. Yes, You screwed up, but We put you there in
| the first place.
| Jenk wrote:
| It should be obvious why SPA/PWA frameworks were developed by the
| likes of facebook and Google: Offloading their content rendering
| to the client.
|
| Instead of Google/Facebook CPU cycles being spent on rendering
| their content, it's now the client devices, while the
| Google/Facebook infrastructure is "just" serving the data.
| salt-thrower wrote:
| I'm sure the data that FB and Google are delivering is far more
| expensive than rendering HTML would be. I am skeptical that
| server side rendering was a big enough bottleneck for them for
| that to be their primary motivation. I'm also skeptical that
| SPA frameworks would have been widely adopted by developers all
| over the world if they were just some conspiratorial plot by
| tech companies to save on CPU cycles.
| jtsiskin wrote:
| This is completely inaccurate. Every millisecond of load time
| affects conversion so much that they would trade huge amounts
| of CPU to speed up a page load.
| hinkley wrote:
| First lead dev offered me advice for the rest of my career.
|
| Most of what you are going to see people argue about are
| cyclical fads. A pendulum. We try A and it doesn't work. So we
| try !A. And when people forget why we stopped doing A someone
| tries it again over and over.
|
| How are things different this time should be your second
| question. Your first question is what is the middle ground?
| Boolean logic falls on its face in the real world. If 1 is bad
| that doesn't mean 200 is better. If 200 was bad the solution is
| not 1. The best answer is probably three.
| pkilgore wrote:
| So I ran across a shit ton of your comments in this thread,
| like how you think, you should hit me up if you're ever
| hiring.
| AtlasBarfed wrote:
| The issue is you need some of both for an "optimal" solution.
|
| Unfortunately, Javascript and the basic "controller" capabilities
| of a web browser just aren't up to the task.
|
| Here are your "controller" options:
|
| 1) the server is the controller
|
| 2) the web page is the controller of itself (which sucks)
|
| When what is probably needed is:
|
| 3) a controller that lives as an extension of the browser.
|
| Frames, for all their issues, basically enabled #3. A controller
| frame could manipulate the view frames, and those frames were
| scoped/contained web page "processes". There were issues of
| course, if you hard-refreshed the overall page (and the
| "controller" frame) it would lose state, so I don't want to say
| that frames were a complete solution.
|
| Client storage is half of the equation, and that was added. Good
| caching infrastructure, multiple asset delivery, connection
| multiplexing, that seems to be working so you don't need a "big
| bertha" first page. Standardized DOM capabilities and the like
| seem to be fairly well solved, and maybe the "Javascript problem"
| will be solved once ... crap the thing where you have an IR
| bytecode so you can code in anything in a browser... well that
| will be solved.
|
| Frankly this needs to be solved. Apps and app stores are a pox
| upon the land, and the web browser can still save us from that.
| todd3834 wrote:
| To me one of the biggest distinctions here is the overuse of the
| term "App". I agree that a lot of websites written as an SPA were
| the wrong tool for the job. There are tons of examples besides
| the mentioned media websites where SPA is the way to go. Most,
| but not all, of the applications I work on feel like desktop
| class applications and the traditional server side rendered
| approach simply would not work. This includes when I was on the
| iCloud Web team working on the iCloud Drive App, the Mail App and
| some others behind icloud.com.
|
| I think a lot of companies that default to SPA would benefit from
| a very quick traditional website. However, some of the
| applications that I've been fortunate enough to work on would
| never be possible.
| karaterobot wrote:
| When I was a FE developer building single page apps, I would hear
| these arguments and say "you just don't get it, man, SPAs are the
| future". Now that I don't get paid to work on SPAs, these and
| other downsides come into very stark relief, and it's the
| advantages which seem more dubious to me. I doubt I'll ever touch
| an SPA again, and I'm not mad about that.
|
| Indeed: "It is difficult to get a man to understand something
| when his salary depends upon his not understanding it"
| donatj wrote:
| I have in my life used a couple of SPAs where I thought "Man,
| this works _really_ smoothly and quickly! " Like there have
| seriously been _a couple_ really good ones.
|
| They absolutely can be done _right_ , I've built _one_ I think is
| done right. I 've built a couple. I don't think the average team
| has it in them to build a good SPA.
|
| The majority of SPAs are user hostile hot garbage.
|
| The 95% of other SPAs were full of minor frustrations that could
| have been easily avoided by not being an SPA including
| 1. Completely unhandled errors with no indication anything is
| wrong. - This is a majority of SPAs. Any request error
| on flakey internet? Don't bother tell the user, just break.
| - The sheer number of times I've needed to open inspector to see
| that something has gone wrong... At least an actual non-SPA
| request that fails will show you an error page. 2.
| Broken... native... everything - 2.1 Especially "broken
| open link in new tab"/middle click - see next. 3. Inability
| to run the site in multiple tabs. - State is entirely
| local so state gets broken *easily*. - Some just outright
| refuse and warn you. 4. Adding everything I do to the
| browser history api - Makes it even worse than the back-
| button-not-working of old. Have to hit back a thousand times.
| - Scrolling SHOULD NEVER add things to my back button. NEVER.
| 5. High CPU usage on a site doing seemingly nothing -
| Looking at you, Medium. 6. Generally being way slower to
| use than the previous non-SPA website - Looking at you,
| Wells Fargo. 7. LOSING MY POSITION ON HITTING BACK
| - The sheer number of times I've been scrolling down an infinite
| list for like 30-45 seconds, click on something, nope not what I
| wanted, hit back, returned to the top of the list is entirely
| unacceptable as a society. - This is very often combined
| with 2.1 and 3 to make for a truly infuriating experience
|
| Like don't get me wrong, you can do a lot of this junk in a non-
| SPA but the failure state is almost always better.
| com2kid wrote:
| > Inability to run the site in multiple tabs. State is entirely
| local so state gets broken _easily_.
|
| I have seen this more for sites where a TON of state is stored
| in the backend, the site expects the user to have 1 tab that is
| kept in sync with what the server thinks that user session is
| doing.
|
| Heck I have seen sites that throw up errors asking me not to
| open multiple tabs.
|
| I have also seen sites where if I have Tab 1 on Page A, and I
| open Tab 2 to Page B, then go back to Tab 1 and navigate to
| Page C, if I go to tab 2 and try to navigate anywhere, it just
| goes to Page C.
|
| Fun times when the server has too much state.
| blunte wrote:
| I don't disagree with most points here, but I did chuckle at this
| one:
|
| > YouTube is a great example. Being able to keep a video playing
| while you explore other videos is fantastic.
|
| I hate that (mis)feature. When I click something else, my
| attention is on the new thing. Having to go find the little
| still-playing video window to close it is a hassle.
| onemoresoop wrote:
| Some like it some hate it. I hate it too but generally I like
| simpler things. I wish we could opt out of some features so
| everybody would be happy.
| [deleted]
| remram wrote:
| And if you don't, you're probably going to open in a new tab.
| Too many webapps are designed with complete disregards to the
| fact that browsers have tabs.
| colejohnson66 wrote:
| As a counter: I love it. It allows me to add videos to a queue
| without having to build a playlist beforehand. And halfway
| through the queue, I can add more without having to navigate
| away.
| stjohnswarts wrote:
| Yeah I like it as well, but there should probably be an
| option to disable for those who don't like it.
| jdrc wrote:
| agreed. i dont think youtube needs to be an SPA and simple
| pages work better. For comparison: porn sites.
| kizer wrote:
| Also, more SPA framework logic needs to become part of the web
| platform; APIs beyond pushState, service workers, etc. You have
| to integrate it into the browser to really remove the confusion
| and the boilerplate.
| k__ wrote:
| While Web2 is moving to SSR, I think SPAs will be a huge part of
| Web3.
|
| SPAs are perfect for decentralized infrastructure like IPFS and
| friends. Same goes for mobile apps.
| gls2ro wrote:
| What exactly from SPA is making them good for decentralized?
| lambda_dn wrote:
| SPAs were a good solution when page load/rendering times were
| longer. However with todays internet speeds, edge caching,
| HTTP3/Quic as well as todays chips and browser implementations
| page reloads are barely noticeable so you get all the goodness
| the browser gives you out of the box creating MPAs.
|
| There are still some examples were SPAs are useful such as
| replacing complex desktop applications but 95% of web apps don't
| need it.
| hinkley wrote:
| It was a big day for me when I realized the CSS perf tool had
| been removed from my browser because the clock resolution was
| no longer sufficient to make it work. Everything was <1ms.
|
| Bloom filters for CSS were a huge deal, and the CSS load and
| apply times are one of several things SPAs were trying to
| amortize.
| blablabla123 wrote:
| I think SPAs are awesome, there are just so many cases that SPAs
| can handle easily and more gracefully. From non-redundant input
| checks over interactive elements to optimizations for spotty
| networks or even offline usage.
|
| Anyway, it's painful when a page won't load or it takes 10
| seconds to load for no apparent reason. That's why profilers need
| to be used, loading indicators within the elements and also
| there's the trend towards frameworks with small footprints or
| even to go framework-less.
| mithr wrote:
| If the choice was between building a traditional app from
| scratch, or building an SPA from scratch, then I think the
| article would have a solid leg to stand on: building an SPA from
| scratch _does_ involve finding ways around things that browsers
| provide out-of-the-box.
|
| However, pretty much no one writes SPAs from scratch, and there
| exist many very popular frameworks that handle the vast majority
| of the common SPA tradeoffs out-of-the-box, so that in reality,
| you don't really have to think about e.g. whether links are
| internal or external.
|
| That's not to say that SPAs are always a good idea, or that they
| do everything well -- the author's point about scrolling to the
| right place, especially when navigating backwards and forwards,
| is one thing that many SPAs don't get right, for example. And the
| rise of next.js and the like have shown that there are other
| benefits to hybrid approaches, as well, and there isn't a one-
| size-fits-all solution.
|
| As for _why_ SPAs have become so popular, I think this can be
| summed up pretty neatly: everything is code. There 's something
| appealing to a software engineer about being able to control
| everything about how your app behaves, control when and how it
| loads or preloads data, how navigation works, etc. This comes
| with tradeoffs, you have to be careful about breaking user
| expectations and making things accessible, and if you go too far
| you can end up with a big mess ("just because you _can_ make
| everything custom doesn 't mean you _should_ "), but that
| underlying freedom to make those choices is appealing.
| thex10 wrote:
| My dev was asserting that a modest change to how a certain form
| control works would be "easier in React" (and this is on a piece
| of our application that's not even in any SPA right now). I
| marvel over the eagerness with which developers reach for React
| and friends nowadays.
| synergy20 wrote:
| Unless you already have a SSR in place(or you're familiar with
| it, e.g. Django, Laravel, Rails,etc), I feel SPA(or MPA) is
| actually a decent choice albeit the learning curve. Separation of
| concerns is always good. With SPA frontend developers can develop
| the UI using restful or some web APIs provided by the backend,
| while backend engineers can advance the server side and keep the
| API consistent.
| root_axis wrote:
| SPAs are ideal for web applications where users are manipulating
| application state in real time. There are many situations where
| this is applicable, you can't build something like e.g. Office on
| the web without an SPA, calling SPAs a mistake is trendy, but
| betrays an ignorance of the practical tradeoffs of an SPA.
| fmakunbound wrote:
| Seaside on Squeak (now Pharo), is still my happy place for web
| application development.
| a_chris wrote:
| The problem with SPAs is that they have been misused and
| overused, at least in Italy. Tons of projects built with SPA in
| which we have to re-implement basic browser features like the
| back button, just because project manager has no idea of how this
| technology works. I've worked on at least 4 projects which could
| be written in Nextjs in half of the time
| aminerman wrote:
| They don't know about frameworks in Italy?
| tofuahdude wrote:
| Hate to break it to you but Nextjs is for building SPAs.
| Toine wrote:
| This is way oversimplified. You can build a completely static
| website with NextJS. What I love about it is that you can do
| everything : SSR by default, SSG as an option, and awesome
| features like ISR etc.
|
| However, the way NextJS implements SSR is really weird right
| now : if you use their <Link/> component, the pages props are
| actually fetched with an XHR request, then the page is
| rendered. I don't know why. It does feel like an SPA in the
| end.
| midiguy wrote:
| I was going to say.... ironically NextJS is just an
| additional layer for creating static-rendered sites over an
| SPA framework. We have come full circle.
| deltaonefour wrote:
| All of software engineering is a flat circle. All of it. On
| the backend side it's microservices vs. monoliths.
| sinker wrote:
| Next.js recommends delivering static assets by default and is
| geared towards that.
|
| > _We recommend using Static Generation (with and without
| data) whenever possible because your page can be built once
| and served by CDN, which makes it much faster than having a
| server render the page on every request._
|
| If you need dynamic content, they recommend server-side
| rendering, and lastly client-side rendering only if the page
| is unaffected by SEO and requires a lot of in-page updates.
|
| https://nextjs.org/learn/basics/data-fetching/two-forms
| osrec wrote:
| It is annoying to see titles such as this, since SPAs are most
| certainly not a mistake (the article itself points out that the
| Youtube SPA is not a mistake).
|
| The truth is most devs struggle to implement SPAs well. To
| implement an SPA well, you need to understand browser APIs
| _extremely_ well (such as the History API), and in my experience,
| most devs don 't, hence the broken back buttons etc.
|
| To me, there is nothing nicer than a well made SPA, and often,
| the best SPAs are faster and lighter than the desktop apps they
| replace. I believe they are the best way to deliver software in
| the current age, and the sandbox that the browser offers actually
| provides users with a more secure execution environment than
| traditional software delivery mechanisms.
|
| I personally LOVE SPAs.
| andix wrote:
| A SPA is an Application and not a Web Site. With a SPA you can
| replace classical desktop or mobile applications, for example
| Gmail, Spotify or maybe Dropbox.
|
| SPAs are good for that, because you just have to develop it once,
| instead of 5 or 10 times for all platforms.
|
| SPAs are bad for traditional websites that deliver content.
| rado wrote:
| Anyone else encountered NG routing locking up upon return to the
| web app with Safari back button?
| wrnr wrote:
| At this point most articles like this or tools addressing the
| problem discussed here replace one local optima with another, I'm
| holding out for something radically different, maybe something
| like makepad or bevy like ECS with good support for UI.
| hunterb123 wrote:
| This opinion gets reiterated over and over and it's still wrong
| no matter how many times you say it. SPAs are just apps.
|
| I'm sorry people can't tell the difference of when you need a
| site and when you need an app. That doesn't make web apps a
| mistake.
| Jensson wrote:
| But it is so strange, most SPA's are basically just power point
| presentations. Why did it go like that? It isn't like people
| look for programmers to replace their power point presentations
| or PDF's, but for some reason that is exactly what they do on
| the web.
| coding123 wrote:
| SPAs were not a mistake, SPAs were an attempt to make the front
| end work like front ends have ALWAYS worked.
|
| Back before the web people made C++ and VB user interfaces that
| interact directly with the data source. SPAs are an attempt to
| make the web closer to that well known paradigm. POST REDIRECT
| REFRESH cycle was an insane programming paradigm that wasn't
| found in any previous edition of programming.
| commandlinefan wrote:
| > POST REDIRECT REFRESH cycle was an insane programming
| paradigm that wasn't found in any previous edition of
| programming
|
| Actually I'm old enough to remember old mainframe CICS
| programming that was a lot closer to the form-based HTML
| server-side programming of old. When "the web" came out in the
| mid-90's, it was actually a "blast from the past".
| wrs wrote:
| Not so. IBM mainframe systems (3270 terminal based) that ran
| most of commerce for a long time are basically the same
| paradigm as a web browser. Send a form to the smart terminal
| (GET), wait for the response with the field values (POST), send
| another form.
|
| In fact there are adapters that literally turn these
| applications into websites by translating the forms into HTML.
| Commonly seen when you need to do something like change the
| beneficiaries on your health insurance.
|
| "Client-server" paradigm came out in the 90s when PCs became
| powerful enough to run a "thick client" application, and was
| considered revolutionary.
|
| In other words, the eternal cycle continues... :)
| dboreham wrote:
| GUI application patterns predate the 90s (Mac, X11, Apollo
| Domain, Xerox Star, etc)
| wrs wrote:
| Of course yes, GUIs go all the way back to Sketchpad in
| 1963. The PARC work was more about putting files on a
| server than putting the application logic on a server. X11
| put _all_ of the application on a server (or as X11 calls
| it, a client...). Based on my bookshelf, the "client-
| server" paradigm of putting the UI part and a substantial
| portion of the related logic on the client, but with most
| of the business logic on the server, reached mainstream
| adoption in the 90s.
| ramesh31 wrote:
| >Back before the web people made C++ and VB user interfaces
| that interact directly with the data source. SPAs are an
| attempt to make the web closer to that well known paradigm.
|
| I wish more web developers were aware of just how damn good UI
| tooling was for native systems. Stuff like WinForms/WPF/Visual
| Studio and Cocoa/UIkit/Xcode on OSX. Perhaps we could get away
| from the insanity of rebuilding a select component for every
| new project.
| bdcravens wrote:
| Most SPAs don't interact directly with the datasource, but
| interact with a middle service. Also many older architecture do
| draw entire "pages" on the screen at once, rather than
| manipulating only individual components. (at least not on every
| interaction)
| coding123 wrote:
| Clearly, we can't have an SPA front end performing an SQL
| query directly. The HTTP/GQL/REST services are the SPA
| equivalent of that data source (they are still a data
| source). The C++ and VB apps written back in the day were
| single user programs so yes that's a difference but not by
| much architecturally.
|
| "Pages" are similarly in SPAs too. We usually have a router
| that helps the app decide what main "page" is on the screen.
| eloff wrote:
| I hate SPAs. I would never do another SPA again if it were up to
| me. It just adds too much mental context switching and overhead.
| I can develop fully server-side apps that are lighter, run
| faster, and at least 20% less development effort (I actually
| compared that for the same task: https://medium.com/@mustwin/is-
| react-fast-enough-bca6bef89a6). So why would I ever do an SPA
| again if it were up to me? I would use
| https://github.com/jfyne/live which is inspired by Phoenix
| LiveViews. This is my professional opinion, having many years of
| experience in both kinds of web apps.
| rosenjcb wrote:
| Template based UI programming is like going back to the year
| 2007. Your views should be reactive. Elm, Flutter, React, Et
| Cetera understand this. Having a function that takes data and
| returns a view is much better.
| ColonelPhantom wrote:
| Isn't a template essentially a "function" that takes data and
| returns a view? I don't have much experience with UI
| programming but I don't really see the conceptual difference.
| rosenjcb wrote:
| No, the template is usually a static file that is read into
| memory and served over HTTP or locally if it's a JS only
| site. But before being served, it's being picked at via
| imperative operations. And if it's really bad, then when a
| user presses a button it triggers some event that actually
| statefully changes the view itself.
| remram wrote:
| That is a usual way this is done but not what it _means_.
| In fact, HTML recently got a ` <template>` tag which is
| definitely not a separate file or served separately.
| Vue.js also refers to the HTML-ish portion of a component
| as "template".
| ColonelPhantom wrote:
| I don't see template operations as imperative, rather I
| see them as declarative: you write the HTML and declare
| lists/placeholders inside the HTML. You also don't
| generally do much with the data except insert it into
| HTML; the rest of the backend is responsible for
| fetching/etc the data.
| rosenjcb wrote:
| Yeah, but the function itself doesn't return that view.
| The framework you're working in essentially composes the
| view based on the associated code and template. This is
| fundamentally different from just returning the view
| itself in the function. These are all declarative
| approaches, but leaving your view in code is a lot
| better.
|
| Every template-based framework I've seen has involved a
| lot of magic, syntax and DSL. That's not to say that JSX
| isn't a DSL as well but you can return regular
| React.Elements just as easily. You shouldn't need to
| remember a unique expression system just to be able to
| conditionally render. The premise that you're just not
| doing much with the data except dumping it into HTML is
| less true the more complex your site becomes. Think of
| the loads of conditions and evaluations that happen when
| you go to your Facebook wall or friends list.
| bcrosby95 wrote:
| It's okay because despite JSX being a DSL you don't have
| to use it even though everyone does?
|
| Your line of thought is a large part of why I prefer
| ClojureScript to Javascript for SPAs. With reagent your
| components just work like the language, with nothing
| particularly special to remember.
| eloff wrote:
| We can debate syntax but a Go or Python based template
| language is not conceptually any different to JSX based
| syntax. Both are essentially functions that take some input
| data and return the data formatted in HTML.
| aminerman wrote:
| Let me translate this comment fo you guys: "I'm incapable of
| making an SPA, therefore I'm questioning the whole pattern and
| I'm trying to find some convoluted reasoning to justify my
| position".
| dimgl wrote:
| I kind of have to agree here. There are very few times I've
| ever worked on a SPA and felt like throwing it all away and
| using the alternative.
|
| The last time I thought about this, which admittedly was many
| years ago, the alternatives that I knew about were: server-
| side frameworks like ASP.NET MVC Razor, PHP, RoR templates,
| Node.js EJS, Jade (now Pug), and static HTML.
|
| Nowadays, you can create extremely elegant and performant
| SPAs with tools like Next.js and Remix, so I really couldn't
| agree less to the OP.
| lp0_on_fire wrote:
| Instead why don't you let us know why you think that position
| is incorrect rather than resorting to reddit-tier insults?
| hinkley wrote:
| Harsh. Dude ported liveview, this isn't amateur level work.
|
| It's a useful brush but you can't use it to paint everything.
| eloff wrote:
| I just want to clarify, I didn't create the LiveView port,
| but I think it's excellent work.
| freedomben wrote:
| wow you must be incredibly smart and discerning, being able
| to confidently make assumptions and judgments about people's
| lives and background based on one or two HN comments, and
| then dismiss them as an ignorant and incapable fool.
| eloff wrote:
| You're being very rude and dismissive. I may well have more
| SPA experience than you do. Don't make assumptions about
| people and then use that to dismiss something they say -
| we're better than that here on HN.
| salt-thrower wrote:
| This reads like a Reddit comment. Let's try to be better than
| that here.
| diordiderot wrote:
| This is rude
| gowld wrote:
| Sure, if you implement a trivial single-task app (one tiny
| feature of a Calendar app) with an unfriendly UI, you don't
| need an SPA. That doesn't prove anything.
| eloff wrote:
| It doesn't "prove" anything, but it's a data point, and quite
| a lot more thorough than your dismissive comment. If you want
| to make a well supported counter-argument, please be my
| guest. It's easy to criticize, it's harder to make a
| thoughtful argument.
| pacifika wrote:
| When I was reimplementing "reset state" for a logo click I knew
| it should have been serverside rendering.
| phendrenad2 wrote:
| Luckily we don't have to use them. Go ahead and do a full page
| reload when the user navigates to another page. Go ahead and
| implement interactive elements using jQuery. It all still works
| just as well as it did in 2012.
| onion2k wrote:
| SPAs are a pattern that's been applied too broadly IMO, but it's
| going a bit far to call them a mistake. The aims of an SPA are
| pretty noble - the idea of essentially removing the network round
| trip when a user clicks on something is not a bad one. It means
| things are faster, they work if your connection is flaky, they
| can do things like offline support. Those are _good_ features.
|
| They might not be actual _requirements_ for a blog or a brochure
| site but it 's not totally unreasonable for someone to want their
| website to work that way. The question is not whether or not an
| SPA is a good or a bad thing, but whether or not the cost (more
| code, more complexity, potentially a series of background
| requests after the initial page load) is worth paying in order to
| get the benefits.
|
| When either an SPA or a multi-page site is done well most users
| can't tell which sort of site they're looking at. _That_ should
| be the goal. Make stuff where the user forgets about the tech.
| Make a website that just works, that 's fast enough for users not
| to think 'this is a bit slow', and that's coded in a way you can
| maintain and work on for a long time. If you get those things
| right then no one can reasonably criticise what you've made no
| matter how you've made it.
| RHSeeger wrote:
| > When either an SPA or a multi-page site is done well most
| users can't tell which sort of site they're looking at.
|
| And therein lies the problem. In the _vast_ majority of SPA
| sites I've been to, they are not "well done" by this
| definition. It is commonplace for things to break, like the
| back button as the quintessential example, because the
| developer(s) didn't spend the time to make sure things work
| correctly. With a non-SPA site, you generally have to go out of
| your way _to_ break those same things.
|
| I like SPAs for some things (gmail being a good example), but
| they should not be the default implementation; there should be
| a _very_ strong argument before the SPA architecture is used.
| gowld wrote:
| You're just saying that bad software is bad. That's
| tautological.
|
| Without SPA you have horrific 10page forms and the challenge
| of maintaining state as you go back and forth to make edits.
|
| The hard part is managing state, and there is no way to avoid
| it if your product is not purely readonly. SPA is one
| strategy, and a pretty good one.
| acdha wrote:
| If one style of writing applications is far more prone to
| having "bad software", consider that this is a valuable
| signal about the difficulty of using that style
| effectively. SPAs require you to take on ownership of more
| hard to debug challenges and that's an important factor to
| consider when selecting tools.
| onaworkcomputer wrote:
| The GP was not saying "bad software is bad"; they pointed
| out a lot of footguns that are introduced by going the SPA
| route. "More code -> more (opportunities for) bugs" is the
| truism at play here.
| zozbot234 wrote:
| > the idea of essentially removing the network round trip when
| a user clicks on something is not a bad one.
|
| Practical SPA's have many _more_ network roundtrips than the
| equivalent server-rendered web interface. Every AJAX request is
| an extra roundtrip, unless it can be handled in parallel with
| others in which case you 're still dependent on the slowest
| request to complete. With SSR, you can take care of everything
| with a single GET and a single POST no matter what. Images load
| in parallel of course, but those are non-critical.
| horsawlarway wrote:
| I pretty strongly disagree with this.
|
| The distinct advantage of an SPA is that, done correctly,
| cached data lets you render pages instantly.
|
| Who CARES if the SPA had to make 3xRTT in the background, if
| it can serve the next page up instantly because that data is
| already present and cached, it's a huge win.
|
| The server rendered app will _ALWAYS_ have to wait at least
| 1xRTT for every new render. The SPA does not.
|
| Still doesn't make an SPA the right fit for everything, but
| on bad networks, we get incredibly improvements in
| performance by rendering from cache, and occasionally
| handling cache updates in the background. User's fucking love
| it compared to waiting 2-5 seconds for every page load, even
| if they were JUST on the page a second ago.
| freedomben wrote:
| Have you tried to use a heavily SPAed site from a slow,
| distant (high latency), or metered connection? A SPA that
| works and feels great from a big city quickly becomes
| unbearable when internet access isn't as ideal. There are
| ways to handle this nicely, but maybe 5% of devs actually
| think about and test that, and no PM will allocate sprint
| time for it.
| efdee wrote:
| In case of slow internet, SPAs are much easier to make
| responsive than an SSR application.
| freedomben wrote:
| Sure, _if_ that 's your goal. It won't happen by
| accident, and the "default" method of SPAs make it really
| easy to fire off lots of different requests, often on
| demand.
| blablabla123 wrote:
| It's not that SPAs cannot handle that but it's rarely a
| requirement.
|
| I've once launched a product on (early days) Google App
| Engine and it was unusable as purely server-side rendered
| website because sometimes it would take ages to load or
| worse an error would come up eventually. With AJAX it
| could be solved and failing requests could be repeated.
| It's a pity that this is rarely done but it is of course
| possible.
| 8note wrote:
| Using the web at all is your problem there.
|
| If that's your targeted usecase, send an exe on a thumb
| drive, and get them to call you back over the phone
| freedomben wrote:
| I know this is/was not your intention, but to be honest,
| I find that attitude insulting and frankly
| discriminatory.
|
| The internet has become essential to modern life, and
| many people have no choice but to use it. Most of my
| monthly bills don't have any alternative to paying
| online. (Some will take a payment by phone but they'll
| charge a $20 "phone fee" or similar).
|
| There are certainly sites/apps that just can't work
| without requiring a big and short pipe, but it's
| extremely defeatist to suggest that it's hopeless and we
| shouldn't even try.
|
| You're certainly not alone with your opinion. I suspect
| that attitude is a big part of why this is such a problem
| nowadays.
| horsawlarway wrote:
| Yes - that's literally exactly what I talked about.
|
| I can tell you - My app renders immediately in these
| cases, precisely because I lean heavily on a cache.
|
| I preload basically all the data a user might need at
| startup (prioritizing the current page) and then
| optimistically render from cache.
|
| I'm very familiar with these kind of situations (I have
| developed software designed explicitly to handle offline-
| only cases, and I'm very familiar with how bad a
| connection might be in rural Appalachian schools.)
| onaworkcomputer wrote:
| > I preload basically all the data a user might need at
| startup
|
| This can be a great strategy when you're dealing with
| bounded data that's not sensitive, but it's important to
| recognize that this approach is often inappropriate. A
| web app may be allowing users to wander around terabytes
| of data, or it may need to make highly consistent
| authorization determinations before allowing a user to
| see specific data, or you may need to keep a highly
| detailed audit log of who requested what when (e.g., if
| the app targets healthcare or government users), which
| aggressive preloading would render useless.
| horsawlarway wrote:
| > Still doesn't make an SPA the right fit for everything
| mrtranscendence wrote:
| It's still worth pointing out.
| freedomben wrote:
| Awesome, thank you for doing that! I wish more people
| did. I've had several people tell me that "in a web app
| you only want to load the data you need, at the time you
| need it" and I die inside a little.
| gowld wrote:
| Have you tried to use a site that reloads all the data on
| every click, from a slow, distant (high latency), or
| metered connection? Same problem.
| freedomben wrote:
| Of course, and it's usually not as big of a problem
| because everything you need comes in the page render.
| With SPAs it's not uncommon to have to click 5 or
| buttons/menus and then wait for data to load, then click
| again, and more data.
|
| That said there are plenty of SSR sites that are terrible
| too. It's not the technology that's at fault, but SPAs
| and common dev patterns in the community definitely
| enable and encourage making lots of small requests.
| tomnipotent wrote:
| > have to click 5 or buttons/menus and then wait for data
| to load, then click again, and more data.
|
| How is that any different from SSR? Waiting for a full
| page reload is fine, but incremental loading is not?
| giantrobot wrote:
| > Who CARES if the SPA had to make 3xRTT in the background,
| if it can serve the next page up instantly because that
| data is already present and cached, it's a huge win.
|
| The data is never in the cache. It is for a developer
| because they forget to clear their caches when testing. For
| most users the data will not be cached unless they're
| sitting on the SPA all day.
|
| So when the user _doesn 't_ have data cached that 3xRTT on
| their spotty 4G signal the SPA pattern is of no help. Not
| everyone is sitting still on great WiFi. Someone's cellular
| reception can go from great to unusable just walking down
| the street.
| horsawlarway wrote:
| >The data is never in the cache.
|
| Then you have a shitty app.
|
| Between localstorage and indexdb - unless you're
| literally out of disk and having storage being evicted,
| then if you've loaded my app once (and I mean _once_ ,
| not once this browser session) then I have data in cache.
|
| Basically - don't blame SPAs, blame developers for
| assuming that the same "request the data every page view"
| paradigm is still in play.
|
| It's not, and storage is insanely cheap.
| acdha wrote:
| > Then you have a shitty app.
|
| This feels a lot like you're making a "No True Scotsman"
| argument. The behaviour you're saying doesn't / shouldn't
| happen has been the defining characteristic of SPAs since
| the beginning and it's still immediately visible on most
| of them as soon as you have a less than perfect high-
| speed internet connection. If statistically nobody except
| the Wordle developer can make something which handles
| crappy WiFi the problem requires more than just saying
| someone is a bad developer.
| hinkley wrote:
| Unless their cache is cold and then they navigate back
| before your first render completes. Often we are not the
| sole source of a piece of information and first load time
| counts.
| horsawlarway wrote:
| > Unless their cache is cold and then they navigate back
| before your first render completes.
|
| This doesn't matter. It's an SPA - my js context hasn't
| been wiped because I'm not letting the back button eat
| the whole thing and start over. I just complete the
| request and store in cache either way, and next time they
| hit it, it will be there.
|
| > Often we are not the sole source of a piece of
| information and first load time counts.
|
| Sure - caching is hard (full stop - it's really hard).
| But I think if you actually consider most applications,
| there's not really much difference between an SPA
| rendering from cache and a server-side page that a user
| hasn't refreshed in a bit.
|
| Basically - it's not going to solve all your problems,
| but in my experience developers really underestimate how
| much usage is "read only" and a cache works fine.
| hinkley wrote:
| It doesn't matter!?
|
| SPAS push giant gobs of logic and CSS ahead of the Time
| To Interaction and cross their fingers that nobody will
| notice because it's not supposed to happen the next time
| due to magical cache thinking.
|
| People have been ignoring actual research on caches for
| the entire time SPAs have been around. First time
| visitors have this as their first time visit. Occasional
| visitors show up after the last deploy, or like and
| enthusiastic web users get evicted between loads. And
| then don't convert because your site is "always slow".
|
| P95 statistics don't tell you if 5% of your users are
| having a bad experience. Or if new users are massively
| over represented in the P95 time. You are flying blind
| and shouting for other people to follow you.
| zozbot234 wrote:
| To be fair, there are SPA frameworks that try to minimize
| the amount of logic that's shipped to the client, Svelte
| is an example, which should be as lean and efficient as
| any hand-coded JS. It's more of a side effect of what
| frameworks you use than SPA per se.
| hinkley wrote:
| It's still a specialty sub-discipline though. Getting the
| base size down is a wonderful goal for a framework. But
| for the behavior the company is adding, there are both
| diminishing returns and a lot of surface area for bugs.
| horsawlarway wrote:
| Look - I understand that I'm making a tradeoff here, and
| I'm very clear that not all sites are the right fit for
| an SPA.
|
| But yes - I explicitly handle offline-only use cases, and
| god-damned terrible connections (think <1kb/s). In these
| situations, users are going to wait a long time for the
| first load either way.
|
| They call in excited as all get out when they realize
| they only have to wait _once_ with my application, and
| not once every page load. It 's the difference between
| having a chance to grab a coffee at the start of the day,
| vs pulling your fucking hair out all day long.
| NoGravitas wrote:
| Your application seems to be a magical unicorn (not being
| sarcastic!). Most SPA websites I use on a regular basis
| end up having to reload all of their page components
| every visit, and frequently on every 'back'.
| horsawlarway wrote:
| I'll be really honest here - it helps that it was a
| direct requirement from day one, and we have financial
| incentives aligned with handling the offline-only case.
|
| If you handle offline up front - you mostly get bad
| connection speed wins by default.
|
| It also helps that our app really isn't intended for
| casual use - ex: we have very few users who just load a
| page or two and then leave. Mostly they'll be interacting
| with the page for a duration of between 30 minutes and 2
| hours (sometimes as often as once a second).
|
| So yes - very much not a "blog" or "news" or "social
| media" site, and I think the value proposition for most
| companies might be harder to sell.
|
| But I personally find it very, very nifty that we can do
| this at all in a browser. 10 years ago it would have
| required an installed application, or a port to each
| mobile platform. Which is sadly still a hard sell in some
| of the particularly poor school districts we worked with
| (mostly computers from the early 2000s, if you're lucky a
| really cheap tablet - like a kindle - floating around)
| kevinmcconnell wrote:
| > The server rendered app will ALWAYS have to wait at least
| 1xRTT for every new render. The SPA does not.
|
| Not necessarily. I think you're conflating caching/fetching
| and rendering here. You can cache rendered views in the
| same way you'd cache the data for those views.
|
| Turbo does this, for example. When you navigate to a cached
| page it will display the page from the cache first, then
| make a request to update the cache in the background. So
| it's similar to what you describe, but with server-rendered
| content.
| horsawlarway wrote:
| Turbo is making your site an SPA, and hiding the
| implementation details from you
|
| That's not what the article was about (it was very
| clearly advocating for the standard browser flow)
| tomnipotent wrote:
| > You can cache rendered views
|
| Sort of. There's been no shortage of vulnerabilities
| where user data has been exposed when an authenticated
| users request was cached and re-used for subsequent
| users. It's been my experience that most SSR apps disable
| caching for authenticated users, or rely on more explicit
| control of components for partial caching where possible.
| onaworkcomputer wrote:
| > The distinct advantage of an SPA is that, done correctly,
| cached data lets you render pages instantly.
|
| Yeah, but full page caching is a thing, and in my
| experience, teams writing traditional server-rendered pages
| are much more aggressive in their use of response caching
| than are teams writing JSON APIs. Honestly, a
| Rails/Django/Laravel app with smart caching headers and a
| Varnish instance in front feels more reliably instantaneous
| than the bespoke caching solutions each SPA seems to invent
| for itself.
| zozbot234 wrote:
| Preloading is a browser-native feature, you don't need a
| SPA for that. And just as often you can't know in advance
| what data will be requested by the user.
| horsawlarway wrote:
| > And just as often you can't know in advance what data
| will be requested by the user.
|
| This is a cop-out. Storage is insanely cheap, and
| abundantly available on most machines. Plus the browsers
| will usually give it to you.
|
| Can I know precisely what series of pages this user might
| hit? Nope. Can I load _ALL_ the data this user might need
| to read? Probably.
| onaworkcomputer wrote:
| > Can I load ALL the data this user might need to read?
| Probably.
|
| You can do that with HTTP/2 server push on a multi-page
| app, too. The main difference is that with an SPA, you
| get to reinvent it all yourself.
| horsawlarway wrote:
| Yeah - there's a trade off here.
|
| Server push gets you closer with a traditional app, but
| it doesn't really solve the problem (or rather - yes, you
| get to reinvent it yourself, but you can do it better,
| with the specific context of your app)
|
| Basically - My argument is that developers tend to treat
| SPAs the same as "the website" but with a bigger js
| framework. And that's the wrong mindset.
|
| Instead, you should think of the first load as an install
| of a native application. You want to push absolutely
| everything, not just the next couple of resources you
| might need (like imgs/css). Ideally you push the current
| page first, and do the rest in the background while the
| user can interact with the current page, since you're
| almost never CPU bound on terrible connections anyways.
|
| You'll get one additional load at login (because now I'm
| pushing all relevant user data), but after that...
| basically everything is rendered from cache (including
| optimistic cache updates based on what the user might be
| adding/updating).
|
| After that... unless you log out or have cache evicted,
| you're going to see immediate response times, even while
| offline.
|
| ---
|
| This isn't easy, and most teams don't bother, so if the
| comment is "If you're treating an SPA like a traditional
| page - don't bother" then I tend to agree.
|
| but an SPA genuinely opens up options for bad connections
| that otherwise just don't exist (or are so bad people
| won't use them)
| giantrobot wrote:
| Storage is cheap but _bandwidth_ is not guaranteed.
| Getting content from your server to my device is not
| necessarily fast. Making wrong assumptions about my
| device 's environment makes for a poor experience for me.
| horsawlarway wrote:
| if you cache well - you will absolutely use less
| bandwidth with an SPA.
|
| Sure - that first load is going to be bigger, but
| literally every subsequent request will use less data.
|
| I try to reward consistent and current customers - and
| I'm not selling a news article or a social media site...
|
| Now - if you do things like attempt to refresh _all_ of
| the cache often, then sure, you have some problems to
| deal with.
|
| > Making wrong assumptions about my device's environment
| makes for a poor experience for me.
|
| Tough shit? I go way out of my way to make sure that
| loads on bad lines (or no lines) don't interfere with my
| users. You could just as easily say "I'm on gigabit why
| is this app using my disk space? Making assumptions makes
| for a poor experience. WAAAH".
| giantrobot wrote:
| hinkley wrote:
| People generally have a very bad estimate of just how engaged
| users are with their sites.
|
| These people have lives and other shit to do besides spend
| all day in my web app. There's a lot more accidental and
| exploratory clicks than you think and all of the background
| requests run even though the user is only on that page for
| half a second.
| bastawhiz wrote:
| > Practical SPA's have many more network roundtrips than the
| equivalent server-rendered web interface. Every AJAX request
| is an extra roundtrip, unless it can be handled in parallel
| with others in which case you're still dependent on the
| slowest request to complete.
|
| This is largely solved with innovations like GraphQL (which
| you don't need a SPA to use). Pages that require multiple API
| calls can show their UIs progressively with appropriate
| loading indicators. For SPAs that have ~long sessions, it's
| arguably a good thing to have multiple API calls, because
| each can be cached individually: the fastest API call is the
| one you've already cached the response for. This is stuff we
| were doing at Mozilla in 2012, it's nothing new.
|
| There's also nothing stopping you from making purpose-built
| endpoints that return all the information you need, too. Your
| proposed solution (SSR) is literally just that, but it
| returns HTML instead of structured data.
| candiodari wrote:
| What they're meaning is that the _total_ time is longer for
| the SPA if you don 't go all out (and nobody does).
|
| SPA: 1. get html from server (1
| roundtrip) 2. get resources
| (js/jpg/movies/gifs/favicon/...) from server (1 roundtrip)
| 3. get ajax calls from server (1 roundtrip) 4.
| process answer from server + update page (not a roundtrip,
| but not zero)
|
| Vs traditional: 1. get html from server
| (1 roundtrip) 2. get resources from server (1
| roundtrip)
|
| Also if there are sequential ajax calls required to build
| the page (like a list -> detail view), it goes up a lot
| without speed oriented (very bad code style) API design.
| For instance you need a separate
| "GetListOfUsersAndDetailsOfFirstUser()" (or more general
| "getEverythingForPageX" calls). You can't do
| "GetListOfUsers()" and "GetUserDetail()" separately.
|
| So to match traditional webpage total load time you cannot
| do any ajax calls in your SPA until after the first user
| action. And even then, you only match traditional website
| performance, you don't exceed it.
|
| Time until the first thing is on screen however, is faster
| in SPA's. So it's easy to present "a faster website" in
| management/client meetings, despite the SPA version
| actually being slower.
|
| You _can_ make SPAs faster than traditional websites ...
| but, for example, you cannot use javascript build tools.
| Since you need to do the first calls server-side and have
| javascript process them, and only send the result of the
| preprocessing, and the resulting dom to the client, after
| optimization and compression. _After_ that you need to then
| do image inlining, style inlining, etc. I know react _can_
| do it, but does anyone other than facebook actually do
| that?
| abemassry wrote:
| I wrote a post very similar to this comment that you
| might be interested in reading. I broke down what takes
| time to load, how fast the browser determines something
| has loaded, and how fast the user can perceive the page
| loading. I ended up having to take a high speed video and
| measure frame by frame the time it took to load for user
| perception.
|
| https://www.ireadthisweek.com/author/ireadthisweek/post/2
| 022...
|
| The TLDR is it takes longer than reported.
| 3np wrote:
| The more something behaves like an actual _application_
| and the higher the number of user interactions per visit,
| the more sense the SPA approach makes IMO. This is
| because the initial load overhead of an SPA gets
| amortized over subsequent interactions.
|
| Blog or corporate/news website on one end and an
| interactive game or video editor in the other, with a
| site like FB somewhere in the middle.
|
| It's not a hard rule and I can already think of counter-
| examples but this line of thinking is useful when
| architecting a new project.
| bgirard wrote:
| You eliminate #3 by having data preloaders inline it into
| the html response and move it into #1. But without SSR
| your rendering still starts after #2 instead of #1.
|
| I think your point is still correct. SPA by default are a
| huge regression and you have to build and maintain
| sophisticated web infra to reclaim it.
| Scarblac wrote:
| Yes, but most of the time (getting the HTML and all the
| Javascript etc) is only at startup time. Let it take a
| second or two. From then on the user is in the
| application, and everything is much faster than it used
| to be with getting entire new pages from a backend every
| other click.
| bastawhiz wrote:
| > For instance you need a separate
| "GetListOfUsersAndDetailsOfFirstUser()" (or more general
| "getEverythingForPageX" calls). You can't do
| "GetListOfUsers()" and "GetUserDetail()" separately.
|
| This is literally a core use case of GraphQL. But you
| probably also want to fan out to preload all of the other
| user data in one API call: that's the whole point of
| doing it on the client. If you are trimming the handful
| of kilobytes on the first request, you're paying the
| price for that on each subsequent load.
|
| > I know react can do it, but does anyone other than
| facebook actually do that?
|
| Yes. Every job I've worked at professionally since 2016
| (when this became mainstream) has done this. I do it in
| my side hustle. It's really not that hard.
|
| > 2. get resources (js/jpg/movies/gifs/favicon/...) from
| server (1 roundtrip)
|
| This doesn't go away with traditional sites.
| candiodari wrote:
| > Yes. Every job I've worked at professionally since 2016
| (when this became mainstream) has done this. I do it in
| my side hustle. It's really not that hard.
|
| Can you link to a tutorial for this? I'd be most
| interested.
| [deleted]
| tiborsaas wrote:
| SSR isn't a one-size-fits-all solution. Blogs? Sure.
| Corporate marketing site? Absolutely. Wikipedia? What else.
|
| A webapp where state can exist in various components is a
| perfect fit for SPA-s. Clicking a button in a widget and
| submitting the page with every other state, updating them and
| refreshing the page makes no sense.
|
| SPA-s also help with separating frontend and backend
| development, they are different beasts. I know many backend
| devs who wouldn't touch frontend with a 10m pole and not
| because of JavaScript, but because they don't like design and
| UX in general.
| nwsm wrote:
| > Every AJAX request is an extra roundtrip
|
| But not every AJAX request is blocking or necessary for the
| site to be usable.
| efdee wrote:
| If you can do it in a single GET/POST in an SSR, you can do
| it in a single XHR call in an SPA. There's no reason it has
| to be split up in separate XHR calls.
|
| You just have to want to do it.
| tonyedgecombe wrote:
| >It means things are faster, they work if your connection is
| flaky, they can do things like offline support. Those are good
| features.
|
| Yet the reality seems to be the opposite. If my connection is
| flaky (which it often is) then SPA's seem to fail more often
| and it isn't obvious what is going wrong. They don't seem to be
| faster either, long pauses between pages is common.
| zozbot234 wrote:
| Right. The typical SPA doesn't recover at all from network
| failures, and you end up poking random buttons hoping that it
| will reach some sort of consistent state. Then you find that
| doesn't help and you need to refresh anyway, which is a
| reboot for the whole 'app'. So much for saving page loads.
| uhoh-itsmaciek wrote:
| I think it's exciting to see frameworks like https://remix.run/
| trying to temper the disadvantages of SPAs by relying on web
| standards and server-side rendering. It's pretty cool that this
| is a JavaScript framework that can work without any (client-
| side) JavaScript.
| freedomben wrote:
| Honest question: why is remix the primary example for this
| now? Next.js has been doing this for years and is really
| amazing. It seems like a ton of people had no idea this was
| even a problem they had until remix came along, and now remix
| is the savior.
|
| Am I missing something with remix? Is there anything really
| novel that it does/introduces?
| pl0x wrote:
| Yet another javascript framework to learn, no thanks.
| uhoh-itsmaciek wrote:
| I don't know. I'm not very familiar with Next.js (I'd heard
| about it but never really looked into it much). Your
| response inspired me to investigate, and I found an article
| by a Remix founder about the differences [1]. It's
| obviously biased, but maybe still interesting. It looks
| like there was an HN submission and a bit of discussion,
| too.
|
| There's a bunch of other comparisons out there, too.
|
| [1]: https://remix.run/blog/remix-vs-next [2]:
| https://news.ycombinator.com/item?id=29983950
| eithed wrote:
| Those are very good points - I wonder how the author would see,
| for example, Google Sheets implemented as not a SPA
| [deleted]
| aelzeiny wrote:
| SPAs exist for a reason. Same with SSR. Developer ergonomics play
| a bigger role than you think. And if you think that the choice is
| either SPA or SSR then you haven't been paying attention to
| recent developments in the frontend world.
|
| Websockets+SSR (PhoenixJS) attempts to store state on the server
| rather than the client; in that way you can still have stateful
| interactions with minimal JS. NextJS does an amazing job patching
| the bridge between SPA+SSR by having the same codebase run on the
| backend and the frontend. What I would like to see more of from
| this industry is less "grass is greener on the other side" and
| the unification of a single tool that allows for the cross-
| collaboration of SPA + SSR without having two distinct codebases
| that one has to context-switch between.
| MaxMoney wrote:
| [deleted]
| goodpoint wrote:
| The web is a mistake.
| ravenstine wrote:
| Nah, they weren't a mistake, at least not in isolation. Much of
| modern software development is a mistake, generally speaking.
| When you look at it that way, SPAs only failed in the sense that
| Object-oriented Programming failed, as well as the failure of
| various design patterns, microservices, write-once-run-anywhere,
| test-driven development, decentralization... I can go on and on
| with the number of engineering and computer-sciencey crap that
| never really lived up to its promises.
|
| SPAs only suck as much as _we_ suck. Just admit that SPAs are
| like any other tool, and if we 're going to swing back to
| apologizing for goto-statements (something I don't necessarily
| disagree with) then we can't at the same time act like SPAs are a
| mistake in and of themselves. We collectively continue making
| mistakes and instead of owning up to our collective lack of
| craftsmanship, we are blaming the tool.
|
| Only when we shed the mindset that informs us that computer
| "science" is actual science might we then be in enough touch with
| reality that we seriously impose some standards upon ourselves to
| address our clumsiness.
| laerus wrote:
| why do you think TDD failed :(
|
| Doesn't every other science field work pretty much the same way
| though? We make mistakes, we iterate, we make new and better
| mistakes. It may be too obvious in software cause it's easy to
| create stuff and iterate very fast cause there aren't so many
| natural constraints. Someone may even argue that this is what
| makes software also an art.
| ravenstine wrote:
| TDD, or rather the effort behind TDD, failed because its
| proponents couldn't help but preach it as a cornucopia of
| solutions with the insistence that it's appropriate for every
| circumstance. When you are familiar with the domain of a
| problem, TDD makes a lot of sense. For the project I'm
| working on now where I'm effectively _learning_ at just about
| every step of the way, and said project is intended for very
| few users, it 's highly questionable if I could have
| benefited from TDD. Even when I'm not doing something
| unusual, TDD doesn't always make sense.
|
| Any research that currently exists around TDD is of poor
| quality and proves little, but TDD fanatics (not sure how
| many of them exist anymore though) speak like there's
| objective evidence in their favor. And some call this sort of
| thing "science"?
|
| By the way, when I mentioned science, I was specifically
| referring to the concept of "computer science", of which
| there has been very little actual use of the scientific
| method in our lifetimes. Computer science is of course a
| legitimate area of study; if our heads are still so in the
| clouds that we are still calling it a "science" then it's no
| surprise that we're continually losing touch with the very
| technologies we create.
|
| TDD also shot itself in the foot with this (IMO toxic)
| insistence that the tests _are_ the documentation, which is a
| nice principle to keep in mind, but I 've never seen it come
| close to replacing actual documentation. A simple comment
| block describing the _why_ of a function is always better
| than scrolling through tests and reconciling inconsistencies
| with the mocks that were used. And yeah, I know that TDDing
| isn 't really about "mocking", but let's face it [...].
|
| Perhaps the worst thing of all is that TDD is founded on a
| somewhat dishonest implicit premise, which is that if you
| _aren 't_ TDD'ing then one must be either not writing enough
| tests or are writing inferior code because one is writing
| tests _after_ development. TDD fanatics, in particular those
| freshly inducted into the cult, often think it 's either TDD
| or nothing, and if you're not TDD'ing one particular part of
| an app then you're not following "standards". Maybe TDD is
| fine as a form of guard rails when you're a junior developer,
| but by the time you're a high mid-level and in touch with
| reality then you're going to intuit whether a unit of work
| will actually benefit from TDD.
|
| TDD isn't bad at all in terms of its mechanics. It's a great
| idea, and I've used it many times. In fact I even TDD'd an
| entire web app that handled payment processing from start to
| finish. The part about TDD that "failed" was this belief that
| it is actually a generalized solution that needs to be
| applied everywhere, which lead to it both being misapplied as
| well as _dismissed_ when it becomes apparent that those
| promises of better and easier code /process/readability often
| don't magically manifest.
|
| This is really the story behind just about every failed idea
| related to our field, not just TDD. SPAs were supposed to
| make pages snappier because it meant server responses to
| different user actions would require fewer bytes and no page
| refreshes. Instead of viewing SPAs as a tool with a purpose,
| people had to treat SPAs as the end-all-be-all of frontend
| development and a way to do everything, and now the world is
| stuck with many SPAs that are likely worse than if they were
| done as regular webpages.
| mrvenkman wrote:
| The article does give good examples of where SPA works.
| vinceguidry wrote:
| They were necessary from a perspective of "we need a way to
| develop a company's web presence in a way we can send kids to
| code camp to get the gist of." Of course they weren't a wonderful
| thing in terms of actually building sustainable infrastructure,
| but what's that to stand in the way of business's need to go to
| market yesterday?
|
| Code camps don't have time or resources to educate their students
| so we got the reinvent-the-world half-solution that is the SPA.
| SPA frameworks won't ever go away but you'll get the chance
| eventually to go work on something better-architected than your
| run-of-the-mill NodeJS shitshow.
| toqy wrote:
| I don't think that's accurate. SPA's arise from the desire to
| put something like Slack in a web page. If bootcamps are
| responsible for that, I don't see how. Isn't it more likely
| that they meet the demand rather than create it? And bootcamps
| taught Rails long before they taught React.
|
| And let's be honest, making a server rendered site with some
| traditional Python framework is in many ways just as easy or
| easier than making a SPA.
| i_have_an_idea wrote:
| No shit, Sherlock. Of course, all of this was obvious to any of
| us with more than 5 minutes of industry experience, alas this
| field seems super prone to reinventing the same things over and
| over again, making the same mistakes and never learning from the
| past.
|
| Also, this article does not even mention the fact that SPAs are
| terrible for SEO. Of course, that's not an issue for YouTube, but
| it might be a huge issue for your clients, unless it's ok to not
| have any search traffic.
| randomsearch wrote:
| SEO for SPAs is a solved problem
| i_have_an_idea wrote:
| It is definitely not solved for the vast majority of SPAs out
| there. Where it is solved, it is not solved for free or
| cheaply, as it would've been if these apps used server-
| rendering tech.
| elchief wrote:
| Lame opinion, but I miss the (pre-license-change) ExtJS days
|
| Unified library of tools. An actual GUI designer to design
| layouts in.
|
| Now everything's just a mess
| austincheney wrote:
| > Browsers give you a ton of stuff for free
|
| True, but irrelevant. I have written an OS GUI, including full
| file system support, in the browser that performs faster than
| native OS GUIs. My biggest learning from this is talking about
| performance in a job interview is the fastest way to kill the
| interview. Performance, like security, requires trade offs that
| deviate from comfort. If the common developer is insecure comfort
| is the only thing that matters.
|
| JS hiring expects the following: React components, 2-6 weeks of
| JS practice, the ability to use map/filter on arrays, and CSS. If
| you overshoot that you begin to enter unknown territory that
| intimidates other developers. The better you are the less
| employable you become as the further from the bell curve you
| drift.
|
| If you are wondering why this is or how we got here the answer is
| _trust_ , or the lack thereof. In software there is a long
| standing bias: if you can see it visually its worth less. I have
| been doing this work for more than 20 years and that bias
| predates my work, so its been around for a while. Bias is
| continuously reinforced by the lack of standards in software
| hiring and the inability of employers to train their employees.
|
| This lack of trust means that employers do not trust their
| employees to perform original work and likewise the developers
| don't trust each other. This is why absolutely everything, I mean
| this literally, is a downloaded NPM package, because the
| developers will trust an anonymous stranger to write original
| code before they trust anyone they know. There is all kinds of
| excuses to qualify this, of which some are bizarre and nearly all
| lack any kind of merit.
|
| This is why its irrelevant what the browsers provide. Its baked
| into the framework, an NPM package, or ignored.
| midiguy wrote:
| Every week someone posts some half-baked blog ramble about how
| SPAs are bad (except for media sites!).
|
| How about this - I am just as or more efficient working with SPA
| frameworks such as React as working with server-side-rendering. I
| have invested in a skill and toolset that can deliver any sort of
| website or web application from blogs to Youtube to Figma. I
| don't see any reason I would invest in learning an MPA framework
| that is only good for a subset of that.
|
| If you are delivering content-only website with simple forms you
| might as well just use a CMS and call it a day.
| hinkley wrote:
| Why are wood shops loaded to the rafters with tools? Because
| there is no Golden Hammer, only people who think they've found
| one.
|
| You're saying you're doubling down on a single solution, which
| is probably not actually true, but you are surrounded by
| younger developers who will copy what you seem to be doing
| rather than what you're actually doing.
|
| All of these unresolved arguments are about team dynamics, not
| technology, which is why they never get resolved. Because we
| talk about our experiences or "objective" things like logic.
| midiguy wrote:
| > All of these unresolved arguments are about team dynamics,
| not technology
|
| No, it's definitely about technology. Let me simplify this
| for you. Technology A can do thing 1 very well, and thing 2
| decently. Technology B can do thing 2 well, but can't do
| thing 1 at all.
|
| In reality, people who only do technology B claim technology
| B is necessary to do thing 2 and go to great extents to write
| blog posts claiming such, while people who only do technology
| A get on with doing things 1 and 2 without feeling the need
| to rant.
| dec0dedab0de wrote:
| I've been thinking about this a lot, and the one thing I love
| about SPAs is that everything the user can do from the front end.
| They can do from the API. The trend has essentially tricked tons
| of corporate apps into opening up APIs to their users. My screen
| scraping skills are starting to get rusty, but it's worth it.
|
| I sometimes daydream about a framework that allows me to build a
| spa and a server side app at the same time using the same url
| scheme.
___________________________________________________________________
(page generated 2022-03-02 23:00 UTC)