6 ms·

I think you're misunderstanding React's API surface. It's about 20 core methods, not a giant lib like jQuery. From my experience, a medium sized project is adj

I think you're misunderstanding React's API surface. It's about 20 core methods, not a giant lib like jQuery. From my experience, a medium sized project is adjusted to the changes in about two hours. Once every three months. Is this a big deal in trade for progress?

Silhouette 11y ago
Is this a big deal in trade for progress? It is a big deal any time someone's code works, and then they update a dependency, and then their code doesn't work any more. Even if the actual code changes required to update the integration are minimal, someone still needs to divert to make those changes and then test everything, which is disruptive at best. Before they can do that, they need to identify what changes are required and perhaps learn how to use any automated updating tools that are available, both of which also take time. If one person on the team wants to upgrade to access some new feature or just get a bug fix, everyone else on the team has to come along, so for example they might start seeing warnings that they'll need to investigate. As I mentioned in another post, there is a nasty hidden cost to breaking the interface of fast-moving but lightly documented libraries, because it will tend to invalidate all the tutorials and example repos and demo videos and so on offered by other contributors or, worse, those resources may become actively misleading. This is a lesson the web development community will learn in time. Unfortunately today it is a very young part of the industry, obsessed with the appearance of making progress, even though actually web development is almost comically inefficient. The lack of respect for issues like standardisation, compatibility and portability is a major contributing factor in that inefficiency, as is the willingness to build on fragile dependencies in the first place.

Silhouette 11y ago

Is this a big deal in trade for progress? It is a big deal any time someone's code works, and then they update a dependency, and then their code doesn't work any more. Even if the actual code changes required to update the integration are minimal, someone still needs to divert to make those changes and then test everything, which is disruptive at best. Before they can do that, they need to identify what changes are required and perhaps learn how to use any automated updating tools that are available, both of which also take time. If one person on the team wants to upgrade to access some new feature or just get a bug fix, everyone else on the team has to come along, so for example they might start seeing warnings that they'll need to investigate. As I mentioned in another post, there is a nasty hidden cost to breaking the interface of fast-moving but lightly documented libraries, because it will tend to invalidate all the tutorials and example repos and demo videos and so on offered by other contributors or, worse, those resources may become actively misleading. This is a lesson the web development community will learn in time. Unfortunately today it is a very young part of the industry, obsessed with the appearance of making progress, even though actually web development is almost comically inefficient. The lack of respect for issues like standardisation, compatibility and portability is a major contributing factor in that inefficiency, as is the willingness to build on fragile dependencies in the first place.