4 ms·

Yeah what's weird is that there's is an entire generation of developers who think of SPA as the default. They think that server side is slower because you have

by chubot 6y ago

Yeah what's weird is that there's is an entire generation of developers who think of SPA as the default. They think that server side is slower because you have to send down more data, or you have to wait for the server to generate HTML. Quite the contrary, it's slower to send down 1 MB or 10 MB of JavaScript to render a page, than to simply send down a 100 KB HTML page. Even if you need some JS also, browsers know how to render concurrently with downloads, as long as you provide enough HTML. Rendering HTML on a server side Intel/AMD/whatever CPU is way faster than rendering it on a mobile device (and probably more efficient too). Even if it weren't faster and more efficient, it would save battery power on the client. And there is a ton of latency on the client side these days, ignoring network issues. There are ways of using the DOM that are expensive, and a lot of apps and frameworks seem to tickle those pathological cases. These 20-year-old browser codebases don't seem to be great workloads for even modern Android or iPhone devices. --- edit: To be fair, I think what's driving this is that many sites have mobile apps and web apps now, and mobile apps are prioritized because they have more permissions on the device. (This is obvious when you look at what happened to Reddit, etc.) It's indeed a more consistent architecture to do state management all on the client. Doing a mix of state on the server and state on the client is a recipe for confusion -- now you have to synchronize it. Still there are plenty of apps that are website-only, like the government sites people are talking about. Those people appear to be copying the slow architecture of the dual mobile+web clients and getting a result that's worse.

zamadatix 6y ago
I've always taken "server side is slower" to mean "slower to host" in context of web pages. Sure it may blow chunks to parse 10 MB of JS to click a button and leave on the client side but that's 10 MB of static JS served via dirt cheap anycast style CDN and it doesn't matter if you have 1 client or 100,000 clients you could host it on a single server's worth of CDN which doesn't have to worry about any client state ever (and for the tiny percentage of client state you do need to manage it might be hosted on a much smaller solution that handles just that logic). I'm more of the classic take that the "problem" is performance has continued to grow meaning we get more stuff made faster but the tradeoff is it runs at the same speed. Client side or server side there is no reason the app needs 10 MB of JS logic to do its job it just made it quicker and easier to deploy to have it use 10 MB of JS logic. For some things like required government services this is a real problem but for most things this is just reality - how fast a piece of software is isn't the only benchmark software is made against, often not even in the top 3 things it's checked against.
austincheney 6y ago
Take away React, Vue, Angular, or similar away from most current front end developers and there is panic. When I say panic I mean full insanity panic like abandoning the profession or completely going postal. —— A simple checklist to provide superior front end applications: * Don’t use this. You (general hypothetical you) probably don’t realize how easily you can live without it only because you have never tried. Doing so will dramatically shrink and untangle your spaghetti code. * Don’t use addEventListener for assigning events. That method was added around the time of ES5 to minimize disruption so that marketers could add a bunch of advertising, spyware, and metric nonsense everywhere more easily without asking permission from developers. That method complicated code management, is potentially point of memory leaks, and performs more slowly. * Don’t use querySelectors. They are a crutch popularized by the sizzle utility of jQuery. These are super epic slow and limit the creative expression of your developers because there is so much they can’t do compared to other means of accessing the DOM. I now add ESLint rules to my code to automate enforcement of that tiny checklist.
- pm 6y ago
  What do you use instead of these constructs?
  - austincheney 6y ago
    Instead of this I use explicitly named variables and functions. Instead of addEventListener I assign event handlers directly to the event property of the DOM: button.onclick = whatever. This forces simplicity and cleaner code management because only one function can be assigned to any given property. Instead of querySelectors I use other standard DOM methods.
    - robertakarobin 6y ago
      Other standard DOM methods like what? getElementById and getElementsByClassName?
      - Valord 6y ago
chubot 6y ago
Thinking about it a bit more, Reddit is a really good example because it launched and got popular before the iPhone or the App Store existed (2006 or so). It was a fast and minimal site back then, similar to what Google used to be. Either the existence of the mobile app, or the drive to get people to install it, ruined the website. It's slower and has poorer usability than 5 years ago, and also 15 years ago. Twitter is another company that existed before the App Store and the SPA trend. I noticed they recently turned off the ability to see the 280 chars you care about without having JavaScript on :-( It's trivial to have a no-JS fallback, and they had it, but turned it off.
- mixmastamyk 6y ago
  Indeed about twitter, I won't follow about 95% of links there due to the issue you mention.
- busymom0 6y ago
  Imo Reddit ruined their site on purpose as that makes users go to the app instead which adblockers have a hard time blocking ads on (unless you have pi hole setup). They also added a ton of extra wasted space to make users scroll longer and thus stuff more ads in and increase user times.
  - maeil 6y ago
    This isn't an opinion, this is a proven fact given that Reddit blocks many subreddits from being accessed from the browser when using the default UI, redirecting to their app, for no reason other than moving users to the app. They do not even pretend for there to be any other reason for they have never given any explanation as to why they do this. It's some of the most user-hostile behaviour I've seen, even the usual suspects don't block basic access.
    - busymom0 6y ago
      Good to hear there’s fact behind my opinion. I hadn’t researched it deep enough but just figured it out based on my own experience on their site. I don’t visit Reddit often for 2 years now unless I really need to. And when I do, I go to the old.Reddit subdomain. Question: which subreddits does Reddit block from the browser? Genuinely curious. Are they also blocked from third party apps like Apollo?
