5 ms·

I feel like I'm about to wander into a debate that's over my head, but I don't see why one computer (or one small group of computers) should be responsible for

I feel like I'm about to wander into a debate that's over my head, but I don't see why one computer (or one small group of computers) should be responsible for doing work that could easily be performed in a more distributed way by people's browsers, if only because it's cheaper to offload that work onto the client and leaves less ways to crash the server-side application. I'm with you 100 percent when it comes to "I can't read this text document because it needs 45 JS libraries to render," that's stupid. But it's probably stupid because it's over-engineered, not because it uses the browser. I feel like this is going to become a bigger and bigger debate in the coming years, and I'm eager to be proven wrong, or at least understand the other side. But if I'm building the next great web-based spreadsheets application (I'm not), my immediate and overwhelming success is going to be WAY easier to manage if the majority of my code is being executed on the millions of computers calling in to use it, not on the three servers running in my auto scaling group. Why WOULDN'T I pick that option?

TheLoneWolfling 11y ago
Let me tell you a (probably-apocryphal) story: There was a giant multinational hamburger chain where some bright MBA figured out that eliminating just three sesame seeds from a sesame-seed bun would be completely unnoticeable by anyone yet would save the company $126,000 per year. So they do it, and time passes, and another bushy-tailed MBA comes along, and does another study, and concludes that removing another five sesame seeds wouldn't hurt either, and would save even more money, and so on and so forth, every year or two, the new management trainee looking for ways to save money proposes removing a sesame seed or two, until eventually, they're shipping hamburger buns with exactly three sesame seeds artfully arranged in a triangle, and nobody buys their hamburgers any more. (http://www.joelonsoftware.com/items/2007/09/11.html http://www.joelonsoftware.com/items/2007/09/11.html)
- rev_bird 11y ago
  I think I see the connection, but I think it jumped over one piece of my argument (if my statement could even be called that): In the burger example, removing sesame seeds is an act that makes the product objectively worse, just in a way that will hopefully not make it worse enough to affect demand. I don't think it's analogous to a developer taking advantage of modern consumer hardware to do the work computers were designed to do, because it's not necessarily a worse product you're delivering. If your internet connection is spotty, it's likely a better experience in some ways. It just seems like people have these brilliant machines capable of executing all of this code (more or less) out of the box, but we're treating them as thin clients because... why? Because some people won't upgrade their OS/browser? Because the method of delivery is the same one that's used to inject banner ads and flashy video ad thingies? If that's the case, then it seems like the whole "server-side rendering" option is getting to sound pretty good for advertising, too. Then where are we?
  - TheLoneWolfling 11y ago
    Let me make the connection a little more explicit: In {the burger case}, {removing sesame seeds} is an act that makes {the product} objectively worse, just in a way that will hopefully not make it worse enough to affect demand. And in {this case}, {punting things from server-side to client-side} is an act that makes {power usage, wear and tear, security, battery life, bandwidth use} objectively worse, just in a way that will hopefully not make it worse enough to affect demand.
    - rev_bird 11y ago
      Ah! Now I see, thank you. I think some of this is debatable, though: * Security: Yes, there's not too much argument that can be made for unquestioningly allowing arbitrary code execution on your computer. I think part of this will improve with browser enhancements, so long as they go more in the direction of sandboxing than in the direction of "Hey let's give Chrome access to everything in your computer right?!" Doing important stuff server-side is probably safer for users. That said, I'm bad at security. I just don't know enough about it, so I can't put up much of a fight. * Bandwidth use: I'd actually be really interested to see some research on this. Needing to download a different version of jQuery/AngularJS/Backbone for every website you visit is certainly not particularly efficient, but I wonder how long you need to be on a website before they've sent you more HTML data than you would have had to deal with pulling down the Javascript and just pushing JSON data into it. For the mobile web at least, you win. * Regarding power usage and wear and tear, I don't consider it a crime to make a computer do computing, which may be our main point of disagreement. If I've got a 2+ gHz processor and a few gigs of RAM, what else am I going to be using it for? Almost all of my apps are web-based, and I'd rather hear my fan rev up a little bit while Firefox renders a big graph instead of waiting for a server to generate a picture of one and just send it to me.
      - TheLoneWolfling 11y ago
        > I'd rather hear my fan rev up a little bit while Firefox renders a big graph instead of waiting for a server to generate a picture of one and just send it to me. You are not me. (Not to mention I am not against doing most things client-side. I am specificially against Turing-complete languages being required on the client side. Things like charts are fine.) I do not see why things should be done multiple times when they can be done once. You're offloading visible costs to places where they are hidden and then calling it gone.
- jacalata 11y ago
  I hate this story, because its clearly actually about people failing at designing studies, and everyone glosses over that.
TeMPOraL 11y ago
> I don't see why one computer (or one small group of computers) should be responsible for doing work that could easily be performed in a more distributed way by people's browsers For one reason, because that one computer can usually do it (or at least most of it) once, and instead you're forcing millions of people to redo the same computation themselves. That's just... wrong. > But if I'm building the next great web-based spreadsheets application (...) Why WOULDN'T I pick that option? Well, in this case this is the right way, because you need to dynamically interact with data entered by the user (in this case, people usually make another error - they send data to server that there is no need for; but that's another topic. [0]). You're writing a web application. But a web site, like landing pages, blogs with articles, etc. have exactly zero reasonable needs for rendering everything client-side. It's just making the same compute millions of times because someone was too lazy to compute it once. [0] - actually, it's not. One could notice that most of the problems with current web come from two things: sending the code that should stay on the server to the client, and sending data that should stay with the client to a server.
- rev_bird 11y ago
  I think we might agree with each other, but you are being more clear than I was. If we are looking at the web as the miraculous document-exchanging network that it was, yes, Javascript is may be literally ruining everything. If you can render something once, absolutely do it once, what a huge waste. I was more disagreeing with the concluding assertion that "with modern tools, there's no reason that anything — even a highly interactive app — couldn't be prerendered on the server." There's no reason it couldn't be, sure, but it's way harder when the clients are just as capable -- and, once things start getting busy, probably even more capable.
  - deleted 11y ago
    [deleted]
adrusi 11y ago
Well yeah, you're right that you don't necessarily want every interactive app to use server rendering. TeMPOraL's reply gets the point across pretty well. What I was trying to convey is that with tools like react, where you can share your view code between the client and server, and do the same work on the client and server without doubling the required development effort, you can reasonably do it. Whether or not to take this approach is to be determined on a case-by-case basis. Some tools are too interactive and have too tight a feedback loop to make any sense without javascript. A spreadsheet is an example where I'd probably choose to break support for no-javascript, but it's less clear-cut than, say, a CAD application. An example where I'd opt to support clients without javascript is a todo-list application, or a twitter-like.
tripzilch 11y ago
> I don't see why one computer (or one small group of computers) should be responsible for doing work that could easily be performed in a more distributed way by people's browsers, if only because it's cheaper to offload that work onto the client and leaves less ways to crash the server-side application. Of course, this has always already been the case! That's why we don't stream our webpages as images (or video, if you need to scroll), but instead offload the work of rendering a graphical representation of the symbolic HTML representation to the client-side browser. It's a pretty solid idea (apart from the Browser Wars), and one of the ideas that made the WWW viable. The ridiculous part, however, is where people somehow decide that we should wrap more and more and yet another layer of abstraction onto it. It's not that web servers have grown less powerful and therefore need to offload more work onto their clients. The demands on web servers are higher today, but they've also grown more powerful, and we came up with some pretty clever scaling technologies to deal with those higher demands. But offloading code execution in the form of client-side JS is not really one of those, in practice. Yes, the idea could technically be used to accomplish that and make less work on the server side, but really, take a look at this page, or any (bloated) page like the problem we're describing; That's not what's going on here, it's about the same amount of work on the server side, nothing's being offloaded, just more work on the client side. At least the Flash-only-interface websites that plagued the web 10 years ago offered us UI elements that weren't possible in HTML back then (for better or worse), but today's JS bloat truly doesn't add anything that can't be done in a much leaner, less client resource-intensive way. Even your spreadsheet example. Sure, run the calculations client-side, that only makes sense, no need to throw out JS with the bathwater. But what sort of calculations are we talking about, realistically? For a medium spreadsheet, a few hundreds of summations and multiplications. Nothing of the kind that should make a 5-year old computer even blink. But whatever these types of apps are actually doing they manage to crawl the jankscroll already even on an empty document, let alone when you try to use it.

TheLoneWolfling 11y ago

Let me tell you a (probably-apocryphal) story: There was a giant multinational hamburger chain where some bright MBA figured out that eliminating just three sesame seeds from a sesame-seed bun would be completely unnoticeable by anyone yet would save the company $126,000 per year. So they do it, and time passes, and another bushy-tailed MBA comes along, and does another study, and concludes that removing another five sesame seeds wouldn't hurt either, and would save even more money, and so on and so forth, every year or two, the new management trainee looking for ways to save money proposes removing a sesame seed or two, until eventually, they're shipping hamburger buns with exactly three sesame seeds artfully arranged in a triangle, and nobody buys their hamburgers any more. (http://www.joelonsoftware.com/items/2007/09/11.html http://www.joelonsoftware.com/items/2007/09/11.html)

rev_bird 11y ago
I think I see the connection, but I think it jumped over one piece of my argument (if my statement could even be called that): In the burger example, removing sesame seeds is an act that makes the product objectively worse, just in a way that will hopefully not make it worse enough to affect demand. I don't think it's analogous to a developer taking advantage of modern consumer hardware to do the work computers were designed to do, because it's not necessarily a worse product you're delivering. If your internet connection is spotty, it's likely a better experience in some ways. It just seems like people have these brilliant machines capable of executing all of this code (more or less) out of the box, but we're treating them as thin clients because... why? Because some people won't upgrade their OS/browser? Because the method of delivery is the same one that's used to inject banner ads and flashy video ad thingies? If that's the case, then it seems like the whole "server-side rendering" option is getting to sound pretty good for advertising, too. Then where are we?
- TheLoneWolfling 11y ago
  Let me make the connection a little more explicit: In {the burger case}, {removing sesame seeds} is an act that makes {the product} objectively worse, just in a way that will hopefully not make it worse enough to affect demand. And in {this case}, {punting things from server-side to client-side} is an act that makes {power usage, wear and tear, security, battery life, bandwidth use} objectively worse, just in a way that will hopefully not make it worse enough to affect demand.
  - rev_bird 11y ago
    Ah! Now I see, thank you. I think some of this is debatable, though: * Security: Yes, there's not too much argument that can be made for unquestioningly allowing arbitrary code execution on your computer. I think part of this will improve with browser enhancements, so long as they go more in the direction of sandboxing than in the direction of "Hey let's give Chrome access to everything in your computer right?!" Doing important stuff server-side is probably safer for users. That said, I'm bad at security. I just don't know enough about it, so I can't put up much of a fight. * Bandwidth use: I'd actually be really interested to see some research on this. Needing to download a different version of jQuery/AngularJS/Backbone for every website you visit is certainly not particularly efficient, but I wonder how long you need to be on a website before they've sent you more HTML data than you would have had to deal with pulling down the Javascript and just pushing JSON data into it. For the mobile web at least, you win. * Regarding power usage and wear and tear, I don't consider it a crime to make a computer do computing, which may be our main point of disagreement. If I've got a 2+ gHz processor and a few gigs of RAM, what else am I going to be using it for? Almost all of my apps are web-based, and I'd rather hear my fan rev up a little bit while Firefox renders a big graph instead of waiting for a server to generate a picture of one and just send it to me.
    - TheLoneWolfling 11y ago
      > I'd rather hear my fan rev up a little bit while Firefox renders a big graph instead of waiting for a server to generate a picture of one and just send it to me. You are not me. (Not to mention I am not against doing most things client-side. I am specificially against Turing-complete languages being required on the client side. Things like charts are fine.) I do not see why things should be done multiple times when they can be done once. You're offloading visible costs to places where they are hidden and then calling it gone.
jacalata 11y ago
I hate this story, because its clearly actually about people failing at designing studies, and everyone glosses over that.

TeMPOraL 11y ago

> I don't see why one computer (or one small group of computers) should be responsible for doing work that could easily be performed in a more distributed way by people's browsers For one reason, because that one computer can usually do it (or at least most of it) once, and instead you're forcing millions of people to redo the same computation themselves. That's just... wrong. > But if I'm building the next great web-based spreadsheets application (...) Why WOULDN'T I pick that option? Well, in this case this is the right way, because you need to dynamically interact with data entered by the user (in this case, people usually make another error - they send data to server that there is no need for; but that's another topic. [0]). You're writing a web application. But a web site, like landing pages, blogs with articles, etc. have exactly zero reasonable needs for rendering everything client-side. It's just making the same compute millions of times because someone was too lazy to compute it once. [0] - actually, it's not. One could notice that most of the problems with current web come from two things: sending the code that should stay on the server to the client, and sending data that should stay with the client to a server.

rev_bird 11y ago
I think we might agree with each other, but you are being more clear than I was. If we are looking at the web as the miraculous document-exchanging network that it was, yes, Javascript is may be literally ruining everything. If you can render something once, absolutely do it once, what a huge waste. I was more disagreeing with the concluding assertion that "with modern tools, there's no reason that anything — even a highly interactive app — couldn't be prerendered on the server." There's no reason it couldn't be, sure, but it's way harder when the clients are just as capable -- and, once things start getting busy, probably even more capable.
- deleted 11y ago
  [deleted]

adrusi 11y ago

Well yeah, you're right that you don't necessarily want every interactive app to use server rendering. TeMPOraL's reply gets the point across pretty well. What I was trying to convey is that with tools like react, where you can share your view code between the client and server, and do the same work on the client and server without doubling the required development effort, you can reasonably do it. Whether or not to take this approach is to be determined on a case-by-case basis. Some tools are too interactive and have too tight a feedback loop to make any sense without javascript. A spreadsheet is an example where I'd probably choose to break support for no-javascript, but it's less clear-cut than, say, a CAD application. An example where I'd opt to support clients without javascript is a todo-list application, or a twitter-like.

tripzilch 11y ago

> I don't see why one computer (or one small group of computers) should be responsible for doing work that could easily be performed in a more distributed way by people's browsers, if only because it's cheaper to offload that work onto the client and leaves less ways to crash the server-side application. Of course, this has always already been the case! That's why we don't stream our webpages as images (or video, if you need to scroll), but instead offload the work of rendering a graphical representation of the symbolic HTML representation to the client-side browser. It's a pretty solid idea (apart from the Browser Wars), and one of the ideas that made the WWW viable. The ridiculous part, however, is where people somehow decide that we should wrap more and more and yet another layer of abstraction onto it. It's not that web servers have grown less powerful and therefore need to offload more work onto their clients. The demands on web servers are higher today, but they've also grown more powerful, and we came up with some pretty clever scaling technologies to deal with those higher demands. But offloading code execution in the form of client-side JS is not really one of those, in practice. Yes, the idea could technically be used to accomplish that and make less work on the server side, but really, take a look at this page, or any (bloated) page like the problem we're describing; That's not what's going on here, it's about the same amount of work on the server side, nothing's being offloaded, just more work on the client side. At least the Flash-only-interface websites that plagued the web 10 years ago offered us UI elements that weren't possible in HTML back then (for better or worse), but today's JS bloat truly doesn't add anything that can't be done in a much leaner, less client resource-intensive way. Even your spreadsheet example. Sure, run the calculations client-side, that only makes sense, no need to throw out JS with the bathwater. But what sort of calculations are we talking about, realistically? For a medium spreadsheet, a few hundreds of summations and multiplications. Nothing of the kind that should make a 5-year old computer even blink. But whatever these types of apps are actually doing they manage to crawl the jankscroll already even on an empty document, let alone when you try to use it.