MDN (beta) is now built with React | Hacker News Reader

MDN (beta) is now built with React

beta.developer.mozilla.org

33 pointsLouistiti41 comments

So. It seems that without Javascript, regular documentation pages work, but there is a useless position:fixed progress bar at the top.

https://beta.developer.mozilla.org/en-US/docs/Web/API/Docume...

Search is broken: https://beta.developer.mozilla.org/en-US/search?q=DOMContent...

The menu to navigate in the documentation works, and everything seems reachable from there. https://beta.developer.mozilla.org/en-US/docs/Web/Reference

These links work okay on Netsurf.

I'll report the useless progress bar when Javascript is disabled.

Not so bad overall. Quite good, actually.

I am shocked and feel kind of betrayed that the de facto "Web documentation" moves away from using Web technology for static documents to something that treats the Web as a broken runtime for apps.

Isn't it maybe because it does not?

That'll mostly depend on if it still gracefully handles JS being disabled. But I hear ya.

It's a webpage built on web standards and designed for web developers. It couldn't get any more webby.

Furthermore, it's fast and it looks good. What's the problem?

> It's a webpage built on web standards and designed for web developers.

There are a lot of web standards. XHTML and XSLT are web standards. Server-side rendering is web standard. Being able to save a page with search results and view it online used to be standard.

Some standards are better than others. Some are objectively bad and promote hazardous and error-prone practices. ActiveX is a standard, that was meant to turn Web into platform for running Windows applications. It did so by giving web developers access to powerful programming languages and diverse range of APIs (some of those APIs were a bad idea by themselves). All modern Javascript web frameworks are spiritual successors of ActiveX, and I sincerely hope, that they will end up in the same garbage dump of history where it did.

Well, the W3C's standardization attempts of XHTML were a bust. Microsoft's use of ActiveX was also quite proprietary (only ran on Windows as I recall). At the very least it wasn't an open standard.

ECMAScript however is open, very well-supported, and actually works. I see little connection between today's JS frameworks and ActiveX controls. That seems like a stretch of definitions.

> I see little connection between today's JS frameworks and ActiveX controls.

XMLHttpRequest used to be a popular ActiveX control, that introduced ability to programmatically perform web requests at programmer's discretion. Most modern Javascript frameworks can't be used without such ability.

XMLHttpRequest was useful enough to become a standard browser feature. That doesn't prove that ECMA is somehow nonstandard, or even a poor standard. Or that frameworks built on top of it are.

Besides, today XHR is being replaced with the fetch API.

This is very weird to me. It seems like a totally static site. What does it need React to do, exactly?

You missed the point. It's not about what React does, it is the "nobody uses jQuery anymore, everybody uses React" syndrome. React doesn't need to do anything as long as we use it.

I think you're attacking a straw man here. The people who want you to get rid of jQuery are mostly arguing that vanilla JS does what jQuery does.

As for abstracting the relationship between data and presentation, there is definitely a React bandwagon, but that's kind of the second stage after getting past jQuery.

I got your point, but who uses vanilla JS these days when you can just use React, specially when it is not needed?

I can’t imagine a more suitable use case for a static site than for documentation. Why on earth?

Docs can be really dynamic, like the ones that have runnable sample code in various languages. It's just that these docs... aren't.

Even for those, it's completely reasonable to have most of the page be static and only have the runnable parts be dynamic. You could use React for the dynamic bits and regular HTML for the rest.

Unfortunately, React typically takes over the whole page, so it's a little less straight forward.

I find react to be a very pleasant way to make websites, even static ones. And for static sites you can use SSR or something like GatsbyJS to make everything load as if you had actually written the html (i.e. no dependence on javascript). That's the approach I use for my blog and according to google pagespeed the only problem with it is that the TTFB is too high (which is surprising because I host it as a totally static site on AWS)

How is it surprising that rendering a React website is slower than simple HTML?

An SSR React site IS simple HTML.

Doesn't matter, React has to rehydrate which blocks the CPU.

SSR solves waiting for the API but not the CPU problem.

That doesn't affect TTFB.

Ah you are right, my bad. I was thinking of TTFI.

The server doesn't do any rendering before serving the page. All the "SSR" is done exactly once at build time. To the server it's no different from serving any other site.

I'm not too familiar with Gatsby but something has to be slowing you down if TTFB is too high.

It's not that high, Google says I might be able to save .8 seconds. I might try hosting on netlify and see if that improves things

Because static sites are not cool anymore unless you use Gatsby and its GraphQL interface to read your markdown files, because directly read markdown from your disk is not cool either.

Why keep reading markdown from disk and regenerating the page when you can just compile the site once and be done with it? Much easier to cache.

I think you missed the sarcasm from parent poster.

Even a static site needs to be generated somehow, and React is quite a nice way to generate HTML. It can even do that on the server, and disabling JS in dev tools shows that's what they do :).

> Even a static site needs to be generated somehow

No, it doesn't. You can just write it.

Anyway, the question here is not why they're using React to generate a site, but rather why they're using it to display the site.

As others have mentioned, there are lots of tools to write DRY HTML/CSS, then compile, then deploy as a static site. No one would ever know which tool you used.

The weird thing here is that they're using React in the browser (not as a one-time step) for a completely static site.

Why not? There's no real downside when combined with SSR.

Complexity is costly and generally more brittle

I love using Markdown for documentation. It's readable in source, it's easy to compile to HTML, and it's pretty easy to add some JavaScript later for dynamic parts.

Even "just writing it" is a generation step.

If it's anything like my experience then one thing to switch to React or any frameworks would be for better developing experience.

For simple pages templates are totally fine and frameworks might be overkill but when the projects starts getting big stringing templates together can be quite painful let alone debugging them.

Just my opinion though but I'd also like to hear the actual reason for the switch.

Firefox's web developer tools are all react/redux now as well, and are much laggier because of it :(

Because apparently traditional server-side rendering isn't complex enough...

It appears they are using server-side rendering with React...

When did inlining svg icons become a thing? I've always seen things like font awesome.

Inline SVG has several advantages over icon fonts, which were never meant to exist:

- immediate rendering

- multi-color icons without any stacking tricks

- flexible styling

- better aliasing, more consistent rendering

- can be animated

- easily load only assets used on the page vs a sheet of hundreds, most never used

- works well with rendering libraries like React, makes manipulating images very easy

- compresses well with gzip, no need for symbols

It’s becoming standard practice for good reasons.

- works for people who block web fonts

Are they using React only for the small interactive parts?

Reply on news.ycombinator.com