

Promote JS - evilhackerdude
http://promotejs.com/

======
bobds
This site generates a link to a random page of the Mozilla Javascript
reference, with various keywords added in title and alt attributes. It would
be better if they used text instead of an image as the link anchor.

Here's how this should be done instead:

* Register a new domain, say javascriptdocs.com or javascriptreference.org

* The new domain should be used for hosting the JS reference as well as the link generator. Using an unrelated domain means you are wasting a lot of links from people that want to support the cause.

* The documentation should get a SEO treatment by someone who knows what he's doing. You need good titles, sensible site structure, a small excerpt to be used on top of each page and in the meta descriptions.

* Contact people and websites that link to bad docs, make them aware of the better docs you are offering and get them to switch.

* A reward program for people that put up links, refer visitors from their website, etc. Give them a Mozilla t-shirt or a hat or something.

~~~
keyle
Good stuff...

it would also pay to look less like a communist movement.

~~~
pjscott
I don't think many people worry about robot dinosaur communists, now that the
Cold War is over.

------
nene
I don't really buy all this big campaign to promote MDC.

First of all, I do it anyway. I constantly promote the MDC resources when ever
I write a blog or forum post about some JavaScript thingie.

Secondly, the MDC site itself is not a perfect guide to JavaScript. Just look
at the main page - <https://developer.mozilla.org/en/JavaScript> \- it's
overwhelming. Even though I use it frequently, it still makes me feel lost.
Plus it has the same academic feel as W3C pages, and you know what... HTML
spec is not the first result in google for "html" either.

Compare all this to the w3schools page on JavaScript:
<http://www.w3schools.com/js/default.asp> It might not be teaching the best
practices, but it sure as hell is a lot clearer than the MDC page.

Therefore I would suggest that MDC guys follow the first rule of SEO: just
make a better site.

~~~
nowarninglabel
Not to mention they don't seem to be scaling well:

"Service Unavailable

The service is temporarily unavailable. Please try again later."

~~~
emilis_info
I use MDC reference rather often and their loooong response times and
occasional "Service Unavailable" messages annoy me very much.

Every time I have to use it I am thinking of making a mirror of it.

------
lars
This is a bad idea.

1) It's essentially spam, which Google works to prevent. It seems likely this
will actually hurt Mozilla's rank in searches.

2) It's unnecessary. Google's results are usually fine. If you really want a
page on Mozilla Dev Center you just add the letters "mdc" to your search, and
it's the top result every time.

~~~
daleharvey
the point is you need to add mdc, people searching for javascript that do not
know about mdc get sent to barely related sites at best, but more often
misleading and wrong documentation

~~~
DuncanIdaho
Oh my god... This is so awesome!

Call me stupid - but I am one of those persons who was unaware of MDC - and to
be honest Mozilla sites hierarchy can be hard/impossible to traverse for the
un-initiated.

I was wishing so much to find something like that JavaScript Guide. I love JS
- but the little intricacies that are common knowledge to greybeards were so
hard to find about - now I got it all here.

!!! Yay!

~~~
DTrejo
_Mozilla sites hierarchy can be hard/impossible to traverse for the un-
initiated_

I wonder if they'll improve this.

~~~
carussell
Well, it's not for a lack of trying.

------
walkon
Googling for 'javascript' brings up some sites about javascript, such as
Wikipedia and Crockford's, along with some not so good tutorial-ish sites. The
only really bad thing I see is the java.com reference at number three.
Searching for 'javascript documentation' or 'javascript docs' pulls up the MDC
doc site. Not sure why this is that big of a deal. I don't see a need for
enlisting "the community" to drive SEO here.

------
MisterWebz
Why do we only get to promote a certain part of the JS documentation instead
of the general JS guide (<https://developer.mozilla.org/en/JavaScript/Guide>)
?

~~~
liamk
I find that w3schools also offers great documentation for JavaScript:
<http://www.w3schools.com/js/default.asp> .

~~~
daleharvey
the w3c documentation is terrible, I mean the first function you see on the
home page is document.write

~~~
jacobolus
I don't think w3schools has any affiliation with the W3C. But I agree with
you, their documentation is terrible: bad examples, idiosyncratic code
conventions, confusing layout, (no syntax highlighting,) lots of distracting
ads, and very little of the "what are the corner cases", "how does this work
in every browser", &c. details that are essential in this type of resource.

------
gregable
It would go much further for the mozilla development center to do a little
basic, white-hat, on-page SEO. For example, this URL:
[https://developer.mozilla.org/en/JavaScript/Reference/Global...](https://developer.mozilla.org/en/JavaScript/Reference/Global_Objects/Array)
has a title of "Array - MDC". Even when it does come up in search results,
most users wouldn't have context from the title what it's about. "MDC" adds
nothing to the title. Words like "JavaScript" or "documentation" might help.
Similarly, "documentation" isn't even on the page, and "Javascript" is first
found halfway down the page and mostly in extra small text.

That said, the search results seem fine for this. [javascript array] turns up
this page, albeit at position 9. It also shows w3cschools.com's page on the
javascript array at the top, as well as several other great references. The
only less than ideal results that I see are the two from javascript-array.com
which tends to smell a little over-seo'ed from the fact that the hyphenated
domain matches the query.

~~~
jaybhai
We are going to be doing some basic SEO very soon, but some of the current
issues are due to the wiki platform we are using. We'll be investigating way
to improve the overall markup for all docs.

Thanks. \- Jay, MDN product manager

------
alanh
It’s a great idea to have a comprehensive and user-friendly standard place to
look for JavaScript information. Just two problems:

1\. That site will naturally get links if and when it exists (natural SEO)

2\. It isn’t necessarily the best idea to have it so closely tied with one
browser vendor

------
jhuckestein
Keeping this on the frontpage will help as well :)

This is a great idea. One of the reasons why JavaScript is frequently
misunderstood is because if you search for anything JS related you will find
posts explaining how to do some DHTML thing in IE5/6 and Netscape.

It's great that Mozilla considers themselves to be the patron saints of JS,
but much of the recent growth in the JS community is due to projects like V8
and node. Why doesn't Joyent or Google get to host the docs on their servers?

Perhaps it's a better idea to establish a Javascript Foundation that runs
javascript.org or something. This approach will probably not last and then
it'll be a wasted SEO effort.

~~~
srwh
I am one who doesn't really understand javascript hype (and have used it in
advanced ways), there are few types, objects are automatically converted to
strings, few functions support even for the web (urlparse). I am in favor of a
VM to the web, supporting more programming languages.

