I'm starting a new project as a technical lead. The last React app I built from scratch was as a freelancer using Next.js. Generally my experience with Next.js has been positive, but while I can still debate my options I'm wondering if anyone has run into problems that caused you to move away from Next.js? And if so can you please tell me about them.
Next has been improving very much recently, and would definitely be my number one choice for the vast majority of React projects. What is making you look for other solutions?
Mostly to double check my assumptions and try to dig around and see if there is a downside to Next I'm blind to. Or any gotchas or problems that arise that I wouldn't expect a year or two into the project. Maybe excessive due diligence?
But I'd rather ask around while I have the chance before committing a ton of code.
With large community support and coperate backing, I think Next is well setup for the long term (5-10 years). I can't think of any direct downsides, however Next does "force" you in a way of writing application, which I personally think is a good thing, since it provides standardization and structure to projects (for example, routing).
Next can still be very flexible, with things like catch-all routes, you could even add another router on top of Next. It also supports customizing the Webpack configuration if needed, but there's plugins for almost all cases that I have needed to use (PWA/service worker, CSS/Sass which is now built-in, etc).
I think Next is one of the safer option for new projects.
> I think Next is well setup for the long term (5-10 years).
No way. Take as an example one of the most used JS libraries in history (jQuery): released in 2006, and it has been already 4 years or so that it's been slowly substituted by React/Vue/Angular. So, jQuery has had around 10 years of solid development and usage. Saying that Next.js will have between 5 and 10 years of live, it's not realistic (perhaps React will, but Next is going to be dead in 2 years when yet another framework appears that is better/faster/smaller/more featured).
> Next can still be very flexible, with things like catch-all routes, you could even add another router on top of Next.
I don't think this is the case? We were looking to add React Router (to add client side routing). And the only way that seemed achievable was by hacking around (https://dev.to/toomuchdesign/next-js-react-router-2kl8)
Thanks for your thoughts. I'm also a fan of opinionated frameworks. I was an early Rails developer and over years of freelancing seeing both framework codebases and micro-framework or from-scratch codebases I believe frameworks make decisions for you that are unimportant to your work in 80-90% of use cases.
I live in Berlin now and Ruby isn't very popular here. It's much more difficult to find Ruby/Rails developers than React developers. The tech industry here is growing but still in its infancy, there aren't a glut of devs who started working with Rails when it was a hot new thing that have an appreciation for it. Javascript and Python are very popular, Ruby not so much.
A lot of my friends in SF tend to pick up a new language every year or two. Is this type comparatively rare in Berlin or are people just digging into a long list of other languages first?
From the jobs I see Javascript, Python, Java & iOS are pretty much the entire market so there isn’t a lot of opportunity to actually work with other langs and get paid for it.
Pretty much every language I've learned, I've learned on my own and only possibly later gotten paid for using.
For example, I picked up Elixir (which I currently make money using) by rewriting a Rails app into Phoenix four years ago. That app never made me any money, but it did provide a great motivation for learning Elixir!
Similarly, I'm learning Rust now. I'm going through books and videos, building toy projects and slowly picking it up. I've never been paid to write Rust, but that will likely change in the future.
Other languages, like Racket and 8088 assembly I've never been paid to write and likely never will but I don't regret exploring them a bit.
Never choose a tool before you've seen the job. If you need the things Next does, use it. If you don't, don't use it. Just dragging whichever tools you've recently used into your next project is how some of the worst projects I've seen got built. There are many valid solutions to any problem in web dev, and they ALL have tradeoffs.
Some may consider velocity to be part of the problem's domain considerations while others may not. If you consider that part, then Next is a great choice if you are novicely advanced at frontend web.
It does come with a lot of preoptimizations that may not be necessary for the job (as the job is currently defined), but the thoughtful way they're implemented makes having them in there anyway not all that costly. The directory based build stuff that auto code splits, does SSR, and static site generation is high value with a very low learning curve. Not only does it not require a lot of load on the meat to use the bazooka of Next for an anthill of a problem, but it also doesn't really add any load on the metal. And the fact that these features do a great job of covering your ass should business demands pivot under you makes Next a rare kind of contender.
It's a bad choice if all you need is some small piece of an already-existent architecture, but if you need something as the main frontend body for a long-lived app, I've found Next to be the best thing I've ever used by a significant amount.
Very few downsides to Next.js generally. I’d say for smaller projects I really love leveraging Gatsby’s plugin system (specifically the image transforms), but it’s not as useful for anything dynamic where Next.js comes out ahead.
If you're doing a lot of computation that's entirely on the client-side, you'll at least want to look at JS hooks.
However, if you're doing things that require a trip to the server anyway, such as navigation, form validations, etc, you should get significantly better performance with LiveView. Sending tiny diffs over web sockets is a lot lighter than doing JSON requests.
Why put another layer of complexity (and dependencies) on top of a solid and battle-tested library like React? Chances are that Next.js will be obsolete in 1-2 years while React will be even better and maintained (probably React will die in 5 to 10 years, just like any other lib/framework).
How can you compare a PHP framework like Laravel (that sits on top of a language) with a framework (Next) that sits on top of a library (React) that sits on top of a language (JS)?
I have 98% confidence Next will be alive in 2 years. In five years if this company's biggest technical problem is needing to refactor an older front end framework then I have absolutely succeeded in my job building version 1.0.
I generally like next.js, but I have since built some things in Svelte [0] and prefer it for simple projects. Not dealing with JSX and complex React components is refreshing. It just works. There are some upsides to its static generation (with sapper) as well - it can create static pages for things that would need API routes in Next.
TLDR; For large projects that must make use of the React ecosystem I'd take Next. For smaller SPA projects I prefer svelte.
We chose to roll our own SSR, in an otherwise "normal" react + apollo app. This meant that, if we ran into bugs, that we weren't reliant on someone else to update an ecosystem to get unblocked.
I set up a react project recently using parcel, typescript, reach-router, and emotion css. I was surprised how easy and painless it was. In saying that, Next provides good value to a team with it's conventions and workflow.
I would take a look at Gatsby. NextJS has had some major updates recently so It would be good to give it another look as well. I personally switched from Next to Gatsby and the main reason is Gatsby's GraphQL API which is fantastic.
Interesting. Having worked with both Gatsby and Next I definitely prefer Next. But also this web app is going to need a lot of dynamic content so I would not choose a static site generator like Gatsby for the use case.
