| ▲ | solatic 5 days ago |
| Half these issues stem from a relative misunderstanding of exactly where the code is running. Next.js has layers upon layers upon layers due to the interplay between the browser, middleware, edge vs. node, SSR... It's an enormous amount of complexity and it really only fits under the following set of circumstances: * You sell a B2C product to a potentially global audience, so edge semantics actually help with latency issues
* You're willing to pay Vercel a high premium for them to host
* You have no need for background task processing (Vercel directs you to marketplace/partner services), so your architecture never pushes you to host on another provider.
Otherwise, just tread the well-trod path and stick to either a react-vite SPA or something like Rails doing ordinary SSR. |
|
| ▲ | oDot 5 days ago | parent | next [-] |
| I wouldn't say I agree with those circumstances, but even if they did indicate a match with Next.js, they are not worth the reduction in productivity and maintainability that comes with it. I use Gleam's Lustre and am not looking back. Elm's founder had a really good case study keynote that Next.js is basically the opposite of: https://www.youtube.com/watch?v=sl1UQXgtepE |
| |
| ▲ | tajd 5 days ago | parent [-] | | this is a really interesting talk - thank you for sharing! | | |
|
|
| ▲ | 9dev 5 days ago | parent | prev | next [-] |
| Vercel is the cancer of the modern web. The claw into every framework ecosystem and abuse them as sales funnels for their paid plans, pretending they care about open source, competition, and the web. |
| |
| ▲ | hirako2000 5 days ago | parent | next [-] | | Thank you for the reminder. Not used next.js in years, mental health improved significantly. | |
| ▲ | oompydoompy74 5 days ago | parent | prev [-] | | Vercel funds and sponsors many open source projects that would otherwise be struggling for funding. Their framework is tailored to the platform they build because that’s a good experience. I don’t currently use them, but people get funneled to their paid plans because it’s a good developer experience. I acknowledge that they are a capitalist enterprise with their own motives, but I think cancer of the modern web is a little strong. | | |
| ▲ | specialp 5 days ago | parent | next [-] | | People get funneled to their paid plans out of necessity. While NextJS is open source, the back-end to run it is not. That is where all the complexity lies. Even on Netlify, you run into crazy issues with things like their image stack. It does all this "Optimization" and caching that make it completely impossible to reason about and you run into implementation problems from the providers. Sure you can just run it in a container but then you are taking on all the complexity of NextJS preoptimizations without getting any of them. Serverless framework attempted to make this stack to run yourself for Next but it is buggy due to the complexity of Next. Open source includes being able to run it. Releasing the framework and funding OSS that also enhances NextJS is nice, but it is a trap because if it comes time to seriously run it, your only option is vercel. | |
| ▲ | rustystump 5 days ago | parent | prev | next [-] | | Vercel won the techfluencer space like none other. They get a bad rep largely due to the influencer crowd adjacent to them. Influencers are cancer but an almost necessary one like marketing. Annoying, obnoxious, and always trying to get your email but god damn do they get your attention. | | |
| ▲ | 9dev 5 days ago | parent [-] | | No. It’s not the influencers, they are just an irrelevant nuisance. It’s the business plan of Vercel, the venture-Capital backed company. They hire the core contributors of all major web frameworks to continue development under their roof. Suddenly, ongoing improvement of the web platform is largely dependent on the whims of Vercel investors. They pretend to cater to all hosting providers equally, but just look at Next, which will always be tailored toward Vercel. When will it happen to Nuxt? Sveltekit? Vercel is in a position to make strategic moves across the entire SSR market now. Regardless of whether they make use of that power, it’s bad enough they wield it at all. When has this ever been a good idea? When has it produced a good outcome? It never has, and it never will. | | |
| ▲ | rustystump 5 days ago | parent [-] | | If you know much about oss devs, then you know they make little money for buckets of work. Vercel is a path where they can make good money and still do some amount of oss work. I dont agree with the argument that vercel=bad because they hire people. The fact you use the term ssr market is a key point to how effective vercel’s marketing has been via techfluencers. There isnt a market for ssr in the way you use it, only web hosting. There is a world of engineering outside js framework relevancy wars. It isnt only vercel pushing the framing btw. Other players are trying to replicate the vercel marketing playbook. Use/hire techfluencers/oss devs to push frameworks/stacks on devs who then push it up the company stack. Usually it doesnt work for a startup but vercel proved it can. Enter a million lite framework wrappers around well known tech, like supabase and postgres, upstash and redis, vercel and aws. |
|
| |
| ▲ | badestrand 5 days ago | parent | prev [-] | | I agree, I don't understand the hate in this thread. And I think their paid hosting was actually really good, up until they switched their $20/month plan to a whatever-it-may-cost and we-send-you-10-cryptic-emails-about-your-usage-every-month plan. That's when they lost me, not because it got more expensive but because it became intransparent and unpredictable and annoying instead of carefree. |
|
|
|
| ▲ | vendiddy 5 days ago | parent | prev | next [-] |
| And even if you fall under the first category, I find it hard to believe that the performance bottleneck is solved by using Vercel and SSR. With all the other crazy shit people are doing (multi-megabyte bundle sizes, slow API calls with dozens of round-trips to the DB, etc) doing the basics of profiling, optimizing, simplifying seems like it'd get you much further than changing to a more complex architecture. |
|
| ▲ | ncphillips 5 days ago | parent | prev | next [-] |
| > Half these issues stem from a relative misunderstanding of exactly where the code is running. I used to think Javascript everywhere was an advantage, and this is exactly why I now think it's a bad idea. My company uses Inertia.js + Vue and it a significantly better experience. I still get all the power of modern frontend rendering but the overall architecture is so much simpler. The routing is 100% serverside and there's no need for a general API. (Note: Inertia works with React and Svelte too) We tried Nuxt at first, but it was a shit show. You end up having _two_ servers instead of one: the actual backend server, and the server for your frontend. There was so much more complexity because we needed to figure out a bunch of craziness about where the code was actually being run. Now it's dead simple. If it's PHP it's on the server. It's JS it's in the browser. Never needing to question that has been a huge boon for us. |
| |
| ▲ | jbreckmckye 5 days ago | parent | next [-] | | Notice that nearly everyone pushing edge-execution JS has some infrastructure to sell you. It's positioned as a ramp up for companies where frontend and backend devs work at loggerheads and the e-commerce / product teams need some escape hatch to build their own stateless backend functions | |
| ▲ | fragmede 5 days ago | parent | prev | next [-] | | > If it's PHP it's on the server. It's JS it's in the browser. Never needing to question that has been a huge boon for us. In what way has that been a boon? Context switching between languages, especially PHP, seems like an even bigger headache. Is it strlen($var) or var.length or mb_strlen($var)? Do you ever output JavaScript from PHP? My biggest question though is how do you avoid ever duplicating logic between js and PHP? Validation logic, especially,
but business logic leaks between the two, I've found. Doing it all in Next saves me from that particular problem. | | |
| ▲ | 1oooqooq 5 days ago | parent [-] | | spoken like a middle manager. why would anyone send JavaScript from the php? why care about duplicating a couple json translations and null checks... it's all code is today anyway. and switching languages? you can't use most of js as it is. even something as simple as split() have so many weird bugs that everyone just code from a utils lib anyway. | | |
| ▲ | fragmede 3 days ago | parent [-] | | Oh hey, insults. Those are fun. spoken like someone who's not experienced enough to realize that duplicated code needs to be kept in sync, and then when it inevitably isn't, it'll lead to incidents, and also can't write JavaScript without using leftpad. |
|
| |
| ▲ | makestuff 5 days ago | parent | prev [-] | | I am a backend dev, and I needed a website that was temporary for an event. I thought to myself this would be a good opportunity to learn some frontend development. After looking through the 20 different popular front end frameworks and getting confused by SSR, CSR, etc. I decided to use Nuxt. I thought oh this is great, Vue makes a lot of sense to me and this seems like it makes it easer to make Vue apps. I could not have been more wrong. I integrated it with Supabase + Vercel and I had so many random issues I almost scrapped the entire thing to just build it with squarespace. | | |
|
|
| ▲ | b_e_n_t_o_n 5 days ago | parent | prev | next [-] |
| Yeah this is basically it. Vercel is trying to solve for optimised performance by using a combination of React Server Components, Partial Pre-rendering, Edge servers, streaming, etc. A lot of their seemingly weird design and API decisions basically come down to that. If you need it, it's good that it exists. But you can also go pretty far with doing some ssr in an edge function too. |
| |
| ▲ | cluckindan 5 days ago | parent [-] | | I would be more inclined to believe it’s an end product of years of simultaneous resume and job security driven development. | | |
|
|
| ▲ | mvdtnz 5 days ago | parent | prev | next [-] |
| > Otherwise, just tread the well-trod path and stick to either a react-vite SPA or something like Rails doing ordinary SSR. Just write your SPA the grown up way. Write your APIs in a language and framework well suited to such work (pick your poison, Rails, Spring, whatever Microsoft is calling this year's .NET web technology). And write your front-end in Typescript. There's absolutely no reason to tightly couple your front-end and backend, despite how many Javascript developers learned the word "isomorphic" in 2015. |
| |
| ▲ | matt-p 5 days ago | parent | next [-] | | Having front-end and backend in the same language and mono repo is such an outrageous productivity booster for me. Obviously the opposite may still be true if you've got big, separate frontend and backend teams but if you just want to ship.. I wouldn't have it any other way. | | |
| ▲ | webdevladder 5 days ago | parent | next [-] | | Full-stack rich schemas, not the poor lossy JSON Schema or other language-agnostic ones, are so nice for long-term quality and development velocity. You get to categorically avoid bugs that drag teams down. Zod 4, ArkType, and Valibot are all great. | | |
| ▲ | smaudet 5 days ago | parent [-] | | This is the problem inherent in web dev I suspect. JS developers thought they reached the zenith of programming because they had a type system and could realize some gains via strong typing checks applied to what would otherwise be network calls. However, at a certain point, you're better off not writing a web app anymore, just an app with a somewhat wonky, imprecise runtime, one that lacks any sort of speed and has many drawbacks. And you lose one of the most fundamentally important parts of the web, interop. I'm sure other langs can be made to speak your particular object dialect, however the same problems that plague those other type systems will still plague yours. Which circles back to my issue, no, sticking your head in the sand and proclaiming nothing else exists, does not, in fact, make things better. | | |
| ▲ | webdevladder 5 days ago | parent [-] | | You've missed the point, it's inherent in any serialized communication, and the gains are far greater than a type system. Protobuf and friends, and every type system in existence, pale in comparison to runtime capabilities and guarantees. |
|
| |
| ▲ | happimess 5 days ago | parent | prev [-] | | You can have a monorepo with any tech stack you'd like. You can write your front-end and back-end in the same language. No shade to you for finding a productive setup, but Next.js tightly couples your front-end and back-end, no question. | | |
| ▲ | evilduck 5 days ago | parent | next [-] | | > Next.js tightly couples your front-end and back-end, no question. I'd question that statement, since it's wrong. There's no requirement to connect your NextJS server to your backend databases, you can have it only interact with your internal APIs which are the "real backends". You can have your NextJS server in a monorepo alongside your APIs which are standalone projects, and Next could exist solely to perform optimized payloads or to perform render caching (being the head of a headless CMS). It seems like a weird choice to make but you could also build almost a pure SPA have have Next only serve client components. The tightness of the coupling is entirely up to the implementor. | |
| ▲ | matt-p 5 days ago | parent | prev [-] | | I don't use next.js really any more. That's exactly what I do. |
|
| |
| ▲ | zarzavat 5 days ago | parent | prev | next [-] | | I don't agree. Having front-end and backend in the same language is so convenient I would never go back to doing it the old way. I'd rather compile the frontend to WASM than introduce a mismatch. I used to use Django and there were so many issues that arose from having to duplicate everything in JS and Python. | | |
| ▲ | turtlebits 5 days ago | parent [-] | | What about HTML? Are you writing HTML via JS - if not you're already writing multiple languages. | | |
| ▲ | zarzavat 4 days ago | parent [-] | | HTML is not a programming language. But yes, I don't write much HTML anymore. The issue with mixing languages is that they have different data models, even simple things like strings and integers are different in Python and JS, and the differences only increase the more complex the objects get. Sometimes I write some code and I realise that this code actually needs to execute on the client instead of the server (e.g. for performance) or the server instead of the client (e.g. for security). Or both. Using one language means that this is can be a relatively simple change, whereas using two different languages guarantees a painful rewrite, which can be infectious and lead to code duplication. |
|
| |
| ▲ | b_e_n_t_o_n 5 days ago | parent | prev | next [-] | | Agreed. It's a bit insane that updating a button padding redeploys your entire backend. | | |
| ▲ | matt-p 5 days ago | parent | next [-] | | Not the same problem though is it? You can have a express backend and react-vite frontend both in typescript and in a mono repo. | |
| ▲ | fragmede 5 days ago | parent | prev [-] | | Are you paying for computer time by the CPU cycle? |
| |
| ▲ | nchmy 5 days ago | parent | prev | next [-] | | or dont even write a SPA. Send hypermedia from your backend language/framework, use HTMX + Alpine or Datastar, and call it a day. | | |
| ▲ | icedchai 5 days ago | parent [-] | | I’ve been experimenting with HTMX and it feels so much simpler. |
| |
| ▲ | jakubmazanec 5 days ago | parent | prev [-] | | > There's absolutely no reason to tightly couple your front-end and backend I'll give you one reason: Gel [1] and their awesome TypeScript query builder [2]. [1] https://www.geldata.com/
[2] https://www.geldata.com/blog/designing-the-ultimate-typescri... |
|
|
| ▲ | rco8786 5 days ago | parent | prev | next [-] |
| > a relative misunderstanding of exactly where the code is running. This is the exact problem with the App Router. It makes it extremely difficult to figure out where your code is running. The Pages Router didn't have this issue. |
| |
| ▲ | robertoandred 5 days ago | parent [-] | | Does it? Just look for "use client" at the top of the file. | | |
| ▲ | rco8786 4 days ago | parent [-] | | I love this comment! "use client" does NOT mean it only renders on the client! The initial render still happens on the server. Additionally, all imports and child components inherit the "use client" directive even when it's not explicitly added in those files. So you definitely cannot just look for "use client". See what I mean now? From the docs: ``` On the server, Next.js uses React's APIs to orchestrate rendering. The rendering work is split into chunks, by individual route segments (layouts and pages): Server Components are rendered into a special data format called the React Server Component Payload (RSC Payload). Client Components and the RSC Payload are used to prerender HTML. ``` HUH? ``` On the client (first load)
Then, on the client: HTML is used to immediately show a fast non-interactive preview of the route to the user.
RSC Payload is used to reconcile the Client and Server Component trees. ``` HUH? What does it mean to reconcile the Client and Server Component trees? How does that affect how I write code or structure my app? No clue. ``` Subsequent Navigations
On subsequent navigations: The RSC Payload is prefetched and cached for instant navigation.
Client Components are rendered entirely on the client, without the server-rendered HTML. ``` Ok...something something initial page load is (kind of?) rendered on the server, then some reconciliation (?) happens, then after that it's client rendered...except it's not it actually does prefetching and caching under the hood - surprise. It's insanely hard to figure out and keep track of what is happening when, and on what machine it's actually happening on. | | |
| ▲ | robertoandred 4 days ago | parent [-] | | Correct, 'use client' means it can render in the browser, not that it only renders there. Rendering only in the browser would break SSR. If you try to use browser functionality in a component without 'use client' or to use server functionality in a client component, you'll get an error. |
|
|
|
|
| ▲ | pjmlp 5 days ago | parent | prev | next [-] |
| As mentioned somewhere else, these are the kinds of layers SSR frameworks have had for decades, maybe people should learn not to do SPAs for everything. |
|
| ▲ | marcosdumay 5 days ago | parent | prev | next [-] |
| > so edge semantics actually help with latency issues Hum... You make an entire app in node, load the UI over react, pile layers and more layers of dynamicity on top (IMO, if next.js didn't demonstrate those many layers, I wouldn't believe anybody made them work), eschew the standard CDN usage, and then want distributed execution to solve your latency issues? |
|
| ▲ | h4ck_th3_pl4n3t 5 days ago | parent | prev [-] |
| > Half these issues stem from a relative misunderstanding of exactly where the code is running. If I take a look at other languages, these kind of multi-threading issues are usually represented by providing a separate context or sync package (that handle mutexes and atomics) in the stdlib. And I guess that's what's completely missing in nodejs and browser-side JS environments: An stdlib that allows to not fall into these traps, and which is kind of enforced for a better quality of downstream packages and libraries. |
| |
| ▲ | christophilus 5 days ago | parent | next [-] | | This has nothing to do with multithreading, though? | | |
| ▲ | arnorhs 5 days ago | parent | next [-] | | Absolutely correct. Those are runtime execution context-issues. There are other frameworks that do force you do deal with those (and in other languages, probably), but I believe in next.js the difficulies are at another level - because of poor documentation and the built in abstractions to allow for running next.js both in development, node.js server, and edge. | |
| ▲ | cookiengineer 5 days ago | parent | prev [-] | | Not OP but wasn't the article about lots of async/await context issues? If the handle() method of the middleware API would have provided, say, a context.Context parameter, most of the described debugging issues would have been gone, no? | | |
| |
| ▲ | 5 days ago | parent | prev [-] | | [deleted] |
|
