[austin-cheney]

Components are themselves a form of added complexity. The idea is to deliver a composed and self contained code island. To accomplish this you have a big ball of markup, presentation, event handling, business logic description, and then security and accessibility logic to compensate for the prior mentioned abstractions. What you see in your editor may not look like much, but just under the hood is a colossal mountain of foolishness.

Why do people prefer this? It doesn't increase speed of maintenance. Its preferred because its composable to a predefined architecture scheme the developer is comfortable with. That's it. Its just about comfort, but the complexity is through the roof.

Simple isn't free.

[vacuity]

From what you're saying, it sounds like components in this framework (React?) are not simple at all. A major hurdle in evolving a program is capturing and maintaining simplicity. The proof of whether something is simple lies in its composability, readability, and so on. If someone claims to have found a method of writing simple components, do not believe them if the simplicity is not evident. A truly simple solution would not be so burdened, and a somewhat simpler solution would be less burdened. Of course, simple still doesn't mean easy, because the Fast Fourier Transform may be simple, but I can't teach it to a 5 year old (or anyone, really).

Never religiously cling to statements such as "strictly separate presentation and content". These are all just guidelines to suggest simpler solutions, not hard rules that guarantee simplicity. They will sometimes be excepted.

There are such things as components, which compose strictly by interfaces and externalize separate details, but it is up to the programmers to realize them in their programs. Also, simplicity is a global property of a system. Nothing can be judged on simplicity in a vacuum.

All that being said, I don't have experience in web or UI in particular. Seems like logic is moreso a local thing, whereas presentation is moreso global (but may consider locally defined advice). State can be local or global.

[austin-cheney]

You are mixing your terms. Complexity is another word for many. As such it is measurable objectively. The opposite, simplicity, means fewer.

Readability is highly subjective. At this point you are talking about what is easier for you. Easiness is not simplicity. Simplicity, in almost all cases, requires addition effort and that is not easy.

[vacuity]

I did say that simple doesn't mean easy. I don't know how to judge whether something is many or few without a fixed norm, nor how to measure it without reference to the environment it exists within. Simplicity does not mean having so little to the point of unease.

"Everything should be as simple as possible, but not simpler"

- Einstein (probably[0])

Brainfuck is a simple language. A Brainfuck program written to parity with an existing non-Brainfuck program is likely complex. A musical note is simple, but a musical score may be highly complex.

I think your objections are misplaced.

[0] https://quoteinvestigator.com/2011/05/13/einstein-simple/

[knollimar]

Composability is really valuable; you don't get bogged down in interconnectivity when your application gets really big.

You pay for it for smaller stuff, though, since that multiplicative coefficient is high.

[austin-cheney]

I don’t have that problem with large vanilla projects. It’s just a matter of organization and this is supremely straightforward when making heavy use of TypeScript interfaces to define that organization.

[qudat]

I’m not sure i could disagree more with a statement.

Reacts innovation is simple: view is a function of state.

Before that we had to construct the ui imperatively where we managed state AND ui transitions to state changes. Now we mostly just focus on rendering a ui based on the snapshot of state we have. It is revolutionary (for ui dev), it is scalable, it is the reason why react STILL dominates the ui landscape.

React isn’t just popular because it’s familiar, that might be a component, but it ignores the historical and technological achievement it created

[KingMob]

To be precise, React was the first (afaik) to apply that to web UI, but definitely not the first to apply that to UI in general.

The basic idea of a unidirectional loop is how video games were built for years before React.

[austin-cheney]

I have had other people tell me this because they perceived state management as a challenging problem to solve. That is true of the big frameworks, but otherwise state management is a ridiculously straightforward problem easily solved.

[scotty79]

React came to be because folks at Facabook couldn't get the label displaying unread notifications always to display correct value. This seems like ridiculously straightforward problem easily solved. Yet still many websites and applications today struggle with that.

[scotty79]

I'm getting downvoted into oblivion but you can hear it from horse's mouth:

https://youtu.be/nYkdrAPrdcw?t=757

[austin-cheney]

I stopped watching the moment the speaker correlated imperative code to fragility. All code is inherently fragile. The only thing that makes code durable is not failing. Failure can be minimized by separating code into portable units that do nothing more than achieve a singular purpose.

Secondly, they kept talking about this creeping complexity in their code base of about 8 lines of code. 8 lines is still ridiculously tiny. I suspect their actual concern is that the code did multiple things like decrementing a number and modifying a state. I understand this was before TypeScript where execution can be planned against an interface, but I still would have created an object that stores all the relevant data they need to modify on each interaction.

[scotty79]

Apparently you are smarter than the team that created the library that spontaneously taken over nearly entire field of front-end development. Good for you!