Why is that, I wonder?

The code, too, has to be tailored to fit into the specific architecture of the program.

It might create a bit more code in components, agree. I think this is a fair price for the all benefits it brings.

That said, the total amount of code might be even less (no action-creators, reducers, etc.).

Also declarative nature of the libraries makes the added code very easy to follow.

this.

Granted, it's the same with everything- if you expanded every compressed file and counted every class, most languages and frameworks would just be incredibly nuts, because all of them aren't needed.

But, something could be done about that; you could better differentiate what is there for convenience, and what needs to be there and make the developer more aware of what they are using. It can make development more difficult if done poorly, but good examples of minimalist development are out there, e.g. Sinatra and similar frameworks that said X is too much- just use this.

This feels a tad reductionist based on my experience. Sure, most apps are designed around an agreed-upon set of affordances and design principles that the community determines, but modeling application behavior for real-world scenarios involves way more than theming a bootstrap component. I think it’s a mistake to reduce a developer down to the code that they write, because the ultimate value of a developer is in the code that they choose not to write just as much as the code they do write.

Yep, if application started to grow, it'll require significant refactoring at some stage. But many application won't grow and using framework for something like 5 services looks like overkill for me.

I'm not sure if maybe you're referring to the Options<T> stuff?

The way I do it is pretty simple.

1. Create a POCO that represents your config. You can have properties for bested configs if you want, e.g. SecurityConfig, MessageBusConfig 2. When the app starts, use a ConfigurationBuilder to build an IConfiguration from whatever Co fig sources you want - typically JSON files and env vars 3. Bind the IConfiguration to your POCO 4. Configure both IConfiguration and the POCO as singletons

Now you can inject the POCO config object wherever you want it, or the IConfiguration should you need it. I feel like this is simple, and works well for dev, test and prod.

Not sure what apps you've built, but usually that business logic is the minority of the codebase. The rest of the stuff is boilerplate, like drawing boxes, describing layouts, handling events, managing state. All this has nothing to do with business logic.

Ideally, I want to write it once that I want a row of buttons what colors they have and what function should be called when the user clicks on it.

I did what you describe and extracted all the logic in a small component I manage and the result was very banal, extremely straight forward code with was essentially "business logic". The 90% rest was building the UI based on it.

100k is not small, but also not particular large; even for one single app with highly interweaved code. My companies main codebase is around 800k lines and I consider it as middle sized.

But lines of code are not the problem. The length of your code paths is it. Understanding the flow of one or two functions, ok, not that hard of a problem. Having your data flowing through some dozen functions, big problem. Complexity kills any understanding at some point. Or you need to invest unnecessary much time for it.

That’s how I was taught to do it. But I’ve yet to see people take the time to do this in real-life Code.

I'm not a fan of single-class-per-file as a rigid rule, but it's not my effect that it has any effect on architecture. Adding a file with a new class isn't substantially greater overhead than adding a class in an existing file, and moving stuff between smaller files is, if anything, easier than moving it around within a single monster file.

I’d be generally in favor of such a change as this is what I use for all of my projects when I start out. I find it much more comfortable to deliberately opt in to things that I need as I find that I need them.

The biggest pain point I’ve experienced is for features that are performance based when I am writing an application instead of a library. It’s hard to know that those exist, and that I probably do want them, I just don’t require them.

This can go both ways - I've seen plenty of projects where you have to dig through 3k lines of unrelated spaghetti code just to find the bit you need. That turns into a special piece of hell when you have multiple team members working on it.

The original motivation for having more small files was driven by these "god objects" and the limitations of version control. CVS, Visual Source Safe and to a lesser extent Subversion were much easier to use together with smaller files.

If you're using modern version control (git) then that reason has gone.

My personal preference is to split horizontal concerns into their own modules and depend on them; they become the core / support libraries for my team/organisation. For services I try to keep the domain-specific parts close. Tests go in a different module which mirrors the structure. When units start to get big (or become cross-cutting) they get factored into smaller units or other modules.

In the end it's all a balance and unless you're under outside constraints (cough SonarCube box-ticking busywork idiocy cough) then you can generally keep it sane.

Can you elaborate on this ? Which trouble you came across while using which low-code builder to build what kind of complex app ?

As opposed to a multitude of implementations of varying quality and functionality for the same concept in each init script that needs it?.

Yet people do this everyday. So it's not that complex.

