[HN Gopher] The Single-Page-App Morality Play
___________________________________________________________________
The Single-Page-App Morality Play
Author : midrus
Score : 181 points
Date : 2021-10-15 11:20 UTC (11 hours ago)
(HTM) web link (www.baldurbjarnason.com)
(TXT) w3m dump (www.baldurbjarnason.com)
| est wrote:
| if SPAs are bad, compiled JS are evil. They only seem to hijack
| the scrollbar or give cookie consent or waste 2/3 of viewport
| with a fucking subscribe/login cover.
|
| Every page should promise some kind of plain text content length
| vs full page resource bytes ratio. Why would anyone emit 20MB of
| .min.js only to deliver 140 characters of tweet?
| Raidion wrote:
| I get the feeling, but it's worth noting that it's not just 140
| characters of tweet. It's also delivering all the analytics,
| the content surrounding the tweet (replies, likes, etc), and is
| a teaser to the rest of the app.
|
| The business driver isn't just delivering the content, it's
| increasing engagement, and the SPA application provides a
| significantly better and scalable way to make that happen.
| Everyone seems to think they could do better, and we end up
| with yet another "modern" JS framework.
| kbsspl wrote:
| thank you for saying that.
| hunterb123 wrote:
| Yeah pretty much. Depends if you are making a web app or a web
| site.
| antihero wrote:
| Is this just an advert for Hotwire? Every single point just seems
| to mention Hotwire.
| moon_other wrote:
| Not really.
|
| Hotwire is provided as an example of a Hybrid app framework /
| toolkit and is mentioned about five times. But so also is
| Svelte.
| cardanome wrote:
| As someone that had my fair share of experience with mismanaged
| teams, this rings very true.
|
| For example I had to maintain a legacy PHP project, relatively
| old school PHP before there was even OO, plain HTML with just a
| bit of JS sprinkled it. Everyone complained about it and sure the
| code was horrible but I could dive in and be productive on day
| one.
|
| Same company, more recent project with a more modern stack,
| trying to follow all the OO patterns and everything. I was not
| even able to fix minor bugs in any reasonable time even studying
| the code for weeks. What happened? While the developers made good
| technical choices and the quality of the code in isolation was
| fine, it was horrible mismanaged. There was no continuity, just
| people working on it for a couple of days then doing something
| totally different and forgetting everything again on repeat.
| Individual design decisions were "industry best practice" but the
| end result was something I wished I could just delete.
|
| Everyone loves to play wiht the newest toys but you got to keep
| you developer vanity in check. Sometimes the boring CRUD app
| should use boring technology. With horrible management you will
| learn to hate what you once loved anyway.
| userbinator wrote:
| For some reason, web development seems to have an obsession
| with "progress" and the new-and-shiny-but-objectively-worse.
| I've noticed that constant reinvention of the wheel and doing
| the same thing more inefficiently ("but it's more _modern_! ")
| is a common theme.
| HPsquared wrote:
| Fashion (which values novelty) is a major factor in web
| design, it stands to reason this preference would spill over
| to the underlying technical stack as well.
| Gene_Parmesan wrote:
| I agree, but this has always stuck out as odd to me. Why is
| this so true even of the developers in web when people in
| something like C# are perfectly content using the
| established tools/frameworks they know year after year? I
| have seen sometimes seen this in the same person - someone
| who would never complain about using Entity Framework, but
| who is always pushing for the latest trend when working in
| the front end stack.
| userbinator wrote:
| Even C# isn't completely immune to trendchasing, although
| you're right that it's less. Maybe it could also be due
| to how much effort and money is spent promoting novelty
| --- and certainly for companies like Google, change is
| their weapon for fighting competition.
| HillRat wrote:
| Y'know, I'd argue that C# may be the _worst_ when it
| comes to trend-chasing -- for better or for worse, the
| language's a giant toy box that lets you develop in very
| expressive, not to say idiosyncratic, ways.
| BackBlast wrote:
| As someone who has changed the kind of work I do in my
| career I've had two very different experiences.
|
| There is a web development culture. There was a pace of
| advancement for many years that helped shape this desire
| for newest shiniest stuff. Other ingredients such as
| chasing FAANG, VC money, and the general youth of the
| average web dev. Salaries chasing talent due to the
| online boom and corporate policies not adjusting to keep
| talent, thus needing to do resume building for the next
| job hop because it's going to happen in less than 2
| years.
| hellbannedguy wrote:
| Big business probally loves it. It's hard to unionize a
| workforce that needs constant education, and retraining.
| grey-area wrote:
| When people say a web app is 'modern' I know it involves a
| javascript framework.
|
| I'm not sure how or why this came about, but it seems to be a
| code-word meaning one of the newer javascript frameworks,
| that single word is almost a shibboleth at this point for an
| entire culture of development.
| DeathArrow wrote:
| Not necessarily, it can involve web assembly.
| 0x4d464d48 wrote:
| When it comes to pages that would be served just fine with
| basic HTML, JavaScript and CSS there's an irritating,
| crossing into stupid, overemphasis on frameworks and
| patterns. A lot of times it's gotten to the point of
| bikeshedding.
|
| But that said there _is_ important progress being made in web
| tech but very little of it has to do with how you mash your
| HTML, JavaScript and CSS together.
|
| Take a look at what's being done with tech like WebAssembly
| and full on 3d grpahics in the browser (if youre using a
| phone I recommend that you connect to a wifi spot to not use
| up your data).
|
| https://threejs.org/examples/#webgl_animation_keyframes
|
| https://playcanvas.com/
|
| Theres a whole other can of worms to deal with like finding
| talent (this kind of content is way more labour intensive and
| requires much stronger domain knowledge). But the point is
| that there is a path for enhancing online UX and disrupting
| user expectations. The value add for being able to review 3d
| models of construction or order previews on demand speaks for
| itself.
| hk1337 wrote:
| Kind of sounds like a continuity problem, perhaps even a
| leadership problem.
|
| > Sometimes the boring CRUD app should use boring technology.
|
| Absolutely. I would even say most of the time, CRUD and
| relational databases can be a much better solution.
| giantg2 wrote:
| "There was no continuity, just people working on it for a
| couple of days then doing something totally different and
| forgetting everything again on repeat."
|
| This is a great description of my current work. Multiple
| systems, stacks, and technologies to support. It's just
| constantly jumping from one thing to the other. It gets even
| worse when you throw PRD support work in there. The context
| switching is brutal.
| jarcane wrote:
| I worked at a job once where this was _deliberate_.
|
| Certain voices in the team were terrified of "siloing", and
| so it was a matter of policy that everyone had to jump tasks
| and teams every two weeks, unless they had a solid case for a
| longer term task.
|
| The result was that no one knew what the hell they were
| doing, because no one had time to learn anything before they
| were shuffling chairs again.
|
| We were only saved from this madness when a major data center
| failure took out the app and all process theatre was
| temporarily suspended during crisis mode. Once we got back
| online, it was quickly realized that we'd all been wildly
| more productive and not just because of the crisis, but
| because we could actually function organically without the
| artificial strictures.
| giantg2 wrote:
| I feel like our's is the product of management not wanting
| to staff up our team or another team to handle different
| tech (not willing to pay up).
|
| It's possible it's intentional though. It's hard to leave
| the team or company when you're just ok at a lot of things,
| but not an expert in anything.
| draw_down wrote:
| Article: bad management is the number one problem.
|
| Your post: yeah someone needs to rein in these stupid
| developers!
| [deleted]
| DerekBickerton wrote:
| For the bulk of my Internet surfing, I have JS turned off by
| default in uBlock. Now and then I encounter a _white screen of
| death_ which on closer inspection is a Single Page App (and didn
| 't have the courtesy of having a <noscript> tag telling me I
| needed JS to view the page).
|
| I have JS turned off for accessibility and privacy reasons. What
| annoys me is sometimes JS is needed just to render a bit of text
| when it could be rendered with plain HTML. Not _everything_ needs
| to have JS in order to work /function. Also: many hamburger menus
| are rendered useless when JS is turned off when it could be
| implemented with CSS alone.
| kbsspl wrote:
| Great style of writing.
|
| A great example of a 'forced perspective'. The entire ecosystem
| of browsers, standards, devices, business imperatives is being
| forcefully turned into a spa/mpa comparison.
| gorgoiler wrote:
| Nice to read something that made me laugh out loud.
|
| Pro tech work really is 80% coordinating people (quashing jerks,
| dealing with drama, etc: "don't leave the new guy alone with the
| CTO") and 20% funtimes-computer-stuff.
|
| It might not seem like that in terms of wallclock time, but it
| sure feels like it in terms of energy spent.
| not2b wrote:
| Since he refers to misogyny elsewhere, I suspect he might mean
| "the new gal".
| endisneigh wrote:
| It's hard to draw any real conclusions from this. The author says
| things that the delta between an average single page app is great
| from multi page, but is that true?
|
| The author makes tons of claims but presents no evidence.
|
| Seems more about poorly designed apps and managed teams than
| anything inherent in either type of app.
| jrochkind1 wrote:
| This article is blowing my mind, as is the linked article "Agile
| as Trauma"[1], written by apparently a different author but with
| a very similar broad perspective.
|
| I want to read more like this.
|
| [1] https://doriantaylor.com/agile-as-trauma
|
| [update: holy cow, this one too
| https://www.baldurbjarnason.com/2021/software-crisis-2/
|
| Today is turning into "read about existential problems with how
| software is developed" day for me]
| denton-scratch wrote:
| SPAs make web resources impossible to index or link to - by
| definition, they do not contain "pages". OP failed to mention
| this at all. For me, this is the killer "anti" posture.
|
| Hyperlinks are the defining feature of the WWW; that people put
| resources on the WWW that can't be linked to, is cause for
| regret.
| ngrilly wrote:
| It used to be impossible to link to specific page in a SPA
| without using hashes in the URL, but this problem has been
| solved years ago, and all modern browsers support it.
| denton-scratch wrote:
| What's a "specific page" in the context of discussing single-
| page applications?
| hbn wrote:
| If you go to example.com/user/jim in your browser, it'll
| navigate to (presumably) the profile for the user with the
| handle "jim"
|
| Maybe I don't understand what you're asking. Browsers these
| days have functionality that enables SPAs to navigate
| between URLs, push/pop to and from the back history, etc.
| without full page reloads.
| denton-scratch wrote:
| Well, example.com/user/jim looks to me like a Unique
| Resource Locator. If that's right, then what I'll get is
| a "page" (you could call it a resource). If the locator
| is really "unique", It'll be different from the page I
| get if I ask for example.com/user/jane, right? (modulo
| aliasing)
|
| Well if that's right, then this site is not a "single-
| page application". It has multiple pages with different
| URLs, and I don't know how that's different from any
| other website with server-side state.
|
| [Edited to mention state; state is irrelevant to whether
| its an MPA or an SPA, but without state it's hard to
| argue its an application at all]
| pjc50 wrote:
| I really like the virtue/vice discussion framing this. You don't
| see virtue-oriented discussion of topics very often unless it's
| the accusation of "virtue signalling" being flung around.
|
| > I keep seeing Single-Page-Apps with huge JS files that only, in
| terms of concrete User Experience (UX) benefits, deliver client-
| side validation of forms plus analytics. Apps rarely leverage the
| potential of a Single-Page-App. It's still just the same 'click,
| wait for load' navigation cycle. Same as the one you get with
| Multi-Page-Apps. Except buggier and with a much slower initial
| loading time.
|
| Very true - and also of mobile apps that behave in this way,
| either because they're using the same SPA technology or are just
| misconceived.
|
| However:
|
| > The Multi-Page-App forces the team to narrow the scope to a
| level they can handle. It puts a hard limit on their
| technological aspirations.
|
| I don't see how this follows at all?
|
| The link to https://doriantaylor.com/agile-as-trauma is fantastic
| too, as is the whole "I am Vanity" section. But yes, I also agree
| with the people here asking what this has to do with SPA vs MPA,
| because I don't understand the scope argument.
|
| (Frankly I could write a paragraph response to each section as if
| it were a separate blog post, that's how much good content there
| is here)
| bcrosby95 wrote:
| MPAs are naturally limiting compared to an SPA. And dev teams
| know this. So does management.
|
| SPAs are magical pixie dust that lets you easily code a native
| experience in the web. Some management thinks this. So do
| under-experienced dev teams.
|
| MPAs provide natural pushback against unrealistic demands and
| feature requests that your experience might not let you
| recognize, or that company politics won't let you do.
| onemoresoop wrote:
| My overall experience with SPAs as a user of different
| services is not so great on average. There are a few services
| where this works out great but for the most majority it makes
| the experience worse.
| bulatb wrote:
| I think he's implying that traditional MPAs are relatively
| well-understood. The team will pretty much know how to make
| them and will not expect to break new ground on architecture,
| discover new things the model enables, or spend a lot of time
| on "How do we build applications?" versus just delivering on
| business goals. SPA development is less mature, so there's a
| lot more room (and sometimes need, or just temptation) to
| reinvent things.
| throwaway284534 wrote:
| Maybe I'm just full of Ruby on Rails induced trauma, but I
| can't remember any particular pleasant memories. Every app
| would start with a reasonable and straightforward view layer,
| usually ERB templates sprinkled with jQuery, and then slowly
| but surely be consumed by one-off JavaScript snippets.
|
| "We need a sortable table on this route and it should support
| pagination without a reload, _but_ the pagination needs to be
| persisted to the address bar for outside link sharing." This
| feature alone can introduce all kinds of unmanaged state and
| be a testing nightmare. And if another part of the site uses
| the same functionality, you've just signed up for an lifetime
| of maintenance, usually somewhere between your server-side
| templates, and your asset pipeline. God help you if your bugs
| can be described as, "I have some local state _here_ , but
| I'm not sure how to get it either up or down to the right
| place."
|
| Personally, these kind of code smells demoralize me enough to
| consider a job elsewhere, preferably at a company that uses
| something like React where there's bound to be complexity,
| but at least there's component boundaries to keep your mental
| facilities from being overrun by a "simple multi page
| architecture."
| pjc50 wrote:
| > "We need a sortable table on this route and it should
| support pagination without a reload, but the pagination
| needs to be persisted to the address bar for outside link
| sharing."
|
| How would you do that differently in a SPA? Or would that
| just preclude the link sharing, removing the requirement
| altogether?
|
| Are SPAs doing client-side pagination or something?
| shadowgovt wrote:
| I've seen a variety of solutions used in SPAs, from a
| thin wrapper around server-side pagination to some
| extremely fancy client mirroring of server state where
| the client builds an increasingly larger cache of the
| data coming from the server, complete with eviction
| strategies and maximum memory usage limitations, and only
| has to send a request to server side when it knows it
| cannot satisfy the client's viewing desires with what
| it's gathered so far.
| ellyagg wrote:
| > I've written in the past about how conferences are the
| business equivalent of morality plays. They don't exist to
| educate or enlighten but to unify a community around shared
| values--which is why they are great for networking. That is
| why they need a liturgical adversary; somebody who can
| represent the opposing heterodoxy. >> unless it's
| the accusation of "virtue signalling" being flung
| around.
|
| You can't have one without the other.
| crate_barre wrote:
| What did I just read? GPT spotting here guys?
| shadowgovt wrote:
| This rings extremely true based on my observation. Fundamentally,
| companies working on large projects will ship their org chart. It
| is modestly more difficult, if your org chart gets spilt in two
| such that two or more teams are now maintaining the same SPA, to
| synchronize their work such that they don't interfere with each
| other's activities. You begin looking at a more traditional
| application development model with full program integration
| testing in the mix.
|
| Multiple pages means multiple entirely separate client-side
| contexts that are a security hole if they can clobber each other.
| DeathArrow wrote:
| What's worse, those frontend devs who love Javascript frameworks
| began writing desktop and mobile apps in Javascript.
| oblib wrote:
| Well this made me feel good about being a lone developer who gets
| to make all the decisions on how to make an app.
| bulatb wrote:
| For anyone deciding whether to read, I'd say the article is
| broadly centered on this:
|
| _> As developers, we need to operate under the assumption that
| good management is the exception, not the norm. Multi-Page-Apps
| and hybrid frameworks let under-resourced, mismanaged developer
| teams deliver reliable and safe code. That should not be
| dismissed lightly._
|
| There's also a helpful "Summary" section at the bottom. Overall
| it frames the SPA vs. TWA[0] debate in terms of which approach is
| likelier to produce successful software... or successfully
| produce software, at least.
|
| [0] Traditional Web Application? Do we call it that?
| SilasX wrote:
| <deleting because comment was based on a misreading>
| mwcampbell wrote:
| Can you elaborate on what you found laughable? I thought the
| article made valid points.
| SilasX wrote:
| <deleting because comment was based on a misreading>
| afavour wrote:
| Is the article not arguing the opposite? That multi page
| apps are the ones that better insulate against management
| failure?
| SilasX wrote:
| <deleting because comment was based on a misreading>
| afavour wrote:
| The quoted claim doesn't say anything about SPAs
| providing insulation against bad management either?
| SilasX wrote:
| Oops, my mistake. Deleting as best I can.
| hirsin wrote:
| We've largely broken app architectures in AAD down to spa,
| hybrid, and "webapp". Where webapp means "a server owns the
| state, and creates a web page and sends it to your browser".
| MPA is rough - 110% some engineer within minutes of that doc
| going live will point out that their spa has multiple pages.
|
| Personally, I like TWA - will start using that locally to see
| how it goes. Look for a doc update near you soon...
| resignThis2021 wrote:
| AAD?
| easton wrote:
| Azure Active Directory -- the OP is a PM for that at
| Microsoft.
| flerchin wrote:
| The bits about SPAs seemed to have no relation to the thesis,
| which is that management drives the antipatterns, not the tech.
| bulatb wrote:
| The author argues that the non-SPA approach deals better with
| that kind of management than SPA does.
| louissm_it wrote:
| I've always found that when people say they dislike SPAs they
| actually mean they dislike APIs and the whole circus of how to
| handle building, consuming, validating, error handling, network
| errors, etc.
|
| Not affiliated, but Inertiajs[1] has been a fantastic middle
| ground between MVC goodness and using React/Vue/Svelte for client
| side interactivity. It even plugins in with your Rails/Laravel
| errors for form handling.
|
| [1] - https://inertiajs.com
| hahamrfunnyguy wrote:
| I've been doing web development for over twenty years now. Perl,
| PHP, ASP, Rails, .NET, Flash, Flex, Silverlight and various
| JavaScript and SPA frameworks.
|
| I really like the MPA approach. To me it means building a bunch
| of mini SPAs. You can still stuff everything into a single SPA to
| deploy to a mobile app, but it gives you the advantage quicker
| first-time page loads and a lot of extra flexibility.
|
| Compared to the Web 1.0 way of doing things where you POST and
| then reload the page, you're taking an API based approach so when
| a 3rd party needs to integrate with you - that part is probably
| done already.
|
| A lot of sites use the MPA approach wrong though. They load the
| "apps", then proceed to make a whole bunch of asynch requests for
| data. In most cases, using a mechanism to inject in data when a
| page first loads makes everything feel a lot faster.
|
| It's the best of both worlds: you get the speed of the old school
| web and the flexibility of modern practices.
| SPBS wrote:
| If you have multiple pages each with their own javascript that
| allows them to behave like an application, is it still
| considered a SPA? Yes it behaves like an application, but
| javascript running AJAX is hardly different from what
| traditional webpages already do. To me the defining trait of a
| SPA is a site that does all its routing within a single html
| page (which I consider an antipattern).
| martin_drapeau wrote:
| Back-end routing is very solid. My experience is that front-
| end routing is complex and is hard to maintain. Multi SPA
| allows you to modularize your application into different
| concerns.
|
| Most of the time, an SPA can be limited to one action or
| group of actions. For example one SPA to manage the user's
| preference, another for managing a list of objects, so on and
| so forth.
| bcrosby95 wrote:
| > Back-end routing is very solid. My experience is that
| front-end routing is complex and is hard to maintain.
|
| There doesn't seem to be anything inherently more complex
| about routing on the front end vs the back end. Why does it
| turn out to be messy when the back end isn't? What's
| keeping you from using the same patterns?
| debaserab2 wrote:
| If you implement it on the frontend you lose all the
| builtin navigation behavior that the browser gives you
| natively when loading pages. You instead get to build all
| that behavior yourself in places where you think it
| should exist using your best judgment (things like
| deciding when to push to browser history state, for
| example, may be perceived as breaking the back button to
| many users if you haven't thought through your app's
| navigation hierarchy very carefully).
| oblib wrote:
| You can cache templates in the user's browser and insert
| those into the user's page and show/hide parts of a single
| page.
|
| For example, you can use mustache.js to load a cached
| "Preferences" template and just grab the data from the
| server to fill it in, or from the browser's IndexedDB if
| you've stored that data there.
|
| Does this approach not qualify as a single SPA?
| twobitshifter wrote:
| MPA + SPA is how most native Android and iOS apps are
| developed. I agree with the other commenter that a single html
| file is an anti pattern.
| martin_drapeau wrote:
| I couldn't agree more. It is a spectrum.
|
| <-- Fully MPA ... MPA with mini SPAs ... Fully SPA. -->
|
| Many don't venture in the middle. Not sure why. Do not stay on
| either end. It will bite you!
| zerkten wrote:
| People don't venture in the middle because it's complicated
| and scary for many people due to the skill requirements. It
| only starts to feel safe to play there when you have
| experience with development at both ends of the spectrum
| because you likely won't have the support of tools which are
| intended to run there.
|
| Further, it's a compromise that is difficult to explain and
| justify to management. If they are risk averse then they
| won't want to move far from the safety of the frameworks at
| either end of the spectrum.
|
| If you are a developer of frameworks, it also seems
| advantageous to go to one end of the spectrum because it's
| easier to reason about the problem space. When you target the
| middle there starts to be more variations in how to handle it
| best. It's really the only place to go though, if folks
| really want to innovate and provide better experiences for
| all.
| martin_drapeau wrote:
| Laravel encourages the middle ground. Sprinkle Vue.js. I've
| worked in both MPA and SPA. The middle ground is much
| faster.
|
| You can pre-load objects in the page and then use AJAX to
| finalize loading. The user experience is snappier.
|
| The bundle size also remains smaller. Divide and conquer.
|
| Yes, it does require being comfortable navigating back and
| front end. Over time, a good developer will get there.
| nightski wrote:
| This trope of "if you were just skilled enough" needs to
| die. Things cost money. They cost money to maintain and
| evolve. If a solution requires exceptionally high skill
| that means it is very expensive and pushes employees to
| their limits. Meaning it is not a healthy technological
| solution.
|
| It's funny how the article goes on about "If managers
| were just good enough". But the problem is managers face
| real world constraints. They can't just give us unlimited
| resources to live out our complex ego-driven tech
| fantasies.
| zerkten wrote:
| >> This trope of "if you were just skilled enough" needs
| to die. Things cost money. They cost money to maintain
| and evolve.
|
| I don't disagree terribly with the trope aspect, but
| people are hurting from the cost to evolve and maintain
| projects using approaches that sit at the extremes. There
| needs to be some understanding, and possible embrace, of
| elements of the middle ground in order to be truly
| maintainable in a lot of cases.
|
| My call to action would be more for the innovators and
| framework developers to think more about this. Companies
| can try to solve it for themselves, but forces like staff
| turnover prevent meaningful progress for most.
| sanderjd wrote:
| Maybe an unpopular opinion here: as a _user_ of web applications,
| I very strongly prefer the "modern" javascript heavy SPA
| dominated culture of recent years. Every once in awhile I get
| annoyed by something that is just a webpage but thinks it's an
| application, but more often I have the reverse annoyance.
|
| But as a developer, I agree that it is harder to develop these
| kinds of applications that I like than it used to be to develop
| multi page applications with mostly server side logic and only
| sprinkles of javascript.
|
| I guess I just do, actually, think there is UX benefit to the
| complexity. But of course there are better and worse ways to
| accomplish it, figuring out that balance is the hard part.
| mwcampbell wrote:
| Can you expand on why you prefer the JS-heavy SPA style?
| sanderjd wrote:
| Because they are faster and easier to use. Using them is like
| using an application, rather than like using a website.
|
| I think a good rule of thumb is: am I mostly clicking or
| mostly scrolling? If I'm mostly clicking - say, something
| like AirBnB or Zillow or Discord - where I'm exploring things
| and interacting a bunch, that feels better to me as a rich
| client-side application. If I'm mostly scrolling, like a blog
| or substack or a newspaper or even twitter, that feels better
| as a website.
|
| I thought of a good concrete comparison: Vanguard vs.
| Coinbase Pro. Vanguard is a website, and it basically works
| for them because their business model is very passive, but
| you wouldn't want to do active trading there. Coinbase Pro is
| a web application where you can do lots of exploration and
| take actions quickly, and for me, it would be a major
| hindrance if they implemented it in a traditional page-based
| way.
| DeathArrow wrote:
| If you want to use an application, then why don't you
| download and run an application? You will have a better
| experience running an application on desktop instead of
| running it on the browser.
| sanderjd wrote:
| Because the web is a revolutionary application
| distribution platform. It is a better platform in every
| way _except_ that some things that should be applications
| are still behaving like websites (and vice versa) and
| that it is harder for developers to target than native
| platforms. But as a user, I don 't care at all whether it
| is harder for developers.
| streptomycin wrote:
| Write once run anywhere. Nothing else comes close. A lot
| of web applications simply wouldn't exist on your
| platform if they were forced to be native applications.
| wizhi wrote:
| Except now replace "platform" with browser, and you have
| the exact same dilemma as if we still made desktop
| applications.
|
| It's sad how many "web apps" (and even more regular
| sites) only work in Chrome - try using Firefox or any non
| major browser, and quite a lot of the web simply doesn't
| work.
| themacguffinman wrote:
| Hardly the same. Desktop applications are still much more
| time-consuming to make. The differences between desktop
| platforms is on another planet compared to the
| differences between browsers, especially the difference
| between Firefox and Chrome, especially when you consider
| mobile.
| etchalon wrote:
| Is this a React thing? I haven't run into any of these problems
| in five years of building Vue.js SPAs. Literally everything is
| easier, and faster, than traditional MPA development.
| lsalvatore wrote:
| I can't relate to this at all. I've been happily working on SPAs
| with React and Redux for nearly 6 years.
|
| Hotwire makes no sense: switching to managing client-side state
| on the server and sending HTML over the wire introduces a ton of
| problems: you are going to have to write and debug JavaScript
| eventually. Now your server is running client-side code to update
| every local browser state? How is that scalable at all?
|
| React has a ton of great libraries for UI that these articles
| always ignore: Something like react-select to manage a dynamic
| dropdown- you can't implement that on the server.
|
| You need SPAs for complex dashboards, and React is a great
| library to store and update local state. I don't understand what
| the controversy is.
| sanderjd wrote:
| I've always thought some of it stems from the nomenclature and
| the cultures that flow from it. A lot of people (reasonably)
| don't think the best architecture for their application is a
| "single page". But many of those same people nonetheless have
| (often large) portions of their application that benefit from
| complex client side interactivity. But the whole thing can seem
| really all or nothing, either you have a "single page
| application" that does everything client side or you do
| everything through html from the server. Of course in practice
| everybody does some hybrid in between these two extremes. But
| the apparent split creates a cultural battle between the
| extremes, which is not helpful.
| lsalvatore wrote:
| I come from a financial reporting background where pages
| needed to be dynamic and update through filters / sorting /
| etc- think Excel or Robinhood- these are applications, not
| pages. When you are building an application, users don't want
| to experience a page refresh. You either want a dynamic
| behavior without page refresh, or not. React Router gives you
| client-side routing- I don't know why you wouldn't want that
| even if you were building something like AirBnB where there
| is mostly static content- to argue against dynamic search and
| filtering without page refresh seems silly to me.
| sanderjd wrote:
| Yep exactly this. I even just used Coinbase Pro vs.
| Vanguard in another thread as a concrete example of
| application vs. website where the Vanguard approach would
| really suck for an actual trading application.
| ithrow wrote:
| No need to go full SPA, dynamic dropdown can just be a
| component(with react-select) in your MPA. You create coupling
| between your front-end server and the browser but that's not
| bad at all for many type of webapps.
| yurishimo wrote:
| Meh, I think you can get 98% of the way there. Look at the
| explosion of these "server side SPA" frameworks popping up.
| Hotwire for Rails, Livewire for Laravel, LiveView for Phoenix,
| etc etc.
|
| I think Elixir is a super interesting case given how insanely
| fast it is. If your request to fetch new data and patch the DOM
| takes 5ms, who cares if it's slower than React? It's plenty
| fast for a ton of use cases and lowers complexity.
|
| And then, if you do need the super slick interactive element,
| you bust out React and code up a nice little inline thing that
| writes it's value to a hidden input field that you can send
| along with a the submission of a normal form.
|
| Webdev swung heavy to building entirely frontend solutions and
| I think the past year or so has been the potential beginning of
| the pendulum swinging back as teams are now feeling the pains
| of maintaining these huge frontend applications, on top of
| already needing to maintain the complexity of their backend.
|
| Time will tell!
| lsalvatore wrote:
| There is no "pain" managing large React / Redux applications
| for experienced frontend software engineers. If you don't
| want to write JavaScript, you probably shouldn't be building
| interactive applications for the web.
|
| The Browser manages HTML, CSS and JavaScript and provides
| Developer Tools to debug and manage these languages. When you
| build with a javascript framework, you package a user
| experience that is entirely run by the browser, only to
| dispatch and save to the server when necessary.
|
| I doubt there is a future for "backend SPA" frameworks- no
| one will take seriously the idea of, instead of two REST
| calls to get and put data, every client must connect through
| a socket to manage user input. Surely that will dramatically
| increase server bandwidth, and ignite the same type of
| "bloat" arguments that SPA critics use.
| yurishimo wrote:
| > If you don't want to write JavaScript, you probably
| shouldn't be building interactive applications for the web.
|
| Wow, thanks! I've been writing production apps in Vue and
| React for large companies for years now, but good to know I
| can stop. /s
|
| I have nothing against JS; I have problems with complexity
| on teams of varying skill levels and tenure. If you're a JS
| shop, it's great. But if you're an agency of Rails
| developers building CRUD apps for B2B, you shouldn't feel
| forced to write a bunch of JS just to get some values
| updating on the frontend in realtime.
| lsalvatore wrote:
| You don't need to write a bunch of JS, that's why
| JavaScript frameworks like React exist to make this easy.
| JavaScript is the only client-side scripting language on
| the browser that you can use to manipulate the DOM. If
| you want to locally CRUD without making a round trip to
| the server- you have two options- manual DOM
| manipulation, or use a JavaScript framework. That idea
| that HTML streaming will replace JS frameworks and REST
| APIs, and is easier and less problematic than a JS
| framework, is preposterous to me.
| subsection1h wrote:
| Who said that JavaScript frameworks and REST APIs are
| going to be replaced?
|
| I've noticed that many people who enjoy developing SPAs
| believe that SPAs are the only way that web apps should
| be developed, and when anyone suggests otherwise, they
| get very defensive. Pretty weird.
| ramchip wrote:
| > Surely that will dramatically increase server bandwidth
|
| LiveView can actually decrease B/W and load, because the
| HTML diffs are more efficient than sending JSON, and the
| statefulness means you don't need to constantly refetch
| user information from DB/cache, etc. The details depend on
| your app and how carefully you optimize it, but it's far
| from being an unconditional "dramatic increase".
|
| > If you don't want to write JavaScript, you probably
| shouldn't be building interactive applications for the web.
|
| That's gatekeeping and just plain insulting.
| lsalvatore wrote:
| JavaScript is the only language browsers will run. It's
| not gatekeeping to suggest that you have to learn and use
| JavaScript frameworks if you want to build web
| applications- it's a fact.
| resignThis2021 wrote:
| I agree with you.
|
| My only, personal, issue with front-end is typescript - I
| don't enjoy it for some reason.
| chasd00 wrote:
| This is the problem
|
| >for experienced frontend software engineers
|
| web development skill varies wildly. Much more so than in
| any other branch of software development.
|
| btw, "backend SPA"? That web world has officially jumped
| the shark. "page" has no meaning outside of a web browser.
| backend single string application makes more sense than
| backend single page application.
| thebean11 wrote:
| > If your request to fetch new data and patch the DOM takes
| 5ms
|
| Even in the US people are still dealing with pretty bad
| internet in a lot of places. Even with the best internet, and
| assuming it takes 0ms to handle the request, 5ms sounds
| insanely optimistic. I'm in a big city and my ping (to my
| ISP's datacenters in the same city) is 10-20ms...
| yurishimo wrote:
| Sure. I'm being super optimistic there, but it's also worth
| noting that Phoenix uses a websocket so some of the latency
| in the handshake is negated for subsequent requests.
|
| Still, 50ms would probably be fast enough for a lot use
| cases, and if it's not, it's easy to configure debouncing.
| jgwil2 wrote:
| > Single-Page-Apps can be amazing.
|
| > You can make a great Single-Page-App with a User Experience
| that a traditional site will never be able to close to matching.
|
| What is actually meant by this? What is an example of a feature
| that can be far better in a SPA than in an MPA?
| resignThis2021 wrote:
| Spreadsheet apps in the browser?
| afavour wrote:
| You can persist data on the client with IndexedDB and make a
| SPA with zero load times no matter what page you're loading.
| That would never be possible with a MPA. It's also almost never
| something that _actually_ happens with SPAs but it certainly is
| possible.
| mwcampbell wrote:
| The best example I know of a purely client-side web app that
| makes effective use of local storage is the Pinafore [1]
| client for Mastodon.
|
| Edit: And it's worth noting that this app is a labor of love
| by an expert web developer, i.e. the antithesis of a typical
| corporate project.
|
| [1]: https://pinafore.social/
| DeathArrow wrote:
| It's the Web what Tim Berners Lee envisioned it to be, a web of
| "dumb" hypertext used to disseminate information or a web of
| interlinked apps which happen to run in the browser instead of
| desktop or mobile?
|
| In the 2000 it was clear: if you wanted to find informations, you
| went on the www. If you wanted to chat, you used an IRC app. If
| you wanted to type a document, you opened a text processor. If
| you wanted to see a movie, you used a movie player. If you wanted
| to listen to music, you opened a music player. If you wanted to
| game, you fired a game. Now all this are on the web.
|
| It's not clear to me if I am a web developer or an app developer
| because the borders are erased day by day.
| nyanpasu64 wrote:
| > the root cause of every bad Single-Page-App isn't that it's a
| Single-Page-App.
|
| The root cause of https://vector-of-bool.github.io/ scrolling
| incorrectly when navigating between pages isn't due to bad
| management or lack of care, it's because it's a single page app
| that didn't handle scrolling correctly (which a browser would
| provide for free), and the author didn't notice despite coming in
| with good intentions.
| snarkypixel wrote:
| That's the point of the article though. SPA is /hard/. Using a
| normal many-page app, you get scrolling that works across all
| browser - even mobile - for free, without having to do
| anything. I'm not saying I necessarily agree, but that's what
| this article is about.
| DeathArrow wrote:
| For me SPAs are when we want to run apps in the browser less
| efficiently than on the desktop or mobile, while taking more time
| to develop them.
| afavour wrote:
| This article rings very true to me. In my mind a badly managed
| project (and yes, these are legion) will accumulate complexity
| very quickly. The important technical difference between MPAs and
| SPAs is where they put that complexity.
|
| In a multi-page app the complexity largely lives on the server,
| which is a known quantity, profile-able and scaleable. In a
| single-page app the complexity lives on the user's device. There
| are innumerable variations in device power, capability and so on
| so there is no good sense of what "good performance" even is. But
| it'll work great on the developers supercharged MacBook Pros, so
| the code gets shipped.
| toddmorey wrote:
| Those interested in this debate really need to watch a very
| fantastic presentation on this exact topic: "Have Single-Page
| Apps Ruined the Web? | Transitional Apps with Rich Harris,
| NYTimes" [1]
|
| [1]
| https://www.youtube.com/watch?v=860d8usGC0o&list=PL58Wk5g77l...
| jonathan-adly wrote:
| I have been developing lately with A django/HTMX stack[0]. It
| covers a lot of the positives of JS SPA, without the headache.
| Also, I get to use the Django superpowers.
|
| https://htmx-django.com
| harryvederci wrote:
| Surprised htmx isn't mentioned more in the comments.
|
| I'm using it with Janet for a side project, really liking it so
| far. Writing server-side html with a hiccup-like library is
| very nice! :)
|
| (Clojure Hiccup library, similar libraries exist for other
| lisp-like languages: https://github.com/weavejester/hiccup)
| mwcampbell wrote:
| I appreciate that Django is a good old full-stack server-side
| framework, and there's a lot to like about that. But I can't
| bring myself to start a new project with something that has the
| gross inefficiency of CPython (or, IIUC, stock Ruby), as
| discussed at, for example, [1] and [2]. I want a runtime
| environment that's efficient enough that I can deploy the web
| application on a couple of small VMs, still have plenty of
| headroom for load spikes (which, in my experience, are usually
| due to screwups on my part and not actual demand spikes), and
| delay thinking about scaling as long as possible.
|
| [1]: https://rachelbythebay.com/w/2020/03/07/costly/
|
| [2]: https://blog.clubhouse.com/reining-in-the-thundering-herd-
| wi...
___________________________________________________________________
(page generated 2021-10-15 23:01 UTC)