Next.js is a cancer. I wish more people would see it sooner before Vercel completely destroys ReactJS.
I thought NodeJS itself was the cancer*. Hard to keep up with all the cancers I guess ;)
Next.js is infuriating
301–310 of 602 posts
Re: Next.js is infuriating
#302Earlier quoted context omitted.
Working with a client just last month that hired an African engineering group to build a tool for them. What they got delivered was a Next.js train wreck that was so coupled to Vercel's hosting that I couldn't make it run successfully anywhere else. The customer was a non-profit and didn't want to/couldn't afford Vercel's hosting so asked if I could try and make it run and I (naively) thought 'its just javascript, it…
[flagged]
When I read "African engineering group" I felt an instant "ugh" of recognition, based on my experience with software created by external consultants on other continents. My experiences were with groups in Asia and Europe, not Africa, so I think what the poster successfully evoked was the experience of dealing with differences of distance, culture, time zone, and commercial interest (engineers answerable to different management and a different bottom line,) all of which tend to produce inferior software compared to what gets produced for in-house use or sale in the SaaS market.
Re: Next.js is infuriating
#303Earlier quoted context omitted.
Angular is absolutely not a sane framework. I'd argue it used to be, but you can't build trust in anything after being rugpulled with 4+ major breaking refactors over the years. If you get it that wrong that many times, I start to wonder what the actual purpose of the framework is.
In consulting we don't do upgrades, we come, we deliver, and we leave, with maintenance contracts for existing deployed versions. For an upgrade someone has to pay for it anyway, so whatever pains there are, they are reflected on project budget anyway. More devs should do the math of work hours to money.
This really highlights one of the main differences between "product" and "project" centric work. With a project, it's the client's problem ($$$.) Usually they'll balk at the dollars and effort required and accept the risks. Even with an outdated, obsolete framework, the actual risks are often minimal. "It's still working, right?"
Re: Next.js is infuriating
#304[deleted]
Re: Next.js is infuriating
#305Earlier quoted context omitted.
My experience with Next.js are that its rough edges are a feature, not a bug. Everything is geared towards you giving up and just using Vercel's hosting
Working with a client just last month that hired an African engineering group to build a tool for them. What they got delivered was a Next.js train wreck that was so coupled to Vercel's hosting that I couldn't make it run successfully anywhere else. The customer was a non-profit and didn't want to/couldn't afford Vercel's hosting so asked if I could try and make it run and I (naively) thought 'its just javascript, it…
I haven't heard anything about trends, stereotypes, positives, and negatives regarding IT and development in Africa. Following HN's guideline to increase curiosity as topics get more divisive (as this subthread has), and looking for "the strongest plausible interpretation of what someone says" I'm going to assume the best:
What's the story here? I assume this group was chosen for a reason and didn't meet expectations.
Re: Next.js is infuriating
#306I feel a poor tool choice for your use case should not give you the right to blast the tool and it's design decisions. Most of those complaints are resulting from not understanding how NextJS works and the design decisions that it's creators have made. For example, the middlewares. they're to be treated as a hook. If NextJS had a mechanism for having handlers like Express does, you'd have complained about handler exe…
NextJS has been pushed aggressively by many people and often recommended as a kind of default for React applications. Which I consider a bad idea, in a large part because NextJS contains a lot of complexity that most applications don't need.
the React documentation is infamously responsible of recommending Next as a "default". After a lot of backlash it got somewhat toned down, but it's still the first thing they suggest[1] for creating a new app
Re: Next.js is infuriating
#307Earlier quoted context omitted.
Yep, been there. It is a lot better these days for React SPAs but it is still a pain. Fact is the only way around this in the frontend without a monolitic "batteries-included" all-encompassing all-knowing all-mighty framework is through standardization which can only be pushed by the browsers. Like if browsers themselves decided how bundlers should work and not have them be extensible. And this tooling-hell is not on…
Advances in the browser standards are slowly removing the need for most client side JS altogether so standardizing on some concept of bundlers would be a step backwards. Vast majority of web dev projects have zero need for an SPA framework these days and all this pain is self inflicted for little benefit. Those tools do have good use cases still but the chances that your project is one of them I'd shrinking all the t…
I don't think we will ever be able to get away from bundlers because there is no way to solve the waterfall request problem of using modules (one module imports requires another module). Maybe some kind of standard manifest spec that tells the browser which parts of the code to load upfront and which parts of the code to lazy-load, but to generate that manifest in an efficient manner you would need at least part of what the bundlers do today.
Minifying is also somewhat of a hurdle, I guess it could be done at the CDN level on-the-fly+cache, but that is also its own nest of complexity.
SPA frameworks have a place, if anything I think they will become more prevalent, but I can foresee WASM opening the door for non-JS language stacks. However they will need bundlers as well and some languages are just not built around giving ways to minimize binary size and lazy-load code. Just try to compile some C++ to wasm, you end up with 10+mb .wasm files.
Re: Next.js is infuriating
#308He made a whole new blog to complain about Next.js and built the blog with Next.js
Re: Next.js is infuriating
#309I 100% agree. I've ran into the same issues, and I would never use Next.js for anything, and I will encourage every team at work to use something else. In general Next.js has so many layers of abstraction that 99.9999% of projects don't need. And the ones that do are probably better off building a bespoke solution from lower level parts. Next.js is easily the worst technology I've ever used.
I'm so glad I'm not the only one thinking this. I built a medium-complexity, money-making, production-grade app in Next.js and started out on Vercel's hosting (and Google Firebase) and then moved to hosting myself and stripping out Firebase, replacing it with Pocketbase. Pocketbase was the ONLY good thing about this journey. Everything else sucked just so terribly. Infinite complexity everywhere, breaking changes CON…
I think the big complex FE frameworks are going to go away. After doing work with HTMX and Alpine JS, and Ruby on Rails with Turbo + Stimulus, I am all in on this paradigm. Basic JS, or a micro front end framework is all you really need.
Re: Next.js is infuriating
#310Earlier quoted context omitted.
Working with a client just last month that hired an African engineering group to build a tool for them. What they got delivered was a Next.js train wreck that was so coupled to Vercel's hosting that I couldn't make it run successfully anywhere else. The customer was a non-profit and didn't want to/couldn't afford Vercel's hosting so asked if I could try and make it run and I (naively) thought 'its just javascript, it…
Why accept the result? Send it back and have them deliver something usable.
It was running when they accepted it. However they didn't realize that the group was running the Django/Postgres 'backend' on a managed Digital Ocean instance, then there were two different Vercel 'projects'. It was costing hundreds and hundreds of dollars a month to run for a project that was VERY lightly used.
They paid them on the strength of seeing it working, but then the consulting group basically ghosted when the customer asked to adjust it to run on cheaper hosting (probably because they couldn't), then the site got shut off because the hosting was all in the consulting groups name and they stopped paying it. Digital Ocean nuked the database for non-payment and they lost tons and tons of manual work putting in data.