Next.js Is Infuriating  ## Metadata - Author: [[The Changelog: Software Development, Open Source]] - Full Title: Next.js Is Infuriating - Category: #podcasts - URL: https://share.snipd.com/episode/c62af556-5d50-4d64-93f7-17a809e68aa7 ## Document Notes ## Highlights - **Framework Vision Causes Friction** - Dominic Mecca argues Next.js enforces a singular vision that causes repeated developer pain. - The community sees too many abstractions, limited extensibility, and Vercel-centric decisions. Transcript: Jerod Santo Next JS is infuriating. Dominic Mecca finally decided write a blog post because anger is the best motivator and he's angry at Next.js. Quote, the Next.js devs have a vision and it's either their way or the highway. Note that if it was just the middleware, I wouldn't be sitting here wasting away my weekend ranting about a React framework. Believe it or not, I've got better things to do. It's constant pain you encounter daily when working with Next.js. End quote. After ranting some more, Dominic points to the issue tracker and calls it a dumpster fire, which I looked at it too, and have a hard time disagreeing with him. Hacker news commenters had a field day with this post. The top comments, there were over 400 as I read this, vehemently agree with him. ([Time 0:00:46](https://share.snipd.com/snip/ad4f361f-320f-4cf0-be1f-fa2cdc6e277c)) - **Open Source Is Often One Person** - Josh Bressers highlights that most open-source projects are effectively single-maintainer efforts. - This reality makes pointing to a project's country of origin a weak critique of risk or trust. Transcript: Jerod Santo Open source is one person. Josh Bressers was offended by the register's recent story titled, Putin on the Code, DOD Reportedly Relies on Utility by a Russian Dev. Quote, if you're not real smart, it seems like pointing out that an open source project is written by one person in a country you don't like is a bad thing. It could be, but it also could be that the software running the whole effing planet is written by one person in a country. But we have no idea which country. It's not the same person, mind you, but it is one person. End quote. Josh goes on to point out with receipts that almost all open source is literally one person. Quote, a project exists called Ecosystems that catalogs a lot of open source. Most of it, I would guess, but not all. They currently have 11.8 million open source projects in their database. So what do we mean by one person is open source? What I mean is, if we look at the projects that Ecosystems is tracking, how many have a single person maintaining that project? It's about 7 million projects. End quote. He also looks at NPM package downloads and found that of the projects with over 1 million downloads this month, which is a proxy for usefulness, about 6,000 of them have solo maintainers, While 6,800 of them have more than one maintainer. ([Time 0:01:43](https://share.snipd.com/snip/181d5b4c-7d55-4d20-9634-e57f3b2d7426)) - **Use 'Copy As cURL' For Reproducible Requests** - Use browser DevTools' 'Copy as curl' to capture and replay exact HTTP requests for debugging. - Edit the generated curl locally to reproduce, share, and iterate on server interactions safely. Transcript: Jerod Santo In the linked article, Juan Wilson does an excellent job describing the usefulness of web browser dev tools' copy as curl functionality and how best to work with its output to get stuff Done. Quote, copy as curl gives bulky curl CLI invocation that captures almost exactly what the browser sent to the server. Explicitly including all headers, authentication information, and any request data in a directly executable way. Being executable means it can be used to easily replay the request as the browser sent it. End quote. Juan says this is great for unambiguous communication with other people and easily editing and running debugging loops because it's executable and easily modified in a shell script. ([Time 0:03:07](https://share.snipd.com/snip/9566b119-48e8-49b6-b010-da244eb52d1a)) - **Creator Changed License After Hurtful Forks** - Herman Martinus describes personal pain from forks creating competing hosted services. - He changed Bear's license to Elastic to prevent forks being offered as hosted products. Transcript: Jerod Santo Bear is now source available. Bear, a privacy-first, no-nonsense, super-fast blogging platform, was MIT-licensed until yesterday. Herman Martinus, Bear's creator, explains why he decided to change it. Quote, unfortunately, over the years, there have been cases of people forking the project in the attempt to set up a competing service. And it hurts. It hurts to see something you've worked so hard on for so long get copied and distributed with only a few hours of modification. It hurts to have poured so much love into a piece of software to End quote. He decided to adopt the Elastic license, which is almost identical to the MIT, but with the stipulation that the software cannot be provided as a hosted or managed service. Herman cites six other projects that have made a similar change in the past few years and concludes this, quote, we're entering a new age of AI powered coding. We're creating a competing product only involves typing, create a fork of this repo and change its name to something cool and deploy it to an EC2 instance. While Bayer's code is good, what makes the platform special is the people who use it and the commitment to longevity. I will ensure the platform is taken care of, even if it means backtracking on what people can do with the code itself. ([Time 0:04:59](https://share.snipd.com/snip/5671da1d-569e-45c4-a800-debd35f67561)) - **Dependency Bloat Is A Hidden Tax** - Nawaz Dhandala frames dependency bloat as a hidden, compounding productivity and security tax. - The problem reduces maintainability and slows development unless teams actively manage dependencies. Transcript: Jerod Santo Nawaz Dandala unpacks why dependency bloat is such a pervasive problem. Quote, dependency bloat has become the silent productivity drag on software projects. It's not just about the size of your node modules folder or the length of your requirements.txt. It's about the hidden costs that compound over time, making your code base harder to maintain, your applications less secure, and your development process slower and more frustrating. End quote. I like some of his advice on how to prevent dependency bloat in the first place. One, question every addition. Two, regular dependency audits. Three, embrace minimalism. Four, monitor your attack surface. And 5. Foster a culture of ownership. ([Time 0:06:26](https://share.snipd.com/snip/71eac427-0d52-4aa2-820a-7c32d78e8951))