4 ms·

Ok, but any front-end engineer worth their salt should be used to the fact that the browser will never be a perfect implementation environment and be willing to

Ok, but any front-end engineer worth their salt should be used to the fact that the browser will never be a perfect implementation environment and be willing to adapt around known issues to produce functional code that works for your users. They aren't going to notice that 1% file size. They are going to notice your page not working.

mistercow 14y ago
Yes of course working in every browser should be the priority, but it is only obvious that this particular optimization would cause a problem in hindsight. As for "they aren't going to notice that 1% file size", you could keep saying that about small optimization after small optimization until your compiler's output is 10% bigger than the competition's, at which point you will start losing significant user base.
shock3naw 14y ago
A 1% reduction in output at Twitter's scale isn't as paltry as you might assume. Engineering decisions are made for both server-side and client-side reasons. You're making a blanket statement about Twitter developing bad code because of a recent bug. It will be fixed.
- GrumpySimon 14y ago
  Yes, saving 1% of a few million requests a day is not a trivial savings.
  - mistercow 14y ago
    I kind of wonder about that reasoning, though. I mean, no it's not trivial if you imagine having to foot the bill for it yourself, but proportional to the kind of money Twitter is dealing with, it's, well, still just 1% of a JS file. But I don't think we need to think of it in terms of Twitter's scale at all. The point is that saving 1% for basically free, is saving 1% for basically free, and that's worthwhile no matter how big you are. On its own, it's a drop in the bucket, but the cumulative effect of many small low-opportunity-cost savings is a significant low-opportunity-cost saving.

4 ms·

Ok, but any front-end engineer worth their salt should be used to the fact that the browser will never be a perfect implementation environment and be willing to

by greghinch 14y ago

mistercow 14y ago
Yes of course working in every browser should be the priority, but it is only obvious that this particular optimization would cause a problem in hindsight. As for "they aren't going to notice that 1% file size", you could keep saying that about small optimization after small optimization until your compiler's output is 10% bigger than the competition's, at which point you will start losing significant user base.
shock3naw 14y ago
A 1% reduction in output at Twitter's scale isn't as paltry as you might assume. Engineering decisions are made for both server-side and client-side reasons. You're making a blanket statement about Twitter developing bad code because of a recent bug. It will be fixed.
- GrumpySimon 14y ago
  Yes, saving 1% of a few million requests a day is not a trivial savings.
  - mistercow 14y ago
    I kind of wonder about that reasoning, though. I mean, no it's not trivial if you imagine having to foot the bill for it yourself, but proportional to the kind of money Twitter is dealing with, it's, well, still just 1% of a JS file. But I don't think we need to think of it in terms of Twitter's scale at all. The point is that saving 1% for basically free, is saving 1% for basically free, and that's worthwhile no matter how big you are. On its own, it's a drop in the bucket, but the cumulative effect of many small low-opportunity-cost savings is a significant low-opportunity-cost saving.