I tend to have the opposite reaction. I want a framework with a small API I can keep cached in my head. I don't want to worry about finding the magic switches to get it working the way I want.
The result is that when you go from project to project, people solve the same problems, again and again, in a different way. And create their own custom abstractions, badly tested and documented.
Eventually, the API you could "keep cached in your head" lead to a system you MUST keep in your head because it's very hard to follow how things work and you need to remember it all to be productive. Debugging, extending and onboarding suffers.
Another consequence is that there is still no Django/RoR equivalent in JS. Building any medium size app is a total waste of time, doing the same boiler plate over and over for problems solved 10 years ago.
Everybody has a boilerplate one of course. Nothing is standardized, so the ecosystem is not reusable. Any pluggable library must carefully chosen, then be manually integrated in your own Frankenstein creature, not to mention you end up with a TON of dependencies.
Vue doesn't have a big API. I learned the entire of vue in an afternoon.
It took me 2 weeks to understand react, and much more to actually write decent code with it. Practically, react is very unproductive without something like create-react-app because you have to take so many decisions about it for every new project. Simple things like placing a setInterval()/clearInterval() at the right place, or conditionally settings classes on stuff is not straightforward, anything more complicated must be meticulously though.
Because of this, when I give a training in react and one in Vue, the people from the vue training will immediately be 3 times more productive: their projects move faster, it rarely hit a read block later. I also get way, way less questions in the vue training.
Let's not confuse "barebone API" and "easy API". It's not the same.
I won't argue that bootstrapping a React project is more complicated than a Vue project. I will argue that React's developer ergonomics are much better.
> Everybody has a boilerplate one of course. Nothing is standardized, so the ecosystem is not reusable.
Not sure what you mean. We use CRA at my company and I can comfortably drop into projects I've never seen before with complete confidence.
> Simple things like placing a setInterval()/clearInterval() at the right place
This doesn't make sense to me. The pattern for setting/clearing an interval with the class-based React API is identical to Vue. With React's hook API it becomes even easier.
> or conditionally settings classes on stuff is not straightforward
How? It's just JavaScript, write a conditional. This is exactly what I'm talking about: you don't need to know how to conditionally set a class in React, you just need to know how to conditionally set a value in JavaScript. I get really tired of the "how do I do task X in Framework Y". I want to ask that question as few times as possible.
My go-to example to explain why I find React so much simpler is Vue's slots. It's an entire API that many people find confusing to replicate something that comes for free in React.
Depends for what. For industrial size project, a little, because of the better typescript support. But that's it. You have the same vscode and browser extensions otherwise.
> we use CRA at my company and I can comfortably drop into projects I've never seen before with complete confidence.
First, on this part I'm talking about JS in general. Only a minority of projects use react.
Of course, not all projects use CRA. Many projects use different versions of react with different things you can do with it. Many projects will chose different convention for adapting components, passing children rounds, talking to parent, binding function, etc.
And I _never_ see two react projects with the same me directory tree. There is no strong convention on it.
Then you must chose.
One project is using an inhouse store with useContext, on other use manual redux with that convention, on use redux with that other convention, one use redux-toolkit, one use manual mobx with that convention, one use mobx react, etc. None of them work the same. None of them integrated the same.
And that's just for one lib. One project as many of such libs, all integrated manually.
And yet, the CRA experience is supposed to be one of the best integration you can have.
When you come from another world like Ruby or Python, it's a mad house.
In fact, I'll argue than only experienced programmers manage to get a consistent experience in the JS world.
> Simple things like placing a setInterval()/clearInterval() at the right place
Nope, in react you can use lifecycle OR hooks. You have to choose. And they don't work the same at all.
In vue, for a simple hello world, you can even place the setInterval outside of the component and hapily modify the model, it will update. You don't have to figure out the lifecycle for small app, only for a reusable component.
>How? It's just JavaScript, write a conditional. This is exactly what I'm talking about: you don't need to know how to conditionally set a class in React, you just need to know how to conditionally set a value in JavaScript.
C strings are just an arrays of char, so you don't have to learn those pesky high level string objects in those modern language with all their new fancy API.
> My go-to example to explain why I find React so much simpler is Vue's slots. It's an entire API that many people find confusing to replicate something that comes for free in React.
In both case the user will google "how to get a reference on children components". There is now way you can guess that it's passed as props.
And then, you will want to have several children at different places. And now the illusion breaks, because props.children doesn't work, you have to manually pass each children as props, and you can use them nested as before. And because it's not a "feature", but a convention, you have to know that you need to do that for components that use it. So it's no more natural that slots.
While in vue, you still use slots, you just give them names. The feature is congruent from the simple use case, to the advanced one.
So maybe for the simple case it took 5 minutes in react, and 6 in vue, and the same time for the complex case. For a rarely used feature.
Both angular and ember are pretty close in my opinion.
They have a very, very limited scope.
They don't have to deal with the DB, the authentication, the permissions, the deployment, the creation of a REST API, the migration, the mix of several run times, uploads, logging, sending emails, session management, etc.
And yet.
Their support for i18n, validation, routing, caching, pagination, data formating and presentation - what they should be good at - is abysmal compared to what you can do with django/ror.
The only thing they are better at is templating and creating a hierarchy of components. Which is the least they can do given they are literally there to render the UI.
If you're starting from a set of APIs that are too complex for someone to keep in their head, it's hard to end up with a much simpler API.
Especially since people do use a large portion of the web's APIs.
For example, "prevent", the thing in the parent comment, is needed if you use javascript to submit your forms, but isn't needed if you have a form that is expected to be submit by the normal browser mechanism.
Webframeworks rarely are prescriptive to the point where they can default in one direction or the other on that point.. and thus we end up with another option.
That repeats many times over and we end up with a large API surface.
