[flimsypremise]

My sense of Vercel (mostly from working with NextJS) is that they are more interested in appearing to support an open source framework while making their product as difficult to interoperate with other technologies as possible in an attempt to lock users into their platform and hopefully pay for it.

[leerob]

Hey, I'm on the team at Vercel. What could we do better? Open to your feedback. Our platform integrates with 30+ frameworks (https://vercel.com/docs/frameworks), we directly fund the development of Next.js and Svelte, and we sponsor Nuxt, Astro, Solid, and more.

[illiarian]

> Hey, I'm on the team at Vercel. What could we do better? Open to your feedback.

You recently broke Next.js with AsyncLocalStorage by putting it in globalThis and breaking any runtime that's not Vercel's. With no specification, and other runtimes scrambled to reverse engineer your implementation: https://twitter.com/ascorbic/status/1616811724224471043 and https://twitter.com/lcasdev/status/1616826809328304129

[flimsypremise]

I'd say one of the big annoyances I've encountered while building applications with the last few versions of NextJS is the increasingly tight integration with the built-in server. The world of Node servers is pretty well-established, with documented interfaces that the major server platforms all implement and support. Simple stuff like res and req in the context and what those objects contain. With each release NextJS breaks a bit more of those interfaces and replaces them with approaches that are very specific to NextJS and pretty unintuitive to anyone who is used to building servers in Node. I'm talking about stuff like handling response codes (the notFound parameter you need to return to get a 404 from getServerSideProps is a particularly egregious example) or redirects. You are presented with what looks like a standard interface, but doesn't fundamentally actually work anything that interface.

Decades of working in this industry have taught me to value interoperability, modularity and standardization. I love the idea of a framework that makes SSR easy, and the idea of static site generation, and a router that uses the pages approach where each file is a route is handy in some cases (though very clumsy in others), but all of those a different things and aren't really something I need a single monolithic framework for. I may want one or some or none of those things based on what project I'm working on. If NextJS makes it harder to pick and choose what I want to use, or makes some features contingent on using other features I don't really care about, I'm going to start looking really hard for an option that gives me more choices.

[brillout]

Seems like you may appreciate https://vite-plugin-ssr.com/ (I'm its author).

[hexidectom]

I love vite-plugin-ssr. Thanks for making it.

[aarpmcgee]

Nice. I was going to use Next for my current project, but may give your solution a try instead!

[huksley]

Hi leerob, I am using NextJS from v.10 in production, and I believe it is amazingly effective way to write complex web applications really fast.

Recently (I would say, after the latest investment round), I as a developer see lots of new features implemented seems rushed, not complete or having no thought about community as a whole.

- API Middlewares are not working as expected [1]

- The new pages layout (i.e. app/) are super-weird, implemented in a completely different way from pages/ with 2 incompatible API sets - one for pages/ (i presume soon to be declared legacy and unmaintained, and shiny new but still experimental?)

- Images API just as others pointed, are beneficial to some tiny subset of developers who have bunch of static images locally. But for most projects it is not useful at all at the current implementation.

- Your release versioning does not make sense for a mature stable product. When you release new major version (e.g. v.13) you stop supporting older v.12 version.

- Could you give balazsorban44 bigger team? Next-Auth needs more love to be a great product.

- [1] https://github.com/vercel/next.js/issues/38273

[scrollaway]

If you want to call yourself open, you can start by making the development more open. Right now it’s almost all behind closed doors until it hits a PR, and once in a while the Vercel gods are feeling generous enough to share some slightly early plans in a discussion somewhere.

Simply “here’s what we have in mind for next release”. An open framework should not be developed like you folks do it. Look at how Python or Django develop their releases for better examples.

You have RFCs, but most of them are internal and don’t reach the public space. Why?

AppDir is a good example. Yeah you have an extremely high level table of what’s planned vs in progress but there’s nowhere public where these discussions are being held. We’re not able to see nor contribute to the decisions. We’re not able to chime in when bad decisions are obviously being taken. Some companies view this as an asset because they want the power to silently take decisions that are good for them but bad for their users.

[3np]

A more sane release lifecycle and release communication.

When a major version bump with a host of breaking changes drops, we'd prefer to be able to stay on the superseded version and still receive bug fixes for at least some time, with expectations set for what that timeline looks like.

The last releases of v11 (v11.1.1~v11.1.4) lack release information/changelog, and the CI still looks failing for Mac and Windows on v11.1.4 without this being acknowledged.

The final release of v12 was 1 month after v13.0.0. The last few releases of v12 similarly lack release info or changelog. You could say "just look at the git history" but the Nextjs git log really doesn't lend itself well for it (unless you're already a dev on the Nextjs codebase or used to code-auditing, I guess).

For a "foundational" (that's what you aim for it to be, right?) software like Next.js, users should be able to have similar expectations to versioning, releasing, and documentation as Vercel is relying on for Nodejs.

Younger devs follow what the leaders in the ecosystem do, which is how trends and norms rise and change. If Vercel changed its approach here it could contribute to setting a good example instead of showing that maintenance as an afterthought is nbd bro, why don't you update already!

[re-thc]

Too many bugs. Too many features rushed out the door. Every major AND minor version of NextJs has new features and/or breaking changes, which is fine on its own but existing stuff often also break.

We go through a cycle of: new feature -> patch fix -> minor fix -> improvement -> finally works -> replaced by something else OR it broke again.

For something like NextJs that has been running for years maybe more focus on polishing the existing features would be a good start.

[mingw__]

The Vercel way is to say "those aren't breaking changes, they're just bugs".

[benjaminwootton]

I was and am a big fan of Vercel but I hated that billing situation a few days ago. You shouldn’t need your post to blow up on social media for support to acknowledge a billing error.

[tipiirai]

You should offer better customer support as repeated in many comments here.

[getcrunk]

And you should fix the stupid net js img bs refrenced in other comments too

[steve_taylor]

Don’t charge a metric fuckton for bandwidth.

[cobertos]

It doesn't help that the main Vercel GitHub repo isn't really any core part of Vercel. It's just the cli and ancillary scripts. None of their infrastructure is open source or self-hostable, which was a surprise after finding the repo and trying to dig through it

[eezing]

No vendor lock-in here. Been running NextJS on GCP Cloud Run for years and each major release has become more Docker friendly. Just my experience.

[athammer]

They’ve helped other UI frameworks run on Vercel. They seem to be very good about that or do you mean something else?

[steve_taylor]

They've "helped" frontend developers of other UI frameworks pay them $400/TB for bandwidth, not to mention various other extortionate overages and hidden charges.