[HN Gopher] The balance has shifted away from SPAs
___________________________________________________________________
The balance has shifted away from SPAs
Author : feross
Score : 220 points
Date : 2022-05-21 16:32 UTC (6 hours ago)
(HTM) web link (nolanlawson.com)
(TXT) w3m dump (nolanlawson.com)
| darepublic wrote:
| Yes to static prerendered pages. Yes to performance and
| functionality on slow networks. No thanks to "hip new frameworks"
| marcthe12 wrote:
| I do agree alot with the article. One of the major use case SPAs
| was optimization hack that service worker can do easily. Service
| worker are like proxy middleware and are capable of some nifty
| tricks. Since I am not in web dev that much so I never actually
| managed to develop a project using it, but I felt that the
| templating could done fully in service worker. It will be faster
| as long the templating/transcompiling is not a bottleneck as the
| on wire format will be smaller. The main issue will be
| bootstrapping as you need to load a page first to install the
| service worker. I wonder if there is a good solution to that?
| (One idea is a service worker middleware on node so you can the
| service worker in the server side on first time use).
| nolanl wrote:
| (Author here.) I totally agree and feel that Service Workers
| are still underexplored in this area. If your main reason for
| writing an SPA is speeding up navigation (e.g. the Turbolinks
| approach), then you may be better served by just moving the
| rendering logic into a Service Worker.
|
| It should be possible to build an "MPA" where all the rendering
| logic lives in the Service Worker. Then you'd get fast
| navigations without needing to worry about a client-side router
| and managing focus/scroll/etc. I'm not sure I've seen a great
| implementation of this though.
| gherkinnn wrote:
| The MPA/SPA dichotomy as is often presented is nonsensical.
|
| Sites built in Next, Remix, or whatever work perfectly well as
| MPA. Astro merely goes a step further.
|
| Pure SPA (as in a literal single route, maybe with horrible #
| based routing) is exceedingly rare and mainly found in legacy
| Angular code bases.
| nathias wrote:
| SPAs themselves have come increasingly towards this with SSR. The
| next step of web is merging both trends into a framwork that can
| combine the positives of both, which the libraries in OP seem to
| be. I'd like to see some comparisons.
|
| Edit: After some research I think SvelteKit is going to be the
| best new thing.
| hirvi74 wrote:
| Doesn't vue.js allow for this in some form with it's low
| barrier to commitment? I thought it could be implemented via a
| CDN alone without installing anything.
|
| Regardless, I have read one of the biggest benefits to vue's
| low commitment is that you can use it or forgo it whenever a
| developer wants, can add it to existing projects, etc..
|
| I will admit that I am far from well-versed in vue, so I could
| be mistaken.
| throwaway4good wrote:
| For internal apps in the corporate world, all I see now is SPAs
| based on vue react or angular.
|
| For consumer facing websites, where search engine viz is a
| concern and less is known about the clients browser, maybe it is
| different.
| VWWHFSfQ wrote:
| I think nearly every spa I've ever used was a piece of crap.
| There is just something off about them. It's almost like it's
| missing tactile feedback or something. And there's always goofy
| stuff that just doesn't work half the time. Like middle click to
| open a link in a new tab. So anyway. Good riddance
| dymk wrote:
| SPAs are like visual effects. You don't notice the good ones,
| because they just work. It's when they're poorly implemented
| that you notice they're SPAs. It's just a form of survivorship
| bias.
| cypress66 wrote:
| I assume you meant "You don't notice the good ones"?
| dymk wrote:
| Indeed!
| recursivedoubts wrote:
| thesis: web 1.0 hypermedia-based applications (clunky)
|
| antithesis: web 2.0 SPAs using JSON Data APIs (slick, but complex
| and & web-native)
|
| synthesis: web 1.5 apps using hypermedia-oriented libraries like
| htmx or unpoly (slick, web native)
| bestinterest wrote:
| Lots of credit for yourself with htmx, its great. I think I
| prefer unpoly myself but htmx is winning the popularity because
| of how vocal you are!
|
| I wish the unpoly creator also did similar! Both great
| frameworks. Hotwire also!
|
| I wish there was deeper comparisons on the big three
| recursivedoubts wrote:
| i always try to mention unpoly unless the discussion is
| specific to htmx because I agree: it is a wonderful library
| and henning is a great guy in general.
|
| Hotwire probably doesn't need my help, I think dhh has a big
| enough mic. :)
| robertoandred wrote:
| None of htmx's modal examples are accessible, doesn't give me
| confidence it can be used for serious projects.
| olliej wrote:
| I love how this credits the back/forward cache to chrome when it
| was a webkit feature chrome inherited. Much like almost every
| other "chrome" feature other than the process architecture (which
| was also the actual real engineering work they should have got
| credit for).
| matchagaucho wrote:
| "Headless CMS" is simultaneously all the rage (API first content
| management).
|
| If I had to generalize in broad strokes, decoupling the front-end
| from back-end using SPAs will be far more practical in B2B use
| cases. While consumer apps will benefit from MPA/SSR (server side
| render) where one page per product is easier to manage and
| bookmark.
| jcmontx wrote:
| Can anyone point me in the direction of any SPA framework well
| integrated with a backend framework that can make me as
| productive as Django, Laravel or Rails?
| tpetry wrote:
| This is not really what you had been asking for but inertia.js
| is doing a spectacular approach of combining Laravel and a SPA.
| All the benefits you have with MPAs and no need to build APIs
| for the SPA view part.
|
| That's the only SPA model I have seen which is a real
| productive approach.
| floucky wrote:
| SPA just use APIs so most of frameworks are compatible
| Nextgrid wrote:
| The problem is that you now need to either make resource-
| oriented APIs for every model in your DB that your frontend
| may need to access (even if just for internal business logic)
| or make RPC-style endpoints that do the business logic.
|
| That's significantly more work than just doing whatever logic
| you want on the server to begin with where you have access to
| _all_ tables directly (they 're an ORM call away) and not
| have to worry about access control because all of this still
| happens within the trusted environment of the server.
| vosper wrote:
| It's hard to know hot productive you are in those frameworks,
| but I'll take your question at face value: if you were an
| expert with NextJS, Typescript, and Prisma or Hasura then you'd
| be pretty dang productive.
| DangitBobby wrote:
| I think remix (remix.run) is really close. You can use it to
| easily build a site that fully functions with JavaScript
| disabled (seriously, at one point while building the demo app I
| disabled JavaScript and there was no observable difference in
| functionality), or one that just does SSR with hydration and
| client-side navigation. The framework is built and maintained
| by the people who did react-router and you can tell that it's
| very well thought out. It seems to fill a similar niche to
| Next.js but it has some clear "second system" advantages, IMO.
|
| I find myself very productive in it, especially compared to
| trying to build a highly interactive frontend on top of a
| Django app. The tutorial app on their website does a great job
| of demonstrating the capabilities of it and the patterns you'll
| expect to use, and you should be able to follow along in one
| long coding session.
|
| It doesn't have built in auth, admin, or ORM, but it heavily
| advocates for the use of Prisma which is probably your best
| option for ORM in js. So far, no node ORM really comes close to
| Django's in terms of capabilities. They don't really even try
| on the production-ready migrations system. However, you could
| always use Django to get auth (change your hashing to bcrypt
| and get a bcrypt lib from npm) and admin for free and use
| `prisma db pull` to keep your Prisma schema definitions (and
| corresponding type modules) in sync.
| B1FF_PSUVM wrote:
| What happened to defining acronyms in texts?
|
| Any civilians coming across this can't even find out what it is
| by searching unless they tack "software" after the word.
| [deleted]
| 11235813213455 wrote:
| something still annoying between navigatng pages normally Vs SPA
| history API is in first case you lose devtools network/console
| data from previous page (while developing at least)
| bcyn wrote:
| Look for a setting named "Preserve logs" to prevent the default
| behavior of clearing console/network log.
| davnicwil wrote:
| So I don't think this pendulum backswing is all that surprising
| or interesting on its own - it's been a journey to discover the
| edges of the SPA paradigm's capabilities and strengths and a
| retreat to pragmatism mostly.
|
| What I do find quite fascinating is that React actually started
| out pushing this kind of server rendered, pragmatic pieced-
| together approach from its very first days. Indeed, because
| that's exactly what the facebook website required - dynamic
| additions to a php-like fundamentally server-rendered site.
|
| I am not sure if I'm always interpreting this correctly but a lot
| of blogs I read about server rendering (the buzz TLA for which is
| now SSR) and the general per-page approach for React apps seem to
| be attributing the idea of the approach to a few of the newer
| frameworks that have appeared. Those frameworks are great and
| package up a load of this goodness, but ironically you don't and
| have never needed any such wrapping, nor any of the learnings of
| the SPA era, for any of this. It came out of the box in React
| before it even hit major version numbers. Somehow, the idea just
| never seemed to catch.
| encoderer wrote:
| These are interesting developments in the browser! Still, I don't
| think this headline conclusion is supported by the facts in the
| article.
|
| Of course "balance" in this context is basically meaningless but
| if you replace it with "consensus" it does mean something, and
| it's clearly not correct: the article makes clear we are still
| adding critical support at the browser level. Possibly, this will
| result in a renaissance of multi page apps, but we have to wait
| and see.
| adamnemecek wrote:
| I have been reading articles like this for the last 10 years. I'm
| not sure why people complain about SPAs.
|
| Guess what, in the mean time as some MPA frameworks have been
| made, the whole web has been moving towards webassembly. Say
| goodbye to MPA HTML, say hello to Rust with custom UI based on
| WebGPU transpiled to webassembly.
| Hayvok wrote:
| > I'm not sure why people complain about SPAs. ... say hello to
| Rust with custom UI based on WebGPU transpiled to webassembly
|
| If this is the future, then no wonder everyone is running back
| to just shipping HTML over the wire. All this has gotten too
| complicated.
| adamnemecek wrote:
| Right because dealing with CSS hacks transpilation to target
| older browser versions is both simple & pleasant.
| paulryanrogers wrote:
| Wait we have to support older browsers? IME if you're not
| on the latest Chrome release, or one prior, then you're on
| your own. Any other browser or older release is rarely a
| serious concern.
| hirvi74 wrote:
| I think Web Development has been trending towards being
| obnoxious no matter how you spin it for many many years now.
|
| All these frameworks, doing too much magic under the hood,
| were supposed to make things easier, in some form or fashion,
| but I feel like each one always come with their own problems.
| Are things actually easier when developing with them?
|
| While I understand nothing is perfect, it doesn't help but
| add so much complexity into many applications for no reason.
| If over half of all websites when back to plain HTML/CSS/JS,
| I do not think the world would suddenly stop.
|
| I feel like a majority of people building web applications
| are using a development methodology I read on here years ago
| that was jokingly called, "Resume-Driven Development." I've
| still not really ever heard a convincing argument for SPAs
| for websites (web applications could be a different debate,
| but it also could be a false dichotomy).
|
| However, I find myself getting urges to learn one of these
| SPA frameworks, not because I think it will benefit much of
| what I do, but because that is obligatory in staying
| competitive in my market.
| david2ndaccount wrote:
| If wasm becomes good enough to replace JS, it will not be rust.
| It will be easier to use languages like C#.
| adamnemecek wrote:
| If someone will build a GUI cross platform toolkit it will be
| in Rust, not C#.
|
| I find Rust more pleasant to use than C#. If you had said F#,
| I woud be like "maybe" but not C#.
| lowwave wrote:
| yeah while c# is more pleasant than Java, but not compare
| to the ease of a functional language.
| marcosdumay wrote:
| I disagree with calling C# "easy to use". But Rust is such a
| bad fit for wasm that any other language will probably
| displace it once it's viable.
|
| The DOM has it's own lifetime decisions, but lifetimes are
| the most central concern for Rust. I don't think both can be
| conciliated without a major rewrite of one of those parts.
| oblak wrote:
| As a JS developer, I think this is correct and kind of fear for
| my future. Time for this old dawg to learn something new again.
| Thing is, I think I am not good enough for system level
| programming. I've only done rust to the extend of going just a
| step beyond "hello world". I've also read good things about Go.
| Decisions, decisions.
| adamnemecek wrote:
| > think I am not good enough for system level programming
|
| I think that this is the wrong way to think about it, the
| languages and tools for systems programming suck. I would
| recommend you check out Rust, it make systems programming
| really pleasant. Like I have been programming C++ for 25
| years and somehow I'm a lot more comfortable with writing
| Rust even though I have seriously written Rust for only like
| 1.5 years.
| teg4n_ wrote:
| It really hasn't been moving towards web assembly. Web assembly
| is not magic performance pixie dust and it generally has pretty
| bad bundle size. You need pretty specific scenarios to get
| genuine improvements with web assembly over JavaScript.
| adamnemecek wrote:
| > magic performance pixie dust
|
| It is. I can finally have value types which let me access
| properties without incurring the overhead of a JIT.
|
| > and it generally has pretty bad bundle size
|
| For now. So do websites btw.
| nightski wrote:
| I build internal apps for my clients and this ship has sailed.
| They love the interactivity and quickness of a SPA. For a while I
| was doing application per page type of apps and it worked fine.
| But honestly maintenance has become a lot easier just making it a
| SPA. I have no idea why I'd go back to having to maintain a JS
| entry point per page instead of just one for no benefit
| whatsoever.
|
| Reading HN you'd think 99% of development is landing pages and
| blogs. Maybe it is? lol. But I have a feeling many here develop a
| lot more sophisticated applications including but definitely not
| limited to data analysis, charting, workflows and business
| processes, statistical analysis, optimization, and having a
| reload on every little operation makes things significantly
| slower from a user experience perspective.
| andybak wrote:
| > Reading HN you'd think 99% of development is landing pages
| and blogs.
|
| I would have said "Reading HN you'd think 99% of web sites are
| web apps". Most of the web is content with a light smattering
| of interactivity
|
| > They love the interactivity and quickness of a SPA.
|
| It's very easy to avoid the full page load without needing to
| go full-on SPA.
|
| > I have no idea why I'd go back to having to maintain a JS
| entry point per page
|
| I'm not sure what you mean here. "Progressive enhancement" was
| an excellent idea that didn't stick around for long enough.
| mmcnl wrote:
| Most of the web is content, but websites rarely are SPAs. If
| you only consume content you would hardly know about the
| concept of SPAs.
|
| I think it's weird to compare websites with web apps. Instead
| web apps should be compared to desktop applications. So many
| applications in the corporates have been replaced by web
| apps. In the company I work for there are 0 "desktop"
| applications other than Office, and even those applications
| you can use using a web browser. Then you see a massive shift
| and that balance is not shifting away at all.
| ebiester wrote:
| This is where I think the confusion lies. When I think of the
| tools that my teams build, they effectively are internal and
| external tools that happen to use the browser as a platform
| because nobody was able to converge on a universally-
| installed tool like java web start. Web applications
| proliferate because it entirely circumvented the problems of
| installing software.
|
| The places people are most enamored with SPAs are tools that
| effectively replace desktop applications. Consider Jira or
| Trello. These are effectively applications that happen to
| live in the browser. If you built progressive enhancement on
| trello, it would effectively mean building a parallel
| application.
|
| Multiple page applications do not have the ecosystem to make
| these tools easier to build. I have built these applications
| before SPAs became the dominant modality and after. The MPA
| has a long way to go to make this a good experience.
|
| Now I think it's great that content apps are moving away from
| SPAs. I think the only reason that people did this was to
| avoid the white flash, frankly, and I'm glad that chrome has
| solved this. I hope nobody is using react to build their
| content in 2022.
|
| However, we have a _long_ way to go before MPAs could replace
| SPAs in web applications. (And frankly, that time would have
| been better spent in building a tool that is truly fit for
| purpose rather than overloading the browser DOM, but I fear
| that ship has sailed.)
| stult wrote:
| I think there is a mismatch between the types of web
| content that the general public most interacts with and the
| types of web content which tend to have lots of development
| resources devoted to them. The ratio of SWEs to users is
| much, much higher for niche (typically B2B or internal
| business line) applications, which often require a fair
| amount of interactivity and custom logic. Whereas the vast
| majority of random web content used by the general public
| probably can just be hosted as static sites or server-side
| rendered apps with better performance and lower cost. HN
| then just reflects the underlying demographics of the
| industry and has a disproportionate number of people who
| work on niche applications where SPAs are still the more
| appropriate tool.
|
| Which makes sense given the economics. Consumer facing
| content is generally free to users and funded by ads so the
| dev costs need to be amortized across more content, which
| tends toward a lower touch, more scalable approach like
| static pages where there isn't much if any custom logic on
| any given page of content. Businesses on the other hand are
| willing to fork over cash directly to solve their problems
| so you get higher touch, more custom solutions where SPAs
| are relatively more useful.
|
| Also software engineering by its very nature automates
| routine tasks, reducing their costs and manual complexity
| dramatically over time to the point that a SWE isn't needed
| to carry them out. So none of us work on static sites
| because at this point it doesn't take a highly skilled
| engineer to set up, host, and scale one. One day SPAs and
| cloud native and k8s and all the latest fads may reach the
| same level of simplicity, and we will all be working on
| tuning hyper parameters on ML models or whatever else
| becomes the de facto cutting edge for the field.
| nathias wrote:
| I can't even imagine a person being "enamored" by Jira.
| rahilb wrote:
| The grand parent comment is likely referring to 'deep web'
| apps that you or I will never see, which probably replace a
| series of excel spreadsheets and email conversations.
| eyelidlessness wrote:
| You should take a look at the frameworks mentioned in the
| article. They each address some or all of your concerns. The
| distinction here isn't going back to "old school" MPA
| development, but a trend in component frameworks towards
| shipping more truly static HTML and less unnecessary JS.
|
| For the landing page/blog type experience, Astro is a great
| fit. Qwik is probably a better fit for your use cases as it's
| intended for more interactive apps. But both can span that
| interactivity spectrum. I can't speak to where Elder fits on
| that spectrum, not having used it and having little experience
| with Svelte.
|
| I'm disappointed not to see Marko mentioned, as it's been in
| this category for years and used at scale at eBay. It fits very
| well in the middle of the interactivity spectrum.
|
| Anyway, it's worth checking all of them out just to even see
| what's happening in the ecosystem. I'm personally very
| interested in Qwik's familiar React-like DX with what they call
| "resumability": their alternative to hydration; components
| compile to fine grained chunks and resume from state serialized
| to HTML, rather than re-running the original component on load.
| baisq wrote:
| SPAs are quicker because you use slow server-side languages
| that take a century to render an HTML template.
| linkjuice4all wrote:
| I've been mixing React with static exports from WordPress. It's
| unbelievable to say that I actually like this solution after
| spending years and years with PHP, custom JS front ends, then
| jQuery and the backend frameworks.
|
| React continues to get better and is great for highly
| interactive and customized experiences. Browsers are also
| making it more usable so it's just up to the front end devs to
| make sure history state and other stuff is accounted for.
|
| WordPress continues to be terrible but accessible to the masses
| for your landing page and blog stuff. That means your design
| and content team don't get bogged down in the app dev process
| and you don't have React slinging fixed/static content. They
| can just bash stuff around in WordPress and export the static
| pages for a quick deploy.
| purplerabbit wrote:
| What do you mean by "static exports from WordPress"? (never
| used WordPress before)
| linkjuice4all wrote:
| The Simply Static[0] plug-in exports all of your WordPress
| pages and assets into a directory that you can deploy. It
| basically renders the entire site and takes a snapshot of
| the rendered HTML.
|
| You'll lose dynamic features (but ideally you'll be doing
| that stuff in your React app) but the static site is very
| quick and you'll avoid some of the security headaches of a
| public WordPress instance.
|
| [0] https://wordpress.org/plugins/simply-static/
| timw4mail wrote:
| When is a SPA quick? I still have yet to see this claim EVER be
| true.
| sibit wrote:
| I've spent the last 2 years building B2B SPAs and, like
| everything in software, they can be fast or slow depending on
| how you build the app and what tools you use. I usually
| leverage lit-html, esmodules, and the dynamic import syntax.
| If you only fetch the business logic and views when you need
| them you can have an app that renders in seconds with an
| initial payload of ~15kb.
|
| I usually also set up a service worker to prefetch and cache
| the rest of the site while cache busting specific files on
| subsequent visits.
|
| Personally I use SPAs for offline support and MPAs for
| "portals" and brochure/marketing websites or blogs.
| treis wrote:
| >that renders in seconds
|
| That's really long.
| sibit wrote:
| Oh geese, I didn't realize that I forgot to add "on
| slow-3g". We usually aim for <1s FCP & <2s LCP. If it's
| ever above 5s on slow-3g we set aside time to
| optimize/refactor. Since our SPAs are offline-first the
| return visits (usually 3-5 times a day based on the
| customer) is on the scale of milliseconds.
| robertoandred wrote:
| https://reactjs.org/docs/getting-started.html is a fast SPA
| kkirsche wrote:
| Define what quick means to you. They can be extremely good at
| responsiveness and background updates once the bundle has
| been loaded
| steve_adams_86 wrote:
| Prefetching content means you can literally load a new page
| instantly without rendering anything but the new content. It
| is inherently faster once the initial page has loaded, and
| the JS no longer needs to be all that large to accomplish it.
|
| Like any technology, using it in the right place helps. This
| is great for documentation where the template and content
| slots are super consistent, for example.
|
| There are places it's not a great choice. It isn't inherently
| worse, though.
| jabart wrote:
| If your non-spa app requires a page load per an operation, my
| opinion is someone built it wrong. You can do a lot with < 200
| lines of JS to make a page interactive.
|
| Legacy apps were rebuilt as SPAs and rebuilding them made them
| faster.
|
| "Spinning wheel of doom" is used by users now to describe
| delays in both SPA and non-spa web applications. Same tricks to
| make a SPA feel responsive work for both styles.
| cjbgkagh wrote:
| I find the more interactions I add to a non-SPA the more SPA
| like it becomes.
| dymk wrote:
| In 200 lines of JS, you can add maybe an interactive file
| uploader, or a tooltip implementation, and some form
| validation. But good luck doing anything of "business-tool"
| complexity in 200 lines that constitutes an application.
| Spivak wrote:
| Yeah I'm so confused what people think "interactivity" even
| means, like do people think interaction ends at "make the
| hamburger menu open and close?"
| NoWizards wrote:
| Its more like the time to become interactive. Even if
| internet and smarphones are fast. Sometimes it's pretty
| annoying to click an unresponsive page... just because
| it's loading-starting a lot of js
| TedDoesntTalk wrote:
| Dynamically replacing a div, based on a DOM event, with
| results of a fetch call can be done in way less than 200
| lines of JS.
|
| But why you'd do that instead of using 10 MB of React
| code, I don't know.
| dymk wrote:
| How do you get 10MB of React code when React is 0.031MB,
| and Preact is 0.003MB?
| TedDoesntTalk wrote:
| I'm exaggerating to make a point :)
| mmcnl wrote:
| What is the point? Optimizing for lines of code is a
| wasteful target. I thought we all knew that by now? Great
| that you can demonstrate that you can do something
| without React where others are using React, but that's
| not the point at all.
|
| If you do more than a few asynchronous calls you will
| quickly find yourself developing your own DOM
| abstraction. That's a waste of time because React and Vue
| already exist, and have existed for years, and are battle
| tested.
|
| SPA frameworks also give you the ability to write your
| applications in a declarative way, which is _far_ easier
| and way less error prone, thus easier to test, than
| imperative DOM modifications.
| bzxcvbn wrote:
| Your point is literally the size of the framework.
| Getting it wrong by more than two orders of magnitude is
| not exaggeration, it's a false argument.
| [deleted]
| jhgb wrote:
| Are you sure that something like PJAX wouldn't bring you like
| 80% along the way from MPAs to SPAs, as far as "interactivity
| and quickness" is concerned? Or did you already try that?
| my69thaccount wrote:
| Do your clients have any accessibility needs?
| Etheryte wrote:
| Accessibility has nothing to do whether your page is cut up
| in one way or another. You can build accessible pages that
| are SPA and unaccessible pages in any other way all the same.
| Most if not all accessibility issues stem from lack of
| education on the matter, rather than technical limitations.
| paulryanrogers wrote:
| One can drive screws with a hammer. It will just take more
| effort.
| my69thaccount wrote:
| SPAs are inaccessible by default.
| azemetre wrote:
| Could you expand upon this? Do you mean the lack of
| routing or something else?
| my69thaccount wrote:
| SPAs reimplement accessibility features in JavaScript to
| the best of their ability. This has created an arms race
| where screen readers need to execute JavaScript and use
| heuristics to determine what's on the a page.
|
| Everyone who down voted me is a total idiot.
| nickreese wrote:
| Author of Elder.js (mentioned in the article) and avid lover of
| both MPA and SPA.
|
| Daily I am writing MPAs for SEO assets and SPAs for internal
| dashboards used to manage the huge amount if data collection our
| teams do.
|
| It really boils down to what you are building.
|
| Google is decidedly terrible about indexing JS for sites with a
| low crawl budget. Why make your life harder. That is why I wrote
| Elder.js. Statically generate everything, sprinkle in
| interactivity where needed.
|
| But for internal dashboards I developed a internal framework to
| spit out crud apps based on nothing more than a couple graphql
| queries and a couple yupjs validations. It is a breeze and adding
| new data collection fields takes minutes so I and my team can
| focus on stuff that drives business value... instead of crud.
|
| As with everything picking the right tool for the job makes the
| job a lot easier. Don't give into the hype one way or another.
| kaycebasques wrote:
| Discussions about website architecture become a lot more
| productive when you use Jason Miller's holotypes idea [1] as your
| starting point. "Holotypes" is kinda just a fancy word for the
| common top-level uses of the web. E-commerce, search, media
| player, etc. With that foundation it becomes obvious that SPAs
| make a lot of sense for some holotypes and a lot less sense for
| others. We waste time when we talk as if MPA or SPA is
| appropriate for _all_ website architectures because neither are
| and never will be. The uses of the web are just too broad at this
| point.
|
| [1] https://jasonformat.com/application-holotypes/
| mwattsun wrote:
| I'm generally opposed to jargon in tech writing so the use of
| 'holotype' caused me to look it up. I'm not sure it works. For
| example, by the definition Hotmail should be the holotype
| instead of GMail, which would be the paratype. (if I'm reading
| it right, I am not a zoologist.)
|
| _How Hotmail changed Microsoft (and email) forever_
|
| https://seforum.se/2019/01/08/the-history-of-hotmail/
|
| https://en.wikipedia.org/wiki/Holotype
|
| https://en.wikipedia.org/wiki/Paratype
| kaycebasques wrote:
| For sure it's a terrible name (sorry, Jason ;P). In my other
| comment I talk about my experiences pitching this idea when I
| was https://web.dev content lead. There's something about
| this word that is an immediate turnoff and prevents people
| from really looking deeply at it. Which is a shame because
| it's _such_ a useful mental model.
|
| Names are important!
| arthurcolle wrote:
| > if I'm reading it right, I am not a zoologist.
|
| This had me in stitches. I'm also not a huge fan of
| obfuscatory jargon, irrespective of how cromulent such
| language may be.
| dvngnt_ wrote:
| but then you used the word "cromulent"
| jjtheblunt wrote:
| as a self-referential joke, hopefully!
| vosper wrote:
| Yes, they could have just listed examples and done without
| the "holotype" term. I don't think it detracts from the point
| of the post, though.
| heavyset_go wrote:
| Something rubs me the wrong way about unnecessarily
| obfuscated jargon for relatively simple concepts in web
| development. The term "isomorphic code" has been living rent
| free in my head for like a decade and it still drives me
| nuts.
| vosper wrote:
| Thanks for this, I liked it.
|
| I'd recommend anyone who's posted for/against some web practice
| to read it.
|
| Maybe one day we could all collectively acknowledge that people
| work on different stuff, with different goals and under
| different constraints, and there isn't actually one right way
| to build for the web. It's such a tiresome part of HN.
| sodapopcan wrote:
| I don't believe that (all of) the people who get frustrated
| by these things don't understand that different problems
| require different solutions, it's when the majority of the
| industry (or more likely an influential minority) starts to
| say, "Hey! Let's build EVERYTHING this way" that that people
| start to complain. And I say this is warranted as it affects
| the job market. SPAs have their place (highly interactive
| applications that more closely mirror traditional desktops
| apps, I would say, the main one) but so many companies out
| there are developing their apps as SPAs that have no business
| being such and some of us would rather not have to deal with
| that (I've experienced this first hand).
|
| The other side (or one other side) of the coin, of course, is
| that our industry is super new and we're all still figuring
| it out. I always liken out industry to thinking about how
| long it took to standardize the hammer design we have to day.
| I don't have the exact stats, but I'm thinking it was
| probably 100s of years and our ancestors had many a fight
| over a big rock vs a plank with a bit small bit of steel on
| the end of it being the better choice.
| dylan604 wrote:
| Yes, just like _____ written in [Go|Rust|flavoflav].
|
| However, at the beginning of every project, this conversation
| should be had. What are the needs of the project, what gets
| us there fast while still allowing to grow after scopecreep,
| what is going to allow for maintanence and future needs?
|
| Picking the latest tech just because it's a new project and
| you want to use the _NEW_ on it just for the sake of it will
| probably mean finding yourself painted in a corner in the
| future (or maybe not the original dev, but those that are
| forced to follow).
| vosper wrote:
| Of course, a discussion should be had, choices should be
| weighed.
|
| But since you mentioned "new just for the sake of it" I'll
| mention that I think that's overplayed, too. If you picked
| React when it was new, or GraphQL, or NextJS, then you
| probably made a pretty good choice. Backbone was the first
| of the modern MVC frameworks to get traction (someone will
| correct me on this) and if you'd chosen that when it was
| new it would also have been a pretty good decision. Kafka's
| still around and going strong, wouldn't have been a bad
| choice early-on.
| lazide wrote:
| It's risk/reward trade offs.
|
| If you can afford high risk (React at the beginning?) and
| it works, you're in a sweet spot for a long time.
|
| Most of them don't pay out though, and most JS frameworks
| that got started around that time died long ago.
| kaycebasques wrote:
| I think it's also relevant to mention that I spent a lot of
| time thinking about whether web developers at large should use
| SPAs or MPAs. It'll take a bit of my history to explain.
|
| I was content lead for https://web.dev from 2019 to 2021. My
| job was to create and execute the content strategy of the site.
| The mission of that site was [1] to provide actionable insights
| on how to build better websites. But the big challenge is _how
| do you provide guidance for the web at large??_ We know through
| MDN surveys, HN discussions, Twitter, etc. that many web
| developers are _drowning_ in uncertainty around how to
| architect their website. Which framework to use is a key
| uncertainty. MPA or SPA is another one. So to me this was the
| obvious opportunity for https://web.dev. Help web developers
| make better architecture decisions and the overall web
| experience is bound to get better. But if you've seen web
| developers talk on Twitter you know that these are landmine
| topics. If you don't handle it extremely delicately and
| respectfully and fairly you are setting yourself up for a
| tsunami of vitriol. This is 10x true for anything that the
| browser vendors do or say (a lot of Googlers work on
| https://web.dev).
|
| So here's where holotypes comes in. When I read holotypes I see
| a very useful framework for understanding website architecture.
| And it provides a way to logically/fairly recommend SPAs or
| MPAs. The answer is that it depends on your use case. If you're
| building a content-heavy, interaction-minimal site like
| Wikipedia then no duh an MPA is probably the right call. If
| you're building a media player like Spotify though then a SPA
| makes a lot more sense. You can use the same logic to figure
| out which framework is probably best for you.
|
| So going back to my personal history. I pitched holotypes as
| the overarching information architecture [2] for
| https://web.dev. It didn't really go anywhere. The main reason
| was that I was just too green as a leader/manager to push
| through a big change like this (or I'm just not a very
| effective leader/manager in general). I still think holotypes
| is a phenomenal way to think about website architecture and I'm
| honestly sharing all this to encourage someone to carry the
| torch and create a website that guides you through which
| website architecture (and framework) to use based on your
| holotype. Happy to chat with anyone about it further just poke
| around on my HN profile page to figure out how to contact me.
|
| Also hopefully it goes without saying that this is all just my
| personal opinion/experience and doesn't represent Google. I'm
| not even working on the web anymore. Working on Web DevRel for
| Google or any of the other browser vendors is very delicate
| work and to all my former colleagues I hope I shared the
| history respectfully/accurately. My intention here is to share
| a key idea on how to make the web better (help web developers
| make better architecture decisions) that I'm never going to
| personally pursue. If you do this "guiding architecture
| decisions based on holotypes" idea right it doesn't really
| matter who "owns" this because all of the decision weighting
| logic/data will have to be rigorously fair/balanced/open or
| else it will never take off because one of the vested interests
| in the web developer ecosystem will mount a campaign to
| discredit it.
|
| [1] It probably still has the same mission. I'm only saying
| "was" because I'm no longer on the project. I quit Google in
| June 2021 for a sabbatical and returned last week working on
| something very different, Fuchsia!
|
| [2] https://www.usability.gov/what-and-why/information-
| architect...
| kaba0 wrote:
| I also think that with today's choices of web technology,
| separating solutions by "holotypes" is the correct thing to
| do. But on non-web platforms there is no such choice, yet
| every holotype has a place. Sure, other platforms has
| sometimes different requirements, but I do believe that
| ideally there should be a single unifying way for both kind
| of webpages/applications.
| yhoiseth wrote:
| Thanks for sharing.
|
| Have you considered adding a "business app" category?
| Thinking of things like CRMs and learning management systems.
| Maybe Salesforce would be the holotype?
| sanderjd wrote:
| Yeah this is super helpful!
| my69thaccount wrote:
| The holotypes that are best expressed as SPAs don't belong on
| the web.
| wrycoder wrote:
| Isn't QuickBooks Online a (multipage) SPA?
|
| Running it on the desktop is far inferior, because a great
| advantage of QBO is the ability for several people,
| distributed worldwide, to work on the same account at the
| same time.
| svachalek wrote:
| Yup same with Google Docs. And there are plenty of other
| SPAs like Google Maps that just work so well that way, that
| it's hard to see the argument for banning them.
| lazide wrote:
| 100% agree, and people are have been slowly figuring that
| out. The front runners were the mobile App folks. But it's
| going to take awhile for the tide to turn fully again.
|
| I'm curious if Java desktop is going to make a resurgence, or
| something else will. Platform native Windows dev never really
| died, but the market definitely shrunk.
| mgaunard wrote:
| People fail to realize that these silly one page websites were
| invented because they're easier to consume on mobile.
|
| Just ask yourself who your users are and what workflow makes
| sense for them, and build something accordingly.
| [deleted]
| zkirill wrote:
| Our web product went from AngularJS to React to Angular to
| Angular + Spring. The addition of Spring helped us introduce a
| useful constraint: if you can build it as an old-school page with
| Spring, don't put it into the SPA. Angular is reserved for deep
| core business logic and UI which would be impractical to build
| anywhere else. One of the biggest benefits is reducing our
| Angular project complexity, making it easier to keep current with
| Angular updates. I am happy to hear that SPAs are no longer sexy
| because this sounds like the landscape has matured. For example,
| Angular started doing LTS releases.
| dimgl wrote:
| This sounds needlessly complicated.
| zkirill wrote:
| Maybe, shoot me an email if you want to chat about it kirill
| at getfillet.com
| TekMol wrote:
| Where are those SPAs everybody is talking about?
|
| All sites I use regularly are MPAs:
|
| Hackernews, Amazon, AirBnB, Booking.com, Wikipedia, GithHub ...
|
| Reddits new design is kind of a hybrid. It is MPA when you hop
| between subreddits and other pages. But it shows a post on the
| same page when you click on it in a subreddit feed. I actually
| are annoyed by the new Reddit enough to switch to old.reddit.com
| most of the time when I end up on Reddit. Not sure why. But maybe
| it tells something, that the only "somewhat SPA" I know makes me
| switch to its MPA version regularly.
| avel wrote:
| Facebook, Twitter.
| 88913527 wrote:
| The best apps seem to be fully MPA or SPA. The hybrids have UX
| problems. It's arbitrary some things require a hard page
| navigation, and others don't. I mean, it's probably an
| intersection between product/engineering teams, but as a user
| of an application, I have no real visibility into that nor
| concern for it; I just see the dichotomy.
| [deleted]
| NewEntryHN wrote:
| It's called "applications" because it's not "sites". Slack,
| Gmail, etc.
| tshaddox wrote:
| YouTube, Facebook, Instagram, and Twitter are the obvious
| examples from among the top 10 or so most visited websites in
| the United States.
| TekMol wrote:
| What is SPA about YouTube? It feels completely MPA to me.
| tastemykungfu wrote:
| If it feels completely MPA to you - then they pulled off
| their SPA implementation :)
| NovemberWhiskey wrote:
| Minimize a video so it's playing in the corner of the
| browser; notice that the video continues to play seamlessly
| as you navigate around the site. You can't do that in an
| MPA right now.
| seydor wrote:
| That s super annoying btw . Frankly video is best browsed
| like a traditional multi page listing, like how porn
| sites do it
| shrimp_emoji wrote:
| But pages are difficult on mobile devices.
|
| So are controls or useful UI or... :D
| seydor wrote:
| i dont get why they are difficult on mobile? inf
| scrolling is worse. Especially on android which has a
| back button everywhere. I think ppl should be more
| mindful of the megabytes of javascript that people have
| to download just to see a list of images
| capableweb wrote:
| You could in theory do that although the experience would
| be slightly odd. Either open the video in a new page and
| put in the bottom right, force focus it after the main
| window been active. Or wrap the entire websites in two
| iframes, one for main content and one for video player.
| Main content can change without interfering with the
| video player.
|
| Not saying you should do either of these, as the UX would
| be worse, but you could if you really want to :)
| 323 wrote:
| It's an illusion. If you look carefully you'll see that all
| YT content is loaded dynamically, starting from a blank
| page with a blank video player.
| eyelidlessness wrote:
| The only distinction that matters is whether it has a
| client-side router. If it feels like an MPA, and doesn't
| feel slow, that can be easy to miss. But it's still a SPA.
| Jcampuzano2 wrote:
| When an SPA feels snappy enough/works well enough that you
| confuse it for an MPA, it means they are probably doing it
| right.
| Akronymus wrote:
| I have a redirect set up for shorts to redirect me onto a
| normal site. As youtube loads the content dynamically, then
| sets the URL it doesn't work unless I open the short in a
| new tab or do a f5.
|
| Seems SPA to me.
| [deleted]
| enra wrote:
| Apps, not sites. It's even in the name, Single Page
| Application. You probably shouldn't build websites as SPAs but
| you probably should build most apps as SPAs.
|
| Slack, Dropbox, Google, Notion, Spotify, superhuman, 1Password,
| Robinhood...
|
| Basically most web tools/apps are SPAs if they have been built
| in the last ~10years. Github, Reddit and Airbnb were founded
| ~15 years ago when Rails was still a thing.
| s__s wrote:
| > You probably shouldn't build websites as SPAs but you
| probably should build most apps as SPAs.
|
| As a frontend dev this has always been my stance, but I've
| been consistently shunned for it.
|
| How much of that was naivete vs. misaligned incentives I'm
| not sure.
|
| In any case, these thing always leave me with the feeling the
| industry is getting way too saturated with script kiddies. It
| just feels immature, and the culture that's grown around web
| dev seems to reflect that. Or more likely I'm just bitter and
| old.
| brailsafe wrote:
| I liked to put the line between whether you're required to
| sign in to use it or not. If none of the data was
| necessarily publicly accessible anyway, that's more of a
| spa suited interface
| MrBuddyCasino wrote:
| People largely don't think for themselves, every once in a
| while the firmware gets updated and they have a new
| opinion. All you can do is pick your battles, there is
| finite amount of credits to spend.
| teakettle42 wrote:
| OS developer here. You're all naive children playing in our
| sandbox, arguing over what color to paint your sandcastles.
|
| Or more likely I'm just bitter and old.
| mLuby wrote:
| Purity: https://xkcd.com/435/
|
| Farmville Devs <- Facebook Devs <- Chrome Devs <- OS Devs
| <- Chip Devs <- Factory Devs
| vbezhenar wrote:
| IMO the distinction is simple. You want Google to index your
| website. You don't want Google to index your webapp.
|
| I'm aware that Google can run JS, but its support is limited
| compared to server rendering and there are other crawlers
| behind Google which probably will never be as sophisticated.
| Mordisquitos wrote:
| Yes, sure. If you don't want Google to index your online
| service, one way to do it is to design the whole thing as
| an SPA, with all the added complexity and reinvention of
| the wheel that it involves.
|
| The other way is to add a few lines to your `robots.txt`.
| andyp-kw wrote:
| Rails never went away.
| mostlysimilar wrote:
| Rails is still "a thing" and is better today than it has ever
| been.
| kache_ wrote:
| only because the companies that use rails are stuck on it
| :P
| djfobbz wrote:
| Majority of the ones I know are making billions. Why
| change something that's already profitable?
| hirvi74 wrote:
| Really? I miss it sometimes. I haven't kept up with it in
| over 5 years (switched to .Net now).
|
| I am just curious, why would I use Rails over something
| like .Net in today's time? I am no apologist for .Net or
| anything, I am just genuinely curious.
| dghlsakjg wrote:
| Rails has added a lot of cool built in stuff. SPA like
| stuff that is done over sockets but written in ruby
| (Hotwire is the name of it) is the most germane to this
| conversation.
|
| But all t he other stuff common to popular libraries
| still applies, tons of community support, huge
| extensibility, large population of devs that have
| experience building large apps.
| DeathArrow wrote:
| With net you can accomplish the same with HTMX. And you
| can do the a SPA frontend fully in C# using Blazor.
| jhgb wrote:
| I imagine that one reason why you might want to use it is
| if you don't like the "let's reinvent the wheel
| incompatibly every three years" approach from the .NET
| world.
| hirvi74 wrote:
| I'll be honest, this made me chuckle.
|
| You are not wrong though, and it's quite annoying when
| hopping between multiple .Net versions. I feel like I
| have a bit of insight into what it would have been like
| to be developing in Python during the 2.x to 3.x schism
| years back.
| swat535 wrote:
| I don't think there is any particular "reason". Majority
| of the languages and tools are really good enough to
| achieve 90% of business use cases out there.
|
| Unless you have some specific requirements for you app
| like high concurrency or memory safety and so on, then
| you can pick whatever you (or your team) are most
| comfortable with: Django, Rails, Symphony, .. are all
| excellent.
|
| It's more about solving business problems and building
| great systems than anything else. All tools have pros and
| cons of course, it's simply up to us to review the
| requirements and pick the right one for the job.
| [deleted]
| jb3689 wrote:
| Hot take: Phoenix does almost everything Rails does but
| better. Ruby is still superior for scripting, but OTP
| gives you so much flexibility for integrating your
| backend (supervision is built in, process abstraction is
| built in, rpc is built in, microservice architecture is
| built in). The only other thing I don't care for with
| Phoenix is the amount of metaprogramming which I think is
| even worse than Rails
| paulgb wrote:
| I haven't kept up with either, but remember that "because
| you know it" is a perfectly reasonable and fine reason!
| travisgriggs wrote:
| I struggle with this a little. Or rather, I struggle with
| the counter corollary: "Because you don't know it."
|
| I mean, I solve most of my problems with the hammers I
| have at hand. But I try not to fall _exclusively_ in this
| trap of "I will use tech X because that's what I know."
|
| But I see a majority of my programming peers who will
| avoid moving "forward" because it's easier to "stay
| behind." At first, this works, because the difference
| between what's new and evolving versus what's established
| and a "core competency" is trivial and easy to
| marginalize. As it persists over time though, the
| investment can become a real millstone.
|
| I am pretty comfortable with Python. We use it some
| pretty key areas in our product. It's an established
| technology and competency for us. Last year, I needed to
| construct a service that was going to involve spinning up
| LOTS of little long lived threads. I was concerned about
| doing this in Python. Doing so would be easy and
| straightforward. "Because I know it" would definitely
| have said "do this in Python right now, deal with scaling
| issues later." Instead I looked around and deemed this a
| good reason to take Elixir for a spin. I'm glad I did. It
| turned out to be a good fit for this problem. "Because I
| don't know it" caused others around me to raise their
| eyebrows and question my approach initially. Was it the
| 100% best choice? Who knows for sure. But it's worked out
| well. Ironically, just the other day, a data
| serialization library I have in both systems, the Python
| one needed to run faster (new use case for it suddenly
| needed speed that we didn't hitherto care about). After
| some profiling, I rearchitected the python algorithm to
| be more similar to the Elixir one and gained about 50%
| speed up.
| msbarnett wrote:
| Because you or a team knows it, because it's still a hell
| of a lot more of a batteries included ecosystem than the
| last Scala or node projects I was involved in which had
| to reinvent a shocking number of wheels that are table
| stakes in Rails-land (can't speak to .net, never been an
| MS stack dev), because you're working with some other
| Ruby or Rails thing and its easiest to stay compatible,
| because there's a lot of mature, profitable projects out
| there hiring in it with high salaries ;), etc
|
| It's an engineering decision with tradeoffs, like every
| engineering decision.
| CPLX wrote:
| If the Shopify ecosystem was the _only_ example of rails in
| existence then rails would still definitely be a thing.
| pcmaffey wrote:
| The distinction is between websites as documents and websites
| as applications. Both are still websites.
| dmje wrote:
| Couldn't agree more, been saying this for years. There are
| moments when an "app-like" experience is what's required -
| and that's mostly (not always but mostly) when these SPAish
| approaches are relevant.
|
| On big, sprawling, multipage content-rich websites, not so
| much if at all.
|
| It depends. Web people should have this tattooed on their
| foreheads.
| karmakaze wrote:
| I was expecting a discussion of native, cross-platform or
| hybrid apps. Single or multi-page application/site barely
| registers as a distinction to me like it once did with faster
| mobile networks and devices.
|
| I'd venture to guess that even an MPA comprising multiple SPA
| 'pages' is an unsurprising composition especially for captive
| audience apps like internal, or government etc.
| TekMol wrote:
| Slack, Dropbox, Google, Notion, Spotify, superhuman,
| 1Password, Robinhood...
|
| I don't use any of these. With the exception of Google (the
| search engine). Which I don't think is a SPA. When I type a
| search query and hit enter, it loads a new page. When I click
| on the next page at the bottom, it also loads a new page.
| gunapologist99 wrote:
| Both Google Maps and Gmail were among the very first SPA's.
| eschaton wrote:
| Nah, you should build most apps using operating systems'
| native toolkits, and stop trying to pretend web pages are
| applications.
| muxator wrote:
| > Google
|
| If you mean "google" as "google properties as a whole", then
| yeah (the fusion of google maps and google earth is something
| absolutely _mind blowing_ to see in a web browser, for
| example).
|
| If you mean "google" as "the search engine", then I was
| perfectly fine with a server side rendered, non-so-much-
| semantic search it was until last decade. Advanced search
| worked well, fast as hell already. Hell, there were two
| search text boxes if you wanted to search for something else
| once you scrolled down to the bottom of the page.
| criddell wrote:
| What are the primary characteristics that distinguish a web
| site from a web app?
| snowwrestler wrote:
| For me it is reading vs doing.
|
| When you first go to aws.amazon.com, you get a website with
| content about AWS.
|
| Once you log in, you're in the AWS web application, and
| it's time to start doing things.
|
| Forums like HN, I would consider websites because there is
| a lot of reading and not much doing.
| jvalencia wrote:
| I would say interactivity. A spreadsheet for example, you
| are constantly modifying rows. You want that in memory in
| the browser, not on a server, where you need to constantly
| be making ajax calls.
|
| How many micro-interactions do you want --- the more you
| have, the more likely you want an application rather than a
| site.
| em-bee wrote:
| i'd say the dynamic of the content.
|
| anything that can be done offline ought to be an SPA so
| that it can be made to actually still work without internet
| access.
| Avshalom wrote:
| number of pages
| glitcher wrote:
| At a very superficial level, HN feels like a website and
| logging in to do my banking feels like a web application.
| But trying to drill down into specific definitions or draw
| a clear line between them seems to fall apart quickly. So I
| guess for me at least I really don't know the answer, but
| also don't think it's terribly useful to make a distinction
| either.
| edflsafoiewq wrote:
| A bank should be a website (if only my bank would
| agree...). If you're making a Photoshop clone in the
| browser, that's web app territory.
| krapp wrote:
| >But trying to drill down into specific definitions or
| draw a clear line between them seems to fall apart
| quickly.
|
| The only clear line I've seen is javascript. If it uses
| javascript for anything nontrivial, people believe it's a
| web app. This comes up all the time in threads about "the
| old web" or "how you would fix the web," in the context
| of what seems to be a prevalent belief on HN that the web
| should be split up between the two paradigms, with purely
| static, noninteractive "sites" in one place, and "apps"
| in the other.
|
| Problem is, as mentioned upthread, the vast majority of
| sites using javascript, including SPAs, are still _meant
| to be read as documents._ If you include any form of
| interactivity, including backend processing and
| rendering, even more sites become apps.
|
| In practice, it seems to me to be more of a religious
| taxonomy than a technical one, based on the belief that
| the modern web has become tainted by complexity and needs
| to be made pure again.
| dmje wrote:
| Possibly old fashioned view here but I think of it in two
| ways.
|
| Firstly if it's "transactional" it fits more often into the
| label of "application". If it is there mainly for
| consumption of media, it's more "Web site".
|
| Secondly, I think it's useful to think about what it'd feel
| like as a desktop app. Stuff like say Google Sheets would
| feel perfectly normal running on your desktop. It's super
| snappy, all on-page. Something like the BBC or HN, not so
| much.
| mmcnl wrote:
| I'd say there's is not a clear definition, but I think: low
| interaction intensity / no personalized experience =
| website, high interaction intensity / personalized
| experience = application.
|
| Wikipedia and blogs are mostly for consuming content and
| it's the same content for everyone. Clearly a website.
| Instagram usually isn't super interactive, but it's
| extremely personalized, so it's much more like an app.
| Gmail also clearly a web app.
| dymk wrote:
| Airbnb is not a SPA in the sense that it's a _single_ page, but
| the main pages of the site contain a lot of interactivity, and
| IMO individually constitute at least mini-SPAs.
| dingleberry420 wrote:
| > I actually are annoyed by the new Reddit enough to switch to
| old.reddit.com most of the time when I end up on Reddit. Not
| sure why. But maybe it tells something,
|
| For me it's because the new design is hilariously slow in every
| way. And also it looks really, really bad. Meanwhile
| old.reddit.com loads instantly and doesn't burn my retinas.
| epistasis wrote:
| I think new Reddit is intentionally terrible, and incorporates
| SPA attributes, purely to make the experience unpleasant and
| drive app usage. They offer old.Reddit.com so that some core
| users don't leave, but those users might not be needed forever,
| if a different user base can be cultivated.
| eyelidlessness wrote:
| GitHub is definitely not an MPA. Or at least most of the core
| functionality people use for work isn't. It feels like one
| under ideal network conditions, but if your connection stalls
| you can see its routing stall before any attempt to load a new
| page.
| bdcravens wrote:
| Github is a Rails app, and leverages Turbolinks which does
| partial page renders (but still keeps routing server-side)
| msbarnett wrote:
| GitHub is an MPA Rails app that uses turbolinks to make page
| transitions quicker, which is what you're seeing stall. No
| routing is done client side.
| maxloh wrote:
| Navigations within the same repo are powered by client side
| routings (e.g. from "Code" tab to "Issue" tab).
| msbarnett wrote:
| No? I'm looking at the request in webinspector right now.
| GitHub is kicking back the full partial for the issues
| tab, and turbolinks JS is then swapping out the relevant
| DIVs -- it's a bog-standard Rails MPA server side routed
| setup, I think you're just letting the turbolinks
| animation convince you there's more happening on the
| frontend than really is.
| dmix wrote:
| Github uses something called View Component to render
| 'partials' (aka components) which is a bit more
| sophisticated than just Turbolinks and IMO the future of
| complex web apps
|
| https://viewcomponent.org/
|
| It's the right balance in-between React/SSR hydration and
| Railsy server-side apps, taking the best of both worlds.
|
| This is a really good talk about how we got here from
| Jquery->Backbone.js->SPAs +
| React/Vue->Stimulus/ViewComponent/ActionCable
|
| https://www.youtube.com/watch?v=sIxvxp7E0xg
|
| There's another similar project called AnyCable which
| combines websockets with an ActionCable style approach:
|
| https://anycable.io/
| eyelidlessness wrote:
| > It's the right balance in-between React/SSR hydration
| and Railsy server-side apps, taking the best of both
| worlds.
|
| This is similar to how React Server Components work,
| except that they work for arbitrary server-side rendering
| updates to the client as well as navigation. And it's
| conceptually similar to how Qwik works, only the
| "partials" are typically client chunks. And again with
| Qwik, not tied to navigation, but that's pretty much how
| I'd imagine a client routing solution for Qwik would
| (will?) look.
| msbarnett wrote:
| Eh, we use ViewComponents inhouse at work too, and
| they're great, but they're really just a better way of
| approaching partials instead of the normal "grab the
| Controller's ivars" free-for-all -- they don't move the
| needle any on the MPA front, and they change nothing
| w.r.t turbolinks (or any client side JS), since they're
| purely a server-side rendering time thing.
| dmix wrote:
| I'm more interested in the concept of ViewComponents than
| just the current library. It's really just starting with
| Rails adopting ActionCable and Phoenix using LiveView
| (which I see as both immature proto-concepts of the
| future of JS frontends).
|
| This blog post (and my linked talk above) opened my eyes
| on the subject:
| https://evilmartians.com/chronicles/anycable-actioncable-
| on-...
|
| Right now the complexity is a bit high on this approach^
| and I personally just use a mix of Vue + Turbolinks/Rails
| at work for legacy/simplicity reasons. But I'm watching
| the space.
| maxloh wrote:
| You are right. It wasn't client side routing.
|
| But GitHub doesn't use turbolink. They wrote their own
| implementations that lies at
| app/assets/modules/github/behaviors/pjax.ts.
| msbarnett wrote:
| Ah, AFAIK that's not actually theirs but:
| https://github.com/defunkt/jquery-pjax (although I guess
| they rewrote it in TS, unless that's a different project
| floating around?), from which Turbolinks took its
| inspiration as a Rails-native built in solution.
| Presumably GitHub never saw any reason to rewrite for
| Turbolinks when the latter appeared.
| manmal wrote:
| Was AirBnB not one of the first companies to champion server-
| side rendering of React apps? I think you're listing apps that
| are actually a bunch of SPAs glued together (each page is super
| complex and an SPA of its own right).
| marcosdumay wrote:
| Hum...
|
| > Hackernews, Amazon, AirBnB, Booking.com, Wikipedia, GithHub
|
| I don't know about AirBnB. Booking has a little bit of
| interactivity that is more annoying than helpful1, like the
| GP's example for Reddit. None of the others can be described
| as "applications".
|
| 1 - The map is good. The stuff on the map is very good. The
| map itself is an SPA. For all the rest of the site, if they
| removed all the Javascript it wold be an improvement.
| AlchemistCamp wrote:
| It wasn't React, but Spike Brehm gave a lot of talks about
| Airbnb moving to "isomorphic JavaScript" with a library he
| created. It was called Rendr and it basically let you stitch
| together Backbone and Node and share code between the client
| and the server.
|
| I remember being pretty interested in it at the time.
|
| https://techcrunch.com/2013/04/19/airbnb-open-sources-
| rendr-...
| manmal wrote:
| Ah yes, before React even!
| winrid wrote:
| Lever was doing this in 2014 with DerbyJS.
| TekMol wrote:
| On AirBnB, you search for a location on the homepage and then
| you go to a new page, the map page. Which is a bit SPAish
| because it reloads apartments when you move the map. Then
| when you click on an apartment, you go to a new page, the
| apartment page.
|
| Overall, I would count that as MPA?
|
| The apartment pages seem to be client side rendered. When I
| CTRL+u and look a the source code, I see a lot of JSON and
| not much HTML.
| altdataseller wrote:
| Monday.com, Google Docs, Trello.
| WalterGR wrote:
| Gmail
| pkamb wrote:
| Old.Reddit.com does some kind of page-reload every time you
| navigate back to the subreddit from a comments page. Incredibly
| annoying and makes Hacker News feel blazing fast by comparison.
|
| Does anyone know how to block that page reload and associated
| movement of stories and scroll position on the page you're
| returning back to?
| egypturnash wrote:
| I do not know how to stop it and I hate it so much.
| bmacho wrote:
| Replace the button you click with
| history.back()
|
| with tampermonkey?
| FpUser wrote:
| >"There's a feeling in the air. A zeitgeist. SPAs are no longer
| the cool kids they once were 10 years ago.
|
| Hip new frameworks like"
|
| I have my own company developing products. Some for our own, some
| for clients. I count my money. Why would I give a flying fuck
| about what is "hip"?
|
| The only thing that matters is how much it costs me to develop
| solution assuming it satisfies all the constrains imposed by
| client's specs. The difference makes a profit and this is what I
| am after.
|
| I use SPA when I need real business application and it needs to
| be delivered in a browser. If SPA becomes too big I make it
| dynamically load a pieces of needed functionality upon request.
| By nature is is still SPA and dynamically loaded parts tend to
| stay in browser's cache anyways. When I need a website I make
| plain website. I do not turn one into the other.
| Nextgrid wrote:
| > I have my own company developing products. Some for our own,
| some for clients. I count my money. Why would I give a flying
| fuck about what is "hip"?
|
| You are a minority in a sea of crap whose only goal is to
| extract more money from investors by dazzling them with
| buzzwords, "growth & engagement" and engineering playgrounds
| where complexity is a _feature_ to justify hiring more
| engineers and make an engineering blog to brag about solving
| (self-inflicted) problems in order to help hire _more_
| engineers.
|
| When your objective is to make money by solving clients'
| problems as opposed to dazzling investors to then beg for their
| money, the "bill of materials" changes significantly.
| coding123 wrote:
| So can we really claim these as MPAs? This is all using the same
| architecture of SPAs but it moves it to the backend. Technically
| that's still an SPA that moved the rendering to the server and
| instead of shipping JSON and telling the browser to update with
| the new JSON it's the server sending HTML that the browser is
| told to replace a part of the screen. It's really just the same
| thing but with a twist. This is not "MPA" tech, it's SPA tech
| with new bells and whistles. MPA tech (PHP, CGIBIN, etc..) is
| dead and not coming back.
|
| If the author states this, I would be on board - we're shifting
| to shipping HTML chunks.
| mrtksn wrote:
| SPA makes the backend much more simpler as all the HTML rendering
| is not its concern anymore. The client devices are very capable
| and the networks are fast, it's very logical to offload the
| rendering to the client.
|
| I doubt that MPA is coming back but for things that don't need to
| be SPA in first place, going back to being MPA is reasonable.
| jhgb wrote:
| > SPA makes the backend much more simpler as all the HTML
| rendering is not its concern anymore.
|
| That feels like creative accounting of code to me. Is the
| rendering really simpler, or does it merely happen in a
| different place?
| mrtksn wrote:
| Happening in a different place makes it simpler because the
| backend no longer needs to take into consideration the
| various clients. For example, the same API can serve a SPA
| and a Mobile app and some other interactions with other
| systems(integrations with multiple services becomes so easy).
|
| Also makes it possible to separate the people who build the
| API and the people who build the UI which can have many
| advantages such as hiring more specialised people and
| decouple the releases. For example, you no longer need
| someone who knows PHP/SQL/Linux and JS/HTML/CSS. You also
| have less vendor lock-ins because the front end and the back
| end are agnostic to each other, which means you can much
| easily ditch something from the one side without doing any
| work on the other side.
| jhgb wrote:
| > the backend no longer needs to take into consideration
| the various clients. For example, the same API can serve a
| SPA and a Mobile app and some other interactions with other
| systems(integrations with multiple services becomes so
| easy).
|
| Drawing a circle artificially around a portion of your code
| and saying "look, now the circled part doesn't need to
| change!" feels like creative accounting to me as well. If
| you have multiple clients, the code for multiple clients
| still has to live _somewhere_ , so it's not like the whole
| system that you need to build is getting simpler.
|
| Pretty much the only actual difference I can see here is
| the ability to use more of client's CPU time to run your
| applications. I'm sure there's applications that could
| profit from that.
|
| > For example, you no longer need someone who knows
| PHP/SQL/Linux and JS/HTML/CSS.
|
| But if you don't do your logic in JS but do it in PHP on
| the server, you don't need a JS person. And if you were
| using Seaside, you wouldn't need an HTML/CSS person since
| everything would be just Smalltalk at that point. It's
| again just moving stuff around, but someone still has to do
| that.
|
| I guess _one_ situation where this argument might apply
| would be if one of the two language options was difficult
| to hire for.
|
| > You also have less vendor lock-ins because the front end
| and the back end are agnostic to each other, which means
| you can much easily ditch something from the one side
| without doing any work on the other side.
|
| Not even this argument seems any less artificial to me,
| since if you're ditching something, I'm not quite sure why
| it matters _where_ you ditch it from -- unless you have no
| control over one of the sides. In that particular case, I
| could see this as an argument. If you 're forced to do a
| client for an already existing server, you're obviously
| justified in doing a pure client-side solution for anything
| that doesn't exist on the server yet. If you're building
| your own server, this limitation is removed.
| mrtksn wrote:
| I don't know why it feels like creative accounting to
| you(I actually do, see next paragraph). Indeed, by
| drawing a circle around a code you change the
| architecture through separation of concerns and break
| down larger problem into smaller parts. As a result of
| this, your system acquires new properties.
|
| It all matters because the code is written by people and
| people specialise. Maybe from computational perspective
| you are just moving the computation from one place to
| another but from development perspective you are breaking
| down code into pieces that specialised people can work
| on. Instead of having a linux wiz coding CSS or front-end
| guy creating security holes in your PHP code you have a
| front-end dev who can talk to backend-dev and all do
| their parts and the mobile-app-dev can join the party
| later and simply use the existing work done by the back-
| end dev.
|
| All that when having some of your computations offloaded
| to the client devices. It's pretty neat.
| jhgb wrote:
| > Indeed, by drawing a circle around a code you change
| the architecture through separation of concerns and break
| down larger problem into smaller parts.
|
| I'm not saying "don't have cleanly separated components".
| I just fail to see why it matters that the network
| communication has to happen between very specific modules
| and not some other ones. Ideally your system wouldn't
| even notice at all if you moved the "network border"
| within your system. Some systems would notice that,
| mainly performance-wise (for example moving a database
| engine (which uses random access to a large amount of
| data) across the border could be a problem), but I
| imagine that many would not.
|
| > or front-end guy creating security holes in your PHP
| code
|
| You do realize that this falls under the "hiring
| difficulties" qualification I've added in my previous
| comment?
|
| > you have a front-end dev who can talk to backend-dev
| and all do their parts and the mobile-app-dev can join
| the party later and simply use the existing work done by
| the back-end dev
|
| People can communicate with each other and collaborate
| regardless of whether their code runs on the same machine
| or not. For example, now with Microsoft's Blazor, just
| because the user interface is going to be programmed in
| the same address space and process as the backend doesn't
| mean that two different people with different strengths
| can't work on two different parts of the same large
| program. You can still have the guy who's better at
| dealing with UI design do the UI, and the guy who's good
| at writing fast database code write the backend. Not sure
| what prevents you from doing that.
| mrtksn wrote:
| It's not hiring difficulties, people have limited time
| and energy to specialise - you can't simply try harder
| and hire someone who is the best front end and the best
| backend developer at the same time. Sure, you can still
| have clean separation of concerns and send rendered page
| to the user instead having the user run the UI on their
| device and fetch data as needed but that's just extra
| work and higher data transfers(in fact, it's a common
| practice to send the initial page as a full HTML for SEO
| purposes). If that's your thing, sure go ahead.
|
| But you are keeping dismissing the interoperability part.
| Since you are now sending fully rendered browser specific
| output you loose your chance to use the same backend for
| different type of clients, such as mobile apps or other
| tools that can work with your system. You instantly need
| to create client specific output for each and every
| client type. If you want to do it, go ahead.
|
| Certainly things can be achieved in worse ways at higher
| costs, maybe some people have reasons to want that? I
| wouldn't know why though. An art form? A protest? A way
| to inflate the budget to bill more work for each type of
| client?
| jhgb wrote:
| > It's not hiring difficulties, people have limited time
| and energy to specialise.
|
| I never claimed otherwise.
|
| > but that's just extra work and higher data transfers
|
| Not necessarily. For example, when compression is being
| employed, I doubt that something like Rails' Turbo will
| transfer measurably more data in a page update than
| sending a JSON or XML representation of the very same
| data.
|
| > But you are keeping dismissing the interoperability
| part. Since you are now sending fully rendered browser
| specific output you loose your chance to use the same
| backend for different type of clients
|
| No, I'm not! In a single address space, you can generate
| outputs for multiple clients just as easily as for one
| client. Literally nothing prevents you from doing that.
| mrtksn wrote:
| A JSON containing the data to update a piece in the page
| will always be measurably smaller than the full UI, no
| matter how you compress it because you can compress the
| JSON too. If you use something that loads HTML or
| something like that from the server instead of reloading
| the whole page, congratulations you made a funny SPA.
|
| Sure you can make outputs for multiple clients just as
| easily. On the traditional SPA though, you don't need to
| make those at all.
|
| I think the advantages are clear at this point.
|
| > I never claimed otherwise.
|
| You literally called it "hiring difficulties". What's the
| point to argue after this?
| jhgb wrote:
| > A JSON containing the data to update a piece in the
| page will always be measurably smaller than the full UI
|
| There's no need to compress the full UI again. Rails'
| Turbo for example transfers only the minimum fragment
| required.
|
| > Sure you can make outputs for multiple clients just as
| easily. On the traditional SPA though, you don't need to
| make those at all.
|
| Neither do you have to do that in a traditional MPA. One
| client = one frontend, surely?
|
| > You literally called it "hiring difficulties". What's
| the point to argue after this?
|
| Did I misunderstand the comment I was responding? You
| wrote "people have limited time and energy to
| specialise". The way I interpreted it was that different
| people have different strengths, so it's difficult to
| hire someone who has many different strengths at once
| (and for example wouldn't poke a hole in your PHP code,
| to use your own example).
| mrtksn wrote:
| > here's no need to compress the full UI. Rails' Turbo
| for example transfers only the minimum fragment required.
|
| That's SPA fetching HTML instead of JSON or something.
| You are welcome.
| jhgb wrote:
| As per Wikipedia:
|
| > In a SPA, a page refresh _never_ occurs
|
| This is not true with something like Turbo: the partial
| transfer may or may not take place depending on whether
| it's useful to do that. The point is that you don't have
| to even care about that (and I'm not even sure you even
| any control over that). From the perspective of a Rails
| programmer, you're generating whole pages. How they get
| to the client is immaterial to you. Think of it as
| compression (which is actually is, basically using the
| previously tranferred data as a dictionary).
| mrtksn wrote:
| It's alright, Rails programmers can do that. Nice little
| trick for building SPAs. There are other systems that use
| the technique, it has some advantages and disadvantages.
| If it works for you, great. What's the point to argue
| against the advantages of SPA?
| thiwaw93949500g wrote:
| The point of the person you are replying to is very clear
| so I am not sure why you insist on arguing.
|
| > Not sure what prevents you from doing that.
|
| The technology stacks used on the back-end, front-end,
| mobile apps, and their associated tooling are most of the
| time very different. Most developers aren't polyglot, or
| at the very least have a preferred ecosystem in which
| they are the most productive. By introducing physical
| boundaries, specialization is easier.
|
| For example instead of having a team only composed of
| Java developer, and having a development workflow and
| build process requiring Java knowledge, the back-end team
| may be composed of Java specialists, while the front-end
| is composed of nodejs + typescript folks, and the mobile
| app is composed of iOS or Kotlin experts.
|
| Is there a technical limitation preventing people from
| using typescript in a Java project and separating
| concerns using the java module system or basic folder
| hierarchy? No. However this rarely happens in practice
| unless there is clear physical boundary such as the one
| enabled by SPAs, because people specialize themselves.
| jhgb wrote:
| > The technology stacks used on the back-end, front-end,
| mobile apps, and their associated tooling are most of the
| time very different.
|
| Which feels like a major mistake to me. My house doesn't
| use different construction technologies for different
| rooms. It was built all at once, why would it have one
| room built of bricks and another one from glass and
| steel? (Other than for some artistic reason, I
| imagine...)
|
| > Most developers aren't polyglot, or at the very least
| have a preferred ecosystem in which they are the most
| productive.
|
| Yeah, sure. But you don't need to artificially exclude
| the situation where for example everyone on the team
| speaks C# (like with the emerging Blazor projects). To
| say that different developers on a project often have
| different preferred ecosystems does not mean that
| different developers on a project _must_ have different
| preferred ecosystems, even if they 're working on
| different parts of the same project. That feels like a
| very weird form of segregation to me. "You're a girl,
| you'll learn cooking!" "You're a C# developer, you'll
| write the database interface!". Why couldn't the girl
| weld a bike frame and the C# developer write a Blazor UI?
| mrtksn wrote:
| The house analogy is wrong, we are not talking about
| using different tech for different apps but different
| tech for different parts of the system.
|
| Therefore, the house analogy would be using different
| materials for the floors, for the roof, for plumbing and
| electricity. Then you will notice that different experts
| install all these parts. The plumber wouldn't do the
| electricity. It's not that it's impossible to know
| plumbing and electrical systems at the same time but it's
| much easier when you are plumber or electrician instead
| of trying to be a jack of all trades.
| TrispusAttucks wrote:
| SPAs have been shit since the beginning. It was a wrong path.
| Thank God the new comers have corrected.
| Mikeb85 wrote:
| I mean, SPAs were overkill for half the shit they were being
| developed for. Your average web app is a CRUD app and works
| better as an SSR app. But there's still use cases for them,
| they're still a great way to build highly interactive cross
| platform apps.
| hirvi74 wrote:
| In my experience, one of the biggest benefits of SPAs is that
| the front-end tends to be a bit more decoupled from the back-
| end when compared to SSR apps. Now, of course MPAs could be
| built this way, and plenty probably are, but again, it's not
| something I have personally seen often.
| andix wrote:
| I think it greatly depends on what kind of thing you're building.
|
| A ,,website" like HN shouldn't be a SPA
|
| But an ,,app" like Gmail probably should be.
| endisneigh wrote:
| So much whining about SPAs. A properly written SPA is very
| performant and really doesn't have huge differences compared to
| MPA.
|
| If anything the only thing that's changed is people understand
| how to properly write a SPA and JavaScript web development is
| finally reaching a period of some level of stability.
|
| It really depends on what you're trying to do. Want a fully
| offline app? Good luck without SPA.
| andybak wrote:
| > A properly written SPA is very performant and really doesn't
| have huge differences compared to MPA.
|
| Maybe true but in the wild the vast majority of websites manage
| to fall down on one or both of these.
|
| So either it's hard to "properly write" an SPA or something
| else is going wrong.
| endisneigh wrote:
| Most sites are generally flawed in some sense. SPA is just a
| red herring.
| nomilk wrote:
| > A properly written SPA is very performant
|
| SPAs should offer better UX (by reducing full page loads), but
| at the expensive of developer hours.
|
| Curious to hear what the difference in development time is from
| anyone who made the same app as a MPA and later as a SPA.
|
| I'd guess to make the same app as a SPA would take around 2-3
| times as long.
| BackBlast wrote:
| My experience is the opposite. I say that from a career that
| is dominated by backend experience.
|
| In any application, you have to have a good front end. To
| most users the app/page is the UI.
|
| Having the majority of your concerns in one place will help
| you develop with smaller teams. Certain SPA architectures can
| bring nearly ALL of the concerns into the front end.
| Particularly with databases that are simply port open to the
| world like say couchdb. Your backend needs almost effectively
| disappear. If this is a reasonable data model, SPA looks and
| feels much faster to use and develop.
|
| When you attach a backend, you often attach other
| specialists, languages, techs (python, ruby, Java). Have to
| deal with separate teams, which often means a formal API and
| all the handshaking between. This pretty much triples the
| required work with development and the communication
| overhead.
| [deleted]
| [deleted]
| [deleted]
| randomtwiddler wrote:
| Stop griping about SPAs. Local compute is powerful and lower
| latency than the data center across the country or world.
|
| Page weight isn't that big of a deal, a 2 MB ball of js is
| nothing compared to the multi megabyte pictures and videos people
| routinely add to pages.
|
| For some use cases MPA is fine, but in many cases it's actively
| worse and higher dev costs to boot.
|
| Service workers are an interesting middle ground I think should
| see more attention and development. I like to combine service
| workers with SPAs for fully offline capable web apps.
| [deleted]
| jhgb wrote:
| > Page weight isn't that big of a deal, a 2 MB ball of js is
| nothing compared to the multi megabyte pictures and videos
| people routinely add to pages.
|
| That's a good argument if you're one of the people adding multi
| megabyte pictures and videos to your pages, but I'd bet that if
| page size is of concern to you, you're not one of them, so "a 2
| MB ball of js" would suddenly become your weakest link.
| randomtwiddler wrote:
| You say "weakest link" like there is an optimum. People are
| regularly downloading 4k video. By choice, they want to be
| doing this.
|
| Amazon is one of the most successful websites ever created
| and last I checked came in at over 12MB page weight. Mostly
| highly optimized images. I'm sure they wrangle and agonize
| what shows up there.
|
| There's a limit somewhere, but pointing the finger at a ball
| of js that compresses to less than 500k isn't particularly
| reasonable.
|
| User experience is more about latency. Be it from local
| compute or remote compute+network.
|
| If your visitors are one and done you must SSR at a minimum.
| Because that will drive the average latency of the majority
| of user experience.
|
| If they are long term users, you should seriously look at
| user local data and potentially full offline functionality
| that can mask even poor 3g performance and spotty networks.
| Making users suffer long term through an MPA architecture is
| silly.
| cyral wrote:
| And you end up saving that 2MB at some point since every page
| load is just some JSON instead of waiting for the server to
| render a whole new page that is mostly a duplicate of the
| current page.
| randomtwiddler wrote:
| Page 2 definitely has big wins, not only for the user but in
| reduced server load and thus cost. That is really the key bit
| of information in answering the question, to SPA or not to
| SPA.
| 88913527 wrote:
| As someone who works on design systems, I struggle with the
| concept of consistency in MPA's. If every team has their own tech
| stack, you'll inevitably end up with multiple ways of rendering
| HTML: Java/JSP, Ruby/ERB, etc. It's only easy to SSR React in
| NodeJS.
|
| If all the teams use client-side rendering, I can ship the design
| system as an NPM package of React components, and you can use
| tools like Storybook to run visual regression tests without
| standing up your full environment.
|
| I know I'm speaking tactically here, but a shift away from SPAs
| seems like a loss for shared UI components and design
| consistency. I can't just give a CSS file (which _is_ portable
| across tech stacks) and leave it to engineers to write accessible
| HTML; there 's huge value-add in isolating a11y in something like
| a React component abstraction.
| bestinterest wrote:
| My issue with design systems is that inevitably the team using
| the internal companies design system has to implement custom
| components (usually early on) and try to match the feel of the
| design system already in place.
|
| I'd rather go custom for a project and semi match the already
| in place feel of the company's UI standards. Then we're only
| bottle necked by our internal team and not an external team.
|
| Thinking more on this, I'd love the
| https://tailwindcomponents.com setup for internal design
| components? Seems like the best of both worlds but does move
| the base from React/Angular components to Tailwindcss
| adrianmsmith wrote:
| > I struggle with the concept of consistency in MPA's. If every
| team has their own tech stack, you'll inevitably end up with
| multiple ways of rendering HTML: Java/JSP, Ruby/ERB, etc. It's
| only easy to SSR React in NodeJS. If all the teams use client-
| side rendering, I can ship the design system as an NPM package
| of React components
|
| That's true, but if your various teams are allowed to use
| various server-side programming languages and frameworks,
| what's to say they're not allowed to use various client-side
| frameworks as well? E.g. one team uses Angular, the other
| React, the other Vue, etc. Then you're back to having the same
| problem.
| MiscIdeaMaker99 wrote:
| What's an SPA?
| kayson wrote:
| Single page app https://en.m.wikipedia.org/wiki/Single-
| page_application
|
| In the early days of the web, pages were static, and changing
| content required navigation to a new page (url). Then
| JavaScript took off and you could dynamically change content on
| a given page, even reload data without navigating/refreshing.
| In the extreme, frameworks like react were developed, where you
| no longer have pages at all. The entire website is rendered on
| the same page using JavaScript to load all the content on the
| fly.
___________________________________________________________________
(page generated 2022-05-21 23:00 UTC)