Join devRant
Do all the things like
++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatar
Sign Up
Pipeless API
From the creators of devRant, Pipeless lets you power real-time personalized recommendations and activity feeds using a simple API
Learn More
-
"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. -
@DanielVip3
Not to put too fine a point on it, but youtube, netflix and hulu are SPAs. -
@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.
-
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. -
@3rdWorldPoison I think you're referring to PWAs (Progressive Web Apps) or Hybrid Apps which (unlike SPAs) would be closing the gap between the native and web world.
SPAs alone are still entirely in the web world. -
@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. -
Yeah, 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. -
@DanielVip3
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. -
@SortOfTested Angular is a pain. I already tried it. It tries to do something and makes it 200 times worse than needed. Today the standard for big apps seems to be React.
Not even Google uses Angular.
And there aren't a lot of other options for big apps. -
-
@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.
What only relying on JavaScript for HTML form input validation looks like
Found something true as 1 == 1
Why the fuck nobody talks about Multi-page apps?! We went from a Web where everything was Multi-page server-rendered, and now everything for Web developers is "Single-page apps".
What about websites who can't do that? Not everything can be a single-page app. Only my uncle's restaurant website, or something which is TRULY a full app. No half choices.
If your website is a multi-page app/portal which actually PRELOADS data, instead of doing 100 fetch to an API within a page that is full of loading bars, well, your life is a pain.
When you want a first contentful paint which isn't a white page, well, your life is a pain.
What are React, Vue, Ember, Angular (let's exclude Svelte and Marko) going to do about Multi-page apps and SSR?
React-router sucks to me. It's performance is weak and it's useful only when you have an SPA with multiple sections which can be treated as pages (e.g. A single SPA divided in tabs).
Server-side rendering is the worst pain ever made by humanity, in React (and prob Vue, I didn't try but I can bet). And even when made easier from libs like Svelte and Marko, I (personally) can't get it to be faster enough compared to a traditional website without a JS framework and with a templating engine.
Anyways, if there's anything that I learnt from React, is to stay away from Next.js. Perfect, beautiful, mess.
All JS frameworks just seem to bloat the code and make it worse and slower, even though they're REALLY helpful.
Why? Why everyone loves them if their downsides are so clear? Why 3 projects out of 3 I made (1 React SSR, 1 Vue, 1 Marko SSR) are and will stay painfully slow and bloated, full of shit, even if in 2020 we should have evolved with the famous three shaking, with the famous lazy loading, etc.?
I am just frustrated.
And let's not even talk about Webpack, Rollup, Lasso, those module bundlers shit which are harder to configure and understand than finding a needle in a haystack.
Lasso was the easiest to configure but I anyways can't understand it. Webpack seems it was made to handle SPAs, as any tool in this freaking world, and not even considering an easy way to integrate multiple bundles for multiple pages (I know it's pretty easy, but with component sharing between pages and big unique bundles Next.js handles it soooo bad it feels like hell).
Am I the only one?
Sorry for the long rant. I just needed to rant right now.
rant
webpack
vue
react
nextjs
js
single page application
ssr