[HN Gopher] The balance has shifted away from SPAs
___________________________________________________________________
The balance has shifted away from SPAs
Author : feross
Score : 456 points
Date : 2022-05-21 16:32 UTC (1 days 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"
| LAC-Tech wrote:
| Unless by "hip" they mean "smaller, more powerful, better
| abstractions".
|
| Not writing a bloody wrapper over express.js...
| 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.
| keybits wrote:
| Here's a great example of how this can be done
| https://instantmultipageapp.com/
| nolanl wrote:
| Thank you! This is exactly what I had in mind. The
| streaming aspect of MPA pages is a great example of
| something you can't really do in an SPA. (Although there
| are hacks: https://jakearchibald.com/2016/fun-hacks-faster-
| content/)
| 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.
| tomphoolery wrote:
| > Blog posts are making the rounds listing all the challenges
| with SPAs: history, focus management, scroll restoration,
| Cmd/Ctrl-click, memory leaks, etc.
|
| I guess? Like, who is implementing all this BS themselves? Every
| time I've written a SPA, my framework and/or routing library
| handled all this crap for me. None of these "challenges" were
| ever problems for me, and this sounds like another case of
| programmers creating an issue where there actually isn't one.
|
| If you use a proper framework or routing library that changes the
| history state of the URL, it's pretty much impossible for users
| to tell whether something is a SPA or an "MPA". So who cares?
| nullbytesmatter wrote:
| And yet, a large portion of big websites using SPAs don't seem
| to have functioning back buttons. If a billion dollar company
| can't get it to work properly I doubt anyone else can.
| tuyiown wrote:
| > If a billion dollar company can't get it to work properly I
| doubt anyone else can.
|
| Billion dollars companies rarely delivers high quality
| software, especially in the UI area.
| presentation wrote:
| Or maybe that billion dollar company's users don't change
| their preferences based on back button behavior so they feel
| no need to fix it.
| 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.
| recursivedoubts wrote:
| if you are willing to jump on the discord, we'd be happy to
| improve them
|
| https://htmx.org/discord
| benpate wrote:
| My dude... I made those in like a day, when I was first
| getting started with htmx. Accessibility has nothing to do
| with the language or framework you use. It's about the thing
| you build with it. If you can build it with Javascript, you
| can build it with htmx.
|
| Give this a try, and see if it's any more accessible --
| https://benpate.github.io/hyperscript-widgets/modal/ -- I've
| learned a bit since those first demos, and have followed
| every W3C guideline I can find on accessibility to make them.
|
| One more thing, I'm nowhere near being an accessibility
| expert, so I'm positive someone who knows more will have
| suggestions on how to improve this, too. But it has nothing
| to do with htmx/hyperscript, and everything to do with me
| being new at accessibility.
|
| Bugs/Suggestions/Pull Requests are always welcome. That's
| what makes htmx fit for "serious projects."
|
| Edited to add: Htmx is a JS-based extension of the natural
| hypermedia patterns your browser already uses, not a widget
| library. All of the demos on the site are just that --
| _demos_ that show you the kinds of things you can build, and
| not plug-and-play, ready-for-npm widgets you can just drop
| into your application without a second thought.
| zmmmmm wrote:
| They touch on it at the end but I think it is under-appreciated
| ... the big benefit of a SPA is continuity of client side state.
| I don't actually care whether it's one page or ten but it does
| simplify things enormously that I can maintain a single model
| object and not have to persist it in and out of local storage or
| even worse have all the complex UI state replicated on the server
| side to maintain continuity, just because the user clicked a
| button or something. Especially with reactive frameworks where
| updating the model automatically triggers re-rendering of the UI
| everywhere it needs to, a whole piece of complexity in your
| architecture just goes away.
| my69thaccount wrote:
| SPAs suck at client side state, they barely work with the back
| button or scroll bar and if they do its because its
| reimplemented in JS.
| nighthawk454 wrote:
| Not browser state, but application state. Lot more
| boilerplate and glue to do that on server side and ferry it
| back and forth.
| infogulch wrote:
| But the application is embedded in a browser. Are you
| saying it's fine to bin all that UI state the moment the
| user performs a totally normal interaction with their
| browser? Accidentally hitting back or refresh in a complex
| SPA and losing the state of the application is one of the
| most frustrating experiences on the web, right behind
| trying to hit back or refresh intentionally and being
| blocked because the SPA overrides those functions.
| theonething wrote:
| I actually see having to manage client side state as one of
| SPAs' greatest downsides. You're literally doubling the
| complexity of your application. Now you have to maintain state
| on both the server and the client and it becomes a great effort
| to make sure they don't get out of sync.
|
| The way I see it, the state of an application resides in the
| server, more specifically, the database. Let's keep it there.
| bowsamic wrote:
| If you have a UI, you have UI state, so you'll have to
| synchronise it somehow
| theonething wrote:
| If your UI is rendered on the server, then your UI state
| remains on the server. It just ferries that state to the
| client. There's no synchronization involved because it's
| synchronized by default.
| bowsamic wrote:
| So your proposal is that whenever literally any ui
| interaction is performed the server is notified and the
| page is reloaded with the server state?
| theonething wrote:
| That's how traditional SSR applications work.
|
| The new way is html over the wire e.g. Hotwire, Liveview,
| htmx. So instead of the page being reloaded, the section
| of the UI that needs to updated is rendered on the server
| and sent over via websocket.
| bowsamic wrote:
| No they don't, they use web forms, which are a local UI
| state that gets bundled up and sent when the user presses
| a submit button. They do not refresh on every single UI
| change
| andrewxdiamond wrote:
| This seems awfully more complex than maintaining state UI
| side.
| Existenceblinks wrote:
| Much simpler based on my experience with LiveView. It's
| stateful out of the box, no needs to do the manage part.
| theonething wrote:
| Not in my experience. I've worked on several react apps.
| Currently doing a Hotwire project and it's just so much
| simpler to keep all state on the server side.
| bowsamic wrote:
| So when you enter a character into a text field the
| affected part of the page is then reloaded with fresh
| HTML?
| Existenceblinks wrote:
| Liveview: it sends event to server and the server handle
| the event, then send "diff" to client (and automatically
| patch the dom) .. all of these via websocket, it's fast.
| andrewxdiamond wrote:
| How does this degrade when connectivity is poor?
| granshaw wrote:
| In my experience, not well (we had an important early
| user have to use our web app from a trailer using the
| wifi from the main house)
|
| So might not be the best approach unless most of your
| users are at their desk
| 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).
| fartcannon wrote:
| Webkit is just forked KHTML so credit where credit is due.
| olliej wrote:
| The back/forward cache is from apple era webkit, as is a
| large amount of the basic compat work in webkit.
|
| KHTML did a lot of work, but they did not do all of the stuff
| that made WebKit actually practical as a browser engine -
| webkit had massive rewrites to get compatibility and
| performance to anything approaching acceptable.
|
| That said the problem I had here in this article was that
| this article is explicitly crediting a specific feature that
| predates Chrome to Chrome. The bf-cache is one of the vast
| amounts of work webkit had done to make khtml a practical
| engine for real browsing.
|
| WebKit at the point chrome forked it had already largely
| rewritten the DOM, JS engine, Rendering engine, and layout
| engine.
|
| Or you can continue searching HN to make glib questionably
| accurate and definitely misleading comments in response to
| things I say because you're unhappy that someone suggested
| opencl failed because it was a crappy spec.
| emilsedgh wrote:
| Konqueror/KHTML was more than "acceptable". It was a fine
| web browsing experience. You'd barely notice anything wrong
| with it and it was the first browser to pass ACID 2 tests I
| think.
|
| Saying KHTML wasn't viable/acceptable experience is more
| misleading to be honest.
| fartcannon wrote:
| It looks like KDE is still to this day a primary
| contributor. Isn't giving Apple credit for the work of a
| large team, the same thing OP was doing with Chrome?
|
| Regarding your accusation, I'll make sure to check who I am
| replying to and not reply to you anymore. I guess you have
| interesting counter arguments that encourage discourse.
| Anyways, keep posting, you're doing a great job.
| reddec wrote:
| From my point of view, SPA is really good when you need to use
| one API for different kinds of clients: web, mobile apps, cli
| etc. Second benefit is predicted relative routing: in case you're
| serving your web app (with hash router) as one page, you may
| don't worry about subpaths (ex: page served as /webapp will work
| properly under /foo/bar)
| 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.
| spinaltap wrote:
| Speaking of Rich Harris, is SvelteKit a good framework to build
| MPAs? If not, what is? I'm planning to learn SvelteKit in my next
| side-project. As for "Astro, Qwik, and Elder.js" mentioned in the
| blogpost, I haven't heard about them.
| 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.
| jcmontx wrote:
| This might be what I was looking for
| 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.
| hombre_fatal wrote:
| Perhaps you could elaborate on what you mean, but from my
| viewpoint there isn't much daylight between DB-queries in
| most server-rendered apps vs. SPAs.
|
| Instead of this: def endpointAB:
| a = db.getA() b = db.getB() return
| template('ab.html', {a=a, b=b})
|
| You tend to have this: def endpointAB:
| a = db.getA() b = db.getB() return
| json({a=a, b=b})
|
| When I think of ways you may want to generalize over
| arbitrary queries on the server, I run into the same
| challenges you'd have in a SPA rather than fewer.
| 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.
| abraxas wrote:
| Vaadin
| 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.
| scollet wrote:
| I appreciate the accessible aspects, but the browser is not a
| panacea.
|
| Not that the industry is invested in accessibility out of
| benevolence.
|
| I feel like we're holding up the hard/firmware side of things
| here.
| 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]
| gatvol wrote:
| This is not a binary choice - SPA's remain a valid pattern for
| the right use case. The point is knowing when to apply the
| pattern. Aside from that they have some great features, including
| security; ;they largely reduce the attack surface to supply/dep
| chain, and an API interface - which is a great pinchpoint at
| which to apply mitigations, monitoring etc.
| ferdowsi wrote:
| In what way do Javascript heavy SPAs reduce supply chain
| attacks vs a no-JS solution?
| gatvol wrote:
| That was my assertion, I said the surface for attack included
| supply chain. As another poster pointers out, that is in fact
| reduced under some circumstances, since the runtime context
| is browser side.
| upbeat_general wrote:
| Just taking a guess: supply chain attacks may occur the same
| (or even more) but they're less impactful client side. Makes
| it easier to have more trusted server-side code and less
| validated client-side JS.
| 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.
| farmin wrote:
| SPA movement has given us nice frameworks to build mobile apps in
| Ionic. I wouldn't build a website with Angular but combine
| Angular framework and the million libraries in npm gives a pretty
| powerful ecosystem to quickly build very high functioning apps.
| 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.
| gherkinnn wrote:
| So rebuild everything a browser does on canvas to make things
| easier? On what planet is that sensible?
|
| These ideas must come from people who have no intention to
| learn the languages required to build frontends, but want to
| stick to their systems language of choice. Not realising of
| course, that the problem space remains pixels and users and all
| the irritations that come with it.
| 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.
| sanderjd wrote:
| I relate to this _so hard_. It 's hard to know what other
| people work on, but I haven't worked on a web _site_ in over a
| decade, and it 's just honestly hard for me to relate to people
| who can't understand the user experience benefits of within-
| page interactivity.
| 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.)
| lobocinza wrote:
| > I hope nobody is using react to build their content in
| 2022.
|
| Unfortunately they are. People are using React for things
| that aren't apps.
| Spivak wrote:
| I mean why wouldn't you? Degenerate React -- a mostly
| static content "chrome" replacing the "layout.html.erb"
| and a component to render content from an API based
| entirely on the route replacing "article.html.erb" still
| is way faster than your average site. Slower then the
| equivalent SSR but ehh.
| 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.
| sanderjd wrote:
| > _Most of the web is content with a light smattering of
| interactivity_
|
| Absolutely right. But is that what most people here are
| _working on_? Aren 't content sites like this largely a
| solved problem?
| 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.
| BigJono wrote:
| No, they shouldn't look at some of the frameworks. They're
| all more complex than just making a bog standard SPA, which
| seems to be working fine for them. People need to stop
| bringing in that complexity when they don't need server
| rendering.
|
| This is basic software engineering shit, and it boggles me
| that the industry can't get it right. Same kind of code goes
| in the same place and runs in the same context unless you
| specifically need to do otherwise. No reason not to route and
| render on either the client or the server unless you
| absolutely need both.
|
| Trying to get fancy is how you end up with a truckload of
| bugs you wouldn't have otherwise had. I've been on like 5
| projects that have spent months dicking around with Next or
| Nuxt or Gatsby or whatever rubbish, lighting client money on
| fire, for a portal behind a login that doesn't need to be
| indexed and would work totally fine as an SPA.
| eyelidlessness wrote:
| > No, they shouldn't look at some of the frameworks.
| They're all more complex than just making a bog standard
| SPA, which seems to be working fine for them.
|
| Should was probably too strongly phrased, shouldn't
| definitely is. The suggestion wasn't "hey go learn a new
| framework, your current solution isn't up to date" or
| whatever. It was really, very sincerely, "the frameworks
| discussed in article agree with you, you oughta keep an
| open mind". Encouraging both a general, and clear area of
| interest, spirit of curiosity.
|
| I don't get the sense that you have or want that curiosity
| on the topic, by all means stick with what's working and
| carry on.
|
| If your comment was paired with downvote, I do want to
| thank you for the comment. It's refreshing to get a
| perspective on why someone didn't like something I said,
| when I wouldn't have that insight otherwise.
| 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.
| treis wrote:
| Even still. A 3g connection is a bit under half a MB a
| second. That's a lot of data for something that is mostly
| text.
| robertoandred wrote:
| https://reactjs.org/docs/getting-started.html is a fast SPA
| exodust wrote:
| It's just text.
| 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.
| rcxdude wrote:
| This is the theory, and yet in practice my experience is
| almost always the opposite: MPAs load and render quickly
| and are responsive during use, SPAs are slow to load and
| render and often chug substantially. Some of the better SPA
| manage to beat mediocre MPA implementations, but it's not
| super common. I don't know how it so frequently gets
| screwed up so badly, but it's a really consistent trend
| (and this is across fast desktops with a good internet
| connection to mobile devices with not-so-great signal). For
| example, hacker news is way, way more usable to me than new
| reddit (which actually renders my browser unusable on a
| high end machine after some use).
| hinkley wrote:
| The impedance mismatch always seems to boil down to the
| fact that we have been told umpteen million times that
| most people end up on your website with a nearly
| completely evicted cache, and we (or at least, the people
| who resist) don't seem to believe it.
|
| This is pretty much the default and a given for everyone
| who visits your site... except you. As the author, you
| likely use your application more than most users, you use
| it on a work machine (which has a smaller, more niche
| browser history), and you use it with the sort of network
| connection that software developers demand: you know,
| excessive.
|
| We see what we expect to see, what we want to see, and
| most of us don't challenge that, or only do it
| perfunctorily. And if someone else does? Well that's just
| crazy talk. See? Everything is fine.
| tatersolid wrote:
| Our B2B SaaS apps are SPA and preload static assets in the
| background on the login screen, including the top 90% of
| used js, templates, and icons (simple to find via http log
| analysis). This improves the end-user perception of
| performance dramatically.
|
| Accessibility with said SPAs is still a pain though. Even
| when you use correct semantic elements instead of DIV soup,
| the DOM usable by screen readers changes "out-of-order"
| frequently in SPAs, requiring lots of extra work to ensure
| an accessible experience.
| 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.
| sanderjd wrote:
| Yep, but with ever-more wheel reinvention.
| 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
| thex10 wrote:
| I've worked with devs whose first instinct is to whip out
| React for this use case. It really makes me question
| their skills.
| 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?
| lobocinza wrote:
| Someone that is using React is probably also using X, Y
| and Z library and 10MB is realistic.
| dymk wrote:
| And somebody not using React but rather re-implementing
| everything to achieve their equivalent complexity usecase
| brings in X, Y and Z a well...
| lobocinza wrote:
| Not really. IMO, people are using large dependencies for
| things that can be implemented with a few lines of JS or
| even no JS at all. Doing things for the sake of
| complexity. The whole point is that X, Y and Z aren't
| needed.
| 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.
| zrobotics wrote:
| Agreed. One of our employees is visually impaired, and it
| is shocking how many Spas are entirely incompatible with
| a screen reader and standard keyboard nav. With a MPA,
| most of the things that a screenreader needs come for
| 'free' just by being standard components. When everything
| is wrapped in JS and is slightly different for each page,
| it's frustrating.
|
| We have changed quite a bit of our software systems in
| the past 1.5 years, and I have dropped multiple vendors
| from consideration over accessibility. Many B2B SaaS
| salespeople just give you a blank look if you ask about
| usability for a blind user.
| oignon wrote:
| Hi zrobotics, I'm really interested about accessibility.
| Do you have some resources to recommend, even related to
| SPAs? Thanks
| 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.
| shitlord wrote:
| I worked at a large tech company replacing an internal
| MPA website with a SPA replacement. The MPA website was
| built in the 2000s, it was unmaintainable, and it was
| generally duct-taped together. The SPA website was new,
| shiny, and build on the hottest technologies at the time.
| But screen readers had a hard time understanding the SPA.
| Where the MPA favored simplicity and used <select>
| elements for its dropdowns, the SPA used a custom
| component that consisted of <div> soup with some JS. It
| took considerable effort to make the SPA friendly to
| screen readers.
|
| I'm not convinced that the SPA architecture was the
| source of the problem. A MPA with <div> soup everywhere
| would have had the same problem. However, these sorts of
| issues seem to be more common in SPA than MPA. There
| might be some correlation between using SPA architecture
| and reckless overindulgence.
| wruza wrote:
| Every mainstream desktop ui framework out there has
| standard, evolving out-of-box set of controls and layout
| widgets that do not suck. Guess what, you can build Gtk,
| Qt or Wx app without wrapping inputs into stacks of divs,
| which aren't there for layout. People even barely know
| how to create new controls or containers. The deepest
| container depth for a regular app is like 5-7 there, and
| that's a complex layout already with bells and whistles.
| Web does suck a lot in this regard, so people reimplement
| this functionality in javascript and div soup, as the
| other commenter mentioned. While your statement is true,
| the idiots here are the web standards which stuck in
| 1990s and never realized that this "apps" thing
| everyone's running around with for a decade or soon two
| is something more than a printable document with font
| sizes and empty fields split into sections and
| paragraphs. If web did care, it would at least add
| accessibility-only tags (or a separate structure like css
| does) denoting what's where and how to interact with it
| or how to dumb it down to whatever plain set of controls
| would be there, if the web ui model didn't suck. The
| stockholm syndrome it induced in software development is
| truly tremendous.
| 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
| pdonis wrote:
| _> by the definition Hotmail should be the holotype instead
| of GMail, which would be the paratype_
|
| I think in this particular case the term "holotype" is being
| overloaded; it means both "general category of applications"
| and "what this author takes to be the canonical application
| in that category". I don't think an exact parallel to the
| zoological usage is intended.
| 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!
| webmaven wrote:
| Could archetype/al/ical (or possibly prototypal) have been
| used instead? Both have associations with artefacts
| (usually authored and manufactured, respectively) rather
| than gathered specimens.
| SOLAR_FIELDS wrote:
| Sometimes when going deep into a subject I have to pause
| and explain that it's a very specific name for what we are
| talking about and while it may seem pedantic, Naming Things
| Is Actually Incredibly Important. IMO naming things
| properly is at least 25% of a good system design.
| 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!
| arthurcolle wrote:
| For other @arthurcolle classics, please see
| https://news.ycombinator.com/item?id=29371835
| patmorgan23 wrote:
| Woosh
| [deleted]
| gnat wrote:
| See Blackadder Season 3 for an explanation of why
| "cromulent" is now a punchline:
| https://www.youtube.com/watch?v=hOSYiT2iG08
| tomcam wrote:
| We biologists put that in the taxonomy as a "joke"
| 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.
| mattgreenrocks wrote:
| The goofy thing is how quickly that term fell out of the
| vernacular, and how few people (other than you) even stop
| to be amazed at the ridiculousness of it all in hindsight.
| drittich wrote:
| I didn't find it ridiculous. There were real, tangible
| benefits, like sharing the same validation code on the
| frontend and backend. Would I make it the sole reason to
| choose a given language? No, but there was demonstrable
| efficiency to it.
| TimTheTinker wrote:
| At the time, it seemed rather earth-shattering to be
| programming in the same language on both the front-end
| and the back-end without a browser plug-in or applet. The
| possibilities such an arrangement opened up seemed
| potentially vast.
|
| Up until that point, it had been a basic assumption that
| the front-end and back-end _had_ to be done in different
| languages if you wanted a site /app above a certain
| quality threshold (though Java applets and Silverlight
| (C#) had previously provided a way to run the same
| language on the front and back ends).
| bbarnett wrote:
| You're right, we need a PHP parser in ajax.
| aaronbrethorst wrote:
| Big Thesaurus Energy is a pox on clear communications.
| danielvaughn wrote:
| It's the reason I can't get into DDD. Love the overall
| idea, hate the terminology with the fire of a thousand
| suns.
| leetrout wrote:
| DDD is something that most shops arrive at naturally
| without having to force paradigms to fit.
|
| Other shops dont arrive at it naturally and it is just
| friction all the time trying to apply a practice without
| groking it.
| jqgatsby wrote:
| I've always felt that DDD is more of a meta-paradigm than
| a paradigm per-se, and shops that "arrive" at it have
| actually always been themselves examples of the practice
| in itself, as opposed to being instances _of_ itself.
|
| Sorry, I'm actually just bluffing, what is DDD?
| solarengineer wrote:
| Domain Driven Design
| arjvik wrote:
| You got me there
| recursive wrote:
| This is how I feel about "serverless".
| heavyset_go wrote:
| I'm still in the "I have to pretend to like this buzzword
| in order to remain sane" stage with "serverless".
| 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?
| webmaven wrote:
| _> 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!_
|
| I don't know your background, but this sort of discussion
| predates the web by quite a bit, though the labels,
| affordances, and other factors change considerably due to
| spatial versus temporal constraints.
|
| In HCI (and later on, usability) circles, these were the
| Multi Document Interface, Single Document Interface, Tabbed
| Document Interface, and (largely informally) IDE interface
| debates: https://en.m.wikipedia.org/wiki/Multiple-
| document_interface
|
| In fact during the days of the early web, quite a lot of
| experimentation and development was done on making browser
| windows (especially chromeless ones) participate more fully
| in the desktop environment as objects such as floating
| toolbars and widgets. Other efforts were focused on expanding
| the browser to displace the desktop OS (eg. the Netscape
| "webtop", or more recently, Chrome Apps).
|
| The details of the pro vs con arguments aren't exactly
| repeated, but like history, they certainly rhyme, and are
| similarly affected quite deeply by the capabilities and
| defaults of the underlying platform, like whether the desktop
| environment has a global menu bar.
| sanderjd wrote:
| Yeah this is super helpful!
| karmasimida wrote:
| the balance should come from the business requirement, not
| something as top-down as if the frontend development works like
| physics that it has some intrinsic principles to drive into a
| destined more advanced stage.
|
| this is most likely not true and drunken kruger syndrome
| 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.
| boogies wrote:
| > 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.
|
| Is there any reason the desktop version couldn't do that if
| Intuit wanted it to? (I imagine they just artificially
| limit it to encourage customers to ditch indefinite license
| purchases in favor of monthly SaaSS subscriptions, ie. it
| has little to do with technical advantages of the web and
| much to do with the profit advantages of software that
| stays on Intuit's servers.)
| mikeryan wrote:
| As far as I could ever tell the desktop version of
| QuickBooks was only some sort of Electron or WebView
| wrapper around the site. Not knocking it - it worked
| fine. But that was the main reason I was surprised when
| they End of Life'd the desktop version.
| bryanrasmussen wrote:
| >Is there any reason the desktop version couldn't do that
|
| There is no reason any experience cannot be replicated on
| any computing device, barring hardware limitations.
|
| There may however be reasons why things are easier done
| with one architecture than another, and there may be
| business reasons (not necessarily of benefit to the
| consumer) why a particular way of doing things will be
| preferred, and sometimes it will just be because the
| people who have been tasked with making something are
| comfortable making it one way and that is the way they
| will start because - as we are often told on sites like
| HN - when making something go with what you know if your
| purpose is to ship.
| Gigachad wrote:
| Neither the users or the providers want or care about
| some desktop p2p/self hosted accounting software. It's an
| advantage of offload the risk and accountability.
|
| I think there is also some circular logic when looking at
| the pricing models for SaaS products. Customers use them
| because they are the best, but they are very likely the
| best because they have constant revenue from
| subscriptions.
|
| So maybe you paid $100 for photoshop and used it for 3
| years but now you pay $10/month for photoshop which is
| more expensive but that's all more money going in to the
| product. And with a business tool, the better it is, the
| more money users make using it. So it's worth paying more
| for a better product.
| gernb wrote:
| What would you suggest? Would it be like Valheim (any
| many other games) where if you want to collaborate, one
| person needs to be the host and run their copy of the app
| and if they aren't running it no one can work?
|
| Or are you suggesting the average user would some how
| spin up a server and run some software and maintain that
| server so that all the collaborators can access the thing
| 24/7?
|
| Me, I love that from any of my 7 machines I can access my
| docs, spreadsheets, tax info, etc. If I have to use a
| native app then I can only access it on machines that
| have that app installed. The app might not even exist on
| some of the machines I use but a web browser does.
| 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.
| cpitman wrote:
| Thanks for the link, it is an interesting and obvious way to
| have clearer conversations.
|
| Multiple types have a recommendation to use "turbolinks-style
| transitions", which was new to me. So I did some research, and
| it's basically another take on "just render html server-side,
| and let a framework take care of AJAX-ifying it". I've seen
| some attempts at this before, like the UpdatePanel's from
| ASP.Net Web Forms back in the 2000's.
|
| It looks like Turbolinks itself is defunct, but has been
| superseded by Turbo (https://github.com/hotwired/turbo), and I
| only see chatter in Rails communities. It also looks like there
| are some other alternatives.
|
| Are people actually using "turbolinks-style transitions"? And
| if so, what are you using how is it working out for you?
| 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.
| immigrantheart wrote:
| If you do dashboards and finance applications (like trading app)
| or any other app that requires real time and heavy interactivity,
| you need SPAs.
|
| There is no other way around it.
| Existenceblinks wrote:
| That's very easy with Phoenix LiveView because the data is
| mostly readonly. Buy and Sell button are super simple.
| immigrantheart wrote:
| People don't want to use Elixir
| [deleted]
| LoveGracePeace wrote:
| At this pace, JavaScript will be gone and we will be back to the
| joy of making web apps in all Java before I retire.
| cryptonector wrote:
| > Service Workers - once experimental, now effectively 100%
| available for those of us targeting modern browsers - allow for
| offline navigation without needing to implement a client-side
| router (and all the complexity therein).
|
| Ok, sure, but what you're saying is that the code and rendering
| is still on the client, same as SPAs.
| xtat wrote:
| Here comes 17 new frontend frameworks
| Justsignedup wrote:
| I've been using SPAs to handle lots of complex interactions, and
| react makes a lot of things quite pleasant that I had to fight
| with in the past.
|
| Having said that, I am very very happy to see technology move
| forward and give us more options. I am excited about the
| possibilities. Having many options to solve complex problems in
| simple ways is a great thing, and old down sides of each are
| disappearing.
|
| Overall. Awesome.
| miiiiiike wrote:
| Hello folks and welcome to round 678 of the Least Interesting
| Conversation on the internet. SPAs are great when they're
| necessary and MPAs are great at what they do too. Thanks for
| tuning in, the series stands at 678 ties, see you again tomorrow
| for rounds 679, 680, and 681.
| edanm wrote:
| I think this is too dismissive of the post.
|
| The post wasn't about "which is better, SPAs or MPAs". It was
| specifically "what has changed in the last few years that now
| make MPAs able to handle things that they couldn't before". I
| for one learned from this post since I don't keep up with the
| current state of browser implementations of various features,
| nor with the consequences of these features.
| tomphoolery wrote:
| I disagree, the post is itself a waste of time and energy
| because this is a problem that basically nobody cares about
| or is even aware of. It's not a real problem.
| azangru wrote:
| > this is a problem that basically nobody cares about or is
| even aware of
|
| "Basically nobody" as a percentage of the global
| population? That's fine and as it should be. "Basically
| nobody" as a percentage of web developers? I strongly doubt
| that this is the case; but if it is, it is damnatory of our
| profession.
| kulikalov wrote:
| Why do you think people upvote these discussions?
| nsonha wrote:
| Because it's popular? Do you think you've made a point now?
| kulikalov wrote:
| That was a genuine question, not sarcasm.
| danjac wrote:
| 99% of the time the right answer is "use the best tool for the
| job at hand that matches your team and budget" but that won't
| generate the clicks.
| rat9988 wrote:
| Because it is a useless answer. You don't answer "what is the
| best tool for the job at hand that matches my team and
| budget" by "use the best tool for the job at hand that
| matches your team and budget".
| danjac wrote:
| No, but you answer with specific analysis rather than
| generalizing clickbait.
| graycat wrote:
| As a Web user, I urge Web site developers to return to "keep it
| simple". In particular, _multi-page_ applications are better,
| easier to understand, than _single page_ applications which tend
| to be confusing. Treat the pages of the site more like the pages
| of a book -- those pages don 't change as I'm trying to read the
| book.
|
| Net, a _single page_ application looks to me like it has no
| _pages_ at all, just a lot of confusion where I don 't know where
| I stand, what is the _state_ of my visit, something I can 't
| meaningfully copy or save.
|
| Use big 100% black fonts on a white background. In particular,
| note that about 25% of men are partially red-green color blind.
| So, if insist on using colors, avoid using both red and green on
| the same page.
|
| Have both vertical and horizontal scroll bars. Never omit either
| the vertical or the horizontal scroll bars. Accept no
| substitutes.
|
| Similarly, never have a row of images or other blocks of content
| that scroll off and on the screen left or right via little
| arrows. With that scrolling, there's no real _page_ I can have in
| mind.
|
| Don't have parts of the page moving or coming and going without
| explicit user requests. Such Web pages are a good reason just to
| leave the site. Or, maybe I DO want to look at some of that
| content -- nope, soon it's jerked from me and gone. Bummer.
|
| Don't assume that the user will display the pages at full screen
| -- often can't have that because need other windows open for the
| purpose of visiting the Web site at all.
|
| Don't cover up what I'm trying to read: So, cut way back on
| popups, pull-downs, overlays, etc.
|
| Design the Web page HTML so that I can save the page and later,
| without an Internet connection, still have my Web browser display
| the page correctly. Such saving can be crucial for pages where
| I've done something important, say, pages summarizing a purchase
| I just made.
|
| Conserve the crucial, vertical space: So, get rid of banners that
| overlay the content, take up a lot of the vertical space, and
| come and go as I scroll the page up and down. Apparently as
| people saw how to do that, doing it became popular as if it were
| a good idea -- it was a fad and a bad idea. Don't do it. Quanta
| magazine has done a lot with such banners, and it has seriously
| hurt the usability of their site.
|
| Now commonly a lot of Web pages have been done with some fancy
| work with JavaScript and require me to take several actions just
| to get to the content. I've had more than enough: When I see such
| a page, with nearly no exceptions, I just leave the Web site. I'm
| gone, out'a there.
|
| I commonly have the mouse pointer on the content of the page as I
| scroll the page, and some sites _track_ the mouse pointer and,
| then, generate lots of popups that cover up the content I 'm
| trying to scroll and read. No matter what, almost certainly, I
| regard any popup I have not explicitly requested as a big
| interruption in my work, a big waste of my time, a big
| frustration, something I really HATE, and a good reason just to
| leave the site. Tracking my mouse pointer and responding with a
| popup I didn't request is doing me a _favor_ based on some
| _assumptions_ : To me, it's not a favor. In general, just do not
| make assumptions and then do me automatic, unrequested favors by
| interrupting my effort to read the content of the site. Cut way
| back on unrequested favors. Wikipedia and Disqus both do a lot of
| mouse tracking and popup favors, and I hate both of them for it.
|
| Just keep it simple, e.g., so I can see the real content the site
| does have and I came to see. Just because it is possible to
| insult, interrupt, irritate, infuriate, and frustrate me does not
| make it a good idea.
| 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.
| arcturus17 wrote:
| Now your design system is probably all over the place and you
| have to know two ways to build a view, and have to decide
| every time which one to use.
| zkirill wrote:
| You invented a problem. SPA team and Spring team have
| separate responsibilities. Our customers don't care how it
| looks beyond ergonomics and functionality. It took us a
| long time to shift away from "SPA all the things"
| mentality.
| 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.
| seydor wrote:
| when you go to some page and it downloads 10MB of javascript
| for starters, proceeds to show you spinning wheels for 9
| seconds (sometimes with original messages such as " time to
| take the world"), then when it loads it jumps around for 12
| seconds while the images are absolutely destroying the layout
| of the page, then it beeps some chat asks you if you would like
| help, but the only help you need is to dismiss so many popups ?
| ... that one.
| 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]
| bo1024 wrote:
| I don't think the opposite of single-page app is multi-page
| app. The opposite is not an app at all, it is a "webpage". My
| viewpoint here: https://notan.app/
| nebula8804 wrote:
| >Where are those SPAs everybody is talking about?
|
| I can't speak for others but my company (of 50k) has dozens of
| internal facing SPAs each with their own dev teams. Each of
| these apps are used by at least hundreds of not thousands of
| people on a weekly basis.
| 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 :)
| littlecranky67 wrote:
| Also maintaining fullscreen play during video changes
| (playlists) is only possible in SPAs. In an MPA, every page
| re-render would require user interaction to go back into
| fullscreen again.
| 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.
| rpdillon wrote:
| This is such an interesting inversion. IIRC, one of the
| original arguments for SPAs was that they would be so
| much quicker than MPAs because they don't reload the
| entire page on every action. Now it seems like we've come
| full circle and SPAs are considered to be done well when
| they can achieve the speed and feel of an MPA!
| 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.
| collaborative wrote:
| 6groups.com (PWA) is an SPA I am developing from scratch, no
| frameworks involved. It performs really well vs its native
| Android counterpart
| [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.
| usrn wrote:
| The line between app and site is fuzzy IMO. Does cloudflare's
| documentation reader count as an app or a site? They
| certainly wrote it as an SPA.
| usrn wrote:
| The line between app and site is fuzzy IMO. Does cloudflare's
| documentation reader count as an app or a site? They
| certainly wrote it as an SPA. Hackernews seems more like
| something I would call an app etc.
| 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
| webmaven wrote:
| Not sure that heuristic works. For many people, the major
| destinations that require a login are paywalled content
| sites.
| brailsafe wrote:
| Well, it would be one of many. Considering building an
| SPA for a paywalled content site would be a little
| surprising to me in the first place, but it would make a
| lot of sense to me for any of the behind-the-scenes or
| account management facilities you'd only ever see once
| you've logged in. I wouldn't expect the content view to
| either be sufficiently interactive on its own, or
| sufficiently interactive when coupled with other aspects
| of the UI, to require the complexity of an SPA at all.
| webmaven wrote:
| What do you think the full set looks like?
|
| Once you start adding conditions and context to the
| heuristic, it starts to look a lot like a Design Pattern.
| 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.
| webmaven wrote:
| Speaking from personal experience, those aren't mutually
| exclusive.
| ragnarok451 wrote:
| We need a hardware dev to chime in
| LAC-Tech wrote:
| App developer here. Your sand sucks and it's affecting
| our apps!
| amelius wrote:
| Make your own sand then.
| webmaven wrote:
| ... and then go pound it?
| andai wrote:
| https://youtube.com/watch?v=YSYFs7Y1fFI
| kristopolous wrote:
| It's almost like their small differences come with some
| narcissism.
| mLuby wrote:
| Purity: https://xkcd.com/435/
|
| Farmville Devs <- Facebook Devs <- Chrome Devs <- OS Devs
| <- Chip Devs <- Factory Devs
| ericmcer wrote:
| If you feel old you should try Next.js. I dove into it
| recently and joined the Discord channel, sometimes I answer
| questions. It is really interesting helping people who are
| creating complex apps by stitching together a bunch of npm
| modules while having absolutely no clue about the
| underlying implementations, or the basics of web dev and
| javascript.
| regularfry wrote:
| And the meta-interesting thing is, once the abstractions
| get good enough, that is the correct direction for things
| to move in.
|
| The abstractions are not, however, good enough yet.
| ttty wrote:
| unclebucknasty wrote:
| > _Apps, not sites. It's even in the name, Single Page
| Application...you should probably build most apps as SPAs._
|
| The whole concept of Single Page Applications was misguided
| from the start, and the reason for _that_ is even in the
| name. Pages and applications should never have been mashed
| together. The moment we decided we needed apps, we should
| have abandoned the static document-based "page" concept
| altogether.
|
| We shoul've replaced it with a browser-hosted VM-based
| execution environment in which proper apps could be built.
|
| It's never been a question of MPA vs SPA. The question has
| always been how do you build browser-based applications in a
| way that escapes the impedance mismatched document/html
| model?
| dsego wrote:
| We had that, remember flash and java applets? Well, it
| wasn't that great.
| 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`.
| mhoad wrote:
| It's literally just headless evergreen chromium handling
| the rendering these days and has been for a while. It
| handles JS fine on the condition that you as a developer
| continue to think about accessibility.
| [deleted]
| likortera wrote:
| The problem is that it is not that easy to classify stuff as
| black or white. Most of the services we use are right in
| between. What's worse, what starts on one side might evolve
| to the other as new features are added.
|
| So the "It's even in the name" argument is not an easy
| decision point as you make it look like.
| 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
| moooo99 wrote:
| Many start-ups (especially ones that aren't backed by
| millions of VC money) choose Rails because of the super
| high developer productivity and the broad availability of
| well tested packages.
|
| You could just fade out rails as you could with any other
| monolith, but many companies aren't doing it because it
| offers legitimate advantages.
| wiseowise wrote:
| Nope.
| djfobbz wrote:
| Majority of the ones I know are making billions. Why
| change something that's already profitable?
| kache_ wrote:
| Why make billions when you can make millions (not dealing
| with bad async primitives and type safety that doesn't
| need some third party project like sorbet)
| 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.
| weatherlite wrote:
| Never knew this was the case, I thought these enterprisey
| stacks were all about moving slow and being compatible.
| Why are they doing this then?
| tsimionescu wrote:
| Microsoft has a strong stance of backwards compatibility,
| but they achieve this by freezing the The Old Thing as
| much as possible and keeping it working as is.
|
| Then, they come up with The New Thing every few years,
| which is not backwards compatible and only handles 20% of
| what the old thing did + a few new things, but they
| promise this is the future and will eventually have all
| the features. The Old Thing is always there if you want
| it, so there's no reason to revolt when this happens.
|
| The New Thing will eventually be replaced by a Newer
| Thing, get frozen in its current status, and the Newer
| Thing will be promised to be the future.
|
| A nice example is Windows GUI. The Old Thing is GDI. Then
| they invented WinForms in .NET, then WinForms was
| abandonned in favor of WPF, then WPF was abandonned in
| favor of Metro/Modern/Universal apps, and last I checked
| they had some new HTML+JS-based stack available. All of
| these frameworks still work - you can take an app built
| with any of them and run it on the latest Windows, and
| you can even build a new App based on any of them and
| still find resources for it etc. But none of the old ones
| are getting new features, and MS will steer you to one of
| the newer ones instead.
|
| The same kind of thing happened with communication
| frameworks (COM, then WCF, then???), with ORMs (ADO.NET,
| LINQ to SQL, Entity Framework, Entity Framework Core) and
| I'm sure others.
| v-erne wrote:
| And don't forget about silverlight and frameworks build
| on top of it (for enterprisy like form apps). That one
| was one hell of a swamp that almost drowned my friend's
| startup after MS decided to kill it. Years of hard work
| went down the drain at a snap of a finger.
| regularfry wrote:
| This is exactly why I got off the MS merry-go-round. The
| strategy seems to be to keep developers constantly
| chasing the Next Thing so they haven't got time to
| explore alternatives.
|
| I detect a similar strategy with Apple and the app store:
| make it so that the long tail of small developers can't
| invest in more than one platform by moving goalposts so
| frequently you spend any spare cycles you have trying to
| keep up.
| 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.
| Zak wrote:
| It's mature.
|
| That means it's not likely to make huge breaking changes
| without lots of notice. Its development team isn't going
| to find something more interesting to do tomorrow. Lots
| of people know it. There are lots of libraries and tools
| that work with it. Its capabilities and limitations are
| well understood and predictable. Its future isn't tied to
| a single vendor. _Lots of people know it_.
| [deleted]
| weatherlite wrote:
| Nothing changed much in the last 5 years, if you like
| .Net better stick to .Net. The fact you miss Rails
| sometimes means it wasn't that bad though.
| 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
| weatherlite wrote:
| Hot take: Everyone now uses k8s, I don't get why forcing
| our devops team to learn OTP and understand how to
| integrate Elixir with k8s is a benefit, it will only be
| harder for them. So you get most of the benefits like
| scalablity/reliability etc even if you're on the Rails -
| but you don't have to expose junior devs to a complicated
| and obscure stack like Elixir.
| pmontra wrote:
| All those people using k8s don't include any of my
| customers. Current projects are Django sites running on
| VMs, Rails sites on a kind of Heroku service and a
| Phoenix app running on VMs plus some Elixir services
| running on Google Cloud serverless services.
|
| Actually the latter is a candidate to k8s because the
| team knows less and less of server management. I think
| they are going to replace complexity with complexity for
| something that fits well in a small VM. We will see.
| [deleted]
| weatherlite wrote:
| They sound like small clients, no offense. Indeed for
| them k8s is probably an overkill - as is Elixir.
| pmontra wrote:
| No offense taken. Small contractor, small customers. The
| long tail doesn't need fancy technologies devised by
| companies that have to serve billions of users and yet a
| lot of people live there.
|
| About Elixir, I don't think it's an overkill. I find its
| pattern matching much better than anything similar in
| Python and Ruby. Running a background job without having
| to use Celery or Sidekiq is great. The deploy story is
| worse than Ruby's (IMHO) in part because it's compiled (I
| prefer to deploy with Capistrano than having to build and
| deploy.) Python's deploy story just doesn't exist.
| According to the project I'm using a self made Capistrano
| equivalent, git pull or sending git patches to the
| server.
| weatherlite wrote:
| I'm sure you serve them well with Elixir. All these
| technologies are good enough. You wouldn't be able to
| build stuff for them in PHP/Ruby/Java? You would, but you
| prefer Elixir because you think it's superior and thats
| fine. But even if its superior you have to agree
| equivalent stuff is being built in 15 other stacks.
| Technology choice is a bit overrated imo.
| pmontra wrote:
| Actually the customer chose Elixir. They found me because
| there weren't many Elixir developers in my country when
| the project started years ago. I prefer Ruby for my own
| stuff which of course is way smaller than customers
| projects.
| 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.
| webmaven wrote:
| _> After some profiling, I rearchitected the python
| algorithm to be more similar to the Elixir one and gained
| about 50% speed up._
|
| That would be a VERY interesting case study. Any chance
| you could write it up as a blog post or similar?
| regularfry wrote:
| A _lot_ of places suffer from not believing they have the
| capacity to use the right tool for the job if it 's not
| in the tech stack they already have. Similarly, people
| over-index on having a comfortable implementation path
| for feature X in technology Y, whereas technology Z, if
| they cared to look at it, would halve (or better) the
| implementation time.
| weatherlite wrote:
| There's so much more to this then Stack X runs faster or
| has better concurrency - there's development time,
| there's the team's ability to maintain the code, there's
| community size. Performance is overrated most of the time
| - it simply doesn't matter much to the business if you
| save some money on AWS bills compared to human cost.
| 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.
| regularfry wrote:
| My gut feel is that the .Net ecosystem is probably more
| complete than the Rails ecosystem, but part of that is
| because there's a larger market for commercial
| components. Like you say, tradeoffs.
| LAC-Tech wrote:
| I avoid rails-style megaframeworks like the plague. I'm
| fine writing the glue code if it means I understand more of
| the stack, or it doesn't refuse to budge if I occasionally
| have to go "off the rails".
| charlie0 wrote:
| Same for Laravel, although it hasn't grown as much as
| Rails, the amount of batteries included is amazing. There's
| very little I've had to reinvent, unlike my Node JS
| projects, where there's too much time wasted in finding and
| learning 3rd party packages that are outdated in a year or
| two.
| 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.
| mattgreenrocks wrote:
| "It depends" never leads to thought leadership, though.
| 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.
| winternett wrote:
| Amen, I fondly recall the days when browsers went back to
| exactly the same page and data that I was on before when I
| click the back button.
|
| Database driven sites and apps have experienced great
| performance and functional gains since the marketing teams
| pushed SPAs onto everything and it's tragic that billions of
| dollars will be thrown off a cliff (once again) to refactor
| everything back to prior methods... Hubris always wins until
| it fails massively.
|
| That being said, SPAs do work well for certain things, but
| people just keep losing track of the right shoe for the right
| foot.
| 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.
| tatersolid wrote:
| Wasn't the first SPA actually Microsoft's Outlook Web
| Access 5.0, back in 1997?
| nsonha wrote:
| > I don't use any of these
|
| Thanks for letting us know everyone was waiting for you
| stating your personal preferences, so they can follow suit.
| eschaton wrote:
| Nah, you should build most apps using operating systems'
| native toolkits, and stop trying to pretend web pages are
| applications.
| bowsamic wrote:
| But then you have to build it three times for desktop and
| another two times for mobile
| the_gipsy wrote:
| Mobile users can just use the web. Clicking a link is
| much easier than installing yet another app.
| fdschoeneman wrote:
| Your first paragraph is money and I don't want to get on a
| tangent, but I'm curious to know what you think rails is
| today, if not a thing?
| 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.
| tr1ll10nb1ll wrote:
| I'm building an "app" using the low-JS approach with HTMX and
| Alpine (Django back-end) and it seems to give a more hybrid
| experience.
| 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.
| giantrobot wrote:
| > 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.
|
| I see it more being whether a page uses progressive
| enhancement. If I can disable JavaScript and at least be
| able to read a page's content, then its a web page rather
| than an app. If JavaScript is an absolute requirement for
| any functionality it's an app.
|
| A page with some client-side form validation, AJAX
| submissions, or even just some dynamic content are
| awesome uses of JavaScript so long as the pages
| themselves don't hinge on me running the JavaScript.
| Posting a comment might be a POST and clicking an image
| thumbnail might load it in a new tab instead of a light
| box. The functionality is all still there if for any
| reason the JavaScript doesn't load.
|
| One of my big problems with "apps" is they have zero
| provisions for JavaScript not running. Most "apps" don't
| even give an error page telling you explicitly JavaScript
| is required. Even when you have JavaScript enabled they
| tend to break in stupid ways if you've got an ad blocker.
| 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.
| JohnBooty wrote:
| Why would an SPA do a "personalized experience" better
| than a traditional website?
|
| Amazon is highly personalized and fits well into the
| standard web page paradigm. What about Instagram's
| "personalization" wouldn't work as a standard web page?
| moooo99 wrote:
| > What about Instagram's "personalization" wouldn't work
| as a standard web page?
|
| Really nothing. But for most people Instagram is
| primarily a mobile application and comes with the usual
| experience of a mobile application. Transitions, fast
| reactions, no "whole page" reloads, etc.
|
| Continuing this experience into the less frequently used
| browser version only makes sense, especially given the
| fact that Instagram's tooling allows for a relatively
| easy transfer (iirc large parts of the mobile apps are
| implemented using React Native)
| pmontra wrote:
| Facebook used to be server side PHP and it always was
| personalized. I think the distinction is more about the
| degree of interactivity. Highly interactive GUIs (the
| hell of jQuery developers) went to SPAs and are called
| webapps. Low interaction GUIs could be server side
| rendered with the technologies of 20 years ago even
| today. Most banking sites are low interaction and could
| be old style Java even if almost every one I see is a SPA
| now. The distinction is very fuzzy.
| 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.
| dredmorbius wrote:
| Even old.reddit.com is annoying enough that I head first to
| https://teddit.net/ Principle advantage being that Reddit
| URLs are rewritten such that once _on_ the site, _you stay
| there_. This isn 't the case for either old.reddit.com or the
| even lighter alternative i.reddit.com, for which reverts back
| to www keep occurring.
| mmis1000 wrote:
| For people don't know how slow it is. This is a issue I
| opened 4 month ago and hasn't been answered.
|
| https://www.reddit.com/r/bugs/comments/rj0u77/reddit_redesig.
| ..
| jiggawatts wrote:
| I didn't know Firefox had the capability to post
| performance traces like this!
|
| Also... I wouldn't have thought that by default it would
| include _screenshots_ of potentially private /sensitive
| information such as the the titles of other open tabs.
| 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.
| mouzogu wrote:
| For me it's not so much about the technical merits of SPA vs
| MPA its the annoyance of having all the stuff that used to be
| backend now part of frontend.
|
| I resisted "learning" typescript for like 5 years or more and I
| hope it's been validated somewhat.
|
| Being a web dev is hard enough dealing with myriad devices and
| ever changing trends without consolidating every aspect of
| web/app into that role because Facebook wanted to cut down on
| their server costs.
|
| And I don't enjoy using those bloated electron apps either, the
| difference between native and JS is stark.
| BossingAround wrote:
| > I resisted "learning" typescript for like 5 years or more
| and I hope it's been validated somewhat.
|
| What does TS have to do with SPA/MPA?
| strix_varius wrote:
| ... and why is "learning" in quotes?
| nullbytesmatter wrote:
| Well, Udacity is 90% SPA (React) and it's a content/page driven
| site.
| pier25 wrote:
| Airbnb is really a hybrid. For example, the property page is
| really an spa on its own.
| 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.
| semiquaver wrote:
| > AFAIK that's not actually theirs but:
| https://github.com/defunkt/jquery-pjax
|
| Check out https://api.github.com/users/defunkt:
|
| > "id": 2
|
| pjax was written by a GitHub founder for use in
| github.com.
| msbarnett wrote:
| huh, TIL
| 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.
| littlecranky67 wrote:
| I've been developing SPAs as an independent contractor for over
| 8 years, and not a single of those SPAs is public facing - they
| are all enterprise line-of-business apps used internally.
| Sometimes I wondered how employing a team of 10-15 developers
| to develop an SPA for 1-2years (plus maintenance) is
| profitable, if your targeted user audience is 2,000-3,000
| internal employees of that business.
|
| My current gig for a smaller corp (<50 employees) I am with 3
| other developers (1 FE, 2 BE) and all that team has been doing
| for almost 1.5 years is to develop a SPA webapp that is
| exclusively used by the on-call phone support staff, which are
| no more than 4 actively working supporters at the same time.
| Admittedly, the business customers deal in huge amounts of
| money so having qualified phone support is a must here, and
| upselling/sales also happens on those calls.
| bratbag wrote:
| I have worked on similar projects in finance, where various
| regulatory requirements prevent using adhoc internal tools.
|
| It's either use an application provided by an authorised
| third party (who take a cut of every transaction) or become
| directly authorised to run solo with your own application
| that meets legislative requirements.
| altdataseller wrote:
| Monday.com, Google Docs, Trello.
| WalterGR wrote:
| Gmail
| golergka wrote:
| Visual Studio Code, Spotify, Slack.
|
| Sometimes SPAs are literally apps that you install on your
| computer.
| 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?
| [deleted]
| gandutraveler wrote:
| I don't remember which hotel website(Marriott?),I was using that
| migrated to MPA and their dev team had no clue that it broke
| their in-app chat feature. Agent asks me for registration
| details, I click on the page to get details... Poof, my chat gets
| disconnected and now I have to wait another 30 minutes for next
| agent.
| coinbasetwwa wrote:
| Pour one out for all the junior engineers on teams with senior
| engineers who read this and argue to go back to poorly
| implemented MPA's without the engineering talent to drive
| sensible abstractions.
| 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.
| FpUser wrote:
| >"You are a minority in a sea of crap"
|
| I believe there are countless companies like mine, serving
| needs of various businesses. We just do not make much noise
| and hence are not written about.
| devwastaken wrote:
| Imagine if a kde, qt or other native desktop application had to
| contact a remote server for the actual styled content to render
| to page. An SPA is the same concept of desktop applications, only
| get the data, and render it locally. It doesn't make sense for
| some things and makes sense for others.
| 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.
| hw wrote:
| > Happening in a different place makes it simpler because
| the backend no longer needs to take into consideration the
| various clients
|
| I'd argue it makes it more flexible, but not easier. It's
| so much easier rendering html serverside than having it all
| done separately in React.
|
| > 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
|
| You now also have to worry about versioning and/or
| coordinating releases. Mobile clients demanding a different
| set of APIs than web client. use graphql? Rest?
|
| > front end and the back end are agnostic to each other
|
| This is good in theory but in practice when you have to
| replatform the backend for example, it is often for reasons
| such as separating out concerns, refactoring, rewrites, or
| moving the frontend over to a new system etc and that
| usually ends up with the frontend needing to change as
| well. The frontend is coupled with the API contract that
| the backend provides and is not entirely agnostic to each
| other.
|
| This is pretty similar in nature to monoliths vs
| microservices where monoliths are by far a simpler
| architecture.
| 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?
| hw wrote:
| > 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.
|
| It really depends on what you are building and if the
| interoperability is a requirement vs costs and
| simplicity.
|
| I was part of a 4 person engineering team, all who are
| full stack, that built an app in Rails, started with
| server side rendering and later on moved to React, but
| much of what we had were still serverside rendered html.
| But our mobile app was done in Cordova and we didnt have
| to pay for mobile engineers (who usually are exclusively
| mobile) and to build out APIs for the mobile client. As a
| result our team was able to move multiple times faster
| than another team that had 4 frontend 6 backend and 8
| mobile devs.
|
| There are inherent costs when you have multiple
| teams/components or even specializations, especially
| around coordination and communication.
| 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.
| TeaVMFan wrote:
| There's also nothing stopping teams from developing the
| front-end in Java too. Java SPAs have been possible for
| over five years using TeaVM:
|
| https://teavm.org
|
| It lets you code in Java, compile to a native SPA, and
| gain all the benefits you'd expect from a single,
| strongly-typed language top to bottom (refactoring, POJO
| reuse on the front end, etc.).
|
| There is a full intro article in Java Magazine:
|
| https://blogs.oracle.com/javamagazine/post/java-in-the-
| brows...
| quickthrower2 wrote:
| It happens in one place, where state can just be a JavaScript
| object, which is what makes it simpler.
|
| Rendering on the server-side requires transfer of state, so
| you know the context. For example did you expand the 3rd
| expander or not?
| [deleted]
| hombre_fatal wrote:
| Well, they did say it made the server code simpler, not
| server+client code.
| mouzogu wrote:
| > client devices are very capable
|
| my browser is using 5GB of ram on three tabs.
|
| > and the networks are fast
|
| yeah, if you work next to the data center.
| jb3689 wrote:
| Was HTML rendering ever a concern in terms of complexity? No
| backend engineers at my company do any frontend because JS is a
| large hurdle. Sending data to the frontend requires serializing
| and deserializing which duplicates logic and tightly couples
| two components we're trying to separate by technology. You need
| to deal with a slew of new failure modes when your backend can
| die at any time - particularly if you are lazily fetching like
| most apps do.
|
| Personally I think the only reason to ever use an SPA should be
| performance when sending data over the wire is significantly
| cheaper than sending new templates or when your frontend code
| needs to handle very complex states. An SPA can also be a good
| option if you want to dog food your API layer
| TrispusAttucks wrote:
| SPAs have been shit since the beginning. It was a wrong path.
| Thank God the new comers have corrected.
| rdubs333 wrote:
| Laravel Livewire!!!
| nojvek wrote:
| What is an MPA? Multi platform app?
| julianbuse wrote:
| It's a multi page app.
| 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.
| mdavidn wrote:
| Why is this decoupling important to you? Do you use multiple
| front-ends or backends?
| mb7733 wrote:
| I definitely do where I work. Multiple web front ends plus
| mobile apps.
| NikhilVerma wrote:
| I understand that SPAs were being overused in many places. But
| the pendulum seems to be swinging back way too hard, and people
| are bashing SPAs as if it's the worst thing in the world.
|
| SPAs are cheap to host, as you just need a reverse proxy and with
| increasing internet speeds, bundle splitting can be almost
| imperceptible from MPAs
| 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.
| DeathArrow wrote:
| Even if you want to have a SPA like behavior it's easy to render
| everything on server and keep it interactive by re-rendering just
| small parts of the page using HTMX, Alpine.js or handwritten JS.
| It's trivial to add HTML templating and rendering logic to a
| WebApp.
|
| I'd argue that for somebody equally skilled in backend and
| frontend frameworks, using server side rendering would be faster
| than writing a backend and a fronted.
| FranksTV wrote:
| From a user experience standpoint there's a huge difference on
| slow connections.
| 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.
| regularfry wrote:
| "Everything is simpler if we all use MY tool."
|
| I get it, there's a sort of lowest-common-denominator argument
| going on here, but it is still an enforced consistency which
| ignores the benefits of giving teams the freedom to choose the
| best tool for their specific job.
| 88913527 wrote:
| You end up with a Frankenstein application where different
| product areas feel like they were built by entirely different
| companies. There's a real price to giving that much autonomy
| to each development team. You want teams to be empowered, but
| there has to be ground rules. Having to unwind the "every
| team had all the freedoms" and having dozens of databases and
| hundreds of microservices makes implementing anything cross-
| cutting (auditing, analytics) a slow-as-molasses multi-
| quarter initiative.
| amelius wrote:
| To me it seems more like the balance has shifted to native apps,
| unfortunately.
| LAC-Tech wrote:
| really? I barely ever use native apps anymore. even if the
| mobile webpages nag me to.
| amelius wrote:
| I think young people mostly prefer these apps. And there's a
| reason why companies nag you.
| mbrodersen wrote:
| Different architectures make sense in different contexts. Whether
| one is used more than another doesn't matter one bit. It is not a
| popularity context.
| 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.
| MiscIdeaMaker99 wrote:
| Thank you very much for telling me what SPA means.
___________________________________________________________________
(page generated 2022-05-22 23:02 UTC)