9 ms·

I don't fully understand your point. My quote you're using is meant to be rhetorical. So you're not Twitter... are you implying that you could build an all JS a

by n8agrin 15y ago

I don't fully understand your point. My quote you're using is meant to be rhetorical. So you're not Twitter... are you implying that you could build an all JS application and avoid all of the problems that Twitter ran into at Twitter's scale? If so, I'd love to see you execute your ideas successfully and explain them so we could all learn from you.

moe 15y ago
Yes, I'm implying that. I have personally done it for smaller apps. Google and others are demonstrating it with gmail et al, at a significantly higher complexity than twitter. It's nonsensical to conclude "Twitter can't do it so it isn't possible". I maintain twitter.com is slow because twitter is incompetent or doesn't care about their product. When you look at what the page actually does then there's no reason why it has to be a 2MB download. There's also no reason why any javascript (other than a couple hundred bytes) needs to be loaded synchronously. There's no reason they can't serve direct tweet links as static HTML and upgrade the page post-load or when the user starts interacting with it. There's no reason the page needs to flicker for 2-3 seconds post-load before becoming usable. These are all symptoms of sloppy engineering.
- deleted 15y ago
  [deleted]
- kalleboo 15y ago
  Isn't "they could serve direct links as static HTML" the whole point of this discussion? That writing the whole app as JavaScript only is too slow? In any case, Gmail is not a good example to support your case since it loads just as slowly as Twitter does, with a progress bar and everything.
  - moe 15y ago
    Isn't "they could serve direct links as static HTML" the whole point of this discussion? For me the point of the discussion was the claim that the first-load performance of a fat-client app is inherently terrible. This is false. It is a straightforward optimization problem. Twitter didn't care to optimize. I don't think it is under debate that the overall responsiveness (after first-load) in a client-side app is heads and shoulders above anything you can achieve in the request/response paradigm. Network latency is real, AJAX can mitigate it but instant response is only possible when you don't hit the server. So all we're talking about here is the specific (important) case of the initial page-load. As said above, that case has tons of optimization potential, up to the point where it's near indistinguishable from a regular HTML page-load. Gmail is not a good example to support your case This may be subjective. Yes, GMail is slow. But it loads faster than twitter for me, despite being significantly more complex. I also imagine google has less incentive to optimize the first-load because unlike twitter users rarely follow deep-links to gmail. Now imagine twitter applied only the little optimization that google has to their much smaller app - the latency problem would probably not exist. And if that's not enough, I can only repeat: It's a valid approach to serve static HTML for direct tweet links (or just for everything) and upgrade it asynchronously. My point is that it's very possible to optimize this problem away where it matters (deep links to tweets). I've done it myself a couple times. It's nasty gruntwork, involving endless Firebug sessions. Crying Foul and "this is not possible" is a lazy cop-out.
    - n8agrin 15y ago
      You're making a lot of assumptions that are unfounded. What you're suggesting is usually called progressive enhancement. Yeah it's great, but sadly when you are using a system like Spine, Backbone or Ember, it's not just a matter of "endless Firebug sessions" to resolve the initial bootstrap problem. No one claims that this is not possible, nor is anyone "crying foul". On the contrary I know first hand how much of this work was done at Twitter and how difficult it is. But as you stand by your petulant claim that "twitter.com is slow because twitter is incompetent or doesn't care about their product." I stand by mine, that there are tradeoffs when embracing one style of development over another. Feel free to disagree with me but back it up with experience, not false assumptions, blanket statements and the denigration of many good people.
      - moe 15y ago
        but sadly when you are using a system like Spine, Backbone or Ember, it's not just a matter of "endless Firebug sessions" to resolve the initial bootstrap problem. Oh, what else is the matter then? back it up You mean like you just backed up your claim of Spine/Backbone/Ember having some mythical, unspecified problem that prevents bootstrap optimization?

by n8agrin 15y ago

moe 15y ago

Yes, I'm implying that. I have personally done it for smaller apps. Google and others are demonstrating it with gmail et al, at a significantly higher complexity than twitter. It's nonsensical to conclude "Twitter can't do it so it isn't possible". I maintain twitter.com is slow because twitter is incompetent or doesn't care about their product. When you look at what the page actually does then there's no reason why it has to be a 2MB download. There's also no reason why any javascript (other than a couple hundred bytes) needs to be loaded synchronously. There's no reason they can't serve direct tweet links as static HTML and upgrade the page post-load or when the user starts interacting with it. There's no reason the page needs to flicker for 2-3 seconds post-load before becoming usable. These are all symptoms of sloppy engineering.

deleted 15y ago
[deleted]
kalleboo 15y ago
Isn't "they could serve direct links as static HTML" the whole point of this discussion? That writing the whole app as JavaScript only is too slow? In any case, Gmail is not a good example to support your case since it loads just as slowly as Twitter does, with a progress bar and everything.
- moe 15y ago
  Isn't "they could serve direct links as static HTML" the whole point of this discussion? For me the point of the discussion was the claim that the first-load performance of a fat-client app is inherently terrible. This is false. It is a straightforward optimization problem. Twitter didn't care to optimize. I don't think it is under debate that the overall responsiveness (after first-load) in a client-side app is heads and shoulders above anything you can achieve in the request/response paradigm. Network latency is real, AJAX can mitigate it but instant response is only possible when you don't hit the server. So all we're talking about here is the specific (important) case of the initial page-load. As said above, that case has tons of optimization potential, up to the point where it's near indistinguishable from a regular HTML page-load. Gmail is not a good example to support your case This may be subjective. Yes, GMail is slow. But it loads faster than twitter for me, despite being significantly more complex. I also imagine google has less incentive to optimize the first-load because unlike twitter users rarely follow deep-links to gmail. Now imagine twitter applied only the little optimization that google has to their much smaller app - the latency problem would probably not exist. And if that's not enough, I can only repeat: It's a valid approach to serve static HTML for direct tweet links (or just for everything) and upgrade it asynchronously. My point is that it's very possible to optimize this problem away where it matters (deep links to tweets). I've done it myself a couple times. It's nasty gruntwork, involving endless Firebug sessions. Crying Foul and "this is not possible" is a lazy cop-out.
  - n8agrin 15y ago
    You're making a lot of assumptions that are unfounded. What you're suggesting is usually called progressive enhancement. Yeah it's great, but sadly when you are using a system like Spine, Backbone or Ember, it's not just a matter of "endless Firebug sessions" to resolve the initial bootstrap problem. No one claims that this is not possible, nor is anyone "crying foul". On the contrary I know first hand how much of this work was done at Twitter and how difficult it is. But as you stand by your petulant claim that "twitter.com is slow because twitter is incompetent or doesn't care about their product." I stand by mine, that there are tradeoffs when embracing one style of development over another. Feel free to disagree with me but back it up with experience, not false assumptions, blanket statements and the denigration of many good people.
    - moe 15y ago
      but sadly when you are using a system like Spine, Backbone or Ember, it's not just a matter of "endless Firebug sessions" to resolve the initial bootstrap problem. Oh, what else is the matter then? back it up You mean like you just backed up your claim of Spine/Backbone/Ember having some mythical, unspecified problem that prevents bootstrap optimization?