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.
- 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.
Auth is all you need. It is a non-functional requirement in that your site is non-functional if auth is broken.
In the large it is Yahoo or Google or Facebook buying a site and hooking it up into their entire service but in the small it is "I want an email newsletter script" and instead of messing around with HMR and file-based routing and other inessentials to develop my own, I just pick a best-of-breed application and hook it up to my user database and auth system and I am in business. (Today, without a clean API, I can hack that application to query my user database and be behind my auth module if the tech stack is sufficiently similar to my own at risk of braving whatever inessentials that route entails)
Absolutely disagree. You shouldn't roll your own bcrypt, but you should have full knowledge of how it's used to offer authentication. Hell this is required to even move forward with sales in many enterprise software contexts. If you don't know how passwords work, for the love of god don't offer password-based login.
Exactly. It is not the implementation of the auth module that matters to me so much as is the API through which it slots into the rest of the system. I want the expert designed modules that I can plug various systems into.
Because we haven’t seen good frameworks at the user management level, I think, the mistakes made by the creators of that YT video are common in the industry.
Please make your substantive points thoughtfully and without personal attacks. "The fuck you are talking about" is much too aggressive for this site, as you'll see if you'll review the guidelines.
Even "I'm sorry but" is the sort of flamebait we're trying to avoid here.
Not implementing auth doesn't mean using platforms. Just use any of the many OIDC client/server libraries or completely pre-made open source dockerized services.
For example react-oidc-context on the client side and Passport.js on the server, or Casdoor.
Verifying that your vendor hasn't done anything dumb is hard.
Supporting your customers when they have problems is hard.
Debugging issues with a thrird party in the loop is hard.
Just because you farmed out auth doesn't mean you get to stop monitoring for breaches, or doing all the other things you need to do to have an eye on security.
Farming out auth just ads a recurring cost per user and complexity that your going to ignore till its a bigger issue than dealing with this up front would have ever been.
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')}`)
Hono is great, the context object is really just a collection of helper methods for returning responses, a way to store values through the lifetime of the request, and the Req and Res objects. I understand the concern but I wouldn't let that stop you from trying it out.
I was not totally serious about it. My hunt for the next best framework is over... I tend to use vanilla JS for my pet projects and for more serious stuff I use whatever I find interesting or what the project uses :-)
It depends. If its something like my personal todo list pure-todo [1], I tend to write it down in less than a week without using any frameworks and hardly ever touch it again.
If it's something like m4b-tool[2] or tone [3], that has to be maintained for a while, I tend to use battle proven libraries or frameworks (in this case Symfony, because it is an older project and Spectre.Console and atldotnet for tone). I prefer libraries over frameworks though, less background magic.
However, I have the feeling that you also find something in this comment that you don't like - maybe the shameless advertisement of my FOSS projects ;-)
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.
Next.js jumped the shark with the app router. The page router, though it wasn't perfect, was a nice fit and was an extension of the React way (at the time) by handling the client-side well. You got routing and some ability to execute certain things on the server-side plus basic api support. For everything else you could use a full express backend or even other backend languages/stacks. But like with many things, simplicity could not be appreciated and now you have this mess. It's time for a better alternative.
I think Inertia.js is the answer to this. It’s just some “glue” to make React/Vue/Svelte play nice (as the views) for any of the battle proven frameworks like Laravel, Django, Rails… or Adonis if you want to stay in node for the backend
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.
It’s a very shady company, and despite what it looks like, they’re more a marketing company than a tech one.
I’m glad I noticed this early and stopped using Next on time. For me the thing that made me realize this was their “hiding” (for as much as they can) and making it more difficult than intended of the call home metrics system in next. They refuse to add a setting to turn that off, and instead want you to set an env variable or run a npm command.
Just think about they do this and refuse to add a setting.
What was wrong with Express.js? No, what is wrong with it right now? Because all I see is Next.js just being a wrapper for what Express.js does.
Also, Next.js is becoming like Angular: The progress from Angular.js 1 to Angular 18 was necessary for solving the problem of very hard front-end web development. So I'm guessing this Next.js contender is trying to become the Angular of the back-end. They're basically turning into the theoretical computer science constructs that they must become. Script kiddies and non-computer science students need not apply.
Building a product on Express is like making a sandwich by growing wheat and raising cattle. Sure Next is a wrapper around Express; JavaScript is a wrapper around assembly. Yet some people don’t have time to do everything from scratch again and just want a sensible framework to build upon.
Express is like making a sandwich by buying bread, meat, and condiments from the super market. NextJS is like buying a sandwich from a vending machine.
The biggest issue with apps like NextJS is that they didn't explicitly build upon and expose the Express API. What they should have done is client-side app routing with a version of Express that runs route handlers in the browser. They also needed to add parallel middleware that runs in both a browser and server context. That's the only sane way to support functionality and components that run in both the server and browser context.
The entire NextJS architecture is flawed because they picked the wrong pivot point.
We want to be making sandwiches from store-bought components. Sometimes we do need to swap out the bread and NextJS has the wrong abstractions to do so which results in all sorts of soon-to-be-breaking-changes-spaghetti to work-around the deficiencies.
It would have been much better to maintain an application by working directly with requests, request middleware and request route handlers, with a mock request corresponding to mouse events for the client-side.
The request-response cycle is the fundamental nature of the web application, even in the browser.
Due to economies of scale, the massive manufacturing of your theoretical sandwiches with your own wheat and cattle agriculture should be cheaper in the end on a large scale (compared to the present alternative). And at that large scale it is the only effective and practical choice. So, we can infer the general conclusion that there are multiple and different types of software development with the existence of things like Express.js and Next.js. Namely real developers and lowly developers like cows on a factory line.
How does one set up express and host a web server correctly?
>hono
Seems absolutely the same to me, their getting started shows no login mw (only already token-ed auth), and it’s just a single context param instead of (req, res, next, res.{text,json}). What’s so innovative there? Feels like yet another cute solution looking for a problem.
You know what, I thought Next.js was a backend framework. I must be thinking of something else. I mistakenly have confused one thing with another. So never mind lol
A part of HN history, if you will, making light fun of the "it's just a wrapper" idea that transitions into a multi billion dollar company, because only naively is execution and the integration of different ideas a trivial task. The people at NextJS are obviously(?) doing something that's not just Express and you can look at the version history if you are interested in identifying those things.
Of course, you might not think of them as important. But that's a very different take.
Just the way everything hangs together. It works, but some things are in the code, but not the docs, mentioned on the site, but the init tool they refer has no facility for it, so you need to connect it yourself.
I'm not a fan of Svelte's cryptic syntax and constant changes. They started with something simple, which is why I decided to build upscayl.org's simple website with SvelteKit but now it's simply too much of a hassle when I compare it with Next.js.
They changed their whole state management system. It's like using a totally new framework now and it looks very much like React which is strange because Svelte was supposed to not be like React and offer simplicity in code.
I think the best contender right now Solid.js but it needs some financial help and the fanciness of Next.js to attract a larger developer base.
I share your frustration around the constantly high amount of changes in fundamental concepts, but overall I still feel like SvelteKit gets lots of things right that Next doesn’t.
I think SolidStart framework brings Svelte's and React's strong points together very well. I'm really interested in how it grows, I can say that it has a brighter future than Next or Sveltekit.
Unfortunately Solid's velocity has been kinda weak for awhile and it's missing its own hype. At this point Svelte is many many times bigger than Solid.
Yep, Svelte 5 with Runes was so much like React that I literally asked how it was any different when their announcement first came out [0]. Evan You, the creator of Vue, also noted its similarities to Vue [1]. They kind of answered the question but when actually working with Svelte 5, it simply feels like a reskin of React.
Svelte is a ton of magic, which is great if you like that sort of thing but every time I've tried it I've been frustrated and disappointed, and converted the project to something else.
I want to like Vue but the combination of buggy language tools and a buggy metaframework left a bad taste in my mouth. It's not surprising either when you look at the code quality.
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.
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
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) toolkit. The goal is to brings simplicity back to building SaaS applications, using whatever framework you like.
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."
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)
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.
I joke that this is the framework of choice for people with children. You can be out of the workforce for a year and still everything is mostly the same when you come back.
Also it keeps all the thrill chasers out, which is very helpful in delivering things on time and within budget.
Of course it would be better if we had some creature comforts like fast compilation times and good performance by default, but not at the cost of introducing the sort of chaos the React people live and breathe.
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)
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.
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.
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.
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
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.
Frontend devs were largely bullied into imitating traditional MPAs by people posting memes about SPAs and loading spinners. A huge percentage of pages could simply be pre-rendered (e.g. static landing pages and documentation sites), or they're behind a login wall in which case SEO no longer really matters. Deploying an SPA used to mean uploading a few scripts and html documents to an S3 bucket, and with CDN caching it was fast enough for many organizations. Instagram is still a mostly 100% client side SPA.
> 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.
It's crazy how people want to combine everything together such that adding some padding to a button on their pricing page redeploys their entire backend...
Typically I have a backend server written in a good language, an SPA for the app itself, and then some marketing pages written in plain html and js sprinkles, old school. It's great for SEO.
I use Next.js for marketing websites too though. It's the easiest way to set up SSR (or send pure HTML and CSS) in React, ie use JSX/TSX as a typed templating language with the additional ability to bring in React packages for certain things if needed.
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.
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.
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.
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.
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
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.
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.
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.
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...
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.
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.
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.
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.
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.
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.
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.
If you think that Go is a better choice than C#, you probably spend too much time watching tech influencers on youtube and twitch and too little time programming and getting familiar with the technologies they spread FUD about.
Go is inferior to C# in every possible dimension: performance, package management, terseness and expressiveness - Go brings notoriously more boilerplate, Go has poorer ecosystem for writing web applications, worse ORMs and worse tools for troubleshooting advanced issues in production - the list goes on.
There are companies that do C# disservice, but you're going to hate to see what they will do with Go instead.
I'm not sure how you feel I attacked C# aside from thinking it had the unnecessary bloat of requiring functions to live in class objects. As far as splitting everything up into 9 billion files and projects it's not something C# really forces you to do. I don't mind dotnet too much, I've worked with it for a decade and it's never been as great to work with as what it's become. I'd never pick it over Go for a new project if I had the choice though. I'm genuinely curious as to why you'd say these things however:
> Go has poorer ecosystem for writing web applications
For me personally the std http handlers is by far the best experience I've ever had with web development. Though I suspect that you may have worked with Go before the std was enough, and if so your experience was probably a little "tainted" by how the the ecosystem can be a little too "node" like.
> worse ORMs and worse tools for troubleshooting advanced issues in production
Now this is personal preference but I don't particularly like the rich debugging capabilities of the Microsoft package for C#. Exactly because it's hard to use them in production. Which depends on what sort of production environment you have, but we rely on open telemetry even for our dotnet applications. As far as ORMs go... We operate at a scale where they aren't useable. Entity Framework is quite nice... It's just that the industry has sort of moved beyond the need for ORMs. Even if your teams manage to avoid the lazy loading pitfalls your ORM is eventually going to be more complex than simply working without one. Partly because they weren't really designed for things like an Expand Contract Pattern (which you can implement, but then you're doing more work than simply writing raw SQL), but mainly because LLM's have made it sooooo easy to be both productive and remain control over your data.
> Go brings notoriously more boilerplate
I can write a struct and a function and then call it on my type in less lines of code than it takes to do the whole namespace... So I'm really not sure what you mean by this. If it's the C# magic which happens behind the scenes I think it's up to your personal opinion whether or not you want the control. As you might have guess from my take on ORM's I prefer the transparency and control.
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.
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.
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.
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.
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.
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.
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.
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.
Nuxt just works out of the box. It can get as complex as Next, but (most of) the footguns aren't loaded, cocked, and aimed already like everything in the React world seems to be (skip the component auto-imports tho, that one will bite you eventually) . Been using it to build a completely static SPA for years now, and it never makes a peep about server-side logic when working in that mode. Suspense just works, happening automatically when you have an async component, without any extra ceremony needed on your end.
And yes, it has a pretty nice file router built in, and useRoute() works everywhere. If file routing is all you want though, then skip Nuxt and use vite-plugin-pages (which also works with React).
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.
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.
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
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.
I would have thought 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.
The mix of React components that can also be rendered server side (JSP tag libraries, Razor View Components), middleware (servlets, middleware), API routes (controllers).
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.
Hey. Regarding 1, compatibility is handled by a separate library, Primate's only dependency, rcompat: https://github.com/rcompat/rcompat ; it's a unified compat layer around Node, Deno and Bun.
As for 2, what would you consider a React-like example? The examples on the frontend are meant to illustrate commonalities between different frontends.
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)
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.
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.
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
reply