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.
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.
- runtime plugins
React is great if you stay in the design constraints, which is to be expected. This covers the vast majority of web apps.
edit: [removed svg snippets] I think I was confused with WebComponents not supporting svg elements that don't include the root tag
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.
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)
And my experience tells me that fewer than 1 in 10 React devs can make those calls.
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 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.
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;
Can you elaborate on what you run into?