>The real painful part of the process is caused by everything around React, including the build tools.
Can't agree with that more. I really like the way react works. It just makes sense and doesn't get in your way very often.
BUT it's incredibly frustrating dealing with npm dependency hell. Especially if you really are concerned about security and don't just trust that "someone else has probably made sure this code is safe, right?"
I just want to use something for longer than 6 months :(
You can perfectly use React without npm. Just download the prebuilt development and production versions of react and a simple <script src="..."> would do.
Right. React itself appears somewhat reasonable, except I am not entirely sure that putting entire app state into a huge clusterfuck of json is going to scale, but I am trying to reserve my judgement until I try it myself. And shadow DOM... sigh. It's a cool hack, but it feels like surrender to me.
FWIW, as an experienced developer whose instincts are probably quite similar to yours, I do recommend keeping an open mind with tools like React. They're different to a lot of more traditional tools, but like optimisations and profiling, they're best judged on their real world results rather than against dogma.
I'm not sure where you're coming from with the "huge clusterfuck of json" comment, but where the source data comes from is quite cleanly separated from how it's rendered using React, with one major caveat I'll come back to in a minute.
React itself is essentially a tool for rendering templates but with a declarative programming style, plus one fundamental performance optimisation that makes that declarative style fast enough to use in practice, plus a small number of hooks to integrate quite flexibly with other parts of your code and to allow for further performance optimisation if you need it.
Of course, there is no magic and there are always trade-offs. Most visibly, like any declarative system, sometimes the costs are significant and you do need to give it a hand to get acceptable performance. This is where the caveat I mentioned comes in, because you'll find a lot of projects using React also wind up using immutable data structures of one kind or another to store their model state. That lets you do fast comparisons based on identity rather than deep equality to see whether relevant parts of your underlying model data have changed, and thus lets you bypass the whole re-rendering process in areas of your UI where nothing interesting has happened. There are a handful of knock-on effects in practice that you have to deal with sometimes as well.
The upside, of course, is that you get much the same advantages as any other declarative programming style: your rendering logic tends to be simpler, more concise, more amenable to analysis, and less subject to surprising interactions and edge cases than more traditional, imperative rendering code tends to be, and all of these become disproportionately greater advantages as the complexity of the rendering and/or the underlying data model grow.
Yeah, our consultants set us up using immutable.js. Of course then it turned out that some components don't work with it, causing more craziness.
By "huge clusterfuck of json" I meant that it appears that entire app state is combined into a single huge data structure, which has its positive sides (like ability to save and load state easily), but also sounds scary on an intuitive level.
Again FWIW, my experience is that Immutable.js is a decent library, though the documentation is not very helpful.
Storing application state within a single immutable tree might be counter-intuitive but doesn't really make much difference to anything important. That data was going to be stored somewhere anyway, access is reasonably efficient in JS, and as you say, sometimes it has useful practical advantages.
One thing I would say is that nothing actually requires you to store all of your data in a single immutable tree like that. I've found some patterns tend to come up often when designing UIs with this sort of architecture, and in those patterns a small number of immutable data structures are used instead of one monolithic one.
For example, sometimes it's advantageous to have one structure that contains strictly the underlying persistent state that you'll ultimately store in some database on the back end. If you also need some supporting data derived from that first structure for presentation purposes, you can still create a second, also immutable structure, that is basically a clone of the first but then with the supplementary data added. Doing this sort of manipulation is usually reasonably efficient with Immutable.js because you basically have copy-on-write semantics for everything, and the logic for deriving the supplementary data tends to be easily tested.
Well the truth is you can build React apps any way you like. React doesn't dictate anything beyond the rendering. Redux, with Redux-Immutable & Immutable.js is my current "stack" (hate that term) - but when I first got started I built a component library with barely any logic behind it. That's when I realised just how great React is.
It's made building my web apps front end fun again and bring in big changes is so much quicker than old school dom manipulation.
Took me a long time to become a believer, intuitively I rallied against frameworks, but React is amazing.
>The real painful part of the process is caused by everything around React, including the build tools.
Can't agree with that more. I really like the way react works. It just makes sense and doesn't get in your way very often.
BUT it's incredibly frustrating dealing with npm dependency hell. Especially if you really are concerned about security and don't just trust that "someone else has probably made sure this code is safe, right?"
I just want to use something for longer than 6 months :(