There is this trend where people build content heavy sites like this on using React. It's a weird choice since you want to optimize for SEO. Anyone know why people are doing this? Have this SEO issues around React been resolved?
Not sure what SEO issues you're talking about, since many search engines index React apps properly even with no server rendering.
Also child comments are talking about it being a waste of developer time and server resources. If the developer saved time doing the React version instead of using a static site builder, was it really a waste of time?
Finally, if there's ever a next step for this site having to convert from a static version to a dynamic one could suck.
I have to wonder if this is criticism just for the sake of having something negative to say. Does anybody really think the kind of micro-optimizations these comments perpetuate are really worth making it a more complex problem?
Props to the devs of this site for using what they wanted and felt was best for their use case.
> If the developer saved time doing the React version instead of using a static site builder
How is this even possible?
On top of that, WHY would you even use React (a framework designed for dynamic web apps) for a static website? The only reason I know of is because developers want to look hip. Please tell me if I am completely missing something you know.
Maybe they have processes where it is a one-click thing to setup a new site like this. With a combination of 'set in their ways' using a static builder might include setting up a new build system or fiddling with new CSS setups and so on.
E.g. I'm an iOS developer and if I am to prototype something, I often just start from an already built app rather than doing it inside a prototyping tool. Because it saves me time for what I want out of it.
React has server-side rendering so SEO is covered.
However it’s still a complete waste of developer time & server resources to do this in React when a static website would be better suited for the task.
I really disagree that it's a "waste of developer time" to use React for projects like this.
`npm install next react react-dom` takes an insignificant amount of time and gives you an extremely efficient developer experience immediately, with automatic code splitting, server side rendering and great modern CSS support. Compared to the amount of time I've spent over the years fiddling with gulp/grunt configuration files for "static websites", it's a no brainer for developers who are already productive in React.
Sure, if you're really good with React and prefer that environment, you can use it to build static sites, or a framework like Gatsby to even make it efficient... but this site is 4 pages and requires no JS at all. I could make this thing in about 30 minutes using notepad.
What's the value-add to using SSR React as compared to a framework purpose-built for server-side rendering to begin with if you're starting a "new project"?
Value-add is for engineers who use React day to day already or want to use a minimal API to work to build their UI.
Don't take my word. Checkout the popularity of React, it's proliferation into the marketplace, and it's use on production environments. Also Vue is another popular alternative that UI engineers like to use, which also has SSR.
>Checkout the popularity of React, it's proliferation into the marketplace, and it's use on production environments.
How is this a valid methodology to picking a framework for your web product for your new business / project? If the idea is to reduce training/recruiting/onboarding costs and sacrifice domain-specificity to attempt to utterly commoditize your developers, I can sort of understand that reasoning at larger scales. I just don't understand why a new business/project would choose this weird circumstantial path for new development initiatives.
I also don't understand why I can't seem to get any React enthusiasts to explain to me the business value prop of using React for a _new_ business started today. I'm only guessing that there are elements of cost reduction in training/onboarding/continuing education, but nobody will even go as far as admitting that much of it, let alone give a decent technical reason for using React.
Does all of this really just boil down to "It's javascript, and I know javascript. And not only that, but it's React, and I've used React before to work on this website that I thought was pretty cool, so I might as well just use React again because so many other people use it."?
I don't even think that is that bad of a business reason, I just don't get why people are so cagey about it and try to invent weird technical reasons for why your enterprise document store needs to have a reactive, fully-fledged javascript application running in the client browser just to show a document and expose basic CRUD actions.
This is what happens when you use a frontend framework and a backend framework.
EDIT: To clarify,
> as compared to a framework purpose-built for server-side rendering
If you use ANY framework purpose-built for server-side rendering, the second you need to do some client-side rendering you're now using two frameworks.
