The Mozilla Developer Network has a New Face | Hacker News Reader

The Mozilla Developer Network has a New Face

hacks.mozilla.org

250 pointsrnyman90 comments

Is it going to get faster? I find that MDN pages load much, much slower than e.g. w3schools, which probably explains some or all of their failure to grab the top spot on most Google searches.

For example, a page like this takes nearly 10 seconds to render on the server before the browser receives a single byte: https://developer.mozilla.org/en-US/docs/Web/Reference/Event...

MDN's content is already good. I'd prefer to see effort put into speeding it up rather than adding more features.

Wow, you weren't kidding - 10164ms for me. From what I can tell, there's not much dynamic content in the page. Static caching would go a long way there. I'm sure they'd appreciate a pull request from someone with some Django chops! https://github.com/mozilla/kuma

MDN dev here. Page-load time is one of our immediate next goals. Tons of traffic to our document view and lots of potential back-end processing on each doc kinda sucks. But, we're using New Relic now and hoping to tackle things iteratively as we go.

https://developer.mozilla.org/en-US/docs/Project:MDN/Plans_a...

Please add caching of full rendered wiki pages for logged-out users. I'd much rather get a cached page from yesterday in 100ms than wait 10 seconds for today's edits to be rendered.

Hmm ... it should work that way now. In fact, only admin users can force a page to refresh its cached content.

Though we are getting a spike in traffic with the redesign launch, New Relic still reports app server response times of <600ms. But WebPagetest confirms really slow load times. [1]

If anyone finds some gross offenders of page performance, please file a bug: http://bugzilla.mozilla.org/form.mdn or better yet - send a pull request: https://github.com/mozilla/kuma !

[1] http://www.webpagetest.org/result/131209_Z0_1Q09/

I'm getting response times of 4-5 seconds, which I think is a lot.

This is mainly static content you got there, it's the easiest scenario for aggressive content caching. Just throw in a good Memcached server and serve the whole page from cache. Add some good expiration headers + etags and the website will fly. Unless you have problems with request queueing, which would be a completely different topic.

please make it readable asap, cause it is not.

- darken the text, low contrast destroys eyesight.

- make the text bigger for god sake

- use a serif font for the main text,really,you can keep the headlines sans.

- your website has a big whitespace/negative space balance problem.

I mean,i dont understand designers today. Do they care about readability? or that a site look fancy on their shiny new mac ?

As for performance problems i would suggest moving to a static site generator, a doc is the perfect use case.

A static site generator for a wiki?

A cache

That sounds like a good idea, actually. Why not? Generate and store each page each time it's edited, then serve from the static copies. There will be a lot more reads than there are writes anyway.

That's a static page cache, not really the same thing. And I'm pretty sure they're doing this already, or are about to.

We can't generate the whole thing statically, because there are parts of the interface that change with user state.

We do render the HTML for article content, which includes many scripting templates.

We're seeing a lot of interest in the static/caching side of the site. I wonder if we should do a public article about it and invite people to help us improve it.

Can you not serve a static page and then have Javascript fetch the additional, user state-dependent content? At the very least, that will reduce latency for some content.

The public article will surely be interesting even if it is not all that useful...

> use a serif font for the main text,really,you can keep the headlines sans.

All the web usability studies and web design books I've read that address typography have stated that most people prefer sans-serif typefaces on screens. And the typefaces used by all the top sites reflect this.

I don't have a strong preference either way, but it's important to note that those recommendations came before retina displays. Serif fonts can't be rendered accurately on low-DPI displays. As more people get high-DPI displays, I bet serif fonts will be used more in body text.

This might be news to you, but not everybody has Retina (or equivalent) displays

Umm... That's what I said. "As more people get high-DPI displays, I bet serif fonts will be used more in body text." I was making a prediction, not stating that designers should use one or the other.

If I had to suggest a change in the typography, I'd suggest the opposite. The headings(large text) can have serifs. But the bulk of the body should definitely be sans. Serifs add too much clutter when the font is small.

Add this to your userContent.css: <http://db48x.net/MDN-fix.css>. It fixes the whitespace problems, but I haven't touched fonts. Font size is best corrected by zooming in; Firefox will even remember your zoom level across the whole domain, so you only have to do that once.

Isn't MDN mostly stactic content? I don't understand why it's so slow... Everything should be served off of static pages on a cdn.

