|
|
|
|
|
|
by dev360
2804 days ago
|
|
|
I’ll bite. I have been frustrated with the lack of stable apis in JS in general over the last few years. It may be an ecosystem problem but I think the big projects have an obligation to set the tone for what is acceptable elsewhere and not just jump on the next wizbang thing that’s marginally better or more correct. Pros and cons but I see the cost of maintenance being very high in client side js compared to backend. |
|
|
The frontend ecosystem is definitely less mature than backend. Gmail and Google Maps, two of the first "real" client-side applications, were launched in 2004 and 2005 – so the entire ecosystem is really about a dozen years old. Before that people didn’t really “realize” that JS and web was a real programming environment. That means there's a lot to catch up on and a lot to experiment with as people figure out the best ways to build things. Compare this to backend or infrastructure development which have had decades to develop.
That said – I completely recognize that this can be painful. You don't always need to use the latest stuff though. If a "less fashionable" technology does the job for you, you can definitely use it. And trying to mitigate some of this complexity is why my team works on projects like Create React App which (whether or not you're using React) can insulate you from some of the "churn" that people often feel in the ecosystem.
In React itself, we try to have as few breaking changes as possible. (And our team needs to keep 50,000 components at Facebook working through our changes, which is a major incentive to not break things unnecessarily.) Our last major release, React 16, was released in Sep 2017. But it actually included almost no breakages (we mostly bumped the version number out of caution because it included a huge number of internal refactors). So I'd say our last "actually breaking" release was React 15, in Apr 2016, about 2.5 years ago. React 17 will probably be released sometime next year, so we're talking 3-ish years between releases. I think it's hard to do much better than that without stopping forward progress. Note that if we don't improve React quickly enough people will abandon it for another (incompatible) library, which doesn't really solve your problem either. So we try our best to make sure we're working on (what we think are) the right things and do our best to get it right the first time.