5 ms·
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 be
by solatic 1y 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.
- vendiddy 1y agoAnd 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.
- b_e_n_t_o_n 1y agoYeah 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 1y agoI would be more inclined to believe it’s an end product of years of simultaneous resume and job security driven development.
- boppo1 1y agoLIRPslop, as Brad Troemel would put it.
- pjmlp 1y agoAs 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.
- oDot 1y agoI 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 https://www.youtube.com/watch?v=sl1UQXgtepE
- mvdtnz 1y ago> 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.
- b_e_n_t_o_n 1y agoAgreed. It's a bit insane that updating a button padding redeploys your entire backend.
- zarzavat 1y agoI 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 1y agoWhat about HTML? Are you writing HTML via JS - if not you're already writing multiple languages.
- 1y ago
- h4ck_th3_pl4n3t 1y ago> 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.
- deleted 1y ago[deleted]
- christophilus 1y agoThis has nothing to do with multithreading, though?
- cookiengineer 1y agoNot 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?
- h4ck_th3_pl4n3t 1y agoYes, that's what I meant
- arnorhs 1y agoAbsolutely 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.
- ncphillips 1y ago> 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.
- zero_shift 1y agoNotice 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
- makestuff 1y agoI 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.
- danielroe 1y agowould love to know what kinds of issues you encountered
- fragmede 1y ago
- 9dev 1y agoVercel 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 1y agoThank you for the reminder. Not used next.js in years, mental health improved significantly.
- oompydoompy74 1y agoVercel 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.
- badestrand 1y agoI 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.
- rustystump 1y agoVercel 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 1y agoNo. 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.
- rco8786 1y ago> 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 1y agoDoes it? Just look for "use client" at the top of the file.
- rco8786 1y agoI 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 1y agoCorrect, '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.
- marcosdumay 1y ago> 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?