81–90 of 157 posts
Earlier quoted context omitted.
Fun fact: Vercel “owns” Svelte too. https://vercel.com/blog/vercel-welcomes-rich-harris-creator-...
I know Rich Harris explicitly says, at least when Vercel ownership comes up, that he has a lot of leeway and total control of the project; is there any reason to think that Vercel will force Sveltekit to adopt similar things as Nextjs?
How does this offering (and other serverless postgres) do when there is a ton of data and read/write happening? In my case the most data I've dealt with had a few tens of billions of records. I haven't really worked on small-ish scale things until starting to work on my startup. I've always depended on managed postgres, and I use Go for all my services. I don't really have any experience using things like Vercel that…
I just made basically the same comment, I'm pessimistic, but open minded. Hoping someone can drop some insight on this thread
Basically rather than making your DB calls directly in NextJS server side code, you can make an HTTP call to your API written in Go or whatever. This is how I've used Next for years and it makes a lot of sense. One common API for the website and mobile app. NextJS just becomes another consumer of the API. It does feel a little bit funny that your server-side code is calling your API, but think about any large tech company where there are layers upon layers of APIs that every request is flowing through.
I've been out of the web-dev game for a while, and have been pretty blown away by how much has changed. Suddenly, it seems like everything is a 1-page application, SSR, and doing a lot more on the client than I was used to back when jQuery was the standard. Next.js seems like a pretty beginner-friendly way to get a lot of the "new stuff" without having to learn the multiple technologies in a MERN stack. On the other…
It's hard to take Vercel at face value these days with all of these improvements and announcements. Are we supposed to - in hindsight - understand that odd version numbers of their codebase were really just unstable releases all along? The app server implementation wasn't really meant to be used because it was an experimental release? I'm having a difficult time not being salty about this entire situation. There are…
I stopped paying attention when someone recently told me that everyone uses nextjs because “nextjs is meta right now”. Mind you this person has been a developer for about 3 years (not that there’s anything wrong with that but it gives you an idea of whose buying into this stuff) Vercels devrel is by far the best thing that they do, miles ahead of their engineering.
Fuck next.js. Honestly. Check out how it bundles and sends the entire react-dom library twice to every user on every page view https://github.com/vercel/next.js/issues/51508 . Fuck 1MB of JS to render a static HTML page. Fuck the image component, and not being able to optimise your image unless you use their cloud service for no reason at all. Fuck spending 3 hours working out why you’re not able to use relative imag…
Man this took me on a wild ride once.
We've had an awful experience with Next. There are undocumented, broken things all over the place. Migrating to the App Router was a huge mistake. 'use client' didn't work as expected, and we had to install workarounds and try out different hacks to get access to the most pedestrian features we could expect from any other web framework. This is the broad consensus among everyone else I know using Next - they felt lik…
I’m sorry you haven’t had a good experience. And if you more specifics if anyone on the Next team replied to you in that way, please let me know. I’ll be the first to say the launch of the App Router could have been smoother. Definitely not the first time I’ve heard the feedback. I’m optimistic Next.js 14 is a step in the right direction based on this. What do you feel is undocumented? I’ll get that added.
Someone else in these comments mentioned:
- Fuck spending 3 hours working out why you’re not able to use relative image paths in MDX files and have to shove everything in /public.
- Fuck fighting five layers of configuration and bundlers and libraries and GitHub issues to try and load a WASM file without having the whole thing break.
These were both issues we had to deal with, and similarly lost many hours to trying to resolve.
At one point you guys seemed to have shipped a release that, for some large fraction of users, caused the devserver to start OOMing rapidly. When this started happening to me, I spent about a day trying to debug it, since I assumed that such an a huge and imminent issue would arise from my mistake, not the web framework's. I eventually texted a friend of mine about the problem, only for him to tell me that they had been having the same issue, and linked to this thread.
https://github.com/vercel/next.js/issues/54708
Working with a web framework that's so unstable that fundamental features like the devserver break periodically isn't fun. I stop trusting the web framework, and when a bug arises I find myself having to check both my own code and Next's. Now this applies to some degree with any open source framework, of course - there's bugs in everything. But I have so little trust for Next at this point. We've collectively lost weeks of eng hours to just dealing with quirks of Next.
Right now we're really affected by the fact that the recommended way to cache database connection objects is broken in our repo (and some other users' repos, evidently).
https://github.com/vercel/next.js/issues/47099
This is another example of something where I naively assumed that the error was on my end, and spent days trying to debug our database configuration, hosting provider, etc, before realizing that at some point something broke and the recommended way of persisting these connections on the global object doesn't work anymore. What's the point of using a framework if I have to question whether it's working correctly every time an error arises?
It's a paradigm shift compared to the old way of thinking about React apps
In my company we've been using Next.js in production for a long time now and for us the app router has been key to increasing DX
We've had an awful experience with Next. There are undocumented, broken things all over the place. Migrating to the App Router was a huge mistake. 'use client' didn't work as expected, and we had to install workarounds and try out different hacks to get access to the most pedestrian features we could expect from any other web framework. This is the broad consensus among everyone else I know using Next - they felt lik…
Where are people dissatisfied with Next migrating?
Fuck next.js. Honestly. Check out how it bundles and sends the entire react-dom library twice to every user on every page view https://github.com/vercel/next.js/issues/51508 . Fuck 1MB of JS to render a static HTML page. Fuck the image component, and not being able to optimise your image unless you use their cloud service for no reason at all. Fuck spending 3 hours working out why you’re not able to use relative imag…
> Fuck 500kb of JS to render a static HTML page. Funny, trying to open the post's link ( https://nextjs.org/blog/next-14 ) with JS disabled, it renders a "beautiful" blank page.
I recently tried to rebuild my Jekyll blog with Nextjs. This felt way too hard for something that was basically a nunch of static pages, but I pushed through and ignored that feeling.
This, though? It's confirmation that my type of use case wasn't a priority for this library.
As someone new who started with NextJS v13.4 on AWS, I am also disappointed that AWS/GCP/Others don't support all of Vercel's features. That being said, the commenters here are being unfair and unreasonable. NextJS 13.4+ is nothing short of incredible . Are you telling me I can get a free , faster, opinionated, React implementation with 10's of finicky/unreliable/3rd-party Node_Module dependencies now seamlessly bake…