Blog a la Habr, the choice of platform

In the previous series ( How to slay Habr in a hurry ) launched a project based on the Create React App (CRA). But this is a SPA , which is not very suitable when indexing is required in search engines. Need Server Side Rendering (SSR). And preferably out of the box, and not on the knee. It is extremely wasteful to spend resources on the independent development of basic technologies. How to choose a platform with SSR support? In practice, of course, the POC . I will try to implement a CRUD with an input form on the Material-UI , considering the candidates: React Starter Kit (RSK), NEXT.js and Electrode (not to be confused with Electron ).

Sources on github .

Routing

RSK has its own bicycle - universal-router . Uploading external data to Redux in server rendering is offered via the express (or koa, or hapi) configuration.

NEXT.js approached the question of routing in an original way, suggesting the use of file names in the pages folder. Inside the usual React-components with a static method getInitialProps , in which it is proposed to perform the loading of external data in server rendering. If you need to customize the processing of requests, then this is done in the most natural way - through the configuration of express (or koa, or hapi).

Electrode, unlike other platforms considered, does not force to refuse redux-router . This means that at the time of the implementation of the frontend, you can return to the development of the CRA. All the magic of server rendering inside the electrode-redux-router-engine .

Performance

It is very interesting to see how the site zeit.co is loaded , which works on NEXT.js. When you open the page of the list of posts, 15 MB of traffic comes, but further transitions to the pages of the posts occur instantly - everything is cached in the browser. However, this disgrace can be disabled through the prefetch property of the Link component. Offline-first is promised in NEXT.js ( with reservations ), but it has already been implemented in Electrode. SSR caching: there is an example in NEXT.js, but in Electrode the solution is in production .

In RSK not less interesting behavior is noticed. When I switch the list items in the history of the URL entry line in Chrome, I observe the execution of the routes on the server, although I have not yet confirmed my choice. As a result, the finished page is issued from the server faster.

Build Setup

NEXT.js and Electrode hide their implementation, but allow you to configure the assembly. CRA prohibits configuring the assembly only through the eject (people fought half a year for the right to screw the SCSS), but there is a way out . In RSK, only fork, you need to keep track of the updates of the project and use their hands - the fee for full access to the source code of the platform.

Build and warm up

RSK (like CRA) kills by loading a new browser page during the initial build, NEXT.js and Electrode do not have this drawback.

Electrode very slowly performs the initial assembly.

NEXT.js offers a great service for deploying now , and it is not tied to a specific platform.

Bug work

In RSK, terrible error output, in addition, Source Maps debugging works incorrectly, the cursor moves a couple of lines below. In Electrode, it is simply impossible to understand what went wrong if the error is on the server side. In NEXT.js, the situation is much better, and they promise to finalize it in the near future. CRA is the standard here, and I want to say a special thank you for displaying ESLint messages in the process of working on the project. By the way, RSK turned the ESLint checks into a form of torture, I cut out the pre-commit.

Support

NEXT.js captivates with a variety of recipes, although some important questions are still unanswered, but the dynamics of the project’s development are encouraging. RSK and Electrode complement the overall set well. On the example of CSRF : nothing at all in NEXT.js, a holiday in Electrode, in RSK found a reference to csurf .

Yesterday, March 27, NEXT.js 2.0 was released, six months after the start. Dvizhuha around NEXT.js much more compared to RSK and Electrode. Judging by the stars on GitHub, NEXT.js is catching up with CRA, given the difference in age.

Behind the technology are specific people. This is also an important point of choice. NEXT.js develops ZEIT - the founder of Guillermo Rauch was the technical director and co-founder of LearnBoost, remember TJ Holowaychuk?

PS Along the way, I found out

 // Create an action creator (description is optional) const add = createAction('add some stuff'); const increment = createAction('increment the state'); const decrement = createAction('decrement the state'); // Create a reducer const counterReducer = createReducer({ [increment]: (state) => state + 1, [decrement]: (state) => state - 1, [add]: (state, payload) => state + payload, }, 0); // <-- This is the default state 

 $ yarn add babel-plugin-module-resolver -D 

 { "presets": [ "next/babel" ], "plugins": [ ["module-resolver", { "root": [""] }] ] } 

 { "moduleRoots": [ "" } 

 import MyComponent from 'components/MyComponent' import MyPage from 'pages/MyPage' 

UPDATE

I ran in a circle, and now I can say with confidence that the proposed method of optionally screwing SSR to the SPA is the most correct ( Wishlist formulated a long time ago ).

I was happy when I sat on the CRA. Until then, until I read " What to base React applications on." And then continuous struggle with the complexity of the environment. I read issues - the head swells.

All researched solutions offer their bikes for routing, which can already be thrown away - the latest version of React-Router implements the functionality for SSR .