Big Social Networking Sites--Good Examples?

Discussion in 'Javascript' started by David Mark, Dec 18, 2009.

  1. David Mark

    David Mark Guest

    I've seen the opinion expressed numerous times that large social
    networking sites are shining examples of Web development proficiency.
    In other words, if their (ostensibly) high-rent code monkeys aren't
    doing something, it's not a good idea. Conversely, anything they do
    must be gold. :)

    Well, in the "Real World" (as pundits love to discuss), it doesn't
    fly.

    I've used the IMEEM site off and on since a media server went down,
    but was recently greeted by a re-vamped site (wasn't very good to
    begin with) that played no music. Instead it told me I needed to get
    a newer version of Flash (yet again). Well, that sucks, but I was
    willing to try.

    The link to Adobe landed on a blaring video that brought FF to its
    knees momentarily and left me unable to click the next link to
    download the stupid thing. Finally getting past that barrier, I
    landed on a page that insisted my download would start automatically.
    It didn't. So I clicked the link and downloaded an EXE. Running the
    installer brought up a dialog that said "You must close down the
    following... (FireFox)". Okay. But FF was so traumatized by all of
    the Flash and Ajax that the process hung. Forcing it to shut down
    with Task Manager allowed the installation to proceed.

    Finally back to IMEEM, still no music as they are now part of MySpace
    (!), requiring a sign-up there. That site was so bloated and full of
    endless Ajax requests (status bar never shuts up) that it was unusable
    (at least in FF). The music player never got past the blank white box
    stage. As a last ditch attempt, I tried Chrome. The stupid site
    wouldn't even load (though it appeared to be trying to do something).

    End result. Two sites off my list for good. I'm sure they appeared
    to work great for the developers on the latest PC's, out of the box
    with just the browser (and the latest Flash) running. It's the same
    way with layouts. They might look good at the highest resolution,
    with a maximized browser window, no extra toolbars, etc. For setups
    that vary from the developers' they scroll horizontally, fall apart,
    etc.

    Didn't catch what library (or libraries) went into these
    abominations. Didn't get past this:-

    <head><meta http-equiv="X-UA-Compatible" content="IE=EmulateIE7" />
    <script type="text/javascript">
    //<![CDATA[

    That sort of says it all. ;)
    David Mark, Dec 18, 2009
    #1
    1. Advertising

  2. David Mark

    Matt Kruse Guest

    On Dec 18, 9:37 am, David Mark <> wrote:
    > I've seen the opinion expressed numerous times that large social
    > networking sites are shining examples of Web development proficiency.


    Wow, who ever said that?

    Facebook is one of the biggest and most popular sites on the web. Its
    code is horrendous, and even some of the concepts it uses are very
    flawed.

    Quality is very hard to scale, and they are just a victim of that
    rule. There are very few, if any, exceptions. IMO.

    Matt Kruse
    Matt Kruse, Dec 18, 2009
    #2
    1. Advertising

  3. David Mark

    David Mark Guest

    On Dec 18, 11:52 am, Matt Kruse <> wrote:
    > On Dec 18, 9:37 am, David Mark <> wrote:
    >
    > > I've seen the opinion expressed numerous times that large social
    > > networking sites are shining examples of Web development proficiency.

    >
    > Wow, who ever said that?


    Loads of people. I hear it (here) at least a few times per month.
    Usually in response to a code review (i.e. nothing is perfect!)

    >
    > Facebook is one of the biggest and most popular sites on the web. Its
    > code is horrendous, and even some of the concepts it uses are very
    > flawed.


    No question.

    >
    > Quality is very hard to scale, and they are just a victim of that
    > rule.


    I don't follow. Using terrible JS and tons of Flash has nothing to do
    with scalability.

    > There are very few, if any, exceptions. IMO.


    I know of at least a few. ;)
    David Mark, Dec 18, 2009
    #3
  4. David Mark

    Jim Ley Guest

    On Fri, 18 Dec 2009 08:58:48 -0800 (PST), David Mark
    <> wrote:

    >On Dec 18, 11:52=A0am, Matt Kruse <> wrote:
    >> Quality is very hard to scale, and they are just a victim of that
    >> rule.


    Scalability in development - the more code you need to write, the more
    you need to employ weaker people. the less individuals feel they have
    ownership "why should I work hard to be perfect, when _they_ produce
    such crap?" etc.

    Jim.
    Jim Ley, Dec 18, 2009
    #4
  5. David Mark

    David Mark Guest

    On Dec 18, 12:36 pm, (Jim Ley) wrote:
    > On Fri, 18 Dec 2009 08:58:48 -0800 (PST), David Mark
    >
    > <> wrote:
    > >On Dec 18, 11:52=A0am, Matt Kruse <> wrote:
    > >> Quality is very hard to scale, and they are just a victim of that
    > >> rule.

    >
    > Scalability in development - the more code you need to write, the more
    > you need to employ weaker people. the less individuals feel they have
    > ownership "why should I work hard to be perfect, when _they_ produce
    > such crap?" etc.
    >


    Gotcha. That thought did occur to me, but then I thought about the
    amount of (front-end) code required to present a site such as MySpace
    (not much). So they probably start with ten tons of JS by Someone
    Else. I didn't get that far in the source.
    David Mark, Dec 18, 2009
    #5
  6. David Mark

    Matt Kruse Guest

    On Dec 18, 11:36 am, (Jim Ley) wrote:
    > On Fri, 18 Dec 2009 08:58:48 -0800 (PST), David Mark
    > <> wrote:
    > >On Dec 18, 11:52=A0am, Matt Kruse <> wrote:
    > >> Quality is very hard to scale, and they are just a victim of that
    > >> rule.

    > Scalability in development - the more code you need to write, the more
    > you need to employ weaker people. the less individuals feel they have
    > ownership "why should I work hard to be perfect, when _they_ produce
    > such crap?" etc.


    _Exactly_.

    All too often, I hear criticisms from perfectionists who work in
    isolation on their pet projects and can do everything the "right" way.

    Scaling a team to develop large, high-volume applications is a
    difficult task. You cannot hire a full team of experts who code
    everything ideally. You get a gradient of technical skill levels,
    people skills, communication skills, attitudes, approaches, and
    experience. The people who are experts may have to end up not writing
    code, but designing and reviewing because they are the ones most
    technically suited to do so. Then you have lower-quality code being
    written by a larger number of people (perhaps hundreds or more), and
    those who are the experts end up writing perhaps none at all. So in
    order to manage this, they try to create or select tools that can help
    the whole group operate more cohesively. This often ends up in layers
    of abstraction, generalized libraries, coding best practices, etc.
    These "beasts" arise not because they are the most ideal way to attack
    every problem, but because they are a natural way to scale a large
    development effort and not have it fall apart.

    Meanwhile, the solo guru sitting alone in his apartment picks apart
    little bits of code that are created from this process, and criticizes
    it for not being done how it "should be done". Clearly, he cannot
    grasp the bigger problem of scaling quality, which is not just a
    technical problem but one of business, people, coordination,
    abstraction, delegation, etc. Creating such a beast and making it
    produce an end result that actually works is an accomplishment in
    itself. If the "guru" cannot appreciate this and recognize that
    different sized problems generate different types of solutions, then
    that is why he's still a solo guru sitting alone in his apartment. ;)

    Matt Kruse
    Matt Kruse, Dec 18, 2009
    #6
  7. David Mark

    David Mark Guest

    On Dec 18, 1:34 pm, Matt Kruse <> wrote:
    > On Dec 18, 11:36 am, (Jim Ley) wrote:
    >
    > > On Fri, 18 Dec 2009 08:58:48 -0800 (PST), David Mark
    > > <> wrote:
    > > >On Dec 18, 11:52=A0am, Matt Kruse <> wrote:
    > > >> Quality is very hard to scale, and they are just a victim of that
    > > >> rule.

    > > Scalability in development - the more code you need to write, the more
    > > you need to employ weaker people. the less individuals feel they have
    > > ownership "why should I work hard to be perfect, when _they_ produce
    > > such crap?" etc.

    >
    > _Exactly_.
    >
    > All too often, I hear criticisms from perfectionists who work in
    > isolation on their pet projects and can do everything the "right" way.


    Do you?

    > Scaling a team to develop large, high-volume applications is a
    > difficult task.


    Is it? See my previous response. There's not a lot of JS to a site
    like MySpace (at least there shouldn't be). It certainly isn't an
    excuse to use jQuery. ;)

    [snip mindless blithering]
    David Mark, Dec 18, 2009
    #7
  8. Matt Kruse wrote:
    > On Dec 18, 9:37 am, David Mark <> wrote:
    >> I've seen the opinion expressed numerous times that large social
    >> networking sites are shining examples of Web development proficiency.

    >
    > Wow, who ever said that?
    >

    Appeal to popularity fallacy is is huge in America.

    It is present in TV commercials, sports supplements, javascript
    libraries. You name it. A good many job req's that ask for large public
    facing sites.

    I see a lot of people being fed bullshit, being told what they should do
    and acting on that.

    > Facebook is one of the biggest and most popular sites on the web. Its
    > code is horrendous, and even some of the concepts it uses are very
    > flawed.
    >


    Yelp.com is worse.

    > Quality is very hard to scale, and they are just a victim of that
    > rule. There are very few, if any, exceptions. IMO.
    >



    What do you mean "quality is very hard to scale"?
    --
    Garrett
    comp.lang.javascript FAQ: http://jibbering.com/faq/
    Garrett Smith, Dec 19, 2009
    #8
  9. David Mark

    David Mark Guest

    On Dec 19, 1:44 am, Garrett Smith <> wrote:

    [...]

    >
    > What do you mean "quality is very hard to scale"?


    He's on his high horse. The intimation is that he works on huge
    sites, managing mammoth development teams, etc. (and posters here are
    not part of this "Real World"). Gee, if you want a huge site done
    "right", call that Matt Kruse fellow because he really gets it. It's
    an excuse to counter-balance all of the well-documented incompetence
    (e.g. using jQuery).
    David Mark, Dec 19, 2009
    #9
  10. Jim Ley wrote:
    > On Fri, 18 Dec 2009 08:58:48 -0800 (PST), David Mark
    > <> wrote:
    >
    >> On Dec 18, 11:52=A0am, Matt Kruse <> wrote:
    >>> Quality is very hard to scale, and they are just a victim of that
    >>> rule.

    >
    > Scalability in development - the more code you need to write, the more
    > you need to employ weaker people. the less individuals feel they have
    > ownership "why should I work hard to be perfect, when _they_ produce
    > such crap?" etc.
    >

    That sentence is ambiguous. Who is "they"?
    --
    Garrett
    comp.lang.javascript FAQ: http://jibbering.com/faq/
    Garrett Smith, Dec 19, 2009
    #10
  11. David Mark

    David Mark Guest

    On Dec 19, 2:18 pm, Garrett Smith <> wrote:
    > Jim Ley wrote:
    > > On Fri, 18 Dec 2009 08:58:48 -0800 (PST), David Mark
    > > <> wrote:

    >
    > >> On Dec 18, 11:52=A0am, Matt Kruse <> wrote:
    > >>> Quality is very hard to scale, and they are just a victim of that
    > >>> rule.

    >
    > > Scalability in development - the more code you need to write, the more
    > > you need to employ weaker people. the less individuals feel they have
    > > ownership "why should I work hard to be perfect, when _they_ produce
    > > such crap?" etc.

    >
    > That sentence is ambiguous. Who is "they"?


    Code monkeys in adjacent cages (er cubes.)
    David Mark, Dec 19, 2009
    #11
  12. David Mark wrote:
    > On Dec 19, 2:18 pm, Garrett Smith <> wrote:
    >> Jim Ley wrote:
    >>> On Fri, 18 Dec 2009 08:58:48 -0800 (PST), David Mark
    >>> <> wrote:
    >>>> On Dec 18, 11:52=A0am, Matt Kruse <> wrote:
    >>>>> Quality is very hard to scale, and they are just a victim of that
    >>>>> rule.
    >>> Scalability in development - the more code you need to write, the more
    >>> you need to employ weaker people. the less individuals feel they have
    >>> ownership "why should I work hard to be perfect, when _they_ produce
    >>> such crap?" etc.

    >> That sentence is ambiguous. Who is "they"?

    >
    > Code monkeys in adjacent cages (er cubes.)


    So it sounds like Jim and Matt aren't enforcing code reviews. DId I get
    that right?

    This sounds like a *process* issue.
    --
    Garrett
    comp.lang.javascript FAQ: http://jibbering.com/faq/
    Garrett Smith, Dec 19, 2009
    #12
  13. David Mark

    David Mark Guest

    On Dec 19, 3:17 pm, Garrett Smith <> wrote:
    > David Mark wrote:
    > > On Dec 19, 2:18 pm, Garrett Smith <> wrote:
    > >> Jim Ley wrote:
    > >>> On Fri, 18 Dec 2009 08:58:48 -0800 (PST), David Mark
    > >>> <> wrote:
    > >>>> On Dec 18, 11:52=A0am, Matt Kruse <> wrote:
    > >>>>> Quality is very hard to scale, and they are just a victim of that
    > >>>>> rule.
    > >>> Scalability in development - the more code you need to write, the more
    > >>> you need to employ weaker people. the less individuals feel they have
    > >>> ownership "why should I work hard to be perfect, when _they_ produce
    > >>> such crap?" etc.
    > >> That sentence is ambiguous. Who is "they"?

    >
    > > Code monkeys in adjacent cages (er cubes.)

    >
    > So it sounds like Jim and Matt aren't enforcing code reviews. DId I get
    > that right?


    It sounded to me like Jim was speaking in general. And I don't know
    what the hell Matt is doing. :)

    >
    > This sounds like a *process* issue.


    Yes, but it can also be a _personnel_ issue. The results are limited
    to the proficiency of whomever is in charge of the reviews. ;)
    David Mark, Dec 19, 2009
    #13
  14. David Mark wrote:
    > On Dec 19, 3:17 pm, Garrett Smith <> wrote:
    >> David Mark wrote:
    >>> On Dec 19, 2:18 pm, Garrett Smith <> wrote:
    >>>> Jim Ley wrote:
    >>>>> On Fri, 18 Dec 2009 08:58:48 -0800 (PST), David Mark
    >>>>> <> wrote:
    >>>>>> On Dec 18, 11:52=A0am, Matt Kruse <> wrote:
    >>>>>>> Quality is very hard to scale, and they are just a victim of that
    >>>>>>> rule.
    >>>>> Scalability in development - the more code you need to write, the more
    >>>>> you need to employ weaker people. the less individuals feel they have
    >>>>> ownership "why should I work hard to be perfect, when _they_ produce
    >>>>> such crap?" etc.
    >>>> That sentence is ambiguous. Who is "they"?
    >>> Code monkeys in adjacent cages (er cubes.)

    >> So it sounds like Jim and Matt aren't enforcing code reviews. DId I get
    >> that right?

    >
    > It sounded to me like Jim was speaking in general. And I don't know
    > what the hell Matt is doing. :)
    >
    >> This sounds like a *process* issue.

    >
    > Yes, but it can also be a _personnel_ issue. The results are limited
    > to the proficiency of whomever is in charge of the reviews. ;)

    Well yeah.

    With Pair or reviews is the knowledge spreads. In both directions
    (reviewee <--> reviewer). If the knowledge is full of holes and
    misconceptions, obviously then it won't help.

    When you get a developer who has expertise, that developer can review
    others' code and those less experienced developers can learn from that
    review. The whole process is educational. The mid-level developers get
    sharper at spotting problems in their own code and in their peers' code.
    The team should continue to produce better quality software.

    The Number 1 excuse I hear is "we don't havec time". I have worked in a
    lot of companies and the teams who "don't have time" have, IME, spend
    *more* time developing worse quality software.

    Well I'm out of time. Someone pulling me.
    --
    Garrett
    comp.lang.javascript FAQ: http://jibbering.com/faq/
    Garrett Smith, Dec 19, 2009
    #14
  15. David Mark

    David Mark Guest

    On Dec 19, 5:45 pm, Garrett Smith <> wrote:
    > David Mark wrote:
    > > On Dec 19, 3:17 pm, Garrett Smith <> wrote:
    > >> David Mark wrote:
    > >>> On Dec 19, 2:18 pm, Garrett Smith <> wrote:
    > >>>> Jim Ley wrote:
    > >>>>> On Fri, 18 Dec 2009 08:58:48 -0800 (PST), David Mark
    > >>>>> <> wrote:
    > >>>>>> On Dec 18, 11:52=A0am, Matt Kruse <> wrote:
    > >>>>>>> Quality is very hard to scale, and they are just a victim of that
    > >>>>>>> rule.
    > >>>>> Scalability in development - the more code you need to write, the more
    > >>>>> you need to employ weaker people. the less individuals feel they have
    > >>>>> ownership "why should I work hard to be perfect, when _they_ produce
    > >>>>> such crap?" etc.
    > >>>> That sentence is ambiguous. Who is "they"?
    > >>> Code monkeys in adjacent cages (er cubes.)
    > >> So it sounds like Jim and Matt aren't enforcing code reviews. DId I get
    > >> that right?

    >
    > > It sounded to me like Jim was speaking in general.  And I don't know
    > > what the hell Matt is doing.  :)

    >
    > >> This sounds like a *process* issue.

    >
    > > Yes, but it can also be a _personnel_ issue.  The results are limited
    > > to the proficiency of whomever is in charge of the reviews.  ;)

    >
    > Well yeah.
    >
    > With Pair or reviews is the knowledge spreads.


    Yes. Pairing works well for that. Reviews are less productive IMO
    (some don't believe anything until they see it).

    > In both directions
    > (reviewee <--> reviewer). If the knowledge is full of holes and
    > misconceptions, obviously then it won't help.


    Yes.

    >
    > When you get a developer who has expertise, that developer can review
    > others' code and those less experienced developers can learn from that
    > review.


    Iff they are willing to learn. Talk to many jQuery users?

    > The whole process is educational. The mid-level developers get
    > sharper at spotting problems in their own code and in their peers' code.
    > The team should continue to produce better quality software.


    Absolutely.

    >
    > The Number 1 excuse I hear is "we don't havec time".


    Me too. :) Usually related to testing in "old browsers" (e.g. IE7).
    Ironic considering that most Web developers have no idea what older
    browsers they are trampling with each step. Add one bloated script,
    sack three browsers, add another, sack two more. But no time to go
    back and test whether the documents are now unusable in the "ancient"
    browsers that "nobody uses".

    > I have worked in a
    > lot of companies and the teams who "don't have time" have, IME, spend
    > *more* time developing worse quality software.


    You better believe it. This is especially true in Web development.
    David Mark, Dec 19, 2009
    #15
  16. In comp.lang.javascript message <2642f732-25d5-417d-970b-99848b40b5c0@j2
    4g2000yqa.googlegroups.com>, Fri, 18 Dec 2009 07:37:47, David Mark
    <> posted:

    >I've seen the opinion expressed numerous times that large social
    >networking sites are shining examples of Web development proficiency.


    If you believe that, then you might expect that major national
    laboratories would also have good code.

    Look at the source of <http://saturn.jpl.nasa.gov/index.cfm>.

    Lines 59 & 60 have (in comment) M/DD/YYY (sic) dates, year 209.

    Lines 412-1154 seem of little use.

    Consider Line 2428 in conjunction with Lines 2431-2435.

    View the page countdown (lower left) BETWEEN (in either order; your
    computer's locale) 2010-01-01 00:00:00 LCT and 2010-01-01 00:00:00 GMT.

    For last year's, see <http://www.merlyn.demon.co.uk/saturn.png>, bottom
    left, under DAYS.

    And look at the method of function countdown() (Line 2426 ff. ff.).

    --
    (c) John Stockton, nr London, UK. ?@merlyn.demon.co.uk Turnpike v6.05.
    Web <URL:http://www.merlyn.demon.co.uk/> - w. FAQish topics, links, acronyms
    PAS EXE etc : <URL:http://www.merlyn.demon.co.uk/programs/> - see 00index.htm
    Dates - miscdate.htm estrdate.htm js-dates.htm pas-time.htm critdate.htm etc.
    Dr J R Stockton, Dec 20, 2009
    #16
  17. David Mark

    David Mark Guest

    On Dec 21, 9:47 am, Hans-Georg Michna <hans-
    > wrote:
    > On Fri, 18 Dec 2009 10:34:42 -0800 (PST), Matt Kruse wrote:
    > >...
    > >Scaling a team to develop large, high-volume applications is a
    > >difficult task. You cannot hire a full team of experts who code
    > >everything ideally. You get a gradient of technical skill levels,
    > >people skills, communication skills, attitudes, approaches, and
    > >experience. ...

    >
    > I agree entirely with all you wrote. Particularly in big
    > companies it is difficult to attain high quality for a whole
    > range of reasons, many of which you mentioned.


    Shouldn't need to be that way for JS as most sites don't need much.

    >
    > I'm not surprised that jQuery is often used in such a setting.


    Me too. :)

    > The arguments for it are mainly that it makes the code shorter
    > and nicer, makes the coding easier, and makes the result
    > browser-independent.


    We know it doesn't do any of those things.

    >
    > As I have meanwhile learned, these expectations are only partly
    > fulfilled, because jQuery itself is not perfect either.


    That's putting it mildly. It's fair to say that cross-browser
    scripting _today_ (as opposed to 2006) is far simpler and much better
    documented than any of those silly libraries. But the incapable keep
    churning them out, blogging and twittering about how they are the
    perfect solution for every browser scripting context, selling books
    with horrible and outdated examples, etc.

    > Too bad,
    > because if it were, we would have a really good solution for
    > everything except performance-critical code.


    Context is everything in browser scripting, so general purpose
    solutions are inherently flawed. But a good collection of basic, re-
    usable, low-level functions that suit your favorite contexts is a
    must. ;)

    >
    > There is also a chicken-and-egg problem here. People prefer
    > libraries that are well known and widely used,


    Bandwagon.

    > because they want
    > the impression that the library is widely tested and
    > continuously maintained.


    The operative word is "impression". As we've seen, they are not
    tested properly at all. You can't test what you don't understand.

    As for maintenance, that's a minus as it requires another download,
    another round of testing, added unrelated complexities ("cool"
    suggestions from other users), etc. You don't have to maintain things
    that don't break down and things that are and tested properly don't
    break down, so _continuous_ maintenance is a pretty ominous indicator
    (especially for a Website).

    Despite all of the "maintenance" and contributions over the years,
    what has jQuery accomplished? They hand off queries to QSA when
    available. Unfortunately, this was a step backwards as their original
    query engine is incompatible with QSA (or anything else for that
    matter). They are going around in circles with attr/removeAttr (and
    have been for years). Those are basic building blocks that are ever-
    shifting and never quite straight (and one obvious reason for the
    query incompatibilities). The whole project would seem an aimless
    waste of time (and money for any business foolish enough to bet on
    it). It's certainly not going anywhere good, so why follow?
    David Mark, Dec 21, 2009
    #17
  18. Hans-Georg Michna wrote:
    > On Fri, 18 Dec 2009 10:34:42 -0800 (PST), Matt Kruse wrote:
    >
    >> ...
    >> Scaling a team to develop large, high-volume applications is a
    >> difficult task. You cannot hire a full team of experts who code
    >> everything ideally. You get a gradient of technical skill levels,
    >> people skills, communication skills, attitudes, approaches, and
    >> experience. ...

    >
    > I agree entirely with all you wrote. Particularly in big
    > companies it is difficult to attain high quality for a whole
    > range of reasons, many of which you mentioned.
    >


    Small teams are just as capable of shipping awful software.

    If aspects such as readability and flexibility are important on a small
    team, there are even more important on a large team. When code quality
    is compromised, it tends to deteriorate more in a larger team.


    > I'm not surprised that jQuery is often used in such a setting.
    > The arguments for it are mainly that it makes the code shorter
    > and nicer, makes the coding easier, and makes the result
    > browser-independent.
    >


    Huh. I don't really see it that way. Can you elaborate a little more?

    What I have heard from another is that it has a query selector and a
    large number of quality plugins.

    I did argue that query selector is not necessary and can tend to
    encourage a less efficient design. Also I argue that the quality of
    plugins is poor.

    > As I have meanwhile learned, these expectations are only partly
    > fulfilled, because jQuery itself is not perfect either. Too bad,
    > because if it were, we would have a really good solution for
    > everything except performance-critical code.
    >
    > There is also a chicken-and-egg problem here. People prefer
    > libraries that are well known and widely used, because they want
    > the impression that the library is widely tested and
    > continuously maintained.


    I can agree that your assessment is correct though. Appeal to popularity
    is probably the most common fallacy. It is huge in America.


    When assessing a code base, it is the responsibility of the developer to
    look closely to how it solves the problem.

    I am going to be including that bit in my "guidelines for code review"
    document (coming soon).

    This is fair advice in traditional languages/paradigm but it seems even
    more crucial in javascript for several reasons. There are multiple
    deployement environments (browsers), each with custom configuration,
    next, the fact that javascript is a dynamic language, and finally most
    important of all, the fact that javascript libraries feature code that
    ranges from useless to buggy.
    --
    Garrett
    comp.lang.javascript FAQ: http://jibbering.com/faq/
    Garrett Smith, Dec 21, 2009
    #18
  19. David Mark

    David Mark Guest

    On Dec 23, 9:09 am, Hans-Georg Michna <hans-
    > wrote:
    > On Mon, 21 Dec 2009 13:04:46 -0800, Garrett Smith wrote:
    > >Hans-Georg Michna wrote:
    > >> I'm not surprised that jQuery is often used in such a setting.
    > >> The arguments for it are mainly that it makes the code shorter
    > >> and nicer, makes the coding easier, and makes the result
    > >> browser-independent.

    > >Huh. I don't really see it that way. Can you elaborate a little more?

    >
    > Many bits of jQuery-using JavaScript code are much shorter than
    > they would be without jQuery.


    But they aren't. They start out with 60K of script (rather than 0K).
    All of that code has to be swapped out and re-tested periodically, so
    it's as good as yours. ;)

    > They are also good to read and
    > easy to understand, much more so than pure JavaScript.


    No, they typically read like gibberish.

    >
    > One factor in this is the selector syntax that web developers
    > already know very well from writing CSS.


    But they have no idea what happens when they query by one (nothing
    good cross-browser).

    > Another is the
    > replacement of loops with the elegant functional syntax.


    You don't need jQuery to replace loops with forEach. ;)

    > Here's
    > a very simple example---change the color of all elements with a
    > certain class in a document to green:
    >
    > $(".to-be-colored").css("color", "green");


    It's too simple an example to demonstrate anything. The idea is you
    could write a function to find by class name and another to apply the
    color green to a collection. That would be a lot easier to understand
    and maintain than the magical jQuery spell, which relies on ten tons
    of unneeded complexity that even its authors don't understand. ;)

    There's nothing wrong with (good) functional abstractions.

    >
    > In pure JavaScript the same needs more code and is more
    > difficult to read and understand. I think this becomes even more
    > obvious with more complex programs, where one question is, for
    > example, how much of the functionality you can oversee on one
    > screenful of code.
    >


    There's no such thing as "pure JavaScript" and jQuery is completely
    inappropriate for complex programs (it's a very buggy complex program
    to start with). ;)
    David Mark, Dec 23, 2009
    #19
  20. David Mark

    David Mark Guest

    On Dec 23, 9:09 am, Hans-Georg Michna <hans-
    > wrote:
    > On Mon, 21 Dec 2009 10:09:11 -0800 (PST), David Mark wrote:
    > >On Dec 21, 9:47 am, Hans-Georg Michna <hans-
    > >> wrote:
    > >> The arguments for it are mainly that it makes the code shorter
    > >> and nicer, makes the coding easier, and makes the result
    > >> browser-independent.

    > >We know it doesn't do any of those things.

    >
    > I'm picking out this line, because it looks like the only one in
    > your message that may need qualification.


    Okay.

    >
    > jQuery does one thing very nicely. It offers an elegant
    > functional, selector-based notation, which can shorten
    > JavaScript code tremendously and make it much easier to read.


    It doesn't work well at all. It's incompatible with QSA and XPath and
    uses broken MSHTML attributes for certain types of selectors. And
    they are still twiddling with it three years later. That's
    worthless. :)

    > People generally tend to like that notation, and I am no
    > exception.


    Querying by CSS selector? There are better ways to do that than
    jQuery. Name one browser that jQuery "supports" that does _not_ have
    QSA. IE < 8 doesn't count as they've never come close to getting
    those right. ;)

    >
    > Whether jQuery doesn't fulfill its promises is another question.


    It definitely doesn't. That's been proven repeatedly.

    > The selector notation may be inefficient, but in most cases it
    > is fast enough, such that this does not matter.


    That's an oversimplification. The bigger problem is that the queries
    don't work as expected.

    > jQuery may
    > contain errors and misconceptions, but this only means that
    > people would wish for an improved and corrected jQuery.


    Why would they still be wishing (after three years) for John Resig and
    co. to get a clue? Seems irrational when there are much better
    alternatives available and cross-browser scripting has never been
    simpler.

    > Basically they want to keep using it. If most of them do not
    > understand the problems, they will simply keep using it anyway,
    > no matter how good or bad it is.


    That's called insanity.

    >
    > One other thought on the sidelines---would it be technically
    > possible to augment or repair parts of jQuery by overloading
    > some of its functions/methods, i.e. by loading an additional
    > library after it? I guess it would be. That would also be a
    > funny measure.
    >


    I mentioned that there are better alternatives. Some even offer CSS
    selector queries, $ identifiers and OO wrappers. :)
    David Mark, Dec 23, 2009
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. phaedrus
    Replies:
    9
    Views:
    388
    Default User
    Sep 20, 2006
  2. avh

    Social Networking Framework?

    avh, Jun 14, 2008, in forum: ASP .Net
    Replies:
    3
    Views:
    463
    Peter Bromberg [C# MVP]
    Jun 18, 2008
  3. rote
    Replies:
    0
    Views:
    543
  4. Shaguf
    Replies:
    0
    Views:
    317
    Shaguf
    Dec 24, 2008
  5. cocreators.com

    Cool ROR Social Networking Project

    cocreators.com, May 7, 2006, in forum: Ruby
    Replies:
    0
    Views:
    82
    cocreators.com
    May 7, 2006
Loading...

Share This Page