

Learning from Twitter - flapjack
http://ejohn.org/blog/learning-from-twitter/

======
bretthopper
It's good to know that this situation will lead to improvements in jQuery.

However, I'm disappointed in how twitter, or more accurately, Dustin Diaz
handled this situation. They identified some performance issues. Narrowed it
down to a jQuery version but just left it there.

jQuery is open source so they could have done some investigating on their own
and tried to narrow down what changed in that selector. Especially since this
change was blogged about (as mentioned by John).

Not to mention various people helped out twitter by finding some pretty
obvious flaws and made suggestions. Twitter has a lot of resources and I'm
assuming a lot of talented Javascript engineers. This is a situation where
they could have used their resources to contribute to an open source project
instead of the other way around.

~~~
gfunk911
I don't think it's fair yet to say that Twitter won't do these things. The
first step was fixing the regression as fast as possible.

~~~
jfager
And the second step was writing a highly-visible blog post slagging the free
code they use in their many-million-dollar website before they actually
understood the problem?

~~~
weixiyen
Exactly.

It's not hard to pinpoint the exact line of code that is causing the slow down
and come to a conclusion. This could have easily been fixed without reverting
to jQuery 1.4.2 and risk breaking other things in the process (assuming they
upgraded to 1.4.4 for a good reason).

On top of that it was their own code which led to the slowdown. Passing the
blame to jQuery seems wrong when it was their own mistake to disregard best
practices.

Here is where Twitter failed:

1) Need better testing when updating a version of the library.

2) Need to understand what the library you are using is doing and how to avoid
performance bottlenecks.

Basic stuff.

------
dionidium
I use a generic version of the waiting-for-pause trick:

    
    
        // execute callback only after a pause in user input; the function returned
        // can be used to handle an event type that tightly repeats (such as typing
        // or scrolling events); it will execute the callback only if the given timout
        // period has passed since the last time the same event fired
        function createOnPause(callback, timeout, _this) {
            return function(e) {
                var _that = this;
                if (arguments.callee.timer)
                    clearTimeout(arguments.callee.timer);
                arguments.callee.timer = setTimeout(function() { 
                    callback.call(_this || _that, e);
                }, timeout);
            }
        }
    

Use it like this:

    
    
        document.addEventListener('scroll', createOnPause(function(e) {
            // do something interesting here
        }, 1500, this), false);
    

Edit: Oops! The version in the article runs some code if any scroll event
occurred since it last fired, but this one doesn't execute the callback until
the user stops scrolling for some amount of time. Anyway, maybe it's still
useful for some folks.

~~~
long
For anyone that's interested, two related techniques are called "throttling"
and "debouncing".

~~~
ryankirkman
Both of which are available in the awesome Underscore.js library:
<http://documentcloud.github.com/underscore/>

------
eapen
Why isn't John a billionaire already?

~~~
jeresig
Heh, while I assume that this was mostly rhetorical and largely tongue-in-
cheek it is a question that I've been pondering lately. (Or, more accurately,
thinking about what work excites me.)

I've been working on jQuery full-time now for about 1.5 years (sponsored by my
employer, Mozilla). Prior to that I worked on jQuery in my spare time for
about 4 years while doing other things (I was in college, then in Y Combinator
- Summer 2006, and then worked for Mozilla as a JavaScript Evangelist).

I've managed to pigeon-hole myself into the position of a JavaScript framework
maintainer rather solidly (for better or worse).

That being said I really enjoy what I do and have trouble thinking of
something that I would rather do as my day job. Being able to work on a piece
of code that I've largely written from scratch and promote it to a community
of eager users is my dream. I've often thought about making a leap into
something else but struggle to think of something that would hold my interest
as deeply.

I'm largely not interested in starting or joining a business. For whatever
reason I frequently find that attaching a profit motive to work largely
impedes my ability to be happy and seems to run contrary to my overall goals
(educating people, giving good tools to developers -- and providing both to
anyone and everyone, no restriction).

Perhaps I'll find some interesting project some day that will open the
financial floodgates (or perhaps I'll enter a situation -- such as having
children -- that will necessitate me earning more than I do now) but I'm quite
content now where I am, doing what I'm doing.

All this being said, I'm constantly looking at and exploring new things. At
the moment though most of that is outside the realm of JavaScript, or even
computers, and mostly relating to art. It's unclear to me if that's something
that'll hold my long-term interest (although it has for the past few years)
but we shall see.

~~~
theodore
In my life, discovering jQuery is what made front-end development fun again. I
think we're incredibly fortunate to have people like you helping us build
software, and if it was possible to measure the aggregate impact of your work
it would be staggering..

~~~
weixiyen
Same. Besides being a master of javascript, Resig also has a unique talent for
API design which separates jQuery from competitors.

------
blago
jQuery makes things almost too easy. As a result it gives confidence and power
to a lot of people to write code that despite all sillines will still work. A
professional JS developer would've debounced the scroll events and cached the
selector results.

~~~
axod
jQuery promotes bad practices. People assume $('something') is a cheap
variable access, when in fact it could be pretty slowly executing several
functions. So they don't bother caching anything.

~~~
po
I think by "promote bad practices" you might mean "abstracts complexity away
from the developer".

This is true of just about any API. Nobody blames the API when their ORM layer
generates a massive SQL query based on complex query input. Understanding the
performance characteristics of the 'backend' is assumed.

~~~
axod

      $FOO in php is cheap.
      $('FOO') in jquery is expensive.
    

I don't think using $ to signify "Run some load of jquery code" was a wise
choice. Newcomers who don't know what is going on under the hood will
regularly write loops with $('FOO') inside them, which is crappy code.

They're doing what they think is best, so I don't blame them. I blame jquery
for making it look cheap.

~~~
rimantas
Why on Earth you assume that someone starting to use jQuery will come from PHP
background, and more over, why should that person think that $FOO in PHP is
cheap? I guess anyone thinking in terms of performance cost will be smart
enough to understand what $() does in jQuery, especially when advice to cache
selectors is on every wall.

~~~
axod
idle in #javascript for a while. It comes up all the time.

------
cabalamat
This sort of thing is one reason I hate websites which use a lot of Javascript
when they don't need to. Another reason is that it breaks expectations of how
websites should work.

~~~
larrywright
To be fair, the expectation of how websites work is changing. Lots of small
touches in applications aren't strictly necessary(animation, transparency),
but they do make for an overall nicer experience. People have come to expect
these things from modern websites.

~~~
cabalamat
> _Lots of small touches in applications aren't strictly necessary(animation,
> transparency), but they do make for an overall nicer experience._

I can't offhand think of a single example where they've improved my
experience. (With the exception of things like Google Maps where the JS is an
important part of the user interface.) When, for example, a menu or picture
animates open instead of appearing instantly, at best I feel mild irritation.

Maybe I'm just a cumudgeon.

------
btipling
>since scrolling itself didn't change the DOM

Scrolling did indirectly change the DOM as you load more tweets when you
scroll. But the point here is that the actual scrolling is not changing the
DOM, the append is, and that's probably when you should update your query
cache.

~~~
brown9-2
I interpreted this as meaning that not all scrolling changed the DOM, only
scrolling that reached the bottom of the window.

------
Charuru
What in the world. I expected something interesting, but this is some major
fail by twitter. Not caching selectors just boggles my mind. How can a million
dollar web company do this?

