> Teams end up spending half of their time or more solving problems that could have been accomplished quickly with some off the shelf React libraries with numer

> Teams end up spending half of their time or more solving problems that could have been accomplished quickly with some off the shelf React libraries with numerous tutorials online. I dunno, having seen both sides, there are pros and cons to each. Teams that reach for libs quickly often think in terms of libraries instead of solutions (one recent example was some folks who were asking for my advice on some over-engineered client-side PDF generation thing, and me suggesting `window.print()` as a solution, considering this was for an internal tool and you effectively want print stylesheets anyways), and often use them as crutches due to a self-fulfilling cycle of "I don't know how to do X, let's use a library so I never need to find out" (and then pulling in a huge lib to do the job of a literal one-liner regex - `uuid.validate()`, looking at you). In my experience, they also often end up buried by their own complexity due to gluing too many things together. But at the same time, it's hard to argue with the ease with which one can plop a modal dialog or a calendar or a collapsible table in a React app. I find that teams working with more exotic technologies tend to be more creative with solutions (e.g. "oh there's no zoomable map UI lib bindings, so let's ask ourselves, do we really need a map library for that contact us page or is a static jpg good enough?") and a have a deeper appreciation for how hard things are to implement. But conversely, UX can suffer from too much "creativity". For example, if care is not taken w/ accessibility concerns for some UI element. Or, as you said, things just take longer to ship because people need to reinvent wheels.