
Ask HN: Have you abandoned Next.js for another front end framework/library? - ritchiea
I&#x27;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&#x27;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.
======
CraftThatBlock
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?

~~~
ritchiea
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.

~~~
CraftThatBlock
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.

~~~
ritchiea
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.

~~~
gt2
Since you're the OP, and you were an early rails developer, I have to ask why
you are more in favor of next than rails at this point?

~~~
ritchiea
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.

~~~
AlchemistCamp
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?

~~~
ritchiea
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.

~~~
AlchemistCamp
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.

------
arkanciscan
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.

~~~
ritchiea
Which is why I am trying to get additional background on the tool before I
commit to it.

~~~
arkanciscan
Then you need to be more specific about the requirments

------
jeffbarg
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.

------
gremlinsinc
I've been looking more and more at liveviews as a better option maybe?

Laravel livewire/phoenix liveview.

Anyone know how these compare w/ nextjs/nuxtjs in terms of performance?

~~~
AlchemistCamp
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.

------
sdevonoes
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).

~~~
CraftThatBlock
I don't think you understand the usage of Next if you think it will be dead in
2 years.

Application framework that gain good popularity stay alive for very long. Look
at a lot of PHP frameworks for example.

Next will be alive in 5 years

~~~
dakiol
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)?

Next is not like Laravel.

~~~
CraftThatBlock
Laravel uses Blade for rendering, while Next uses React. They are roughly
comparable.

~~~
prawnsalad
Blade is literally part of the laravel framework, it’s not a third party thing
like react is to Next.

------
gas9S9zw3P9c
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.

[0] [https://svelte.dev/](https://svelte.dev/)

------
citrusx
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.

It's worked out very well for us.

------
jaeming
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.

------
_fat_santa
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.

~~~
ritchiea
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.