There's probably no denying this is a good idea. :) The most successful very large systems seem to be made of independent modules that each strive to do one thing well. They can also be more easily removed, refactored, or replaced, due to their small size, and perhaps most important you can do one at a time.

> I think there's a lot of emphasis on preventing bad code from existing. But if you believe some bad code is inevitable, then it's more important to make it easy to fix when it happens.

Yeah, it's true, emphasis at any given moment is on what list of things we want to see, and what list of things we don't want. The author even started with one. Problem is, code styles also change over time. What some people call reasonable or good code, other people call bad; "bad" is subjective. Hire a brilliant engineer to help make your decent application awesome, and her first reaction may be "oooh, this code is pretty bad. let's make some changes". I honestly wouldn't be able to count how many times I've seen the newest member of a project complain about the mess while nobody else seems to mind that much. (And I count myself in that list, I've done it too.)

What about React? They say right on their front page: “Build encapsulated components that manage their own state, then compose them to make complex UIs.” That’s a textbook definition of OOP.

> it is better to deal with it without using OOP

That’s a famous example but why do you think it’s always better? Sometimes, like when dealing with graphs, holding the jungle with the banana is exactly what you want.

> If the focus of your code is reusability and modularity

My primary focus is meeting requirements and budget. All technical decisions about reusability, modularity, performance, and the rest of them, are driven by these two.

Some projects don’t need reusability at all, because that’s research, or a proof of concept, or a video game that won’t be maintained once launched.

In other cases, being too aggressive about eliminating duplicate code can harm long-term maintenance. More likely to happen in higher-level parts. You introduce an abstraction, then you need to handle just one special case where the code being reused needs to behave differently and introduce a parameter. Repeat a few times and you now have tons of parameters, flags, and other crap no one understands, not even you. This happens regardless on OOP/FP/procedural, the crap is different in these cases but its effect on maintenance cost is equally bad. Wouldn’t happen if you would be more conservative about introducing abstractions, and instead copy-pasted a few lines of code here and there.

> for most modern programming the performance cost is no longer a factor that matters

Almost everything has a performance budget. For a web app difference between 1ns and 1ms doesn’t matter at all, but difference between 100ms and 1 seconds still matters, users will complain, search engines will downrank. Desktop apps ideally need to respond within 17ms because mainstream displays render at 60Hz. Performance cost of immutability is huge, can be 1-2 orders of magnitude, for 2 reasons. (1) memory allocations are relatively expensive (2) CPUs have cache hierarchy, main memory is like 20-40 times slower than L1D cache, each time you allocating a new immutable object it’s pretty much guaranteed to be out of caches.

Still, there’re many cases when immutability is fine. C# immutable structs are awesome, unlike classes they’re free in terms of memory allocations, and they are usually on stack which guarantees they’re well cached. The upcoming C# 9.0 has a language support for immutable classes, pretty sure I’ll use it a lot once released and debugged.

> Games and Databases are two examples where FP may not be the most appropriate paradigm due to the performance critical nature of the areas.

Also CAD/CAM/CAE, realtime multimedia, some projects in embedded esp. real-time stuff. By the way, these areas are what I mostly do for a living.

> If your class does not hold mutable state then essentially it's just a class repurposed as a namespace with syntactic sugar

I like that sugar, and using that approach quite a lot in my code. For example, private methods and fields are invisible from outside, makes life easier because they don’t show in intellisense. I disagree that OOP promotes mutable state for cases when it’s not needed, it all depend on the language. JavaScript or Python don’t support immutable properties of their objects, but C# and (to lesser extent, but still) C++ do.

However, the real value of OOP is when you have to deal with complex mutable state. Every single time mutable state is essential to the problem (rich GUI is just one area where it’s the case, there’re others), OOP has no good alternatives.

They were saying that for a long time before hooks when the only way they had it implemented at all was for classes, and functional components were usable for much narrower use cases. I suppose, if they could have done it cleanly with classes, they would have, whatever that meant saying to those downstream who aesthetically preferred functions. I don't know if it inherently worked better with functions, if the core devs themselves are just more proficient in that style, or if it was just a confluence of experience and the timing that the push to improve functional components occurred, but in the end functional components are just much cleaner.

That will always happen, and I've seen it happen in a monolith too (expressed as module ownership/ownership over part of the codebase).

It's inevitable in almost all organizations.