On the level of practical risk: on the security level libraries are much more risky imo. A good framework for most project i've seen will lead to a more structured and secure codebase. Probably precisely because there is less room for creativity.

For instance Laravel is very structured: orm, auth routes, controllers system etc., where express.js let's you do whatever.

And almost all Expressjs or other Nodejs projects i've joined were a mess and had security issues, something as simple as CSRF tokens, or not allowing redirects to external domains, are often forgotten or not fully implemented.

Doesn't mean I don't sometimes prefer a library approach, but the developer(s) need to be a lot more qualitative.

oh, Laravel is actually an excellent example. It has a lot of hidden "magic" knowledge inside and it takes many months to get a good understanding of how it works. Until then it is trivial to make bad decisions based on this wrong knowledge. Lack of proper IDE support (because of laravel's dynamic nature) doesn't help. And yes, I know about laravel-ide-helper. It has it's issues too

I’ve been working in some largish Rails codebases lately and this is exactly the problem I have. When I’m looking at a screenful of code I have no idea who is calling what, what’s in scope and from where, and what the shape of any of my data is.

In my opinion the productivity benefits of these kinds of frameworks evaporate and go negative pretty quickly once you move very far beyond what they provide out of the box.

I think a lot of that has to do with Ruby not having real modules and everything being global.

Yeah. I prefer Rails, but I'm fluent in python too, and the lack of explicit module importing was a mistake in my opinion.

This hits home for me right now. I'm currently battling some performance problems related to a lot of "magic" that happens when using the Apollo GraphQL framework and am strongly considering ripping it apart and taking back control of what happens and when.

Would be super awesome if you could share what you find! Having the same issues here - and I have a real time accepting that stuff becomes slow when you wanna return over 1k records. Sometimes way less for advanced things. Read: nested objects. But that slow? Come on.

I also use nestjs and there it seems updates to how to resolve a field has made it tons faster l, purely looking at the trace.

And I know that it won't be as fast as regular old json due to the checking but that slow? Must be something someone can do :)

Large queries with lots of nesting is exactly the situation I'm in. Perform a mutation and boom - very slow response from useQuery().

Is Apollo GraphQL helping you more than REST + queries?

I think it helped us to go really fast at first. Observable queries and subscriptions made it relatively easy to make the site feel very live and collaborative. Not sure how much help it is now as some of the magic is causing performance challenges

In a similar vein: boilerplate code is fine in the main control flow. It’s okay if it takes twenty lines of code to set up your library, as long as it’s not the same 20 lines for everybody in production.

Frameworks tend to avoid any boilerplate in the imperative core but then multiply I throughout the rest of the project. Possibly due to chronology.

How can a library providing only sync functions a good thing? Lots of IO is inherently async and it makes little sense for a library developer to go out of his way to make it synchronous only for the callers to make things asynchronous again. If something is async, it's async. You deal with that.

Also, I don't see why one would even consider using a framework if squeezing out every bit of performance from your hardware is that important. I can't imagine writing a Web app without some framework in the interest of time it takes to develop. Then writing a hundred of the same stuff again? You just have to ensure you don't use a bloated framework which is akin to not choosing a bloated library. Unless you are working on a device layer, it's not our job to spread things over the hardware. Unless you have direct access to memory, you can't do this anyway with most of the languages designed to develop apps. I think the primary goal of an app developer is to implement the business logic correctly and securely in a reasonable time. I agree with the OP that libraries should be preferred but I don't see a problem especially with performance in the domains frameworks are used.

Good luck using any sort of GUI toolkit then. Virtually every single one requires you to sacrifice the very top level of your program to some sort of "MainLoop()" function.

(I agree with your main point, and the above fact causes a quasi-allergic reaction in me which causes me to avoid GUI programming - despite graphics being one of my favorite topics.)

Try the "imgui" library?

Sadly even imgui cannot get around the fact that many operating systems (macOS/iOS/Android) force you to give up your main thread. Linux and, perhaps surprisingly, Windows are good guys in this regard.

Instead of using something you're quasi-allergic to, you could work on one you're not?

Rhw issue is that it's not exactly possible, especially on Mac, where your initial thread is sacred and for OS use only. Windows and Linux UI libs need a main loop somewhere, but it can live on any thread and in fact doesn't need to be structured the same.

You could make a point that programming is managing flow control.