10 ms·

It's not just you, Next.js is getting harder to use

146 points by carlual 2y ago

carlual 2y ago
It feels like the entire JavaScript world seems overly influenced by e-commerce, pushing all kinds of optimization, even including RSC and SSR. As a former SaaS builder, I deeply resonate with the author's point: "I care way more about the speed at which I ship features, and all that complexity becomes a burden on my dev team." This is exactly why I started building ZenStack(https://zenstack.dev https://zenstack.dev) toolkit. The goal is to brings simplicity back to building SaaS applications, using whatever framework you like.
- beretguy 2y ago
  Ah! Another js framework that will fix problems of all the previous ones… great…
  - 000ooo000 2y ago
    Relax. No-one is taking your precious jQuery from you.
    - rc_mob 2y ago
      phew! perfect
    - jampekka 2y ago
      jQuery isn't a framework. As a library it's still precious.
      - 000ooo000 2y ago
        I don't think that distinction is key to the insinuation
        jampekka 2y ago
        I got the tribal insinuation.
    - beretguy 2y ago
      No, I write my hobby websites to work without JavaScript.
  - zelphirkalt 2y ago
    I mean, the potential always exist, but I would rather avoid much JS at all and only use a minimal amount of it, which is usually not what JS frameworks intend to let you do.
    - beretguy 2y ago
      That’s what I do. I write my hobby websites to be functional without any JavaScript.
  - zer00eyz 2y ago
    How dare you look down your nose at the techonolgical magpies. They do love to collect shiny things!
