FUCK.
NEXTJS.

...

THIS PIECE OF FUCKING SHIT WORKED 4 DAYS AGO.

I CHANGED ***NOTHING***.

4 DAYS LATER I START THE PROJECT AGAIN AND HALF THE STUFF BREAK. NOTHING FUCKING WORKS!!!!!!!

SOMETIMES IT WORKS SOMETIMES IT BREAKS

MESSAGES GET SENT SUCCESSFULLY 2-3 TIMES IN A ROW AND THEN Random 401 error

Random page glitch flickering when routing to new pages rendering the content blank

Random list map iteration crashes on ui dev side

This is such a fucking SHIT

Now i started my angular and spring boot exact same project that i stopped worjing on since october 2023 AND EVERYTHING WORKS FINE WITHOUT ANY RANDOM ERRORS

RANDOM ERRORS ONLY HAPPEN FOR NEXTJS FUCKSHIT FUCKING FRAMEWORK

FUCKIEST DOGSHIT GORILLACUM MAD FUCKIJNNGG RETARD FRAMEWORK FOR AUTISTICS I WASTED SO MUCH TIME LEARNING THIS PIECE OF FUCKING GARBAGE!!!!!!!!!

Figure 1

JS ... Lol

Next is built on Webpack and Webpack isn't reentrant. Well, it tries to be but for elusive reasons every plugin eventually accumulates a lot of internal state. I try to avoid Webpack and anything built on it for this simple reason.

Skill issue

@lorentz @superdupernova @dontbeevil @ScriptCoded turns out all of this fuckery can be resolved by deleting fuckshit node_modules and package-lock.json!!!!

After upgrading dependencies there was a version conflict between package-lock.json and package.json

Or some other random caching dogcum shit!!!

And then running npm install again

@superdupernova npm works just fine. His issue doesn't appear to be with install times or multi package setup

Let the package-lock.json live it’s own life. You should never have to touch it or delete it. The lock file (and hence the node_modules) will evolve based on the packages you decide to list in you your package.json

NPM update is your friend

@b2plane enjoy node modules 🤣🤣🤣

sanity issue. no one in their right mind would ever use next.js

@kiki who told you i was fucking sane?????

@b2plane well, that's exactly what I'm talking about. Next.js is shit. You love shit. A perfect match.

@kiki i moved from angular to nextjs. Everyone shitted on angular and now everyone shits on nextjs. What do u want from me?!!?????!!

@b2plane that's modern JS programming ..enjoy

@b2plane nothing, Mr. 400k. You're using next.js, the framework with more than 2k unanswered issues on GitHub, made by a VC bitch company, and have the audacity to complain? Go frameworkless, like I did. The best coding decision I ever made.

@b2plane let me make it even clearer: It. Is. Your. Fault. It always was. Using next.js and complaining it is unstable is like using Windows 11 and complaining it tracks your every move. Like… duh?

@kiki i am NOT gonna waste my brain energy and time writing a vanilla frameworkless js code. Are you fucking insane? Thats the stupidest dumbest shit I've ever read. Its not 2002 anymore. You dont need to write a vanilla js frameworkless web app. Get ur shit together or get left behind

@b2plane I'm a CTO, and I write vanilla JS on both backend and frontend exclusively. I don't use frameworks, not even Express. We cut our time per feature time around 90% by dropping React.

@b2plane you claim frameworks save time, yet it's you who's wrestling with a magical black box while I'm shipping features.

@kiki Empirical verification is all you need, right?

I'm glad your advice works for you but the vast majority of devs, even good devs, need declarative frameworks with isolated imperative subsystems, automated testing, or static analysis to write correct code, because the majority of devs, even very good devs, make a lot of mistakes and so they need to code defensively to make the mistakes easy to detect. Your methods would probably work for like two people on this platform.

@lorentz I needed all that too when I was using frameworks. But going without one simplifies code to the point that I make fewer mistakes in JS than I was making with React in TS. I also don't say my approach is better for every use case (for example, it's very bad if I'm a Vercel employee that needs to demonstrate Next.js in action). I merely want people that are manipulated into thinking they NEED a framework by default for every app whatsoever that there is a way to go without it, and this way has advantages, and this way may work. Frameworks are proprietary instruments of corporate coercion.

@lorentz also, stop namedropping declarative things. The number one thing all of them need is good garbage collection and under-the-hood optimization. You can't meaningfully do that in JS without losing flexibility & having 100kb+ lib size. You have to use something like C++, and this is why the only declarative thing that really works on the web is HTML+CSS. Everything else is too inflexible, because when you try to make it flexible, it becomes slow.

@kiki vanilla js🤮🤮🤮🤮🤮🤮🤢🤢🤢🤢

But it depends on what you want to do with it. For a small project, you can just use plain js. Or use jquery for the sake of shortdickshit!

For a big project with alot of components and devs > 1, you can use any framework that you (and team) are most familiar with.

Do not use any other framework you do not know or the team you are working in. That is the best framework.

If everyone knows how to properly write JS, then create your own fucking framework and stop blaming other frameworks. If you can't get it done, it either doesn't suit your needs or you have a fat finger syndrome.

@d00td00t The number one question to ask is: are you actually developing a highly complex web application? Twitter, Facebook, Discord qualify, but 99% of the sites and shops out there don't.

They are websites, it doesn't matter whether small or big, they don't need any JS framework, and would only get worse with a JS framework.

I guarantee tomorrow @b2plane will be praising nextJS for some reason or the next

@d00td00t Next.js devs don't know Next. Next is made of React, React Router, Webpack, a handful of Webpack plugins and some custom glue. From all this, next.js devs usually understand React, a fraction of React Router and the custom glue, even though by far the largest part of the whole system is Webpack.

@kiki I agree that declarative patterns are slow without static analysis. This is a price JS devs end up paying to avoid some mistakes.

I really would like to see how you manage interactive UI without frameworks. I'd only ever seen query spaghetti and React But Worse (TM), the surprisingly popular practice of building document fragments in JS functions and just rebuilding the whole DOM when anything changes.

@Fast-Nop imo faster prototyping with a framework, especially different teams developing features for one webapp

@lorentz oh, easy.

1. Do the entire UI in raw HTML and CSS, as if it was an ux101 assignment. If something can be done in CSS WITHOUT sacrificing a11y, do it

2. Identify the dynamic elements. Add class names that start with js-

3. Initialize lists. Using the first element as an item example, clone it with cloneNode(true), then delete the original DOM node.

4. Fetch the data. Write a purpose-built controller in advance that will return you just the data you need. I have a LOT of purpose-built controllers that are just SQL wrappers

5. Update singleton (non-list) elements with querySelector().innerText =

6. Using previously cloned list items, render lists. To update them efficiently, use a react-style key parameter, store it as a data-attribute of the item root, then selecting elements with querySelector('.js-item[data-key="${key}"]')

Disclaimer: I'm yet to have to deal with huge lists. When the time comes, I'll implement some reconciliation. In the meantime, here's my toolkit

@lorentz as an active React user of six years that started their frontend journey by learning React, I had a hard time accepting that those seven functions are unreasonably effective. After I was converted, almost everything else seems like premature optimization to me. The scary part is 90% of what I do now and what I ever did during my career never scaled to the point it needed something more than my current approach.