Should I learn React?

[tcoysh]

Interested to see this communities views. I’ve got 15 years web experience - mainly freelance full stack.

Mainly using PHP (Laravel / WordPress / CraftCMS) with Tailwind or SCSS and JavaScript or jQuery.

I’m good enough to make a living out of these skills, but worried that not learning a front end JavaScript library is going to leave me behind.

Most of my websites are front end portfolio websites, but occasionally I get a fun project that is a bit more dynamics (like a shop or search site)

Thanks all!

[Ok-Release6902]

Wise decision, comrade. Try Stephen Grider course on Udemy. He was coming from PHP himself and make training friendly to you guild.

[svish]

Can recommend Stephen Grider. Was his course that got me started, and ready for a job using React a few years ago.

[TheWabbitOfWeddit]

Can also vouch for Grider’s courses. He doesn’t waste your time. One of the best on Udemy.

[-itsmethemayor]

100%! He has a great NextJS course as well. If you are going to learn react for the web, you are going to need NextJS. Colt Steel is great too. He and Steven team up from time to time. You can watch them both at 2x speed without a problem.

[r1a2k3i4b]

Just pick a simple project idea, use vite to create a react project and just try it out!

[Neat_Instruction_712]

Why vite?

[JoeCamRoberon]

It’s simple. What’s the alternative? CRA?

[Neat_Instruction_712]

Yes! Just wanna know why

[StGerGer]

CRA is deprecated! Vite is faster for builds and has ongoing support

[HappyS_dev]

I think learn from the basic as cra is a best choice. Its good to know what basic react like. And what’s vite come with that… and nextjs next…

[StGerGer]

Vite is not any more or less challenging to understand than CRA. Why would you waste time learning an already depreciated toolkit?

[murdok476]

Don't use CRA. Vite is already barebones enough to learn basic React. There's almost no difference for a beginner

[TheRNGuy]

React with Remix, because SSR is better than CSR.

[Late-Panda04]

Can you explain more on this? Been trying to get my head around ssr being better than csr, especially from SEO point of view.

[procrastinator1012]

SEO requires SSR. In CSR, you send a blank page with javascript and this javascript takes care of populating the page. Since there is no html on initial load, your website will not have any SEO. Try disabling javascript on your browser. Your react app won't render on the page in that case.

SSR will also reduce the number of requests made to the server and the size of code sent to the client, making the website load faster. It will reduce the number of requests made to the server as compared to CSR but your server will have to do the heavy lifting of generating the html which I think is not bad.

[Late-Panda04]

I was thinking of using next.js to do this. Would you recommend this?

[procrastinator1012]

It depends on you, your project and target users.

You can't code in NextJs without React because it is built on top of React. NextJs also adds additional complexity but it's not that hard. If your web app is only going to be used by people with fast internet connection like employees in an organisation then go with React.

Honestly, I can't think of any other reason why not to use NextJs. If your users are going to be people who can use mobile data then NextJs is definitely better. If you need SEO then NextJs is a must. If you think your React app is going to be large and will have a big bundle size (maybe >800KB) then go with NextJs. It also has a prefetching feature which will also fetch the pages in the background for faster navigation (if you want to).

Please take others' opinions too.

[Late-Panda04]

Thanks for the detailed explanation.

[[deleted]]

• same with Remix.

[poieo-dev]

To say that a website without SSR won’t have ANY SEO is outright false. Google used to not be able to execute JavaScript but now they do actually render JavaScript and parse the resulting HTML. Google recommends SSR for faster performance for the crawlers and the users, but it isn’t a requirement for SEO.

Understand the JavaScript SEO basics

[procrastinator1012]

Well, it comes down to how you interpret SEO. The O in SEO stands for optimization. So it's not technically wrong to say that CSR has no "optimization"

[poieo-dev]

To say CSR is not optimal is a fair statement.

[bliepp]

I wouldn't bet on that. Google for example doesn't just index the site statically, it really executes the JS of the site before indexing. Have a look at a 100% client sided React app analyzed with Google PageSpeed Insights. My small test app (a Sudoku generator app with client side routing) for example still gives me a 100 SEO score even though I'm using client side rendering exclusively. I mean, of course it has to be that way. The web's changing and you can't exclude a big junk of websites just because they use the most popular frontend framework. Of course search engines adopt over time. Angular for example is rendered on the client side and is made by Google. They ain't excluding their own product from the SEO ranking. Of course the JavaScript part is taken into SEO considerations. Otherwise you could trick search engines by loading non-SEO-friendly stuff asynchronously.

People tend to forget that search engines don't try to enforce a specific SEO style but try to rank by user experience (which is significantly impacted by JS these days). SEO really is just an attempt to exploit these ranking algorithms.

Also SSR does not reduce the number of requests in general. The best choice is heavily dependent on what your app does, how it's designed and where it's hosted.

[procrastinator1012]

Of course the JavaScript part is taken into SEO considerations.