Izkata 6y ago
> They think that server side is slower because you have to send down more data, or you have to wait for the server to generate HTML. > Quite the contrary, it's slower to send down 1 MB or 10 MB of JavaScript to render a page, than to simply send down a 100 KB HTML page. Even if you need some JS also, browsers know how to render concurrently with downloads, as long as you provide enough HTML. The argument I remember from years ago used "slower" as a bad simplification. What it actually meant was, doing the rendering server-side wasted CPU the server could be using to respond to another request. Instead, just send the data and distribute some of this processing to all your users by way of client-side rendering. Also, back then bundling was a lot rarer than it is now, so the large libraries that made of most of those 10 MB javascript files would be separate files the browser can keep cached.
dikaio 6y ago
I believe Svelte has the best outlook for developers wanting to build with JS as it doesn’t load an entire framework upfront (Angular/React/etc). In regards to server side languages being slow, as you pointed out, it’s really not the case; in my experience the culprit to slow applications is the database design.

by chubot 6y ago

zamadatix 6y ago

I've always taken "server side is slower" to mean "slower to host" in context of web pages. Sure it may blow chunks to parse 10 MB of JS to click a button and leave on the client side but that's 10 MB of static JS served via dirt cheap anycast style CDN and it doesn't matter if you have 1 client or 100,000 clients you could host it on a single server's worth of CDN which doesn't have to worry about any client state ever (and for the tiny percentage of client state you do need to manage it might be hosted on a much smaller solution that handles just that logic). I'm more of the classic take that the "problem" is performance has continued to grow meaning we get more stuff made faster but the tradeoff is it runs at the same speed. Client side or server side there is no reason the app needs 10 MB of JS logic to do its job it just made it quicker and easier to deploy to have it use 10 MB of JS logic. For some things like required government services this is a real problem but for most things this is just reality - how fast a piece of software is isn't the only benchmark software is made against, often not even in the top 3 things it's checked against.

austincheney 6y ago

Take away React, Vue, Angular, or similar away from most current front end developers and there is panic. When I say panic I mean full insanity panic like abandoning the profession or completely going postal. —— A simple checklist to provide superior front end applications: * Don’t use this. You (general hypothetical you) probably don’t realize how easily you can live without it only because you have never tried. Doing so will dramatically shrink and untangle your spaghetti code. * Don’t use addEventListener for assigning events. That method was added around the time of ES5 to minimize disruption so that marketers could add a bunch of advertising, spyware, and metric nonsense everywhere more easily without asking permission from developers. That method complicated code management, is potentially point of memory leaks, and performs more slowly. * Don’t use querySelectors. They are a crutch popularized by the sizzle utility of jQuery. These are super epic slow and limit the creative expression of your developers because there is so much they can’t do compared to other means of accessing the DOM. I now add ESLint rules to my code to automate enforcement of that tiny checklist.

pm 6y ago
What do you use instead of these constructs?
- austincheney 6y ago
  Instead of this I use explicitly named variables and functions. Instead of addEventListener I assign event handlers directly to the event property of the DOM: button.onclick = whatever. This forces simplicity and cleaner code management because only one function can be assigned to any given property. Instead of querySelectors I use other standard DOM methods.
  - robertakarobin 6y ago
    Other standard DOM methods like what? getElementById and getElementsByClassName?
    - Valord 6y ago

chubot 6y ago

Thinking about it a bit more, Reddit is a really good example because it launched and got popular before the iPhone or the App Store existed (2006 or so). It was a fast and minimal site back then, similar to what Google used to be. Either the existence of the mobile app, or the drive to get people to install it, ruined the website. It's slower and has poorer usability than 5 years ago, and also 15 years ago. Twitter is another company that existed before the App Store and the SPA trend. I noticed they recently turned off the ability to see the 280 chars you care about without having JavaScript on :-( It's trivial to have a no-JS fallback, and they had it, but turned it off.

mixmastamyk 6y ago
Indeed about twitter, I won't follow about 95% of links there due to the issue you mention.
busymom0 6y ago
Imo Reddit ruined their site on purpose as that makes users go to the app instead which adblockers have a hard time blocking ads on (unless you have pi hole setup). They also added a ton of extra wasted space to make users scroll longer and thus stuff more ads in and increase user times.
- maeil 6y ago
  This isn't an opinion, this is a proven fact given that Reddit blocks many subreddits from being accessed from the browser when using the default UI, redirecting to their app, for no reason other than moving users to the app. They do not even pretend for there to be any other reason for they have never given any explanation as to why they do this. It's some of the most user-hostile behaviour I've seen, even the usual suspects don't block basic access.
  - busymom0 6y ago
    Good to hear there’s fact behind my opinion. I hadn’t researched it deep enough but just figured it out based on my own experience on their site. I don’t visit Reddit often for 2 years now unless I really need to. And when I do, I go to the old.Reddit subdomain. Question: which subreddits does Reddit block from the browser? Genuinely curious. Are they also blocked from third party apps like Apollo?

Izkata 6y ago

> They think that server side is slower because you have to send down more data, or you have to wait for the server to generate HTML. > Quite the contrary, it's slower to send down 1 MB or 10 MB of JavaScript to render a page, than to simply send down a 100 KB HTML page. Even if you need some JS also, browsers know how to render concurrently with downloads, as long as you provide enough HTML. The argument I remember from years ago used "slower" as a bad simplification. What it actually meant was, doing the rendering server-side wasted CPU the server could be using to respond to another request. Instead, just send the data and distribute some of this processing to all your users by way of client-side rendering. Also, back then bundling was a lot rarer than it is now, so the large libraries that made of most of those 10 MB javascript files would be separate files the browser can keep cached.

dikaio 6y ago

I believe Svelte has the best outlook for developers wanting to build with JS as it doesn’t load an entire framework upfront (Angular/React/etc). In regards to server side languages being slow, as you pointed out, it’s really not the case; in my experience the culprit to slow applications is the database design.