Is a Project Built With Next.js Maintainable...? 💭

[nelsonic]

At the time of writing, this is the Next.js page on GitHub: https://github.com/vercel/next.js

Some of these stats are a positive sign including Stars (123k), Used By (3.1M) and Contributors (3,3k).

Note: I always find it interesting when a project has more users than stars ...
I've always thought of "stars" as a way of showing support for a project while keeping a bookmark of it.
So there are 30x more people using the code than there are people who bothered to star it on GitHub ... 🤦‍♂️

But the other stats are not as good

667 branches https://github.com/vercel/next.js/branches who can possibly know what they all contain?!

Every one of the active branches failing CI. Most of the CI checks pass ...
but 90+ checks tells me this project has grown out-of-hand trying to be all things to all stakeholders ...

That's a lot of actions ... https://github.com/vercel/next.js/actions

Obviously to someone who has been working on the project for a while this might all seem familiar.
But to anyone looking at this for the first time it's a bit of a head-scratcher. 🙃

https://github.com/vercel/next.js/pulls?page=21&q=is%3Apr+is%3Aopen

Languages 💭

Still 69.5% JavaScript. This reflects the fact that the project was started in JS and they probably haven't had time to port everything over to TS yet ... But there doesn't appear to be any ongoing effort to tidy this.
And the docs are still littered with examples in both JS and TS. Pick a lane.

What is the 3.9% Rust? 🦀

When we tried looking for rust-related files the GitHub search failed:
https://github.com/search?q=repo%3Avercel%2Fnext.js++language%3ARust&type=code

Perhaps one to return to later ... are they rebuilding in Rust ...? 🤷‍♂️
ref: vercel/next.js#67780

A quick glance at the issues searching for the "rust" keyword:
https://github.com/vercel/next.js/issues?q=is%3Aissue+is%3Aopen+rust

I feel like diving into this rabbit hole further is just going to consume time I don't have right now ... 🐇 🕳️ ⏳

Crucially for someone considering adopting the stack for project, we have to ask:

How Much Effort Does it Take to Maintain a Project Built With Next.js?

If there are 2744 tags and 2600+ releases for a project started in October 2016 (8 years ago); 2847 days. ⏳
2600 releases / 2847 days = 0.91 updates per day.
That's almost one update per day for 8 years and crucially a lot of breaking changes to get to v14.2.5.

Next.js appears to only have 7 dependencies:
https://www.npmjs.com/package/next?activeTab=dependencies

https://npmgraph.js.org/?q=next

But the devDependencies are 200 which is what are actually used to develop/deploy a Next.js app;
You cannot build a React Framework App without React!!

Including the devDependencies in the graph/tree it becomes illegible!
https://npmgraph.js.org/?q=next#deps=devDependencies&sizing=&zoom=h

if each one of these devDependencies has just 2 updates per year you will be flooded with dependency updates
and forced to maintain your app at least once a day!! 😕

With a security hat on this number of devDependencies gives me nightmares!!
You are relying on so many people not to be malicious.

If you build an App and have to step away from it for a few months, there's a good chance when you return to it,
there will be a breaking change that will cause you a substantial waste of time.

# Bottom Line: Great to Get Started; Nightmare to Maintain.

If you don't do anything too advanced, you might be able to get away with it.
But from experience of seeing larger projects with multiple sub-projects I wouldn't want to inherit a Next.js project.

As noted in dwyl/nextra-demo#5 (comment) Next.js and Nextra are slooooow for larger projects ...

Build time 20 seconds for a medium sized project ... 🐌 😱 #painful
Morethan 10 thousand modules compiled. 🤷‍♂️

[ianldgs]

For comparison, the dependency graph (including dev) for equivalent setups using alternative technologies:

• Next: https://npmgraph.js.org/?q=next#deps=devDependencies&sizing=&zoom=h
• Basic Vite: https://npmgraph.js.org/?q=vite%2C+%40vitejs%2Fplugin-react%2C+vite-tsconfig-paths#deps=devDependencies&zoom=h
• Remix (vite): https://npmgraph.js.org/?q=%40remix-run%2Fdev%2C+%40remix-run%2Fexpress%2C+%40remix-run%2Fnode%2C+%40remix-run%2Freact#deps=devDependencies&zoom=h
• Vue (vite): https://npmgraph.js.org/?q=vite%2C+vue%2C+vue-router#deps=devDependencies&zoom=h

Next.js has more dependencies, but offers more features. It overall looks pretty similar (all very large).

[nelsonic]

@ianldgs Yeah, I'm not comparing Next.js to other JS projects ... 💭
That's like comparing snails to slugs that comparison is easy;
the snail wins cause it has a shell! 🐌 🐚 🎉

I'm comparing to projects written in Phoenix (Elixir) orGo 💧
which have 2 orders of magnitude fewer dependencies
that don't change all the time (i.e. way more maintainable) 😍
and P99 response time measured in micro seconds. 🏎️

Nothing in JS-land comes close. 🙅‍♀️

But back to the topic of maintainability ... 💭
We need a more objective way of determining how maintainable a project is.
Because to one person - a JS fan - it might seem "perfectly fine"
whereas a polyglot might look at the number of deps and feel sick ...

JS devs suffer from Stockholm Syndrome and cannot be objective about the wider dev ecosystem.
I used to be a proponent of "JS everywhere", writing one language everywhere is so appealing!
It has become a "Hammer": https://en.wikipedia.org/wiki/Law_of_the_instrument
Many people have forgotten that there are other tools that are more suited to a particular job.
As someone who loves to learn as many tools as possible, I know JS is still a required skill.
But there are much better ways of building Web Apps than JS everywhere.

[nelsonic]

I feel like this will be taken out of context so let me clarify for the avoidance of doubt.
Any code/software can be maintained by people with the motivation to do it.
If you have 10+ people working on a codebase and one of them takes it upon themself to be the maintainer,
then the project will stay maintained for as long as they are on the team regardless of how many updates there are.
Keep that person happy and everything ticks along nicely. 👌

We've seen it when that one person leaves the team and then nobody wants to maintain the project.
And the only practical solution is to treat the codebase as "read only" and rebuilt it from scratch.
This happens way more often than anyone in the tech industry likes to admit.

[nelsonic]

Not good ... https://github.com/advisories/GHSA-gp8f-8m3g-qvj9/dependabot

High severity ...

Still no fix/PR from @dependabot ... ⏳
Never seen a High severity security report for Elixir/Phoenix ... 💭

[nelsonic]

Two CVEs the whole time we've been using Phoenix:
https://www.cvedetails.com/product/41509/Phoenixframework-Phoenix.html?vendor_id=17252

Both were fixed fast and no known cases of them being exploited.

[nelsonic]

This isn't specific to a Next.js project, but rather a GraphQL project that is consumed by a Next.js project:

Keeping this here for later. 💭

[nelsonic]

Next.js udpate breaks Nextra docs ... 😢