React and Angular are probably the most popular, competing frameworks right now. They are being used in thousands of commercial and non-commercial ...
For further actions, you may consider blocking this person and/or reporting abuse
I have worked with NextJS and Redux, Saga, etc for years. And to be honest, the future of React is never be NextJS. It should be Static Site Generator (SSG) like Gatsby instead. I can give you lots of reasone, but the most important thing is: SSG makes frontend developer totally independent to backend/server. Frontend developers nowadays don't just only need good framework, they also need good Development Experience.
Anyway, thanks for your passionate post.
A bit on a tangent here - It's funny how the technology comes full circle. Back in a day all we had was static pages (although not generated). Then we had server side pages, finally SPA and now we go back to static pages :-)
Yes agree :) but frontend development now is very interesting journey. I feel lucky when I have faced the time working with static pages from scratch, only with HTML, JS, CSS till now. That's a long but very fun adventure.
But nextjs provides SSG capabilities as well. I just think that gatsby locking you to graphql not a good thing :(
Next.JS doesn't lock you with dynamic rendering and Gatsby doesn't lock you to GraphQL (gatsbyjs.org/docs/using-gatsby-wit...).
SSG is good for 99% of the cases, in some cases you're better off with a dynamic rendering though, i.e. if your data changes a lot above the fold AND you need search indexing on that data frequently. Some notable examples are product catalogs that change a lot, like real estate. Product pages (if you have over 1000000 product pages you won't do them all in build time, some form of dynamic rendering will be needed even if on the spot snapshot rendering + caching for some time). We need to know when to use which.
Yeah correct, but Gatsby team is trying to improve for that case with gatsby cloud.
I mean...that, for me, gatsby is more opinionated than NextJS. I just think it's easier to configure NextJs than to do that with Gatsby. Now (jokes aside) both try to lock you in their cloud service. I find serverless component the best way to do it on AWS for NextJS outsite Vercel service. But that is because I lack a little bit of knowladge to set up that structure for myself :(
I see, everything has its own pros and cons. If you familiar with NextJs, just stick with it as long as it resolves problems :D
At the end we are all stating our opinions :) but it's good to see how others see :) nice talk 🙂
Nice :)
"totally independent to backend/server", could you elaborate on this? Because as I see it with SSR, React would still perform the same requests as with CSR but before sending it to the client?
I'd love to hear! 😉
Sure. NextJS need A WEB SEVER for it, usually Express. But when working with Gatsby, you totally forget about Express or any web server. A real use case is testing frontend on production. With NextJS, you still need to deploy it somewhere to test the production, but with Gatsby, you can totally test production on your server. That sounds like a true "serverless" approach. And Gatsby makes the development experience from development to deployment seamlessly.
Any feedback will be highly appreciated :)
Actually, you can use
next exportand just host your app anywhere that serves static files. See nextjs.org/docs/advanced-features/...Yes that's the new NextJS feature. But for me, it sounds like they realized that the "static file generator" should be the future, that's why they introduced it.
Most of their docs make it seem that way, recommending SSG in most use cases. I just mentioned it because you said that Next forces you to use a backend, but as long as you only use SSG you're good to host your site on e.g. GitHub Pages
Thank you for your reply. That's really a good news for NextJS fan. Let see for a while how both NextJS and SSG grow.
If you use a SSG, you don't need something like React. Because they are complete opposites of each other.
Yes but SSG I mean, a higher level of frontend development. You can choose whatever you want.
obviously scientist
The convention what is considered a framework is really blurry. I remember working in Java more then a decade ago. Everything there was a framework, including a library for making pretty URLs (not even a full routing) was considered a framework. So that's why I wrote, that people can consider it a framework or not.
Next is awesome, but I absolutely HATE that the Next Router is so tightly embedded. I know it's not the same, but it feels too much like RoR forcing Active Record on its devs. As someone who does a great deal of single codebase dev with React Native/RN Web particularly with React Router (web and native) instead of React Navigation, it makes this particularly frustrating.
Compare, for example, how easy it is to integrate React Router with Gatsby. I know, SSG vs. SSR (with optional SSG), but still.
Shout out to After.js for shaking loose from Next Router and basing on React Router instead... Now if it would just provide static site gen like Next.
Agree, the routing is quite strange. I guess I never had an issue with it, but I can understand that it can be not versatile enough for some cases.
It's not bad, it's just... Rigid.
React is very often referred to as a framework, and IMO it fits that description very well. The library-vs-framework argument is as old as software, but the best test I've ever heard (can't remember where now) is this: if you mostly call its functions, it's a library; if it mostly calls your functions, it's a framework. I would argue that React more closely fits the latter definition, while e.g. Lodash and even jQuery more closely fit the former.
I don't know of any definition that says that a framework must have view, routing, state, and auth, though I'd be interested to read about that perspective (genuinely 🙂). With that said, React does at this point have state management built in with the
useStateanduseContexthooks. It's not a particularly advanced state system, but it's there, and I've built entire fully functioning applications in React with nothing more than those. And while it's true that it doesn't ship with routing out of the box, React Router is practically a part of the family with how popular it is; and moreover I don't think a complex router like that is necessary for all projects, and the ability to plug in different routing systems should not lower the status of the thing they're plugging into. And regarding auth... That's usually a server side thing, no? Do other UI frameworks have auth as a major component? (Honest question!)@dotintegral not to crap on your post. It's great. Sincerely.
No problem at all! It's what we do here, share opinions in order to figure out the best solutions for ourselves :-)
Personally, one of the things that sold me on React was that it was a view library (though with context, that's not entirely true anymore) rather than a "throw the whole kitchen sink at everything" complete MVC framework like Angular, while still keeping me from reinventing far more wheels than vanilla JS or smaller libraries, and with corporate backing and a massive community like Angular, and tons of community bits and pieces I could add on only as needed to further avoid reinventing wheels.
I can't fault Next for being opinionated, as many of my solutions are extremely opinionated. It's just that Next's opinions get in the way of many of mine.
Next.js is definitely awesome. With the latest updates and features added it takes the cake over any option currently out there. Like you mentioned, it has its downsides but I think the great majority are positive aspects like on a 80/20 ratio.
React is a state management library, and in my opinion by far the best one.
What?
What what?
Hey, great article.
Wanted to point out that Next does support CSS-in-JS out of the box with Styled JSX: nextjs.org/blog/styling-next-with-...
Thanks! I've missed that one. I think I focused only on styled-components and JSS and forgot about Styled JSX.
Thank you for the article, very informative. I spotted a typo. Last work on the Server Side Rendering paragraph -> 'quite quckly'
Thanks!