Big Social Networking Sites--Good Examples?

David Mark · Dec 18, 2009

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.

Matt Kruse · Dec 18, 2009

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

David Mark · Dec 18, 2009

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.

Jim Ley · Dec 18, 2009

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.

David Mark · Dec 18, 2009

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.

Matt Kruse · Dec 18, 2009

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

David Mark · Dec 18, 2009

_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]

Garrett Smith · Dec 19, 2009

Matt said:
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"?

David Mark · Dec 19, 2009

[...]

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).

Garrett Smith · Dec 19, 2009

Jim said:
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"?

David Mark · Dec 19, 2009

That sentence is ambiguous. Who is "they"?

Code monkeys in adjacent cages (er cubes.)

Garrett Smith · Dec 19, 2009

David said:
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.

David Mark · Dec 19, 2009

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.

Garrett Smith · Dec 19, 2009

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

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.

David Mark · Dec 19, 2009

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.

Dr J R Stockton · Dec 20, 2009

In comp.lang.javascript message <2642f732-25d5-417d-970b-99848b40b5c0@j2
4g2000yqa.googlegroups.com>, Fri, 18 Dec 2009 07:37:47, David Mark

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.).

David Mark · Dec 21, 2009

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?

Garrett Smith · Dec 21, 2009

Hans-Georg Michna said:
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.

David Mark · Dec 23, 2009

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

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.

HTML Aligning social media icons	2	Dec 6, 2020
Quick implementation of social networking	9	Sep 15, 2006
What should I do Before I give up programming?	6	Jan 14, 2023
My Library Examples!	11	Mar 17, 2010
Good Sites - who's got some examples?	254	Oct 4, 2003
Big picture question - Web sites vs Web Applications	7	Jun 24, 2008
Working on mobile css menu with plenty of frustration!	2	Dec 29, 2022
Best JavaScript Books and Sites	1	Sep 8, 2006

Big Social Networking Sites--Good Examples?

David Mark

Matt Kruse

David Mark

Jim Ley

David Mark

Matt Kruse

David Mark

Garrett Smith

David Mark

Garrett Smith

David Mark

Garrett Smith

David Mark

Garrett Smith

David Mark

Dr J R Stockton

David Mark

Garrett Smith

David Mark

David Mark

Ask a Question

Similar Threads

Members online

Forum statistics

Latest Threads