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.

The article is just anecdote, not really good testing.

Mayhaps. Or, just a snapshot from the trenches of real application development.

We all have to make choices. Different pros and cons. Before jumping into, perhaps run some tests with real stuff and change direction based on that.

In application development is usually doesn't matter what the core difference is between two databases because there are drivers and mappers that you more or less have to use. I.e. the Django ORM makes PostgreSQL convenient.

"As he chose to show us C++ code, instead of the assembly code, I'm guess he's not exactly a compiler expert."

I've used Postgres in production since 2002 and speaker that PgOpen. But I'm not an expert. I never will be because I make things with tools. What do you do?

Hey, Original blog post author here.

What a lot of people don't understand is that you want it both. The resilience of Postgres and the speed of fetching from Redis.

You have data stored. You want to retrieve it as painlessly (shorter time, less CPU usage, less complexity, etc.) as possible. What are the options? How much faster is Redis? How much RAM is that going to eat up? Different tools have different properties. Run some tests to answer some of those questions. Don't just guess. Sure Redis is going to save some time, but how much? Do you know by heart?

That's missing the point. The HTML document comes from a regular origin server, the rest of the stuff needs to be downloaded. That's a then down to a choice: Do you use a CDN or the existing HTTP/2 connection.

I go to https://domains.google.com and search for my desired .app domain and it says "Google Domains does not support the .APP ending" :(

Don't know else to shout this from the roof tops, but it's a biiiig deal in terms of browsing happiness: https://www.peterbe.com/plog/another-win-for-tracking-protec...

^ That blog post was written when my Firefox Nightly was what is v58 today.