peterbe

Shameless plug if it helps anybody else, like it helped me; http://govspy.peterbe.com/

What do you miss about it? Can you not find what you're looking for?

It's pseudo code. The real code is TypeScript React and looks very different and it wouldn't serve the article to take snippets from that code to explain how it works.

Getting accessibility right is hard. We very much care about that. One of the strong reasons for why we're using Downshift.

> They hi-jacked the browser's `/` key to focus the field, which is something I hate.

You're not the first one to point it out. Please join github.com/mdn/yari to raise your voice. It's an Open Source project after all.

> They should have just had the search field focused automatically

Why? There's a lot of JS to load to make that work. If you never need to do a search (e.g. from a Google search) it would be a potential waste.

> Also, I'm confused, I thought https://mdn.dev/ was the new thing because Mozilla was stepping back from MDN. Is it a fork?

That domain is just an alias we don't currently use. It's still the old MDN from Mozilla. No fork.

MDN has 2 search things: 1. client-side only which downloads a complete list of all titles. 2. full-text search on everything with Elasticsearch.

Relevancy is the huge game-changer. MDN uses pageviews analytics to determine was a "popular" age is.

(author here) We're still on FlexSearch 0.6 and the new 0.7 is a big refactor. I hope we can upgrade some time.

<datalist> is awesome! But I find it works better for short options. See https://www.peterbe.com/plog/datalist-looks-great-on-mobile-...

On every document, there are appropriate links at the bottom .

Can you scroll to the bottom of that page and use the "Report a problem with this content on GitHub" link?

The raw content is not Markdown. It's HTML with some macros (called kumascript macros).

And yes, you can "host MDN locally" now. Before you had to write a web scraper, now you can just iterate over the files after a `git clone`. But you might need Yari to build the raw HTML to fully formed HTML that you can open in your browser.

It's not that easy. We have 60+k pages carried over from 15 years of organic evolution. It's unstructured and messy. A move away from HTML to something "more popular syntax" (like Markdown) is NOT easy.

MDN is powered by a mix of people paid (by Mozilla, Google, Samsung, Microsoft) and contributors who volunteer their time.

Why would it be for the worse?

Sorry(?) But it's still just MDN (or MDN Web Docs). Yari is just the code name for the code repo. Not a particularly important name.

This is just the beginning. Finally we can do the kind of web performance improvements we couldn't do on the old platform. But to boot, we gained 10-20% on the First Render metrics. And because of the whole new way we deploy, we went from a 27% hit ratio (of popular pages) to 96% in the CDN. That means ~70% of the time you gain about 300-500ms on the initial load. And besides, before, cold cache misses in the CDN would result in a backend server rendering whereas now a cold cache miss just means an S3 lookup.

PostgresSQL is better. We're all aware of that. But it's miniscule in importance. Especially if you use the ORMs and other decent tooling. The move to git isn't MySQL's fault. It's so more and bigger than that.

1. That's right! But it's not really on the roadmaps either. One can hope that someone in the community writes a fancy web app wrapper for GitHub's API or something.

2. Yeah, it's really really convenient to submit a quick PR entirely in the GitHub Web UI. But I admit, we have some work to do make the previewing experience a bit better.

What's cool about git as a persistent storage, is that you can use vscode, emacs, vim, or notepad. Or you can write a little web app that starts a WYSIWYG editor on localhost:8888 or Heroku and have it dump to the file system and then you just need to write a script that takes care of submitting the PR from there.

Also, keep in mind all the tooling GitHub offers. Comments with reactions, quoting, permalinks, blocking, etc. Yes, it can be built in-house but would cost a fortune.

Every story has at least two sides. Check out some of the amazing PRs people have been able to do recently on https://github.com/mdn/content/pulls Being able to do scripts or grep + sed or other advances bulk edits is really cool. E.g. https://github.com/mdn/content/pull/152

The database dump is coming. Busy week.

Also, at the footer of every document is a link to `$0/contributors.txt`. Your attribution is there: https://developer.mozilla.org/en-US/docs/Web/Security/Certif...

There will be a record of every contributor who submitted a revision to the non-archived content in all locales.

It has nothing to do with donors. The less people use Firefox to search Google and click ads on that, the less money Mozilla gets. 90% of the revenue depends on that. When nobody can even go to vacation destinations, they won't click those hotel/travel ads.