MDN is a wiki! There's a django backend which also uses a node.js web service for wiki templating features.

https://developer.mozilla.org/en-US/docs/Project:MDN/Kuma

Since most pages would be read far more often than they are written, you could probably get good results by 'compiling' the page to a static cache after each edit.

I would go that way too. Static content export, put a CDN in front of it, and response times will get < 100ms, even < 80ms.

I have done some experiments with static exports using dynamic frameworks like Rails, and man, it really makes a huge difference. Of course, if your content is mainly static.

I think you underestimate just how fast and furious the edits can fly on MDN.

Rendering page content after edits is exactly what we do. Most page views are served up from a pre-built cache, either from a straight caching HTTP proxy or from a single DB column.

So? Render statically after each edit.

Yes, that's exactly what we do:

https://github.com/mozilla/kuma/blob/master/apps/wiki/models...

pardon me, but is that function writing to the database for each page view?

Seems to me it's actually writing to the database twice for each page view; once to update the render_started_at property on #845, and once again on #881.

That render() method is called only on page edits or forced refreshes, not on every page view.

Yeah - looks like it's emulating a lock so only one page can be rendered at a time (plus the overhead for database IO to maintain the lock). Is this really the best way to go about this?

Unless I'm missing something important, it's locking so the same page can only be rendering once at a time; if another request that would cause a rebuild comes in while a previous rebuild is still in progress, it gets bounced.

Yes, you are correct. We're trying to limit the system to one rendering per page at a time.

No, only views which hit a stale copy of the rendered page and have to call that render() function. Normal views would (I imagine, I haven't traced it back) use the get_rendered() instead, which checks that the cached version is current and schedules a re-rendering (which obviously requires DB writes anyway) if necessary.

The sad part is that I don't mind waiting that long. For most things, I will skip Google entirely and go directly to MDN and not waste my time sorting through the documentation light results from W3schools. Someday, I might start using Web Platform Docs too.

http://docs.webplatform.org/

Agreed — if anything, this just emphasizes how secondary are speed and design if your content is good.

That said, I like both the new and old designs, and as someone who's spent a lot of time on MDN recently, I've personally never noticed it to be slow.

The new site seems speedy enough to me, but I do remember the old one being so slow it was unusable.

It's interesting that they decided to write their own wiki. If I remember correctly, they used to use MediaWiki which has fairly straightforward built-in support for scaling used by Wikipedia and its sister sites. (Replicate your database so it sends all read queries to replicas, set up memcached to cache I18n strings and parser results, use Squid so that logged out users don't even hit the app servers, enable APC, etc.) I'd be interested in knowing why they went with the option of a rewrite.

The site started on MediaWiki. But, probably around 7 years ago, it switched over to a platform called DekiWiki, later renamed to MindTouch.

This is way over-simplifying it, but: MindTouch looks like a fork of MediaWiki (PHP) that's had all the database calls replaced by requests to a local web service running on .NET, with a Lua-based document scripting system (DekiScript) added on.

However, MDN ran all this on Linux servers - rather than Windows servers - so our installation was rather unusual. Eventually, the company behind the software decided to drop support for our kind of setup. So, we decided to move over to software we could support in-house, and launched it around June 2012.

What we have now started from the Django-based wiki that runs support.mozilla.org, called kitsune. From there, we worked on getting some practical feature parity with MindTouch. I added a node.js-based document scripting service (KumaScript) that mostly replaced DekiScript for our needs. We worked up some migration scripts, and moved the whole thing over.

It's admittedly kind of an evolutionary mess, at this point. But, at least it's our mess.

MDN focus is on having the best and most complete content. w3schools rank higher on google search but their content is not the best one, and sometimes it is too shallow.

Those working with the web should use better documentation than w3schools, thats a quick tutorial site.

Also MDN is from Mozilla so it is all open source and we can all contribute and help speed things up ;-)

Thanks for the reminder. I decided to eliminate some of the mental noise and just add w3schools to Chrome's Personal Blocklist extension.

Oddly enough it's reasonably fast for me, always under 2sec.

~2s is not reasonably fast. <100ms is. :)

Sure, but not >10s

We are going to work on performance issues until EOY. If anyone would like to help, we're using a new label in GitHub for it:

https://github.com/mozilla/kuma/issues?labels=performance&pa...

