Help us test MDN's new React Front-End Beta

I think it could be possible. Mind you, we’re using AWS CloudFront but I supposed it would technically be possible to have dynamically redirects based on cookies. But it all feels pretty fragile. Probably best to keep it explicit and simple.
A possible bad side-effect is if you’re in the wiki to editing (“wearing the wiki hat”) but then you open the read-only site in another tab to see it “as non-editors would see it”. If that’s the case, it would keep redirecting you back to the wiki site.

1 Like

I can’t reproduce this. Do you maybe have a link to a page where you are seeing this?

Hey Takeshi, would you mind trying it again? We made some changes we think should fix this.

Hi Kadir,
Now Firefox loads both pages and I can see and .

I can login to while I can’t login to from the link placed upper right corner of top page: .

BTW, is the login link necessary on Beta is for viewing.

Thanks for the quick feedback Takeshi! Can you tell me what happens when you click the login button on

Login is not necessary to view the beta page. We will offer additional features for logged in users later though.

After I click login link on the beta site, , browser seems to be loading some page, but 2 or 3 seconds later it eventually comes to same page.

The URL Transition took by Network Monitor is as following image:

I expect that whoever made the top navbar in was probably some junior software engineer, because it’s definitely not the quality I would expect for a site aimed at providing frontend guides and resources. I mean that search input is just terrible, and that login link and those dropdowns. I’d expect the quality to be nothing short of exemplary.

How will these benefits be felt?
What tangible aspects of this conversion are aimed at users explicitly?

1 Like

I don’t get it either.
Why do you make a new front-end to a totally fine site?

1 Like

In the past, logging in to MDN meant that all further requests would bypass the CDN for documents. That’s not necessarily so bad for people living close to our servers in Portland, but would be a severe degradation of performance for people living further away. With this change, we can offer features that will require users to login without degrading their user experience.

One example of such a feature is a browser compatibility banner on top of the page that shows you compat info for the browsers you have to support. In the past, we wouldn’t have been able to cache those pages, since they’d be specific to each logged-in user, even though only a small part of the page is customized. With the new front end, we can have the documents on the CDN – same for everyone – and insert the features that are unique to any given user.

1 Like

as a heavy user of mdn, thats nothing i would ever request, desire, or think of.
how many requests for that did you all receive?

in doing so you’ve upped the barriers of entry for new users.
the difference in trade-offs seems incredibly contrary to mozilla’s mission.

Hmm, I don’t think I understand what the upped barrier is referring to. Would you mind expanding on that?

1 Like

using react is not as easy as editing plain web platform documents.
moreover, check out these screenshots of users who you claim to be supporting, not liking this at all

The page transition changes, if I once remove cookie and site data from in browser setting.
After I click Login link on the right upper corner, I’m taken to github authentication page, then I seems to be passed 2FA, I’m taken back to the same page on, with not logged in state.

Again, I might be misunderstanding you here, but MDN editors are not expected to write react code, it’s the same wiki as always for editors. People who contribute to the MDN frontend code – Kuma – will write react code, but they are also the ones who requested the change.

Regarding the examples, I’m glad you’re bringing them up. Currently, we can’t ask people to log-in and tell us about their preferred language. Once people log in, they will get a slower version of the website, after this change, we can address that.

The specific issue here is that people go to Google, which will serve the localized version first (with the /nl/ locale in the URL for the dutch version for people who google in the Netherlands). Since they have requested that URL specifically we serve that localized version to people regardless of their own accept language.

1 Like

Firefox 69.0.3 make it, while Firefox 60.9.0esr doesn’t with a fresh profile. I mean the login to beta site.
And I’m on Debian/GNU Linux, just FYI.