As a mostly Python and only occasional JavaScript developer, it always felt like the biggest challenge in the JavaScript community was how fast everything moved - new libraries, frameworks and ideas would tumble past at the rate of one every few weeks, and it felt impossible to keep up.
I've been feeling that a lot less recently, and maybe the fact that React has been steady for 2.5 years is part of the reason.
Those of us who were doing Python web dev in the years 2000s might remember that Python went through a similar period where it seemed that every week a new backend framework came out: Zope, CherryPy, web2py, Pylons, Django, repoze.bfg, TurboGears... to name a few. Nowadays it seems that everybody has settled for either Django or Flask. It might not have been as crazy as what happened with JavaScript in the years 2010s but still I tend to see a similar pattern. People try a lot of different things, going in slightly different directions and eventually interesting approaches get identified and communities build up around a couple of solutions.
Meanwhile the Ruby community was able to build consensus around Ruby on Rails, with just Sinatra on the side for small projects.
I'm wondering if this ability to try many different things might have been the cause for Python building numpy and eventually winning the scientific computing area as well.
Also it seems JS devs don't understand semver either. Massive breaking changes in patch or minor versions are just evil.
It has a tick-tock pattern so that you can upgrade and having time to fix the warnings.
The API changes are carefully crafted.
Sometimes there are even migration tools to help you upgrade.
I have published a library myself and experienced it, going from 2.x to 3.x to 4.x.
After you just do it for the sake of semver though, the resistance vanished for me.
And the second thing: Never use 0.x.x versions, I think those should have been omitted from semver completely, as they circumvent the entire concept.
A problem in React ecosystem is that it's a rendering library not really a webapp framework so you need to use community provided libraries to fill in the gaps. Those libraries are often maintained by an individual so it's unreasonable to expect corporate SDK approach to development, but unfortunately it leads to a lot of abandonware and rewrites, especially since JS is not very maintainable and it's often easier to rewrite something than to pick up someone else's code.
Lags behind in server side frameworks adoption over Vue.
React won the enterprise crowd pushing angularjs out.
React hasn't won over the JQuery crowd
If you do primary js it probably has. If you only do some js and other things it probably hasn't yet.
Over here it is all about Angular and Vue, and this for a minority of projects.
The large majority is done on SSR, CMS based infrastructure with vanilaJS.
If you don't like things moving too fast, then React does seem to be the ideal ecosystem:
https://github.com/facebook/create-react-app/issues/9033#iss...
TL;DR A vulnerability was discovered in a transitive dependency of "create-react-app" and announced back in March, but the one line patch to update the hard-coded reference to the vulnerable version is being held back for a future major version upgrade of the "create-react-app" package. 5 months on and the issue is marked as Closed but the new version hasn't been released.
While I agree that ideally a release should be cut to satisfy people affected by enterprise requirements, we are looking at a case of an overzealous audit checker, not an actual vulnerability that affects your apps.
(Edit: I've cut a release though; see my response in https://github.com/facebook/create-react-app/issues/9033#iss...)
I only worked on documentation and presentation.
Personally I don't like the design pattern, a matter of taste. But it's very annoying now in the market to have mixed React and Hooks codebases, with all their issues..
https://reactjs.org/docs/hooks-faq.html#what-is-the-prior-ar...
Our official Redux Toolkit package [0], which is now our recommended approach for writing Redux logic, _does_ have a few more deps: Immer, Reselect, Redux-Thunk, and the Redux core. But, those are all things you probably would have had in your app anyway.
If you're not familiar with Redux Toolkit, it includes utilities to simplify several common Redux use cases, including store setup, defining reducers, immutable update logic, and even creating entire "slices" of state at once.
I just published a brand-new "Redux Essentials" core docs tutorial [1], which teaches beginners "how to use Redux, the right way", using our latest recommended tools and practices. I'd encourage folks to check it out.
[0] https://redux-toolkit.js.org
[1] https://redux.js.org/tutorials/essentials/part-1-overview-co...
<MyList items selectedItem onItemClicked />
<MyList {...{items, selectedItem, onItemClicked}} />
I really dislike the way they can be abused to litter state and side effects all over React code so easily (e.g. hiding it layers deep in helper functions). And I feel they've made the API worse, such as `this` being replaced with the more clumsy `useRef`, or requiring an empty array to change the behavior of `useEffect`. These are things that break the Principal of Least Astonishment and have consequently led to countless blog posts that try to explain how to do things that were much more straight forward without hooks.
I've written about hooks before in past comments: https://news.ycombinator.com/item?id=19357068
It's been a couple of years since they've been added, and I don't feel the ecosystem has improved because of it. So to me it was a mistake.
I know they will likely not be removed from React, so what I said was more tongue-in-cheek.
Allowing code to be properly ready and tuned for the next major release. Where the new features will be actually introduced, hopefully, without new bugs.
By all means make breaking changes, just maybe tone down the marketing.
I wish macOS / iOS / iPadOS would have a version without tons of new features.
We've had similar releases since then which added a few new features but were primarily focused on stability. The most recent one was High Sierra. These do tend to be the best releases of macOS IMO.
Thanks for maintaining backward compatibility, which is not very common in the JS world. And congrats on the release!
Class components are so stupidly simple to read and write. I appreciate the work put into function components, but to me they make things unnecessarily complex. Just the fact that they took callbacks and other functions from methods – where things are separate, clean, standard – to nested functions – where things are not separate (some local variables, some closure variables), not clean (no possible way to unit test a nested function in isolation), and not standard (object methods are a language feature, use them!) – seems like a huge step backward.
Can someone on the React team speak to how event delegation works when there are portals present? Where is the event handler for a portal bound, and how does the new events system handle event bubbling across multiple versions of React in portal trees?
I can't speak to the exact semantics of how portals work with nested trees, but if you find an issue, please file one on our tracker. Some are expected to be impossible to solve, but hopefully we handle the common cases well.
(I would ask Dominic who worked on this but he just went on a much needed holiday break.)
const [x, setX] = useState()
useEffect(() => {
let isMounted = true
someAsyncFunc(result => {
if (isMounted) {
setX(result) // should not be called on dismounted component
}
})
return () => { isMounted = false }
}, [])
return <MyComponent x={x} />
Imo choosing a different name for new useEffect would be better (like useAsyncEffect or introducing a parameter), because just changing its behavior won't even result in compilation errors or guaranteed run-time errors, only make old code unstable.
Is there a way to reliably detect if component is still mounted before updating it when doing async operations in effects?
So code like this can stay written exactly as it does today. As noted in the blog post we’ve only had to modify ~20 components out of thousands so although this change may cause some breakage (please report anything unusual to the issue tracker!) we’re fairly confident that such common patterns continue to work.
(Edit: added this to the post.)
Yet more excess JS downloading and running on client devices, all in the name of superior developer experience. I hope my cynicism is proven wrong!
It's very suboptimal but I think it's still better to have that option than not to have it — or to try it and run into insurmountable problems. Especially in big long-running projects like internal company dashboards where long-term maintenance is more important than time to first render.
(I don't know why you're being downvoted though! I think your concern makes a lot of sense, and we're also sensitive about how to balance the messaging so that people don't use this unnecessarily.)
https://github.com/angular/angular/issues/37293
I have 2 comparable applications (in size) and React build times are 10 times faster than Angular.
And as you write larger and larger apps, with hundreds of components, it's just ridiculous how poorly the first-party tools handle that kind of code scale. Your only choice it to buy into Bazel to maintain some sense of sanity and productivity albeit some of which gets diminished with the overhead of learning, using and maintaining bazel for the project.
Complexity on top of complexity, nothing about Angular is simple.
By creating `bridge` release, the React community created a safe, well know and stable release that works as bridge for the upcoming complex, feature rich, release.
So: Complex Release -> Stable `bridge` Release -> New Complex Release.
Anyone can stay as long as they want in the bridge release, others can quickly move forward to the next release cycle.
Thought about making a lint for it but never got around to it.
https://reactjs.org/blog/2020/08/10/react-v17-rc.html#no-eve...
I'm sure the React team must be eager to get all the juicy changes out of the experimental branch and into the hands of developers. So it's great to see though that they're still taking their time to do it properly. Looking forward to seeing what come nexts :)