~~~
jhuckestein
I'd be interested to know by what standards you asses programing languages.

JavaScript has an admittedly clumsy and unnecessarily Java-like syntax and few
built-in functions, I agree. But underneath there is a very elegant functional
programming language. Who needs more built-in functions? Most scripting
languages' built-in functions are just libraries written in that very language
anyway. There's tons of such libraries for JavaScript.

A lot of the recent hype is due to node.js, too. Node.js is (somewhat
simplified) a set of evented IO bindings for the V8 JavaScript engine. Those
bindings enable us to build webservers using JavaScript. JavaScript was
designed to be run in an event loop without any concurrency or blocking, which
makes it incredibly easy to build software the scales reasonably well.

That said, I do agree that you should be able to use more languages in the
browser. IIRC somebody has already ported Mono to Firefox which allows you to
run tons of scripting languages in the browser. The next thing we need is
standardization.

~~~
mcharkin
Having JavaScript on the server side makes me a bit weary, because of the
difficulties of developing with it on the user side well mainly the no
compilation/type checking and lack of concurrency. With the push to multi-
processor systems concurrency is becoming much more important to take
advantage of which makes me curious how does a non concurrent loop scale well
(I don't know much about this node.js library).

On the user side however I have learned to like it. The lack of type checking
does bug me since I tend to make cludgy spelling errors which compilers pick
up, but its tolerable. I do wish js had a built in type checker for
development.

Another driver of hype, more negative hype is GWT. But it is a bit
disappointment and is a wrong approach to the whole browser independence
issues. My brother and I have been working on a project for over 4 months,
which initially started with using GWT and after two month of struggling with
it, we threw it out, and switched to JQuerry. Our productivity instantly shot
up.

More language support would certainly interesting, but I agree JS
standardization across browsers is a more important issue to have resolved.

~~~
jrockway
Concurrency is not much of an issue, you write concurrent JS apps like you
write them in other languages.

There are three types of applications, and two are easy in JavaScript.

The first is something that is well within the capabilities of one modern CPU
core. This class of applications includes every program that's currently
running on your machine. Servers that only do IO (message queues? memcache?
SMTP?) can also be included, in many cases.

This is easy to handle because there is no concurrency. For IO, you use an
event loop, of course.

The second class of application is something like Facebook. One machine will
never be enough to handle it, so you design for it to be as distributed as
possible. Each app is "shared nothing" and passes messages to communicate with
other components.

Obviously, JavaScript will do fine here. Each tiny component runs on one CPU
core, and then you run a million copies of the app on 250,000 4-core servers.
Easy. Need to double capacity? Just buy more servers. Wonderful.

The third case is the Enterprise Application. This is something like your
company's HR portal or your online bank. It's an application that's the swiss-
army-knife of applications. It slices, dices, and reads email too. Just
compiling it is a week-long process involving 10 engineers and 4 consultants.
For maximum SPEEEEED, everything happens in its own threads, which share 100%
of everything with the other threads. (How could you read email and RSS feeds
and check your paycheck if there weren't threads!?)

This type of app can only ever run on a single machine; if it's too slow, IBM
and Oracle would be happy to help you out with a marginally-faster box for a
few million more dollars. Since everything is shared, once you hit the most
expensive hardware, that's the best you can ever do. If you wonder why it
takes 120 seconds to load your bank account balance... this kind of app is
why.

And no, you can't write one of these in JavaScript. Shared-state threads are
not implemented. What a loss...

------
joevandyk
Why can't I zoom in on that site on an iPad?

~~~
gojomo
Probably this in the <head>:

<meta name="viewport" content="width=device-width; initial-scale=1.0; maximum-
scale=1.0;">

~~~
bigfudge
Perhaps I'm asking the wrong person, but what is that trying to achieve?

~~~
gojomo
They must think their sizing/font choices are good enough for everyone, so
they've essentially stopped zooming.

Used properly, the META viewport should help pages adapt to smaller screens.
For example, I think an iPhone-specific viewport setting would make the HN
front-page more legible on iPhones by wrapping submission titles.

Unfortunately, lots of sites seem to pick settings that either don't work well
on all mobile devices (like assuming iOS dimensions even for non-iOS devices)
or prevent native zooming (Google mobile sites and the default WordPress
mobile theme are offenders here).

