Earlier quoted context omitted.
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…
it might be a bit over the top but there is Cogent Core[0]; it supports apps on desktop, mobile apps, and the web. it even supports 2d and 3d. and it's all in go, backend and frontend (using WASM). [0] https://github.com/cogentcore/core
Next.js is infuriating
551–560 of 602 posts
Re: Next.js is infuriating
#552Earlier quoted context omitted.
Basic react experience presumably. As a first approximation, it seems like every possible interview sounds like a bad interview to someone. What has worked well for you?
Seems more like a test on random React minutiae. Like, let's take some framework, take away some random piece. How well do you know the area around that random piece we just removed? Frameworks are large and gnarly (or there isn't enough to them). Expecting a candidate to be lucky and know random implementation details in the area that happened to be picked doesn't seem like you'd select for anything other than luck.…
It's like not knowing how to write a for loop or how to access an object's property in JavaScript.
Re: Next.js is infuriating
#553Earlier quoted context omitted.
Then why did HTML became so popular if win32 or MFC were so great?
> Then why did HTML became so popular if win32 or MFC were so great? One of the factors is that web dev pushes for a complete separation of concerns, and thus allows frontend developers to specialize in front end development. Therefore it becomes far easier to hire someone to do frontend work with a webdev background than a win32/MFC background. Number of applicants is also a big factor. There is far more demand for…
Then there came small web applications, and still no "front-end developers", since functionality could only work on the server.
It's only when AJAX was introduced in the mid 2000's that you could start to talk about "front-end developers".
By that time, win32 and MFC was old. We had Java, C# with .net framework, etc.
Re: Next.js is infuriating
#554Earlier quoted context omitted.
Nope my dear, you're the one insinuating that logging works out of the box in production quality deployment without any kind of additional configuration or code changes, hence please make use happy, where that is the case. Word vomit into standard output isn't production quality .
It seems you might've missed functional reading class. The first thing I led with was that you need to import and initialize logging which covers both of those. You're the only one insinuating the strawmen you're arguing against. This isn't Reddit, surely you can do better.
I do whatever I feel like, you're the one that started down this thread, don't complain where it goes.
Re: Next.js is infuriating
#555Earlier quoted context omitted.
Really, which ones? Because anything Java, .NET and Python, it certainly requires configuration and related infrastructure.
> .NET I think you haven't used .NET in a while. Nowadays, logging is absurdly easy to configure. Heck, you usually don't even need to configure it, because the basics are already included in most templates. You just use the Logger class and it works. The only time you have to spend more than 30 minutes on it is when you use some external logging libraries. And most of them are quite sane and simple to use, because i…
Java, .NET and nodejs are all over the place around here.
The point was without configuration.
Logger class doesn't do the work for production monitoring, without additional configuration so that its output appears on the necessary production dashboards.
Re: Next.js is infuriating
#556Earlier quoted context omitted.
their issue with breaking changes is from way before the Remix days - React Router introducing massive breaking changes at every major that required significant rewrites was already a running joke of the community
Their documentation was also abysmal the last time I used their product.
New devs coming in and expecting the framework to be with "batteries included", which it absolutely is not, will also have a bad time. Node apis, ALS/context, handling app version changes on deploys, running the server app itself (if in cluster mode, e.g. with pm2, what that means in terms of a "stateless" app, wiring up all the connnections and pool and events and graceful reloads and whatnot...), hell even basic logging (instead of console.xxx) ... all of that is up to you to handle. But the framework gives you space.
People new to React and/or Node will be confused as hell for quite a bit... in such a cases I would add like 3 months of personal dev time and learning to just wrapping your head around everything... React docs themselves say that you should use a framework if you're using React in 2025 - but it's not that easy. There is a cost, especially if you go the full stack route (client + server + hydration) of having everything under one "typescript roof". The payoff is big, but definitely not immediate.
Re: Next.js is infuriating
#557Re: Next.js is infuriating
#558Earlier quoted context omitted.
I don't agree. Having front-end and backend in the same language is so convenient I would never go back to doing it the old way. I'd rather compile the frontend to WASM than introduce a mismatch. I used to use Django and there were so many issues that arose from having to duplicate everything in JS and Python.
What about HTML? Are you writing HTML via JS - if not you're already writing multiple languages.
The issue with mixing languages is that they have different data models, even simple things like strings and integers are different in Python and JS, and the differences only increase the more complex the objects get.
Sometimes I write some code and I realise that this code actually needs to execute on the client instead of the server (e.g. for performance) or the server instead of the client (e.g. for security). Or both. Using one language means that this is can be a relatively simple change, whereas using two different languages guarantees a painful rewrite, which can be infectious and lead to code duplication.
Re: Next.js is infuriating
#559Earlier quoted context omitted.
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…
" Codebases from years ago are still rock-solid." This is the biggest thing for me. I recently pulled down an 8 year old hobby Java/Maven project I had and it compiled and ran perfectly on the first try. Imagine trying to get an 8 year old javascript project to work...
Re: Next.js is infuriating
#560Earlier quoted context omitted.
> I 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. Things will get far worse before they get better. Right now, online courses such as the ones in PluralSight are pushing Next.js on virtually all courses related to React. I have no idea what ill-advised train of thought resulted in this sad state of affairs but here…
The train of thought is “what is everyone using? I’ll use that too”
It's also dismissive of market forces, i.e. developers have to pay bills and therefore are easier to hire if they know the skillset that is in wide use.
I've never worked or interviewed a single senior that wanted to use Next.