But then you're forced to use React...and as soon as you need to do anything outside of what it provides it all falls apart which happens pretty quickly in my experience with it.
You don't have to use React. The template gives it to you, but if you delete all the code and never import React, you're never using it. I use CRA nowadays for either simple vanilla JS/SCSS brochure-ware sites, or for simple TypeScript sites
What have you been doing that React doesn't handle?
I'm one of those people who is very, very suspicious of imports, and barely ever uses anything outside Vanilla JS, but even with that mentality I have to admit that some libraries have their place. These days I usually use Preact (basically a stripped-down React) and I've not really come across much that it can't handle.
The key for me has been to just write isolated components, and avoid the "full page application" anti-pattern that is so common in web applications today. React doesn't force the anti-pattern on you like other frameworks, so I've had pretty good luck with this. It results in fairly clean, reusable code, and users see positive benefits because it allows me to create consistent, predictable interfaces.
React Router used to be a mess. And should I use Redux? I thought it’s not cool anymore. If I do, do I store everything in a global state? Maybe I’ll use Context and Hooks. Or was it HoCs? And what about mobX? I heard it’s like Vue. I like Vue. And I absolutely need something to handle requests. Saga? Maybe some GraphQL? Now that I have my views, my state, and my data, how do I test this? Jest or something else? But why write tests if I have Types! How to configure TS? A few any never hurt anyone, did they? Too many questions. I’ll let Create React App answer this for me. Or is it Gatsby? Or even Nextjs? Oh, and is Lodash the new Underscore? And what is different about those and Ramda? We need more FP! But how do I structure my Code? Dan “Daddy” Abramov tells us to organise it any old way. But how? [0]
Angular and to a lesser extent Vue give you more direction.
This is of course not inevitable in a React project, but it does take good technical leadership not to be hindered by analysis paralysis before you even set off.
0 - An exaggerated summary of what I gather on various forum and discussions.
Everyone worries about these choices in react, but you don't need to, for most apps, they're all good choices: use redux or mobx, doesn't really matter. Use lodash or underscore, doesn't really matter.
There are minor advantages to some of the tools, and the nice thing about the react ecosystem is that it lets you pick if you really need to, but for getting started, just pick one and move on.
IMO this is highly preferrable to the angular world, where some things just can't done without digging through poorly documented internals (at least this was the case wirh v4 when I last used it)
> Everyone worries about these choices in react, but you don't need to, for most apps, they're all good choices: use redux or mobx, doesn't really matter. Use lodash or underscore, doesn't really matter.
I'd argue that they're all bad choices.
Redux/Mobx are just causing you to use global state, which forces you into a single-page application anti-pattern. I've stopped using either and my code has become massively less complex.
Lodash/Underscore are massive libraries that you end up using only a few functions from. Many of these functions can be written in <10 lines of code yourself, and some are equivalent to ones that already exist in newer versions of vanilla JS. In the latter case I'll often use polyfills, and remove them as support for the new features gets good enough.
That's true, but in that case observables are little more than syntactic sugar over callbacks. The way I've seen them used in codebases a lot is to decrease the pain of global state--but that's only delaying that pain, and global state SHOULD be painful.
That said, I suppose the answer is just, "don't do that". I may have spoken out of ignorance of how people frequently use mobx, since my experience with mobx is very limited. I probably should have constrained my statement to only talk about Redux, since I have a lot more experience with that.
I agree. And since much of that is often superfluous, you end up with a “minimal” setup. Though this does require at least one experienced dev to make those choices.
And my experience tells me that fewer than 1 in 10 React devs can make those calls.
I've used React for a while now, and I agree with you that most of these libraries are pretty garbage. I've solved this problem by just not using any of them.
These days I use two libraries: Preact and Immer. And I only introduce Immer to a project if state management becomes a pain point in the project, so I often don't even use Immer. I import these in my project with:
<!-- in my base HTML template -->
<script src='path/to/immer.js'></script>
// in my JS
import { h, Component, render } from './path/to/preact.js';
import produce from immer;
This is sort of janky because Immer doesn't provide a real JS module, but basically all this does is pull in a total of four variables: h, Component, render, and produce.
The app I currently work on is 100% runtime plugin based. React has not been an issue there at all. I haven’t tried using web components, though, so can’t speak to that.
it's not impossible, I have something working with react-registry. With Vue it would work out of the box since it comes with a registry out of the box.