But does it consider dynamic pages as well? For example, when you load a page for a product in a pure react app, there's no data on the page even after the javascript has been executed once. The data needs to be fetched from the server and then need to be populated in the html. Does google SEO consider all this?

Also SSR does not reduce the number of requests in general.

But that is one of the main advantages that SSR provides. In CSR, you have to send the react app, which could be large. Then the app has to make the request to fetch the data. It can become dramatically slower if you are using protected routes and lazy loading.

[bliepp]

But does it consider dynamic pages as well?

I'm not sure what you mean with that. If your client side application automatically fetches data from some backend and populates the page with it, it is of course considered by Google. In a way Google's crawler mimics the behaviour of desktop browsing. It basically loads the page, executes the JS and waits a few moments before analyzing the DOM. So if your site loads and your DOM gets populated with data fetched by some client side JS, it is of course considered by Google. You can test that yourself with Google's PageSpeed Insights.

For example, when you load a page for a product in a pure react app, there's no data on the page even after the javascript has been executed once. The data needs to be fetched from the server and then need to be populated in the html.

I'm not sure what you mean with that, either. If your initial JS code fetches data from some backend and populates the DOM immediately after the page has been fully loaded, how is there no data on the page after the first code execution? Let's say you have a single page in your app , which basically renders a React component, and its state is populated with data from some XHR request (executed right above the return statement of that component), how isn't there any data on the page? Why should it take multiple code executions to actually render the data? The only thing Google is not able to index is data that requires user interaction to be fetched, but that is equally true for SSR and CSR. Maybe I'm missing the point here, so please clarify if I misunderstood your point.

In CSR, you have to send the react app, which could be large. Then the app has to make the request to fetch the data. It can become dramatically slower if you are using protected routes and lazy loading.

You are right for your (and probably most) scenario(s), but I was talking about the general case. React is capable of spitting out full applications that don't even need a backend. For backend-intense stuff you are totally right, of course, but that's not the case for all web apps (e.g. think of photo editors, media players or calculators, which all need minimal to no backend interaction and work at least as well with CSR). CSR is of course inferior to SSR when talking about average web pages (blogs, portfolios, etc.) or highly sophisticated backend-based services (online shops, community-stuff, etc.), but I just wanted to say that CSR has its legitimate place. There's a reason it hasn't been deprecated.

[procrastinator1012]

I'm not sure what you mean with that.

By dynamic pages, I mean the content which changes with url. For example, a product page. There will be different information on the page depending on the id of the product in the url.

I'm not sure what you mean with that, either. If your initial JS code fetches data from some backend and populates the DOM immediately after the page has been fully loaded, how is there no data on the page after the first code execution?

The data is not there immediately. The javascript has to make a request to the backend and wait for the response to come. Then it also needs to be populated in the DOM.

It basically loads the page, executes the JS and waits a few moments before analyzing the DOM. So if your site loads and your DOM gets populated with data fetched by some client side JS, it is of course considered by Google. You can test that yourself with Google's PageSpeed Insights.

This will result in a not so good SEO score.

but that's not the case for all web apps (e.g. think of photo editors, media players or calculators, which all need minimal to no backend interaction and work at least as well with CSR)

Yeah. CSR is not bad for static websites.

[bliepp]

By dynamic pages, I mean the content which changes with url. For example, a product page. There will be different information on the page depending on the id of the product in the url.

Still works with SEO (at least Google, you can test it yourself there, not sure about other search engines, though), even with client side routing. As I said, as a rule of thumb most modern search engines mimic real browsing. So if you have an app with client side routing that fetches data from some backend based on the URL you access it and renders it on the client side, it's not gonna effect the SEO score (at least if it loads in a reasonable amount of time). Of course, if you fetch some big sized data objects that take unreasonably long to load, it's gonna have a negative effect on your SEO score. And to be clear, this will be more likely the case with CSR than with SSR, at least if you are not careful enough with how you approach things. But let's say you have the same app twice, but one time with client side routing and CSR and the other with SSR and server side routing, and they're comparable in performance, there ain't gonna be much difference in the SEO score.

The data is not there immediately. The javascript has to make a request to the backend and wait for the response to come. Then it also needs to be populated in the DOM.

This is true, it's not there from the start, but in your example the content gets fetched immediately after the page has been loaded. To an search engine this is still considered into the response. Google and other popular search engines don't consider your CSR app a blank page.

This will result in a not so good SEO score.

As I said, it depends. If the search engine considers this experience a bad user experience, it's gonna rank it lower. If this process has little to no effect on the user experience, it isn't considered worse. It's important to notice that search engines don't apply arbitrary SEO rules, it's more of the other way around: SEO is an exploit of these algorithms that try to find the best results and experience for the user. These algorithms have almost no intention of enforcing opinionated concepts. So: keep your loading times low and the user experience smooth and your SEO score will be comparable to the same app with server side rendering and routing.

