i'm currently expolring ReactJS
i saw NextJS and React Router
Can anyone tell me what's the pro cons between the two. I'm not sure if it's right to compare the two, but from what i see, react-router already has SSR feature. So whats the benefit of using NextJS?
Thanks!
Next.js (see also alternatives like GatsbyJS and After.js) are full featured SSR/static site frameworks, so you get a lot of features out of the box if you need to generate a SSR static site. These frameworks have solved lots of problems, so adding a feature becomes as simple as reading the docs, rather than researching and coding on your own.
If you code your own setup with a standard React app and react-router then you might find yourself running into a lot of complexity and edge cases when you dig into SSR.
In short, if SSR is a core requirement definitely consider using a SSR React framework.
Jed's response sums it up pretty much, but here are some clarifications:
React router allows SSR, but does not implement it. You still need to make a server script that, at least, renders the app to a string and serve that to the client. You may need to do other things, like serve static files. NextJS does that for you.
SSR comes with a few caveats that NextJS also covers, mainly initial asynchronous functions (fetchs from APIs, for example). In a custom made system, you'll have to determine which functions you should call, usually based on the route, and pass the data to the components, usually with Redux
I'm currently working on webs with both systems, and both have some pros and cons.NextJS has a specific way to declare routes and a very different way of moving through them, but making a custom system that deals with everything that NextJS covers is quite the work. I would not recommend making everything yourself unless it's really needed, and maybe check alternatives like Gatsby if asynchronous loads aren't a concern
Related
There is a medium-sized application written in Vue 2.7 (vuex, vue-router, etc.).
Until a certain point, we had SSR "with our own hands." Works crookedly and slowly, but works.
Recently, it has ceased to satisfy the needs of the project and we realized that we would be migrating to Nuxt.
Relatively recently, Nuxt 3 was released. It is now in rc state. We are betting on the further development of Nuxt. Therefore, we want to migrate to version 3. In addition, I think that in the near future we will consider switching to TypeScript, and in Nuxt 3 TS support is at a good level.
But there is an ambiguity: Nuxt 3 works with Vue 3. Also, it is recommended to use pinia instead of Vuex.
In this regard, questions:
Will most components work on Vue 2 when using Nuxt 3? I also want to move to Vue 3, but for now we want to speed up the process as much as possible. But I don't want to use crutches like "Vue 3 Migration Build" either.
Is Pinia definitively replacing Vuex? I mean, is Vuex going to be obsolete anytime soon?
Maybe there are more pitfalls that you should know BEFORE moving?
I would first off migration from Vue2 to Nuxt2, for the simplest + fastest approach without too many breaking parts. That way, you can at least benefit of some SSR capabilities until your whole migration is done.
Then, as Estus Flask said, the main issue would be the packages themselves (like Vuetify, which are still not fully Vue3 compatible in a stable state).
Also, you can totally migrate to Nuxt3 while keeping most of your components with the Options API (no need to refacto towards Composition API).
Nuxt3 is runnable in production but you may still need to troubleshoot it depending on what you are planning to use. Also, keep in mind that not all the modules are migrated yet, here is the latest roadmap.
So to answer your questions:
depending on how your components are now, you may need to update some of their parts, for further details you can check the migration guide and see if you are anyhow impacted by the changes when going from Vue2 to Vue3. If you want to iterate faster (and in a safer way), migrate to Nuxt2 first (should be quite fast!), then try to move towards Nuxt3
Pinia is better on pretty much all aspects when compared to Vuex. Will it be un-usable in the next 18 months? Probably not. It's still the official recommendation and will be the way to go overall (it's just better overall) but Vuex is still totally usable as of today. More details can be found here
as always, you gonna add a layer on top of Vue so it may impact several things:
depending on the amount of features you are using (Nuxt modules, Nuxt specific modules), some releases may take a bit more time overall to ship to production (using Tailwind with Vue3 was made possible earlier in comparison of Nuxt3)
Nuxt is a meta-framework, so it will bring some amount of complexity to properly understand all the Nuxt2 hooks, the way an isomorphic app works, how to use Vue2 packages, some gotchas etc... This is not coming from Nuxt itself, but more from the SSR part.
Nuxt3 is using Vue3, so you will need to then understand a bit more
how composition API works to get the benefit of using useAsyncData
composables etc... So the same work will be needed there too, hence why
I recommend a transition to Nuxt2 first. Of course, it all depends of
your team and if your members are already at ease with Composition
API
Overall, if you need a production-grade solution for your SSR needs, it will be quite useful to use Nuxt for sure but it will also require a bit of a learning curve.
You will also get quite some DX out of it, so that's a nice bonus!
Also, there is no real competition to Nuxt in Vue's ecosystem so at least, you don't need to fully compare meta-frameworks. AstroJS could be another approach but it goes out from the Vue ecosystem quite a lot overall (you won't benefit of Nuxt's modules/nice features for example) and solves some specific needs.
PS: Nuxt's team is working on the same approach regarding server-only components + heavy improvements regarding the hydration.
I am planning to implement react.js for my application. As I am new to react I have a doubt that, how google will index the react components?
And what are the best practice needed to make application properly visible in google search.
Any one has any idea please help me on this.
So I can safely say that I have gotten a react SPA with API calls to render perfectly in googlebot (Fetch and Render). So this is not an impossible task but I will say there isn't much documentation to help you along the way.
Since it sounds like you've got a new app, I'll outline both avenues you can potentially go down.
Server Side Pre-rendering (SSR)
Start with Server side pre-rendering (SSR) and stick to it. There are a lot of ways to do this in react and this ultimately means you'll need to stick with isomorphic libraries which support SSR.
However, by going down the SSR path the chances of being indexed by google are significantly higher since you don't have to rely on the googlebot working with your JS at all.
Client Side Rendering (A normal JS app)
Just build a normal React App with no SSR.. basically business as usual. The benefits are that you don't have to deal with any added complexity of SSR and you aren't restricted to libraries that are isomorphic. Basically this is the easiest but you have to hope your JS compiles and is run correctly by the Googlebot.
My observations
I will say server side pre-rendering is incredibly hard to get working sometimes since a lot of libraries might not support it and this in turn introduces a lot of complexity that you don't want to deal with.
The client side rendering route is just business as usual really and I can confirm that it does in fact work with Googlebot. Heres what I did to get client side rendering working:
Added 'babel-polyfill' to my imports list as early as possible
Inlined my Javascript to reduce the overall load time and minimise unnecessary calls. I did this with Razor (C#) but you can do this any way you want.
Added an external call to the Financial times polyfill (not sure if this ones necessary)
NODE_ENV=production will also help here. It'll cut the overall size of your bundle down
For anyone on C#, this is what it looks this might look like:
clientWithRender.jsx (the entry point of my jsx)
import React from "react";
import ReactDOM from "react-dom";
import 'babel-polyfill';
import App from "./App/App.jsx";
import { Router, Route, indexRouter, hashHistory } from "react-router";
ReactDOM.render(
<App></App>,
document.getElementById('App'));
Index.cshtml
<script src="https://ft-polyfill-service.herokuapp.com/v2/polyfill.min.js"></script>
#Html.InlineScriptBlock("~/Scripts/react/react.clientWithRender.bundle.js")
If you take a look at this article from 2015 on the Google Webmaster Central Blog you can see that google recommends not doing anything different for SEO on a single page (or as they called it AJAX) application - which would include react.
They don't go into a lot of detail there about how they do it, but as long as your application is built semantically and renders very quickly - it should rank.
They place a lot of emphasis on performance, with faster render time leading to higher rankings. This puts all single page applications at a major disadvantage over server side rendering.
If you want some more specific guidance - this seems like a really good place to start.
I'm new to Javascript frameworks and looking for framework for my new projects. Until now i created simple apps using MVC framework Django with Bootstrap frontend. Thanks framework i got everything in one package with best-practice well know. For Javascript i used some jQuery libraries without understanding, just configured with doc help.
When i tried to write some Javascript on my own and found there are big changes in JS world (like ES6, TypeScript) i found it very usefull. When i found JS frameworks, i felt in love.
I have read about frameworks, watched some tutorials. As many other, i found React nice. But what i'm completely missing, is the server part. Especially React tutorials creates components or functions, nice UI, but don't cover what happens with data next. I know that React is ment as "V" in MVC. But what is the best-practice or wide-used extension for server part? Are there tutorials or book to take me further than just creating actions and UI?
Thanks for any links, i just need to point best direction. Or is React ment for just specific project parts and better to look elsewhere?
As you said, yes there are quite a number of tutorials and most of them don't cover how do you deploy node apps on the servers. I'll assume you have some server admin knowledge so I'll skip straight to the meat of the setup.
The Server Setup
Regardless of it being a simple static page, a single page API or a react app, you will need to have Node.js installed on any server you will want it to run. Second you will need a production process manager for Node.js. My personal favourite is PM2. The process manages makes sure your app is always on and restarts it if it goes down for whatever reason. You will also need a reverse proxy server (you need this for security and SEO purposes). Again, a go-to for it is Nginx (it's a competitor of Apache)
Two very good tutorials for setting up your server are
Tut #1
Tut #2
The App Setup
Apart from all the server setup you need to handle routing for your app (what happens when you to go to /blog or /login). A stable standard right now is Express.js. You can do without but then you will need to write a lot of the manual routing by hand in Node.js You will set up Express to server back your Index file and any others you may need.
A good tutorial for configuring your Express for a React app is Video Tut.
He does show a bit more but that is on later videos. You can stop once you get the gist of it.
Advanced Stuff
There's also the matter if you want the JavaScript to be rendered on the server or on the client side. For that you will need to make some more configuration for you app. The video tutorial I linked above should show you how to set that up as well if you are interested.
Been reading up a lot on Isomorphic frameworks and curious as to whether Angular 2 can be considered "Isomorphic". It doesn't seem to be included on any lists, but that may well be because it's still very new.
I have read that Angular 2 is less tightly coupled with the DOM than AngularJS, but it does not however support server rendering. Judging from this link
https://github.com/mbujs/isomorphic-angular
Angular 2 doesn't seem to be classed as Isomorphic by default, however it looks like it is heading that way.
Very general question I know but just looking to see if anyone has any thoughts or opinions on the matter, or whether in fact it actually matters!
Thanks
It's looking to be like the creators of Angular 2 want it to be multi-platform (so, yes, server side rendering). If you browse their source code on GitHub you can see that they have a few modules for both server-side and browser-side "platforms" - a platform provides the bootstrap method to the library using Angular2, enabling it to start an application (think angular.bootstrap).
Unfortunately the server.ts is currently empty so it looks like right now, no, it is not isomorphic. It would appear that Angular2 uses an adapter pattern for connecting to the native browser API, so it's entirely possible that an adapter just needs to be written for the server side for this to work.
There's no feature tracking other than the issue that Gunter linked above, so that would be your best bet to keep tabs on the feature.
Interestingly there also appear to be source files for web workers.
Don't worry if you get lost navigating the GitHub repo, for some reason the Angular2 repo looks like it has been intentionally hard to navigate with mixtures of dart and ts everywhere
This document is old. It's planned for Angular2 to support server rendering, it might work already (don't know the current status).
See also https://github.com/angular/angular/issues/1810, https://angularu.com/VideoSession/2015sf/angular-2-server-rendering
I am going to create a big application, SAAS type.
Laravel & Angular has been decided to be used in the project. But I am new to both of these as I am cakephp background.
Now I am trying to take this decision. Whether should I keep both angular and Laravel a completely seperate projects. where Laravel is behaving purely as an API Or should I mix these both. I have seen people serving angular templates from laravel.
I'll have a mobile application for the same later, so that's another thing I have to keep in mind.
I am not sure if that's ok to ask such question here but I'll still appreciate any guidance on this here.
I would recommend separating them altogether. In this way, your projects/repos only contain one "environment" or context, which in my opinion makes everything cleaner. It also helps reusability, in that your API becomes completely app agnostic. You can of course still serve them from the same server.
Separating the components also make them easier to test in CI, because you'll only have to test one component at a time.
I'd recommend versioning the API, especially during early development, so that versions of the app can target a specific version of the API. Developing "API first" in iterations minimizes problems with compatibility between the two components as long as there are few breaking changes from the API side.