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.
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)
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.
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.
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.
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.
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.
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.
> 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.
43 comments
[ 2.0 ms ] story [ 94.7 ms ] threadAs 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.
What, specifically, are you suggesting as an alternative?
Unfortunately, React typically takes over the whole page, so it's a little less straight forward.
SSR solves waiting for the API but not the CPU problem.
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.
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.
Furthermore, it's fast and it looks good. What's the problem?
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.
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.
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.
Besides, today XHR is being replaced with the fetch API.
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.
- 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.
It appears they are using server-side rendering with React...