Do all the things like ++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatarSign Up
I'd like to add that even cache busting feels hard when using module bundlers.
"If your website is a multi-page app/portal which preloads data instead of doing 1000 fetch to an API with a page that basically is 100% full of loading bars, well, your life is a pain."
This suggests a problem of architecture. That violates pretty much every tenet of SOA.
For the most part, SPAs are useful where they're appropriate, like everything else. Building full desktop or native apps is the answer when you need the power they offer.
I never see a case nowadays where there's a legitimate reason to prognosticate HTML on a server and shuttle finalized content to a user. Every application I've worked on that was delivered that way could be kindly referred as "caching intensive." Server-side rendering is an optimization.
@SortOfTested okay, well, I have a streaming website for content I and my community make. And it's quite huge - episodes, info, comments, likes, ratings, leaderboards, archive, filtering, showcase, even a full admin panel.
That should be a multi-page app, and not a single-page app. It would give me pain to develop everything in one page, and have to fetch the API on page load to show the first data.
That simply CAN'T be an SPA, because we have almost a thousand of concurrent users, millions of visits per month and a really big database and caching layer.
Making so much pages and features in a single page... that would hurt user experience too. Our users mostly expect to see all data the fast as possible (as any normal user) and we NEED a good SEO.
We can't use an SPA.
Wondering why most of the websites today AREN'T SPAs? Their principle can't be applied to everything, but only to some (I'd say 60%) of web apps.
Web means links, and links mostly mean different pages.
@SortOfTested Granted Netflix and Hulu - didn't know even YouTube was an SPA. How can they handle that much data, load it so fast and separate routes? YouTube surely has a lot of pages - from videos to channels, to search and others. I don't think they just use client-side routing.
theabbie290422dNobody forced you to be a SPA, not everything can be a SPA.
Devnergy596422dI'm not an expert but after analyzing this post from beginning to end then I cannot say anything.
Because I said in the beginning that I'm not an expert. Thank you.
dontknowshit23322dI can’t tell if you’re trolling or not, but I’ll bite.
Sounds like you misunderstand the term SPA, it does not mean you load everything into a single page all at once, you still separate it into components/pages and endpoints but just replace the main content and handle navigation client side.
I think it has to do with the closing gaps between Android/iOS apps with WebApps. People who are bringing the two domains together preach SPAs for consistency in working philosophy. Although it makes sense to not shove an SPA where it's not necessary but doing so (if not causing pains from awful loading times) is not entirely unrealistic.
PS: Btw I do concur react-router sucks.
@DanielVip3 Like with any trends and fashionable technologies, an amount of people would use those for any use cases and problems instead of solely for what they are for. MPAs are still a thing and have their places.
And as @dontknowshit pointed out, you don't seem to fully understand what SPAs are, as they aren't loading *everything* into a single page (aside from the ones with no lazy loading and code splitting) and you can get a good performance out of SPAs (granted you know a fair few stuff about optimisation, rendering etc).
And you may already know by now, but frameworks like Angular, Vue, Ember and libraries like React enable devs to build SPAs, not SSR Apps.
If you need SSR, you are simply using the wrong tools as there are Angular Universal, Nuxt.js, Quasar and Next.js for this (and many more with the Node.js template-based approaches).
As for bundlers, I agree that those like Webpack aren't easy to configure, but there are options which are easy to use like Parcel.
... And I'm sure you know that bundlers aren't a must 100% of the time and when you'll need one.
Also, no one is forcing you not to do things the vanilla way. I know and have seen a fair amount of devs who never use frameworks or even libraries.
Like with any of the options going from static websites to native apps, there are pros and cons to each and trade-offs to make so what you see as better for a use case might not be suitable for another.
DanielVip31021dYeah, absolutely I understand the SPA term. I already know about routers, as I said. But they feel so wrong and even with that lazy loading thing everything looks and feels wrong.
I tried doing that, but the result was a big mess. Then I had to switch to Next.js, and it was worse.
How would Webpack handle such bundles, for different pages? Do you send different bundles for different components?
Because bundling every "page" together, even when not needed, would just bloat everything.
Also yeah, module bundlers are not necessary, but let's talk about it - if in 2020 things like React and Vue exist is because we need it. Developing a big Web app using purely JS or jQuery is a pain and feels incredibly old fashioned too.
Seems like your problem is you're basing your world view on react and vue. You can use them for large applications, but you have to know what you're doing ahead of time; scaling requires you to solve the problems you're trying to outline yourself.
Angular, on the other hand, has solved all the problems you've enumerated, and was designed for complex applications at scale.
- modules lazy load ootb
- chunks are composed based on a referential DAG
- chunks get a uuid filename at build time, which solves cache busting
Your application only every loads what it needs. There's no banana -> monkey -> jungle issue if you write your application properly.
Keep in mind: I'm not trying to evangelize to you, it's just a moral imperative for me to document counterarguments to ideas which are not fully formed.
Berkmann1850521d@DanielVip3 When you use code splitting which in the case of webpack and Parcel (and I guess it's the same for most bundlers), you'll end up with multiple JS files that are selectively loaded based on the route you're on (a bit like having different script tag sources in other HTML pages).
And keep in mind that React only provide so much compared to Vue and Angular where complex apps are much easier to write while sticking to a more cohesive ecosystem (something which would require a lot of legwork and stitching when using React).
Chances are your needs could be met by Static Site Generators like Gridsome, Gatsby, Scully etc.
And depending on your needs, sometimes an HTML/CSS + Skeleton.css + Mithrile.js stack can do the trick else that would enable you to be close to a vanilla approach while still being able to leverage the VDOM and not having to have WET HTML code.