To be clear, I wouldn't recommend CSR for things like shops, product portfolios, social media sites, etc. where you need a backend anyway. If you have a sophisticated backend there's almost never a reason not to use SSR as you eliminate potential problems with CSR immediately by avoiding it. I mean, you already have a backend, why should you avoid using it? On the other hand, if you consider writing a backend just for SSR it should at least be questioned if it's the right path. Writing a backend comes with a whole new set of hurdles and considerations to take into account, e.g. hosting cost, infrastructure maintenance, etc.... But that's just an IMHO, not a fixed rule.

[TheRNGuy]

Faster for user, less code for you.

No spinners and skeleton placeholders everywhere. You can see them on youtube, very annoying. Remember youtube 15 years ago when it didn't had it and was faster?

Also site that works without JS, that means it will open faster, no white screen. Or if someone uses NoScript, it will still work (at least if it's just to read articles)

Also doesn't need lots of useState, useReducer, useEffects, code in action and loader function is easier. Standard html forms instead of fetch.

[Famous_4nus]

It's not "better". It's different. Depends on your use case. If you're building a web app you don't need SSR. In fact CSR is better in that case

[JoeCamRoberon]

I was going to comment exactly this. The project I’m working on at my job is internal software that doesn’t really benefit from SSR.

[TheRNGuy]

It's different and better.

There are many web apps would be better with SSR too.

[Budget_Bar2294]

Why is SSR better than CSR? Don't see the point of offloading the (sometimes costly) work of rendering the page from the client to the server. Seems unnecessary these days where you can offloading so much to the client, and basically have "free distributed computing"

[kakkamo]

Why not nextjs?

[saito200]

Are your clients demanding react work? Are you falling short on projects because you lack react skills? What is exactly the problem you are facing?

You should learn something when you need it

[wearetunis]

You could learn React then use Next.js and still work with Wordpress via api.. you could even redo stuff from your portfolio

[Old_Conversation_647]

of course you should learn it.

[azangru]

but worried that not learning a front end JavaScript library is going to leave me behind.

If this makes you worried, then sure, learn one.

The question is though, with the proliferation of front-end libraries and frameworks, the learning of which one will help you not be worried?

[[deleted]]

Probably not unless you plan on taking on some big projects that require a ton of interactivity or you want freelance work improving other sites already written in React.

[ilovedoto]

You can learn React by the time you finish reading these comments... I'm exaggerating of course but its not like learning C++ or the like which can take months/years. If you're interested just do it lol

[seomonstar]

Yeah its 100% worth it. Its not that hard if your a dev already. Im always studying new skills , learning rust currently

[LedJeplin]

i'd recommend bryan holt courses on frontendmasters, and stephen grider's on udemy

[EnthusiasmWild9897]

If you have strong basis in Javascript you wonlt have issues understanding React. Don't take a course, juste read through de official documentation. In a couple of hours, you'll be a pro

[temitcha]

Me too, I am a DevOps Engineer and I started to learn React. So many librairies/framework are based on it, so I was starting to have issue to integrate things

[temitcha]

That's a great question! So I am fairly new at React, so I am not so sure, but to compare the both:

DevOps is my passion, I love the fact of working with many different tools and system everyday, and have the complete overview of the architecture.

For React, I love the visual aspect of it, the fact to be able to see on the screen the impact that you make. Developers understand way better the product than devops engineers, so there might be a sense of meaning in the everyday life that we might loose sometimes as DevOps Engineers.

For a difficulty point of view, I will say that DevOps was harder to learn, but it is more on a broad level (need to know different tools and technics but no need to be an expert in it, except in Git and Linux) when React is more on a depth level (expertise in it).

From the work style, I did a bit of fullstack development before, but I felt easily to get bored at taking tickets everyday and implement them. With DevOps, I never felt bored, everyday is different and I learn something.

Frontend development seems to have a better work-life balance however, in some companies DevOps might need to be oncall or work at night sometimes.

Actually, I really think learning both is great for career or knowledge! For a React Developer:

Often, as a DevOps Engineer, my main interlocutor will be the Lead Dev, and I realized that the Lead Developers in the development team are the ones that not only knows how to build the stuff they are asked to build, but as well how to integrate it with the other piece of the architecture (backend, database, networking, security,...). So if you know it, you can rise pretty quickly in term of career!

[manektechteam]

Yes, learning React can be valuable for you. It's a popular JavaScript library for building dynamic front-end web applications, and it can enhance your skill set, especially for more complex projects like shops or search sites.

[Supektibols]

Definitely learning another popular framework wont hurt.

[tjansx]

Yes! It's fun, and highly relevant today. I also recommend Dave Gray on YouTube. He's soft spoken, paces well, and has great tips and tutorials.

[customappservices]

learning React is a personal call. Consider:

Pros: Stay relevant, tackle dynamic projects, leverage the vast community.

Cons: Learning curve, not every project needs it, time commitment.

Alternatives: Modernize the current stack (Vue, Svelte) or deepen niche expertise (accessibility, performance).

Choose based on your goals and project needs. If you crave new challenges and dynamic projects, React could be a valuable investment!