I watched Google's conference on SEO and they suggested to use Dynamic Rendering for JS built applications (React, Vue, etc). One of the tools to achieve this is with Puppeteer JS.
I need to create an app that relies heavily on SEO so Server Side Rendering (SSR) is extremely important.
I know that Next JS by default accomplishes SSR, but can I do the same with Puppeteer + Create React App? What is the difference between Next JS and Puppeteer in terms of SSR and Dynamic Rendering, and which one is better for SSR?
In short,
Next.js is a node framework. You use it to write code, i.e. build your application.
Pupetteer can be considered a tool. It comes bundles with Chromium which is practically a browsers equivalent to a testing environment. You writes tests via pupetteer to run scenarios in chromium.
I've provided an over-simplified explanation for those who want it. Shmotam gave a brilliant answer if you want depth.
Difference Between Nextjs and Puppeteer JS is very very simple.
Next Js :- It is React Framework for server side rendering those help in SEO, Optimized for Discovery , Lightning Fast Delivery.so ,very simple word is SSR. For Link https://nextjs.org/#features
Puppeteer JS it is Developed by Google and this is used for End to End testing of your application like selenium.
Both are completely Different and purpose are also different.
Headless Chrome enables "isomorphic JS" between server and client. It's a great option if your library doesn't work on the server (Node). Example for it is lit-html which it's core feature doesn't work outside the browser.
The difference is huge in terms of features.
Next.js offers some nice features that Pupeteer doesn't.
Hot reloading client & server
Automatic code splitting
Built-in CSS support, CSS-in-JS
Fetching data and component lifecycle
and more.
Some feature of Pupeteer:
Generate screenshots and PDFs of pages.
Crawl a SPA and generate pre-rendered content (i.e. "SSR").
Automate form submission, UI testing, keyboard input, etc.
Create an up-to-date, automated testing environment. Run your tests directly in the latest version of Chrome using the latest JavaScript and browser features.
Capture a timeline trace of your site to help diagnose performance issues.
and SSR apparently...
So you can see the major difference these two tools have.
Next.js is opinionated but aims to do SSR with react and builds on that concept;
Take into account that SSR with Puperteer in relatively new whereas community adoption of next.js is already mature with nice set of examples with different tech stacks.
nextjs is the powerful framework that supports ssr (server side rendering) and seo friendly Google search engine.
The react of interpretation is that the component is called after each state change. but nextjs load component and call getInitalProps first time, so view page source you can see data loaded
Puppeteer is used to make bots which works at backend.
NextJs is used to build Full Stack Website. And may be it will soon be available for React Native to make mobile apps.
Related
I am using React in my project and I have problem with client-side prerendering.
More specifically, it would be necessary to configure SEO
Which is the least painless way to prerender existing reactjs app wiht react-routes
Some examples I have researched:
Gatsby.js - https://www.gatsbyjs.org/docs/porting-from-create-react-app-to-gatsby/
Next.js - https://nextjs.org/docs#custom-document
Netlify - https://dev.to/joelvarty/prerender-your-spa-using-netlify-for-better-seo-3h87
React-snap - https://web.dev/prerender-with-react-snap/
Prerender.io - https://prerender.io/
Keen’s Server Side Rendered - https://medium.com/keen-studio/keens-server-side-rendered-react-wordpress-rest-api-boilerplate-bb58edb7cc0a
Razzle - https://reactresources.com/topics/razzle
React Helmet - https://github.com/nfl/react-helmet
Can anyone suggest what option I should choose that is the least painless.
I have headless wordpress as backend and reactjs client-side as frontend.
Or are there other faster options besides the prerendering?
Thanks.
IMO you really don't need to use a framework to achieve SSR if you want to keep control without turning your codebase into a blackbox and choose your own stack.
I created some boilerplate using Node Express. It supports:
SSR using StaticRouter on the server and BrowserRouter in the client
ES6 webpack transpilation + hot reloading both client and server and auto-updating browser
Redux, data preloading and client store hydration
https://github.com/kimgysen/isomorphic-react-setup
Last time I ran it, I noticed that I hadn't saved the favIcon in the public folder and perhaps there are some minor bugs that I will fix soon (I've fixed them in my projects but didn't update this repo because nobody looks at it anyway (lol!)), but what happens here isn't all that difficult to understand.
I created some basic SSR websites with it in a matter of hours.
I enjoy redux-observable to initiate server ajax calls before rendering the content (using forkJoin), but this is not included in the boilerplate (I haven't actually supported it since I uploaded the first time).
But in terms of setup, I don't really see a point in using a framework for this necessarily, it really isn't that painful / difficult to do yourself.
The benefit that I particularly like is that you don't depend yourself on the scope and dependencies of the framework. You don't get into trouble with things like 'the framework will support this feature or fix that bug in one of the upcoming releases'.
Although ultimately, it comes down to personal choice. So it's not like I want to downgrade these frameworks.
Note: The way Redux achieves pre-rendering is simply by adding Redux store (state) objects to the window object in the html that is sent back to the client.
Then at the client, the it initializes the stores with these objects.
So very simply, this is something that is easy to achieve, even if you decide not to implement any other SSR features.
to create server side applicantion with painless integration you can use my cli to generate a default configuration like create react app cli from facebook, https://github.com/ghondar/crassa
I'm looking into building a very simple CRUD web application fetching data from and sending data to a RESTful API backend.
Since I have a good experience with Gatsby JS and most of the features it ships are very useful, would you recommend using it instead of the more vanilla create-react-app? Are there any drawbacks that I should know of?
I've been searching the web for info and showcases but there's not much around on the topic of Gatsby JS used for web apps.
Thanks a lot.
That depends on requirements to your application. If you need static rendered pages, Gatsby JS is ok. If your application is not needed it, but you need any server side live rendering, maybe you should look on something like nextjs. If it doesn't require anything of that, using of Gatsby may be overwhelmed and unnecessary and create-react-app will be enough.
In an article I read that
React uses server-side rendering.
But in another articles I came across this:
Client-Side-Rendering is a relatively new approach to rendering
websites, and it didn't really become popular until JavaScript
libraries started incorporating it into their style of development.
Some notable examples are Vue.js and React.js
Now Which statement is correct?
When I use create-react-app and run npm start, it seems to me that React uses the Client-Side-Rendering. isn't it?
It’s client side. But React, like some other client side libraries, can be used on the server to prerender it with node, usually for SEO.
Out of the box it renders on the client side.
But, if you have a requirement to render pages on a server, you can achieve this with:
Next.js or
Hypernova or any other tool (there is a bunch of them nowadays!)
Note, that SSR will require a bit more experience than a regular React app.
The main goal of this approach is to allow search engine robots crawl information form web pages(SEO).
create-react-app uses client side rendering by default. There are some tools like next js and gatsby js which pre-render pages on the server side. You can also do Server Side Rendering from scratch.
A few years on from the last answer, it is now quite difficult to implement a client-only React app - serving it on Node is trivial and absolutely what it expects, trying to use it as a client library with other server-side support is more of a challenge and documentation about how to do this is patchy and much of it out of date.
When creating an app with create-react-app,there is only one index.html,does that means React can only handle one SPA at a time? What if I want to develop multiple pages? Should I create another SPA with create-react-app and then put them together after building each of them?
Update:
Parceljs can do that. here is docs.
You can use Parcel instead of Webpack (which being used in create-react-app) and it provide you zero config environment to develop web apps (using react or anything else).
Having multiple pages (instead of SPA) is not what most React environments had in mind [before - see update above].
You can have different page URL's using react-router or similar client side routing solutions.
If the concern is bundle size, there are solutions using webpack or parcel to lazy load each bundle whenever they needed or cache bundle (using service workers) and so on (Tree shaking, ...). (check Code Splitting in React Docs)
Other concern I might have in my brain is SEO, in this case you may find Isomorphic app (react server side rendering) useful which initialize first view of requested URL HTML and sends it to client, then client will load react and react will take control of UI. This will help Google (or other search engines) find your URLs fast and user experience in transitions between pages will remain seamless.
I have an app based on the create-react-app starter kit and need to switch to universal/server rendering due to SEO issues.
Is there an easy way or example of taking the create-react-app teamplate and adding or modifying it to support universal rendering?
A lot of the examples I see for universal are overly complex for my needs and I prefer to keep it very clean and simple, if possible.
Thanks.
EDIT: FYI,
I found this medium post which points at this repository.
Seems simple enough, but since I'm a newbie on all webpack/react/node related stuff, if anyone thinks it's the wrong approach, would love to know...
There was a proof of concept of adding server rendering in this PR.
I can’t speak to how good it is but it’s something you could start with.
You may also look at some of the alternatives.
A few of them provide server rendering out of the box.
I've just created react universal (server-side rendering) starter used recommendations from redux and react-router v4. Fill free for feedback
https://github.com/gzoreslav/react-redux-saga-universal-application
You can take your app (bootstrapped with Create React App) to the next level by replacing react-scripts with a slightly altered version - react-app-tools, which allows adding server-side code to your project (e.g. for server-side rendering purposes and/or implementing an API endpoint). It will allow compiling and running your app using normal Create React App pipeline, using a single instance of Webpack, on the same HTTP port.
You can find more info by visiting React App SDK.