Cool! All the issues I see in the list so far are client issues, but the major issue I see is server-side. Server-side HTML rendering ought to take 200ms or less (a lot less for cached pages), but according to Chrome's dev tools, most of the documentation wiki pages take 500-10000ms to render. Client-side optimizations aren't going to help much until that's fixed.

I'd recommend you open up your console when visiting the site:

               _.-~-.
             7''  Q..\
          _7         (_
        _7  _/    _q.  /
      _7 . ___  /VVvv-'_                                            .
     7/ / /~- \_\\      '-._     .-'                      /       //
    ./ ( /-~-/||'=.__  '::. '-~'' {             ___   /  //     ./{
   V   V-~-~| ||   __''_   ':::.   ''~-~.___.-'' _/  // / {_   /  {  /
    VV/-~-~-|/ \ .'__'. '.    '::                     _ _ _        ''.
    / /~~~~||VVV/ /  \ )  \        _ __ ___   ___ ___(_) | | __ _   .::'
   / (~-~-~\\.-' /    \'   \::::. | '_ ` _ \ / _ \_  / | | |/ _` | :::'
  /..\    /..\__/      '     '::: | | | | | | (_) / /| | | | (_| | ::'
  vVVv    vVVv                 ': |_| |_| |_|\___/___|_|_|_|\__,_| ''

  Hi there, nice to meet you!

  Interested in having a direct impact on hundreds of millions of users? Join
  Mozilla, and become part of a global community that’s helping to build a
  brighter future for the Web.

  Visit https://careers.mozilla.org to learn about our current job openings.
  Visit https://www.mozilla.org/contribute for more ways to get involved and
  help support Mozilla.

The new design is sexy-ish, but I think readability suffers because:

1. the contrast is too low, for example that blue colour of links on white background is too light, hurts my eyes

2. the font-size is too small, especially in combination with the poor contrast. 14px is too small on today's desktops, should be 16px ... better yet, it should be left at 100% as that scales better. On the other hand I like the usage of Open Sans, it's a readable font and ensures availability on all OSes

3. some pages are too slow to load. MDN is a great reference and decreasing latency should be a priority.

I don't know what's sexy(-ish) about the blue corporate look. I guess that's why developers are not graphic designers.

I hate this bandwagon of everyone jumping onto the MS Metro UI look for everything. The old site wasn't perfect, but please come up with something original.

Exactly

It's harder to read. I want to see how many HN readers think the color scheme and the font makes reader uncomfortable? https://bugzilla.mozilla.org/show_bug.cgi?id=948108

Yeah its harder to read ^_^ and I think worse looking the old version.

I have to admit I liked the previous color scheme much more too. White / light blue background + gray text (~#4D). Why is it so popular to make low-contrast sites these days? It's inexplicable to me, other than just the designers' craving for change (yes it probably has all the contrast coefficients within the norms, but it doesn't mean this couldn't be made better).

An oldie but a goodie: http://contrastrebellion.com/

HN makes the cut.

This look is very uninspired, compared to the old one!

I think the new color scheme is nice, but the contrast is way too low for the tiny, low-weight font they're using. A bold or larger text or increasing the contrast a little would make it work. To meet http://accessibility.psu.edu/contrasthtml they'll probably have to do all three.

For those interested, the source of MDN is here: https://github.com/mozilla/kuma

I never really thought about it before, but this new layout immediately made me realize that there's just a single letter difference between MDN and MSDN... the layout is rather similar to what the latter was using a while back. Not that it's a bad thing or anything, just thought it was amusing. MDN is a fantastic resource, so it's great to see some love and care being poured into it.

wow, seems like it's true that there are always two people with the same idea, somewhere on earth. Or, how they would say it in Germany: "Two idiots, same idea."

To me, the MDN to MSDN portal similarity is also a striking symbol of the Mozilla & Microsoft partnership. The design, even looks like it's a little Windows 8 inspired, from my angle.

(There's no assessment involved)

The new MDN theme is horrible. It looks very Microsoft-ish (and a little google-ish)

They changed everything, even the friggin logo is blue now. What was wrong with the old look?

How can I get it back?

I've posted about it here: http://lebgeeks.com/forums/viewtopic.php?id=14889

I'm not a huge fan of the new design. Nothing is really strongly defined so my eyes have no idea where to look. Everything just blurs into each other.

Put "Shared knowledge for the open web" on just one line. It will look less clumsy, plus there will be more content "above the fold." (More content above the fold would be great on other pages, too.)

Generally speaking, dealing with developer docs, "less is more" is almost always true. I love elaborate design, but here, visual clarity and speed are key. Finding things quickly is more important than beautiful fonts and graphics. Therefore, take an "un-design" approach. This iteration of MDN certainly is a step into the right direction.

I love Open Sans, but, at least on Windows, Arial is more legible (and doesn't have to be downloaded first.)

Menu fade effects are cool as long as I perceive them subliminally; 400ms (?) feels extremely sluggish.

As others have noted, page load times still need to improve considerably. In order to find my way around tech docs, I have to browse a lot; therefore, pages can't load fast enough. Grab a copy of "High Performance Web Sites" and heed the rules outlined there. 9 CSS files are not okay! >10 JS files are not okay! (Why would you even need that much code for simple docs pages?)

Regarding the amount of files (CSS +JS) loaded. We will minimize this when we will remove the old theme, which is still there, behind the scenes.

Wow, it's very bright. Would be great if there was a toggle for a dark theme instead.

https://developer.mozilla.org/en-US/docs/Project:Feedback

Pretty useful, but http://sourcegraph.com provides examples & automatic docs for a much larger set of libraries and languages.

Does not degrade.

Ooo, interesting. Now that we're on ES and have a real search index, we should try including code snippets as context when performing a search.

interesting!

though it doesn't include JavaScript (browser related API, only node.js) as does MDN; and no PHP or MySQL

Here is my analysis of the page.

My look at loading times found these biggest offenders:

     GET /             developer.mozilla.org  2153ms (767ms connecting, 499ms wait) 23.42KB
     GET include.js    login.persona.org      2151ms (1921ms connecting, 230ms wait) 16.87KB

Also there is a bunch of png like "persona-person-white.png" and a bunch of pictures like "*_screenshot_1_thumb" that take about ~1000ms each, but are taken in parallel.

For some reason, it looks like JavaScript doesn't make it onto the Web Platform landing page[0] (or maybe I just can't find it?)

It's in the drop down list when I hover the main menu, but I can't seem to navigate to it otherwise.

[0] https://developer.mozilla.org/en-US/docs/Web

And I see someone fixed it, just as I was in the middle of adding it :D

Fixed. BTW, MDN is a wiki so if you see stuff like that again I think you can fix it yourself. :)

Yeah, I was just adding it, but you got in just before me (I had to persona-ify (personafy?) my account first)

I didn't build this, but a cool tool that the author hipped me to on Reddit - http://mdn.io/

It's basically a LMGTFY search on whatever you put after the slash, for example - http://mdn.io/css%20transitions.

I hate to post the typical "why are they focusing on adding new features before making it actually work" kind of comment, but this is that comment. I like MDN, but it drives me nuts how often I click an internal link on it and either get any number of server errors or a 404 page.

If you're signed in, you should have an option to make the page. MDN is a wiki. :)

Could you open a bug the next time it happens (with a link to the page)? It would help in diagnosing the problem (client-side, server-side, doc missing, ...)

Oh, but if you're getting ISE's that's a bug. You can file those here:

http://bugzilla.mozilla.org/form.mdn

Hmm. Great, looks exactly like something Microsoft might have made a few years ago.

MDN and MSDN. Ok, this is maybe just coincidence, but their portal pages do look similar.

https://developer.mozilla.org/en-US/ vs http://msdn.microsoft.com/en-us/default.aspx

I don't see the similarity..? Besides the obvious small stuff, but then almost web page are similar..

Low contrast, lot of white space... reminds me of the PHP.net redesign :/

Old design was better!

What I want to know is: when will w3c update their site?!

can someone point me to their elasticsearch setup? i'd like to see which queries they use and how they index their content.

Probably the most relevant code can be found here:

https://github.com/mozilla/kuma/tree/master/apps/search

Persona login doesn't work for me.

Your profile is not immediately available after login with persona.org, as you also have to provide a username (in case you don't have one already). You're logged in only after providing a username in this second step.

Hi, Persona dev here, could you email me (HN username @ mozilla.com) and tell me more about how it's not working?

Or file a bug: https://github.com/mozilla/persona/issues/new

Reply on news.ycombinator.com