- Tade0 2y ago
  That's just the React world which, granted, is the majority of the JavaScript world. Over here in Angular land not much has been happening. Ok, we have signals now, but that's about it. If you want simplicity, use htmx and your backend framework of choice.
  - lenkite 2y ago
    I dunno why HN likes to hate on angular. Its an amazing, batteries-included framework where you don't have analysis-paralysis from 100 different choices, easy to pick-up and learn, CONSISTENT, quite performant and doesn't break your build from year to year. (or month to month like some other HN-loved frameworks) React terrifies me. Nothing is consistent. Everything is always a little broken and maintenance is painful. This has been my anecdotal experience doing maintenance work on 3 diff React projects. Framework of current project uses Vue and Vuetify - and its been a very pleasant experience. It was the easiest framework to pick up and get going amongst the three. (Though Angular is still the most stolidly consistent framework)
  - graypegg 2y ago
    I was building a big monolith angular (v8 at the time) app a few years ago and I think my old coworkers from that job would get a laugh from hearing me reminisce about it! Angular is actually very nicely laid out as a front end framework. I’m finding the modern react ecosystem more obtuse than old angular apps.
  - spoiler 2y ago
    My 2c on the whole React and complexity situation: it's not great, but at the same time it's not as bad as someone people make it sound. Things _can_ be done in a simple way. The issue with React is that it's just a library, and there's some gaps it leaves that companies like Vercel tried to fill (and abused, but that's another topic). So then you get a bunch of new-ish developers who haven't even properly learned react throwing in a bunch of random libraries they also don't fully understand how to use, and you end up with a shit soup. Not because the ingredients are bad, but simply because the cook didn't know how to use them. I've seen people abuse React. I've seen people abuse Redux (and extensions). Even with there being ample resources for both. People want to try to be creative withou planning ahead, and then things happen and the business wants to go on, but devs are rarely given time to integrate and apply stuff they learned from previous mistakes, etc. So while some of the problems are technological in nature, I think the biggest problem is not the technology itself, but how it's combined with inexperienced developers With that said, I'm also a big fan of designing APIs that are easy to use, and difficult to misuse. React has areas of the API which fail on both of those principles though (I hink some of which they want to address with the React Compiler)
- jampekka 2y ago
  Some feedback on the page: I found the intro blurb[1] a bit off-putting with all the corporatese. Namely "supercharging to unlock potential" gives an instant BS vibe. Don't know how it looks like for other audiences, but I'd guess e.g. HN audience on average do not like it. Just use the space to say what it actually is and does? It's definitely not the worst offender, and that's probably why I wanted to give the feedback. [1] "A TypeScript toolkit that supercharges Prisma ORM with a fine-grained Authorization layer, auto-generated type-safe APIs/hooks to unlock its full potential for full-stack development."
  - carlual 2y ago
    Thank you for the kind and thoughtful feedback! The change has been made.
    - jampekka 2y ago
      Very good now, thanks!
cranberryturkey 2y ago
Checkout primatejs if you're tired of all the nonsense.
- lambdaba 2y ago
  Why is it great?
  - cranberryturkey 2y ago
    It lets you use any ui framework you want
    - moritzwarhier 2y ago
      Then what does it do? Is it similar to Vike.dev?
      - cranberryturkey 2y ago
        It allows you to use vue, react, svelte, angular, htmx, solid, etc....and for the backend you can use Go, python, bun/node/deno and/or typescript. We're also releasing a new version soon that will allow for native desktop apps (ie: Tauri)
- bryanrasmussen 2y ago
  well.. sounds nice but some things make me worried: 1. "Use the comfort of one runtime during development and the speed gains of another in production." how is that possible without hitting all sorts of backwards/forwards compatibility issues. 2. The react example you give on the front page does not seem very react-like. - that said "Write backend code in your language of choice, leveraging the power of Wasm. Mix routes of different backend languages, allowing your application to be written by different teams." sounds like something that you might think who the hell needs that, but I've worked on a few teams, and am on one now that could perhaps benefit from it. instead what happens now is there is a JS api that sends requests forwards to the actual backend - maybe doing some minimal verification etc. so doubling work - not all places but certain api end points where we don't want to reveal secrets in frontend etc.
highcenburg 2y ago
Finally, this helped my decision whether to use Nextjs or Reactjs in my projects.
pjmlp 2y ago
As long as it keeps being the closest to Spring and ASP.NET on node land, I am ok with where it is going.
- stepbeek 2y ago
  I would have thought https://adonisjs.com/ https://adonisjs.com/ was the equivalent? I've not used next.js for a few years but it doesn't seem to have an answer for anything on the back-end except rendering. That only covers a tiny part of what frameworks like Spring or ASP.NET offer.
  - pjmlp 2y ago
    You use API routes for the backend stuff, the typical controllers, what is now known as Backend For Frontend in marketing speak.
- alexhutcheson 2y ago
  What makes it the closest to Spring and ASP.NET?
  - pjmlp 2y ago
    The mix of React components that can also be rendered server side (JSP tag libraries, Razor View Components), middleware (servlets, middleware), API routes (controllers).
rickcarlino 2y ago
I’m curious about alternatives that offer good file-based routing support. Has anyone seen any good alternatives?
- zelphirkalt 2y ago
  Quite easy to implement oneself, I would say.
  - molebury1 2y ago
    [flagged]
    - officialchicken 2y ago
      Yes, that's the idea, dudebro! When the market does not meet your needs - you meet the market.
  - ivanjermakov 2y ago
    Literally. My experience with routing tools is that it's often easier to implement it from scratch perfectly suited for your use case instead of integrating existing general solution.
- Zealotux 2y ago
  Remix is better in every aspect.
  - Aeolun 2y ago
    I really don’t like how remix stuffs their philosophy down your throat. Old next at least was more free form.
    - Zealotux 2y ago
      If you agree with Remix's philosophy (and after years of front-end development, I would say I do), it's heaven. New Next is now as opinionated and much worse, in my opinion.
joeatwork 2y ago
Software tools backed by businesses that target enterprises have very strong pressures towards obscurity, complexity, and generally optimizing for institutional goals and away from development experience and effectiveness. As tools that get developer adoption move up market they get worse and worse for the folks building with them.
- szundi 2y ago
  I wonder wether it is possible to keep on the right (dev) track? One could argue that when becomes shit, sooner or later it is going to be abandoned at the end
- smolder 2y ago
  This is a good reminder of how thankful we should be for the many contributors to Free software.
- jampekka 2y ago
  Here we also have the ensittification on top, as Vercel starts to squeeze out platform profits.
sarreph 2y ago
All this negative sentiment around the App Router like in this post made me really scared to adopt it. I've just been working with it for the past 2 months and absolutely love it. The biggest reason being the ability call functions directly from server- or client-side code! You basically only need to write API endpoints now for externally-facing services. Saves so much time and boilerplate... Yes it is more complex than Pages Router. And while I'm a staunch advocate for simplicity where possible, I do think the tradeoff is worth it for new projects. It just takes a bit getting used to. The negativity feels a bit like hooks all over again tbh...
NayamAmarshe 2y ago
When I first discovered Next.js, it was like finding a gold-mine. I no longer had to use an express server and couple that with React and manage all the crazy configs. Next.js was so simple, everything just worked! The docs were absolutely amazing, dev server was super fast, the build times were fast, I could easily create server side and static sites, host them on Vercel easily, good times all around. Then came the Vercel + React partnership and it took things in a different direction. Now React almost became a child of Vercel. All of a sudden, the focus instantly shifted to server side from what was earlier client side & server side both. Breaking changes, added complexity and the strange co-existence of 2 routers, out of which the old one (which works perfectly fine btw) is certainly set to become obsolete in the near future leaving us with no choice but to move to this 'new' router. Next.js app router is extremely slow. You don't even need to do anything special, just compare the dev server compile times of Next.js v12 vs v14, the performance has decreased. The dev server sometimes occupies gigabytes of memory, why? Can I also mention the 'new' but worse file-based routing system that forces every page to be named page.tsx? Who thought that was a good idea? They simply copied Sveltekit. This even forced the VSCode team to introduce a way to edit the tab names because every page being called page.tsx is undoubtedly worse DX! All good things come to an end, and I certainly feel this way now with Next.js. I was a proponent, I recommended it to everybody who was looking to build apps with React but now? I'm not so sure anymore, considering how confused they are about their own decisions (refer to the v14's caching controversy). I'll be jumping ship to a better product as soon as I find one (and I'm sure there will be in the future). For now, I'm just sticking because of the years of familiarity with React.js and Next.js. They have served me well but Next.js has simply become Outdated.js as far as the future is concerned.
- _andrei_ 2y ago
  Been working with React for the past 9 years and I hate what Vercel's influence has done to it. I hate what they've done to Next as well, but at least that one is theirs.
  - mococa 2y ago
    I have the same feeling, Vercel is destroying React.
ThalesX 2y ago
I used Next.JS awhile ago and it was great. Then I switched to Remix and it was great. Then I went back to Next.JS and I couldn't understand where things went wrong. From the routing model to the deployment model, it all felt so broken that I couldn't convince myself to continue using it.
- fullstackchris 2y ago
  Would you currently recommend Remix over Next.JS? I just started a Next.JS project (trying it as a long time Gatsby user) but am worried about what I am reading here.
  - NayamAmarshe 2y ago
    Moving from Gatsby to Next's pages router is definitely an upgrade. Pages router is awesome and easy to understand.
  - etimberg 2y ago
    I would; it's a lot easier to use and reason about. that being said, it feels like we've come full circle back to the early 00s with form posts for submitting changes rather than fetch/xhr
  - ThalesX 2y ago
    I've had a rough transition from Remix 1 to Remix 2 for a couple of web apps I've worked on, but overall I still feel like the Remix model just works better. That being said, I'm probably not the best person to make a recommendation in this sense as I'm looking to go back to a sane job working with .NET MVC or PHP Laravel and just a bit of dynamic frontend sprinkled on top.
  - satvikpendem 2y ago
    It's by the makers of React Router, who've refactored their codebase 6 different times with breaking changes each time, causing a lot of pain for those who used it and wanted to upgrade. That is the main thing that causes me to not want to use Remix these days.
ulrischa 2y ago
I would like to see a fullstack framework like next for Webcomponents. And one thing is missing for all fullstack frameworks: A CMS. Astro and next is very good but I can not offer markdown or jsx for a client
- terrablue 2y ago
  Primate gets close to that -- there is a webc handler with props support: https://primatejs.com/modules/web-components https://primatejs.com/modules/web-components The webc handler does lack a few things like hydration, and this can be added if users show interest in it.
afloatboat 2y ago
We just turned back from Nextjs after a 4 month trial for a new application. Some issues we ran into: - The dev environment is too finicky. Full page reloads instead of HMR and random errors after x reloads. - Cache is a black hole and works differently between dev and production. They’re changing things up now with v15, but this lack of stability is not fun to rely on. - The file based router has its limitations. For instance: having the language in the URL means your entire tree remounts when the language is changed. - No clear way to bootstrap specific stuff outside of React - Portals don’t seem to work on the server. - very easy to mess up auth stuff. At some point Supabase even put out a YT video [0] where their implementation caused auth to be accidentally cached. There are 3 levels of checks you need to do just to be safe, but this is all very opaque. For me it also wasn’t clear how to combine client and server state. These patterns haven’t been defined yet and I kept running into hydration issues with no clear solution. A year after the app router the eco system still feels very much in limbo and brittle. I also worked with Next as a replacement for Gatsby’s SSR, but quickly discovered that there’s no easy way for Next to just pre generate all responsive image sizes it needs for a static output like Gatsby has. You need to implement a custom loader and rely on something like cloudinary. This is ridiculous for a completely static site. [0] https://youtu.be/v6UvgfSIjQ0 https://youtu.be/v6UvgfSIjQ0
- oslonoway 2y ago
  What do you use instead?
- sandreas 2y ago
  Try hono.js ;) https://hono.dev/ https://hono.dev/
  - hamasho 2y ago
    Yet another JS framework, and it looks great. I've only skimmed the doc, but I already like its simplicity. But I have a mixed opinion on the big Context object. It may help to write less verbose code, but it can also cause OOP's antipattern God Object[1], even though the context is more of a namespace rather than a big object. // Not app.get('/hello', (c) => { return c.json({ greet: `Hello ${c.req.params('id')}`) // But import { jsonResponse } from 'library' app.get('/hello', (req) => { return jsonResponse({ greet: `Hello ${req.params('id')}`) [1] https://www.wikiwand.com/en/God_object https://www.wikiwand.com/en/God_object Fix: format
spoiler 2y ago
I'll never get over how convoluted it felt to make a modal appear on the screen, using the "blessed" Next.js way. You need parallel routes, slots, intercepting routes, file names that look like the blast radius of a shell script gone wrong with names containing (..)s, [slugs], and @slots, and special-purpose file names like page.ts, index.ts, default.ts, some stuff auto-magically passed in as props. It's like they're trying to take ideas from something like Rails without having ever even used Rails, and then pervert those ideas. I know I sound overly critical perhaps, and maybe I'm being too harsh, but it just feels like there's this bizarre appreciation or worship of arcane complexity by Next devs. And any simplicity and straightforward-ness is shunned and frowned upon. Like simplicity is somehow beneath them, and simplicity is only for stupid plebs like myself. I haven't used Remix, but their docs suggest it's simpler.
pictur 2y ago
next js is one of those projects that unintentionally makes things complicated on purpose. Everything is going very well up to a certain point. but at some point you find yourself in a server <-> props hell.
- bryanrasmussen 2y ago
  how does one unintentionally make things complicated on purpose? Next.Js made things complicated unintentionally because they thought that a folder based mapping of routes was good and would evidently scale to their customer base's needs. Then they were so far in that was one of the things they couldn't undo. Oops.
PUSH_AX 2y ago
I started a project with next about 2.5 years ago. That version is pretty good, easy to reason about. A year or so back I spun up a new next project only to be greeted with very unintuitive errors regarding trying to use client libraries in server pages? Something like that. I wondered if I was going crazy or if this was actually going in a terrible direction.
- jddj 2y ago
  I haven't touched Next, but the discussions and issues of some things I do use seem littered with people thinking they're on the client when they're on the server and vice versa. Someone upthread said there were some common Auth footguns and I'm not surprised at all. Maybe the warnings are to try to mitigate that.
- lioeters 2y ago
  I have a couple of fairly large Next.js projects, started a few years ago. One of them I was able successfully upgrade to the latest major version of Next, after going through a number of errors, deprecations, and studying the documentation. There are so many little details and rules to remember now, just like React. It's an accumulation of seemingly user-hostile design decisions for not much apparent benefit from the user's perspective. The second project is stuck with a cryptic error that prevents the production build step from completing, and after searching through GitHub issues and even going into the Next.js codebase, I'm unable to fix it. At this point, I've given up on the upgrade and searching for a different framework to rebuild the app on. It's hundreds of pages, many of them generated by dynamic URL routes, so I'm not looking forward to it. It's a huge effort just to get the application to work exactly as it did before. The upgrade experience has soured me on Next.js, I wouldn't start a new project with it. Even React I'm getting doubtful of its recent direction, and eyeing other view libraries that achieve the simplicity it used to have.
aosaigh 2y ago
I'm still using the pages router due to complexity of the app router. At this point, I think that I'll move to another framework instead of moving to the app router. They completely botched the transition from pages to app router and even now, literally years later, there are still simple things you can't do with the app router. It's also just hugely confusing defaulting to server components. It's a shame because in the beginning, Next.js was a breath of fresh air.
renegade-otter 2y ago
My observation as a [mostly] backend dev is that the JS world in general is fascinated with building complexity and then using more complexity to address the previous complexity. Transpilers, converters, tree-shakers, oh my. It's 2024 - building a web app should not be rocket science or require such obscene tool chains. Unrelated, but I've been trying to finish a project of mine, and after long breaks I would discover that my front-end code was out of date. There was already a better framework, or a new version, making your old code obsolete. I gave up after Vue 3 introduced composition API - all I did was learn "the new ways" without actually building anything. Then I switched to HTMX and ditched all that bullshit.
- Zanfa 2y ago
  My pet theory is that due to zero interest rate policy, too many startups were able to raise too much money and so they hired too many engineers that didn’t have anything really productive to do for years. So they kept reinventing wheels for a decade plus, each iteration more complex than the previous one.
  - renegade-otter 2y ago
    This is what I believe, and it's one of the bigger points I made when I wrote Death By a Thousand Microservices: https://renegadeotter.com/2023/09/10/death-by-a-thousand-microservices.html https://renegadeotter.com/2023/09/10/death-by-a-thousand-mic... It's related, I think. In a truly lean business environment, people would not have so much time mucking around with these frameworks. It actually looks like developers come up with zingy library and framework names and THEN they actually write them.
- Quothling 2y ago
  HTMX with GoLang is such a relief compared to working with anything else in web-related apps. We're still doing a monorepo with NextJs some NX (which is frankly also rather unnecessary since everything it does can be done fairly simply with pnpm workspaces and vite), a complicated storybook setup and 9 billion libraries for components, utilities and what not. We're also still trundling along with C# even though it's 2024 and functions should be capable of living outside of classes in any language... Naturally build on "clean architecture" and "solid" which makes the entire code base a ginormous mess of unnecessary abstractions where a simple helper which does one single thing and is never re-implemented lives in 9 billion files in several different csproj's because it "might" need to be abstracted one day (it won't). It takes me longer to figure out where things are in those projects than it does to develop an entire internal service with HTMX and Go... Which despite being a huge success for everyone, and hailed by the business itself has made no impact on our future plans. We can sit in a meeting where everyone has achieved something marvelous with HTMX and Go and still decide to keep using NextJS and C#. It's silly, but I've never really worked for a company where it wasn't this stupid and at least we're not so trapped by ourselves that we can't build things with "non strategic" tools.
eknkc 2y ago
I think it makes a lot of sense for Vercel to push RSC and all the complexity of new Next. - They sell compute / bandwidth. You can not make a lot of money if people are building SPAs that load from a CDN and execute on client. - SSR kind of gives them some server compute but as soon as the initial page is loaded, we are back to point 1. - Here comes RSC then. And they pushed hard. Made it look like the best thing ever. Oh the initial load time is the most important metric. You gotta make sure you hit this score on whatever benchmark thing… - They also kind of acquired React. It is basically Vercel’s now so they can dictate the development direction. - All this with almost no benefit to developers (compared to something like pre app dir next) but likely helps them a lot in terms of revenue. I mean this might read like “vercel evil” post but it is what corps do and they seem to do it well. I used next on a project recently and will not touch it again because the hype did not materialize as any type of gains during our own development.
martinald 2y ago
I've done an enormous amount of web performance analysis work, and as soon as I see the nextjs bundle come down in the network tools I know there will be issues. It just seems exceptionally slow to another stack I've seen. Whether this is poor docs or bad implementations, I'm not entirely sure, but it seems there is a major issue with it - I do not see in my analysis any other stack having anywhere the amount of issues that nextjs does. The main problems I find are exceptionally poor TTFB on their server side rendering. This then pushes people to do aggressive caching of various types (without often fully understanding the ramifications of cache management) - which improves things, until a user is eg logged in then you're back to square one a lot of the time. The second problem is slow hydration times, regardless of SSR/caching. This causes major waterfall problems for interactivity as the nextjs bundle still needs to hydrate before most (any?) interactivity is possible. While all SPA-esque frameworks suffer with this kind of stuff, nextjs just seems to take it to the next level and it often does not seem trivial to fix when I report the issues.
moogly 2y ago
Useless anecdote: I don't have direct experience with Next.js[1] (but React, Angular, Vue, Solid), but I did help a co-worker out with something in their Next.js app, and as soon as I saw the madness that was file-based routing I wrote off the whole thing. [1]: mostly because I have never been interested in the modern form of SSR due to my controversial belief that that is a truly _insane_ solution to SEO, TTFB and page load performance. You don't really solve a problem by piling more problems on top, however many billion man-hours a whole industry spends on that endeavor.
- epolanski 2y ago
  I don't think file based routing is the evil, on Nuxt it works very well.
- wdb 2y ago
  File-based routing is one of the best things to have up to particular size of an application. Makes navigating the code so much easier then routing spread throughout the code base
  - bryanrasmussen 2y ago
    If you have a single routes source that makes it just as easy, although that really depends on the people making sensible route handlers for the routes to point to, if people are not good at doing that obviously the implicit order of /pages is superior.
  - bluefirebrand 2y ago
    You shouldn't need to structure the codebase based on how the application is routed More importantly you shouldn't need to restructure the codebase if the application routing changes File based routing is a terrible idea
    - moogly 2y ago
      My exact visceral reaction.
- 2y ago
epolanski 2y ago
I think that the industry is very slow into abandoning the React ecosystem (that's a huge statement to React's impact) for saner choices like Vue/Nuxt that have none of the problems of the react ecosystem. At the end of the day, React's weakness will always be it's model of render functions, while nice to reason on, it's close to impossible to pre compilate. That will always make React slower than template, and directives based alternatives, so people need to go into madness to get good performing react applications, and none of this is gonna come out of the box.
- nov21b 2y ago
  I switched from Vue/Nuxt 2 to React at the time of the V3 transition. The reason was horrible slow dev performance, lack of template type checking and overall slow transition of the ecosystem to V3.
  - epolanski 2y ago
    Vue's creator is also the author of Vite, which was designed with Vue development in mind and it's anything but slow.
ncrmro 2y ago
The hardest think now is forgetting all the patterns we used on client side only say. On successful form submet change the ui based on this error state. Now because of server actions you would just redirect to a success page.. It’s actually way simpler. It harks back to full SSR like Django/Rails/Wordpress
yodon 2y ago
Genuine question: what's wrong with a client-side SPA and a server-side backend for 90% of small-to-midsized SaaS apps? I see why Vercel would want everyone using SSR and their opaque server-side caching, but why do generic non-FAANG-scale web apps want it on day one? When Next became a Vercel sales tool, I switched to React + Vite + backend, and everything just got so much easier.
- mattrighetti 2y ago
  > what's wrong with a client-side SPA and a server-side backend for 90% of small-to-midsized SaaS apps? I'm not a frontend dev and what I like about SSR is that you don't have to code frontend visual effects that indicate that "something is loading", you just get the hydrated page back without too much frontend logic.
  - yodon 2y ago
    That's a lot of complexity to bring in just to avoid adding a <suspense> tag
- whalesalad 2y ago
  If SEO is not important there is nothing wrong with this approach.
  - bluefirebrand 2y ago
    Stop building products that get their income from advertising and SEO worries go away in a hurry It's actually wonderful
    - rgbrgb 2y ago
      It’s not about ads, it’s about distribution. If people find your product via google then SEO matters (at least for the page they land on).
      - 2y ago
mattrighetti 2y ago
I am not a frontend dev, but I've been using NextJS for the last 6 months to build a website and I've been using the App Router because I wanted to have SSR and because NextJS suggests to go with that. I'm feeling good with it at the moment, even though I'm trying to keep things as simple as possible so you might argue that I'm not really pushing it to the limits. The major "issue" I'm having is mixing server and client components as I inevitably tend to overcomplicate stuff: if I need any kind of client interaction then I have to mark is with `use client`, but then everything you place in that component also becomes a client component. If you want to keep server components in a client component you have to pass it through the use of {children} prop which sometimes is not ideal.
spirobelv2 2y ago
I am building an alternative to nextjs that consists of just 3 files and has no external dependencies. https://github.com/spirobel/mininext https://github.com/spirobel/mininext (my goal with mininext is to provide index.php like productivity but with all of npm and typescript at your fingertips)
brtkdotse 2y ago
As someone who got started with web dev by sending HTML over HTTP I marvel about the ways modern web devs contort themselves to be able to send json instead.
hamasho 2y ago
Do people use Next.js as an API server too? In all the projects I've joined, we've only used Next.js as a static frontend framework and dev tool built on top of React. We never touched the SSR feature, just used it as a static site generator, and didn't bother implementing any APIs in Next.js. I can't imagine someone can implement a robust code base while mixing frontend and backend code in that messy folder structure.
atlex2 2y ago
As a person who got back into web dev and tried Next for the first time, I was pretty upset once I learned that I was using this half baked App router rather than the more straightforward page router. Their FAQ literally asks if their are any open source applications built on app router: https://nextjs.org/docs/app#are-there-any-comprehensive-open-source-applications-built-on-the-app-router https://nextjs.org/docs/app#are-there-any-comprehensive-open...
- atlex2 2y ago
  Oh, and not to mention that because of Vercel ownership, Next/Image will never support Google App Engine and specifying the image cache directory in an environment variable or at compile time.
patwoz 2y ago
Just use remix. It’s so much easier and less painful.
synergy20 2y ago
I avoid all SSR with node.js these days, not that they're bad, but: 1. it's a mature field with many solutions already, no need reinvent the wheel for me. 2. the frontend is complex enough
deleted 2y ago
[deleted]
dcchambers 2y ago
I think Vercel has a good product and clearly very talented engineers working there, but their takeover of the React ecosystem has been alarming. A well executed embrace-extend-extinguish playbook to get people using the Vercel platform.
0xblinq 2y ago
Inertia.js is the way forward for me (and my company). Just the way to use react or vue the way it was intended to be used, paired (in a beautiful way) with a real backend framework such as Laravel, Rails, Django or Adonis. I’m so done with every weeks new “full stack framework” that doesn’t do anything but routing and has an uncertain future.

146 points by carlual 2y ago

It feels like the entire JavaScript world seems overly influenced by e-commerce, pushing all kinds of optimization, even including RSC and SSR. As a former SaaS builder, I deeply resonate with the author's point: "I care way more about the speed at which I ship features, and all that complexity becomes a burden on my dev team." This is exactly why I started building ZenStack(https://zenstack.dev https://zenstack.dev) toolkit. The goal is to brings simplicity back to building SaaS applications, using whatever framework you like.

beretguy 2y ago
Ah! Another js framework that will fix problems of all the previous ones… great…
- 000ooo000 2y ago
  Relax. No-one is taking your precious jQuery from you.
  - rc_mob 2y ago
    phew! perfect
  - jampekka 2y ago
    jQuery isn't a framework. As a library it's still precious.
    - 000ooo000 2y ago
      I don't think that distinction is key to the insinuation
      - jampekka 2y ago
        I got the tribal insinuation.
  - beretguy 2y ago
    No, I write my hobby websites to work without JavaScript.
- zelphirkalt 2y ago
  I mean, the potential always exist, but I would rather avoid much JS at all and only use a minimal amount of it, which is usually not what JS frameworks intend to let you do.
  - beretguy 2y ago
    That’s what I do. I write my hobby websites to be functional without any JavaScript.
- zer00eyz 2y ago
  How dare you look down your nose at the techonolgical magpies. They do love to collect shiny things!
Tade0 2y ago
That's just the React world which, granted, is the majority of the JavaScript world. Over here in Angular land not much has been happening. Ok, we have signals now, but that's about it. If you want simplicity, use htmx and your backend framework of choice.
- lenkite 2y ago
  I dunno why HN likes to hate on angular. Its an amazing, batteries-included framework where you don't have analysis-paralysis from 100 different choices, easy to pick-up and learn, CONSISTENT, quite performant and doesn't break your build from year to year. (or month to month like some other HN-loved frameworks) React terrifies me. Nothing is consistent. Everything is always a little broken and maintenance is painful. This has been my anecdotal experience doing maintenance work on 3 diff React projects. Framework of current project uses Vue and Vuetify - and its been a very pleasant experience. It was the easiest framework to pick up and get going amongst the three. (Though Angular is still the most stolidly consistent framework)
- graypegg 2y ago
  I was building a big monolith angular (v8 at the time) app a few years ago and I think my old coworkers from that job would get a laugh from hearing me reminisce about it! Angular is actually very nicely laid out as a front end framework. I’m finding the modern react ecosystem more obtuse than old angular apps.
- spoiler 2y ago
  My 2c on the whole React and complexity situation: it's not great, but at the same time it's not as bad as someone people make it sound. Things _can_ be done in a simple way. The issue with React is that it's just a library, and there's some gaps it leaves that companies like Vercel tried to fill (and abused, but that's another topic). So then you get a bunch of new-ish developers who haven't even properly learned react throwing in a bunch of random libraries they also don't fully understand how to use, and you end up with a shit soup. Not because the ingredients are bad, but simply because the cook didn't know how to use them. I've seen people abuse React. I've seen people abuse Redux (and extensions). Even with there being ample resources for both. People want to try to be creative withou planning ahead, and then things happen and the business wants to go on, but devs are rarely given time to integrate and apply stuff they learned from previous mistakes, etc. So while some of the problems are technological in nature, I think the biggest problem is not the technology itself, but how it's combined with inexperienced developers With that said, I'm also a big fan of designing APIs that are easy to use, and difficult to misuse. React has areas of the API which fail on both of those principles though (I hink some of which they want to address with the React Compiler)
jampekka 2y ago
Some feedback on the page: I found the intro blurb[1] a bit off-putting with all the corporatese. Namely "supercharging to unlock potential" gives an instant BS vibe. Don't know how it looks like for other audiences, but I'd guess e.g. HN audience on average do not like it. Just use the space to say what it actually is and does? It's definitely not the worst offender, and that's probably why I wanted to give the feedback. [1] "A TypeScript toolkit that supercharges Prisma ORM with a fine-grained Authorization layer, auto-generated type-safe APIs/hooks to unlock its full potential for full-stack development."
- carlual 2y ago
  Thank you for the kind and thoughtful feedback! The change has been made.
  - jampekka 2y ago
    Very good now, thanks!

cranberryturkey 2y ago

Checkout primatejs if you're tired of all the nonsense.

lambdaba 2y ago
Why is it great?
- cranberryturkey 2y ago
  It lets you use any ui framework you want
  - moritzwarhier 2y ago
    Then what does it do? Is it similar to Vike.dev?
    - cranberryturkey 2y ago
      It allows you to use vue, react, svelte, angular, htmx, solid, etc....and for the backend you can use Go, python, bun/node/deno and/or typescript. We're also releasing a new version soon that will allow for native desktop apps (ie: Tauri)
bryanrasmussen 2y ago
well.. sounds nice but some things make me worried: 1. "Use the comfort of one runtime during development and the speed gains of another in production." how is that possible without hitting all sorts of backwards/forwards compatibility issues. 2. The react example you give on the front page does not seem very react-like. - that said "Write backend code in your language of choice, leveraging the power of Wasm. Mix routes of different backend languages, allowing your application to be written by different teams." sounds like something that you might think who the hell needs that, but I've worked on a few teams, and am on one now that could perhaps benefit from it. instead what happens now is there is a JS api that sends requests forwards to the actual backend - maybe doing some minimal verification etc. so doubling work - not all places but certain api end points where we don't want to reveal secrets in frontend etc.

highcenburg 2y ago

Finally, this helped my decision whether to use Nextjs or Reactjs in my projects.

pjmlp 2y ago

As long as it keeps being the closest to Spring and ASP.NET on node land, I am ok with where it is going.

stepbeek 2y ago
I would have thought https://adonisjs.com/ https://adonisjs.com/ was the equivalent? I've not used next.js for a few years but it doesn't seem to have an answer for anything on the back-end except rendering. That only covers a tiny part of what frameworks like Spring or ASP.NET offer.
- pjmlp 2y ago
  You use API routes for the backend stuff, the typical controllers, what is now known as Backend For Frontend in marketing speak.
alexhutcheson 2y ago
What makes it the closest to Spring and ASP.NET?
- pjmlp 2y ago
  The mix of React components that can also be rendered server side (JSP tag libraries, Razor View Components), middleware (servlets, middleware), API routes (controllers).

rickcarlino 2y ago

I’m curious about alternatives that offer good file-based routing support. Has anyone seen any good alternatives?

zelphirkalt 2y ago
Quite easy to implement oneself, I would say.
- molebury1 2y ago
  [flagged]
  - officialchicken 2y ago
    Yes, that's the idea, dudebro! When the market does not meet your needs - you meet the market.
- ivanjermakov 2y ago
  Literally. My experience with routing tools is that it's often easier to implement it from scratch perfectly suited for your use case instead of integrating existing general solution.
Zealotux 2y ago
Remix is better in every aspect.
- Aeolun 2y ago
  I really don’t like how remix stuffs their philosophy down your throat. Old next at least was more free form.
  - Zealotux 2y ago
    If you agree with Remix's philosophy (and after years of front-end development, I would say I do), it's heaven. New Next is now as opinionated and much worse, in my opinion.

joeatwork 2y ago

Software tools backed by businesses that target enterprises have very strong pressures towards obscurity, complexity, and generally optimizing for institutional goals and away from development experience and effectiveness. As tools that get developer adoption move up market they get worse and worse for the folks building with them.

szundi 2y ago
I wonder wether it is possible to keep on the right (dev) track? One could argue that when becomes shit, sooner or later it is going to be abandoned at the end
smolder 2y ago
This is a good reminder of how thankful we should be for the many contributors to Free software.
jampekka 2y ago
Here we also have the ensittification on top, as Vercel starts to squeeze out platform profits.

sarreph 2y ago

All this negative sentiment around the App Router like in this post made me really scared to adopt it. I've just been working with it for the past 2 months and absolutely love it. The biggest reason being the ability call functions directly from server- or client-side code! You basically only need to write API endpoints now for externally-facing services. Saves so much time and boilerplate... Yes it is more complex than Pages Router. And while I'm a staunch advocate for simplicity where possible, I do think the tradeoff is worth it for new projects. It just takes a bit getting used to. The negativity feels a bit like hooks all over again tbh...

NayamAmarshe 2y ago

When I first discovered Next.js, it was like finding a gold-mine. I no longer had to use an express server and couple that with React and manage all the crazy configs. Next.js was so simple, everything just worked! The docs were absolutely amazing, dev server was super fast, the build times were fast, I could easily create server side and static sites, host them on Vercel easily, good times all around. Then came the Vercel + React partnership and it took things in a different direction. Now React almost became a child of Vercel. All of a sudden, the focus instantly shifted to server side from what was earlier client side & server side both. Breaking changes, added complexity and the strange co-existence of 2 routers, out of which the old one (which works perfectly fine btw) is certainly set to become obsolete in the near future leaving us with no choice but to move to this 'new' router. Next.js app router is extremely slow. You don't even need to do anything special, just compare the dev server compile times of Next.js v12 vs v14, the performance has decreased. The dev server sometimes occupies gigabytes of memory, why? Can I also mention the 'new' but worse file-based routing system that forces every page to be named page.tsx? Who thought that was a good idea? They simply copied Sveltekit. This even forced the VSCode team to introduce a way to edit the tab names because every page being called page.tsx is undoubtedly worse DX! All good things come to an end, and I certainly feel this way now with Next.js. I was a proponent, I recommended it to everybody who was looking to build apps with React but now? I'm not so sure anymore, considering how confused they are about their own decisions (refer to the v14's caching controversy). I'll be jumping ship to a better product as soon as I find one (and I'm sure there will be in the future). For now, I'm just sticking because of the years of familiarity with React.js and Next.js. They have served me well but Next.js has simply become Outdated.js as far as the future is concerned.

_andrei_ 2y ago
Been working with React for the past 9 years and I hate what Vercel's influence has done to it. I hate what they've done to Next as well, but at least that one is theirs.
- mococa 2y ago
  I have the same feeling, Vercel is destroying React.

ThalesX 2y ago

I used Next.JS awhile ago and it was great. Then I switched to Remix and it was great. Then I went back to Next.JS and I couldn't understand where things went wrong. From the routing model to the deployment model, it all felt so broken that I couldn't convince myself to continue using it.

fullstackchris 2y ago
Would you currently recommend Remix over Next.JS? I just started a Next.JS project (trying it as a long time Gatsby user) but am worried about what I am reading here.
- NayamAmarshe 2y ago
  Moving from Gatsby to Next's pages router is definitely an upgrade. Pages router is awesome and easy to understand.
- etimberg 2y ago
  I would; it's a lot easier to use and reason about. that being said, it feels like we've come full circle back to the early 00s with form posts for submitting changes rather than fetch/xhr
- ThalesX 2y ago
  I've had a rough transition from Remix 1 to Remix 2 for a couple of web apps I've worked on, but overall I still feel like the Remix model just works better. That being said, I'm probably not the best person to make a recommendation in this sense as I'm looking to go back to a sane job working with .NET MVC or PHP Laravel and just a bit of dynamic frontend sprinkled on top.
- satvikpendem 2y ago
  It's by the makers of React Router, who've refactored their codebase 6 different times with breaking changes each time, causing a lot of pain for those who used it and wanted to upgrade. That is the main thing that causes me to not want to use Remix these days.

ulrischa 2y ago

I would like to see a fullstack framework like next for Webcomponents. And one thing is missing for all fullstack frameworks: A CMS. Astro and next is very good but I can not offer markdown or jsx for a client

terrablue 2y ago
Primate gets close to that -- there is a webc handler with props support: https://primatejs.com/modules/web-components https://primatejs.com/modules/web-components The webc handler does lack a few things like hydration, and this can be added if users show interest in it.

afloatboat 2y ago

We just turned back from Nextjs after a 4 month trial for a new application. Some issues we ran into: - The dev environment is too finicky. Full page reloads instead of HMR and random errors after x reloads. - Cache is a black hole and works differently between dev and production. They’re changing things up now with v15, but this lack of stability is not fun to rely on. - The file based router has its limitations. For instance: having the language in the URL means your entire tree remounts when the language is changed. - No clear way to bootstrap specific stuff outside of React - Portals don’t seem to work on the server. - very easy to mess up auth stuff. At some point Supabase even put out a YT video [0] where their implementation caused auth to be accidentally cached. There are 3 levels of checks you need to do just to be safe, but this is all very opaque. For me it also wasn’t clear how to combine client and server state. These patterns haven’t been defined yet and I kept running into hydration issues with no clear solution. A year after the app router the eco system still feels very much in limbo and brittle. I also worked with Next as a replacement for Gatsby’s SSR, but quickly discovered that there’s no easy way for Next to just pre generate all responsive image sizes it needs for a static output like Gatsby has. You need to implement a custom loader and rely on something like cloudinary. This is ridiculous for a completely static site. [0] https://youtu.be/v6UvgfSIjQ0 https://youtu.be/v6UvgfSIjQ0

oslonoway 2y ago
What do you use instead?
sandreas 2y ago
Try hono.js ;) https://hono.dev/ https://hono.dev/
- hamasho 2y ago
  Yet another JS framework, and it looks great. I've only skimmed the doc, but I already like its simplicity. But I have a mixed opinion on the big Context object. It may help to write less verbose code, but it can also cause OOP's antipattern God Object[1], even though the context is more of a namespace rather than a big object. // Not app.get('/hello', (c) => { return c.json({ greet: `Hello ${c.req.params('id')}`) // But import { jsonResponse } from 'library' app.get('/hello', (req) => { return jsonResponse({ greet: `Hello ${req.params('id')}`) [1] https://www.wikiwand.com/en/God_object https://www.wikiwand.com/en/God_object Fix: format

spoiler 2y ago

I'll never get over how convoluted it felt to make a modal appear on the screen, using the "blessed" Next.js way. You need parallel routes, slots, intercepting routes, file names that look like the blast radius of a shell script gone wrong with names containing (..)s, [slugs], and @slots, and special-purpose file names like page.ts, index.ts, default.ts, some stuff auto-magically passed in as props. It's like they're trying to take ideas from something like Rails without having ever even used Rails, and then pervert those ideas. I know I sound overly critical perhaps, and maybe I'm being too harsh, but it just feels like there's this bizarre appreciation or worship of arcane complexity by Next devs. And any simplicity and straightforward-ness is shunned and frowned upon. Like simplicity is somehow beneath them, and simplicity is only for stupid plebs like myself. I haven't used Remix, but their docs suggest it's simpler.

pictur 2y ago

next js is one of those projects that unintentionally makes things complicated on purpose. Everything is going very well up to a certain point. but at some point you find yourself in a server <-> props hell.

bryanrasmussen 2y ago
how does one unintentionally make things complicated on purpose? Next.Js made things complicated unintentionally because they thought that a folder based mapping of routes was good and would evidently scale to their customer base's needs. Then they were so far in that was one of the things they couldn't undo. Oops.

PUSH_AX 2y ago

I started a project with next about 2.5 years ago. That version is pretty good, easy to reason about. A year or so back I spun up a new next project only to be greeted with very unintuitive errors regarding trying to use client libraries in server pages? Something like that. I wondered if I was going crazy or if this was actually going in a terrible direction.

jddj 2y ago
I haven't touched Next, but the discussions and issues of some things I do use seem littered with people thinking they're on the client when they're on the server and vice versa. Someone upthread said there were some common Auth footguns and I'm not surprised at all. Maybe the warnings are to try to mitigate that.
lioeters 2y ago
I have a couple of fairly large Next.js projects, started a few years ago. One of them I was able successfully upgrade to the latest major version of Next, after going through a number of errors, deprecations, and studying the documentation. There are so many little details and rules to remember now, just like React. It's an accumulation of seemingly user-hostile design decisions for not much apparent benefit from the user's perspective. The second project is stuck with a cryptic error that prevents the production build step from completing, and after searching through GitHub issues and even going into the Next.js codebase, I'm unable to fix it. At this point, I've given up on the upgrade and searching for a different framework to rebuild the app on. It's hundreds of pages, many of them generated by dynamic URL routes, so I'm not looking forward to it. It's a huge effort just to get the application to work exactly as it did before. The upgrade experience has soured me on Next.js, I wouldn't start a new project with it. Even React I'm getting doubtful of its recent direction, and eyeing other view libraries that achieve the simplicity it used to have.

aosaigh 2y ago

I'm still using the pages router due to complexity of the app router. At this point, I think that I'll move to another framework instead of moving to the app router. They completely botched the transition from pages to app router and even now, literally years later, there are still simple things you can't do with the app router. It's also just hugely confusing defaulting to server components. It's a shame because in the beginning, Next.js was a breath of fresh air.

renegade-otter 2y ago

My observation as a [mostly] backend dev is that the JS world in general is fascinated with building complexity and then using more complexity to address the previous complexity. Transpilers, converters, tree-shakers, oh my. It's 2024 - building a web app should not be rocket science or require such obscene tool chains. Unrelated, but I've been trying to finish a project of mine, and after long breaks I would discover that my front-end code was out of date. There was already a better framework, or a new version, making your old code obsolete. I gave up after Vue 3 introduced composition API - all I did was learn "the new ways" without actually building anything. Then I switched to HTMX and ditched all that bullshit.

Zanfa 2y ago
My pet theory is that due to zero interest rate policy, too many startups were able to raise too much money and so they hired too many engineers that didn’t have anything really productive to do for years. So they kept reinventing wheels for a decade plus, each iteration more complex than the previous one.
- renegade-otter 2y ago
  This is what I believe, and it's one of the bigger points I made when I wrote Death By a Thousand Microservices: https://renegadeotter.com/2023/09/10/death-by-a-thousand-microservices.html https://renegadeotter.com/2023/09/10/death-by-a-thousand-mic... It's related, I think. In a truly lean business environment, people would not have so much time mucking around with these frameworks. It actually looks like developers come up with zingy library and framework names and THEN they actually write them.
Quothling 2y ago
HTMX with GoLang is such a relief compared to working with anything else in web-related apps. We're still doing a monorepo with NextJs some NX (which is frankly also rather unnecessary since everything it does can be done fairly simply with pnpm workspaces and vite), a complicated storybook setup and 9 billion libraries for components, utilities and what not. We're also still trundling along with C# even though it's 2024 and functions should be capable of living outside of classes in any language... Naturally build on "clean architecture" and "solid" which makes the entire code base a ginormous mess of unnecessary abstractions where a simple helper which does one single thing and is never re-implemented lives in 9 billion files in several different csproj's because it "might" need to be abstracted one day (it won't). It takes me longer to figure out where things are in those projects than it does to develop an entire internal service with HTMX and Go... Which despite being a huge success for everyone, and hailed by the business itself has made no impact on our future plans. We can sit in a meeting where everyone has achieved something marvelous with HTMX and Go and still decide to keep using NextJS and C#. It's silly, but I've never really worked for a company where it wasn't this stupid and at least we're not so trapped by ourselves that we can't build things with "non strategic" tools.

eknkc 2y ago

I think it makes a lot of sense for Vercel to push RSC and all the complexity of new Next. - They sell compute / bandwidth. You can not make a lot of money if people are building SPAs that load from a CDN and execute on client. - SSR kind of gives them some server compute but as soon as the initial page is loaded, we are back to point 1. - Here comes RSC then. And they pushed hard. Made it look like the best thing ever. Oh the initial load time is the most important metric. You gotta make sure you hit this score on whatever benchmark thing… - They also kind of acquired React. It is basically Vercel’s now so they can dictate the development direction. - All this with almost no benefit to developers (compared to something like pre app dir next) but likely helps them a lot in terms of revenue. I mean this might read like “vercel evil” post but it is what corps do and they seem to do it well. I used next on a project recently and will not touch it again because the hype did not materialize as any type of gains during our own development.

martinald 2y ago

I've done an enormous amount of web performance analysis work, and as soon as I see the nextjs bundle come down in the network tools I know there will be issues. It just seems exceptionally slow to another stack I've seen. Whether this is poor docs or bad implementations, I'm not entirely sure, but it seems there is a major issue with it - I do not see in my analysis any other stack having anywhere the amount of issues that nextjs does. The main problems I find are exceptionally poor TTFB on their server side rendering. This then pushes people to do aggressive caching of various types (without often fully understanding the ramifications of cache management) - which improves things, until a user is eg logged in then you're back to square one a lot of the time. The second problem is slow hydration times, regardless of SSR/caching. This causes major waterfall problems for interactivity as the nextjs bundle still needs to hydrate before most (any?) interactivity is possible. While all SPA-esque frameworks suffer with this kind of stuff, nextjs just seems to take it to the next level and it often does not seem trivial to fix when I report the issues.

moogly 2y ago

Useless anecdote: I don't have direct experience with Next.js[1] (but React, Angular, Vue, Solid), but I did help a co-worker out with something in their Next.js app, and as soon as I saw the madness that was file-based routing I wrote off the whole thing. [1]: mostly because I have never been interested in the modern form of SSR due to my controversial belief that that is a truly _insane_ solution to SEO, TTFB and page load performance. You don't really solve a problem by piling more problems on top, however many billion man-hours a whole industry spends on that endeavor.

epolanski 2y ago
I don't think file based routing is the evil, on Nuxt it works very well.
wdb 2y ago
File-based routing is one of the best things to have up to particular size of an application. Makes navigating the code so much easier then routing spread throughout the code base
- bryanrasmussen 2y ago
  If you have a single routes source that makes it just as easy, although that really depends on the people making sensible route handlers for the routes to point to, if people are not good at doing that obviously the implicit order of /pages is superior.
- bluefirebrand 2y ago
  You shouldn't need to structure the codebase based on how the application is routed More importantly you shouldn't need to restructure the codebase if the application routing changes File based routing is a terrible idea
  - moogly 2y ago
    My exact visceral reaction.
2y ago

epolanski 2y ago

I think that the industry is very slow into abandoning the React ecosystem (that's a huge statement to React's impact) for saner choices like Vue/Nuxt that have none of the problems of the react ecosystem. At the end of the day, React's weakness will always be it's model of render functions, while nice to reason on, it's close to impossible to pre compilate. That will always make React slower than template, and directives based alternatives, so people need to go into madness to get good performing react applications, and none of this is gonna come out of the box.

nov21b 2y ago
I switched from Vue/Nuxt 2 to React at the time of the V3 transition. The reason was horrible slow dev performance, lack of template type checking and overall slow transition of the ecosystem to V3.
- epolanski 2y ago
  Vue's creator is also the author of Vite, which was designed with Vue development in mind and it's anything but slow.

ncrmro 2y ago

The hardest think now is forgetting all the patterns we used on client side only say. On successful form submet change the ui based on this error state. Now because of server actions you would just redirect to a success page.. It’s actually way simpler. It harks back to full SSR like Django/Rails/Wordpress

yodon 2y ago

Genuine question: what's wrong with a client-side SPA and a server-side backend for 90% of small-to-midsized SaaS apps? I see why Vercel would want everyone using SSR and their opaque server-side caching, but why do generic non-FAANG-scale web apps want it on day one? When Next became a Vercel sales tool, I switched to React + Vite + backend, and everything just got so much easier.

mattrighetti 2y ago
> what's wrong with a client-side SPA and a server-side backend for 90% of small-to-midsized SaaS apps? I'm not a frontend dev and what I like about SSR is that you don't have to code frontend visual effects that indicate that "something is loading", you just get the hydrated page back without too much frontend logic.
- yodon 2y ago
  That's a lot of complexity to bring in just to avoid adding a <suspense> tag
whalesalad 2y ago
If SEO is not important there is nothing wrong with this approach.
- bluefirebrand 2y ago
  Stop building products that get their income from advertising and SEO worries go away in a hurry It's actually wonderful
  - rgbrgb 2y ago
    It’s not about ads, it’s about distribution. If people find your product via google then SEO matters (at least for the page they land on).
    - 2y ago

mattrighetti 2y ago

I am not a frontend dev, but I've been using NextJS for the last 6 months to build a website and I've been using the App Router because I wanted to have SSR and because NextJS suggests to go with that. I'm feeling good with it at the moment, even though I'm trying to keep things as simple as possible so you might argue that I'm not really pushing it to the limits. The major "issue" I'm having is mixing server and client components as I inevitably tend to overcomplicate stuff: if I need any kind of client interaction then I have to mark is with `use client`, but then everything you place in that component also becomes a client component. If you want to keep server components in a client component you have to pass it through the use of {children} prop which sometimes is not ideal.

spirobelv2 2y ago

I am building an alternative to nextjs that consists of just 3 files and has no external dependencies. https://github.com/spirobel/mininext https://github.com/spirobel/mininext (my goal with mininext is to provide index.php like productivity but with all of npm and typescript at your fingertips)

brtkdotse 2y ago

As someone who got started with web dev by sending HTML over HTTP I marvel about the ways modern web devs contort themselves to be able to send json instead.

hamasho 2y ago

Do people use Next.js as an API server too? In all the projects I've joined, we've only used Next.js as a static frontend framework and dev tool built on top of React. We never touched the SSR feature, just used it as a static site generator, and didn't bother implementing any APIs in Next.js. I can't imagine someone can implement a robust code base while mixing frontend and backend code in that messy folder structure.

atlex2 2y ago

As a person who got back into web dev and tried Next for the first time, I was pretty upset once I learned that I was using this half baked App router rather than the more straightforward page router. Their FAQ literally asks if their are any open source applications built on app router: https://nextjs.org/docs/app#are-there-any-comprehensive-open-source-applications-built-on-the-app-router https://nextjs.org/docs/app#are-there-any-comprehensive-open...

atlex2 2y ago
Oh, and not to mention that because of Vercel ownership, Next/Image will never support Google App Engine and specifying the image cache directory in an environment variable or at compile time.

patwoz 2y ago

Just use remix. It’s so much easier and less painful.

synergy20 2y ago

I avoid all SSR with node.js these days, not that they're bad, but: 1. it's a mature field with many solutions already, no need reinvent the wheel for me. 2. the frontend is complex enough

deleted 2y ago

[deleted]

dcchambers 2y ago

I think Vercel has a good product and clearly very talented engineers working there, but their takeover of the React ecosystem has been alarming. A well executed embrace-extend-extinguish playbook to get people using the Vercel platform.

0xblinq 2y ago

Inertia.js is the way forward for me (and my company). Just the way to use react or vue the way it was intended to be used, paired (in a beautiful way) with a real backend framework such as Laravel, Rails, Django or Adonis. I’m so done with every weeks new “full stack framework” that doesn’t do anything but routing and has an uncertain future.