I absolutely failed to follow the logic of this article - is there any?
The toy examples having the same amount of code is meaningless. They're saying it's bad because react is more complicated. But this works in react's favor that simple examples are simple.
It's also meaningless because it's a toy example. Even if the react code was half the size of the backbone, you could still use the strawman of "react's complexity isn't worth saving 5 lines of code" which people would agree with.
Then they go on to complain about use-effect and state-management. But use-effect isn't in the code example. But then why compare it to backbone which also doesn't solve those problems and is arguably much worse at them.
> People say "you need to rebuild React from scratch to really understand it," and they're right
Actually laughed at how shameless this is. Who said this? This is just a thing the author got and just decided is a fact. Not only is that quote not in the linked article, I don't think the average person would say this.
And the answer to what about something small, the answer is either lit-dev, or vanilla. It's not early 2010s, a lot of the functionality of libs like jquery, backbone that made them popular was incorporated into js.
> "react's complexity isn't worth saving 5 lines of code" which people would agree with.
If you look at the code the example shows, the replication is a bunch of HTML and tailwind CSS classes in backbone. So basically if you decide you want to change the input to have a different radius in one place, you need to implicitly know that there's another piece of code patching and replacing that elsewhere, which has duplicated the code.
I'm not one to pray to the alter of DRY like it's the end-all be-all of programming principles, but you take this pattern and repeat it throughout a production codebase and you have a bunch of repetitions that need to happen.
This is the problem with Backbone - it's edits are imperative - meaning, each one is a source of errors. React makes state updates declarative, so you only need write the rules just once. Somebody coming along to edit the code doesn't need to find the implicit relationships in the imperative code that might break or cause inconsistency, because they don't need to exist anymore.
Yeah. I don't follow react closely, but I do know Vue.js is still in very active development and releasing new features because of all the real use cases/bug fixes. Some of the use cases or issues didn't exist back in 2010 (e.g. interoperability with custom elements). "Look at how little progress we've made" only reveals author's ignorance instead of saying anything meaningful or true.
Put it another way -- you can find those "minimal JS frameworks" and create this same demo easily, but it doesn't mean the other JS framework is all that one needs.
I absolutely failed to follow the logic of this article - is there any?
The toy examples having the same amount of code is meaningless. They're saying it's bad because react is more complicated. But this works in react's favor that simple examples are simple.
It's also meaningless because it's a toy example. Even if the react code was half the size of the backbone, you could still use the strawman of "react's complexity isn't worth saving 5 lines of code" which people would agree with.
Then they go on to complain about use-effect and state-management. But use-effect isn't in the code example. But then why compare it to backbone which also doesn't solve those problems and is arguably much worse at them.
> People say "you need to rebuild React from scratch to really understand it," and they're right
Actually laughed at how shameless this is. Who said this? This is just a thing the author got and just decided is a fact. Not only is that quote not in the linked article, I don't think the average person would say this.
And the answer to what about something small, the answer is either lit-dev, or vanilla. It's not early 2010s, a lot of the functionality of libs like jquery, backbone that made them popular was incorporated into js.