Promote JS
promotejs.com
promotejs.com
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.
it would also pay to look less like a communist movement.
we are definitely looking for ways to improve seo on the mdn/mdc website.
not much has been done in that area for a while, but that is going to change very soon.
- jay, mdn product manager
If there is going to be an effort to improve the actual docs, not just their Google ranking, I would be happy to provide some free consulting on SEO, site structure, usability, promotion, etc. You can find contact information in my profile.
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.
"Service Unavailable
The service is temporarily unavailable. Please try again later."
Every time I have to use it I am thinking of making a mirror of it.
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.
If I had to chose one single thing at which Google results suck, it would have to be Javascript documentation.
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!
I wonder if they'll improve this.
just trying to understand this a bit better, because we are planning on doing an official mozilla mdn affiliate campaign to promote other parts of our documentation.
thanks! - jay, mdn product manager
I'm not saying that I personally am offended by this widget, I don't give a damn. But google might.
You can refresh if you want to promote a different part of the guide (Arrays, RegExp, etc).
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.
Thanks. - Jay, MDN product manager
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
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.
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.
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.
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...
The advantage of this approach is that when you write a function in Javascript, it is guaranteed that no other program other than the very function you are writing will modify your data in any way.
I've used GWT on a big project for about half a year. It's not over-hyped. It definitely has it's space. If you're working on a project with two people, you're just not in the market for it. GWT is all about stability, optimization and structured development. I don't want to get into too much detail here, but some optimizations that GWT gives you are impossible to achieve by writing JS code manually.
<meta name="viewport" content="width=device-width; initial-scale=1.0; maximum-scale=1.0;">
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).