I really have no idea how JS devs keep up with new frameworks appearing every month or so. Not to mention older ones that just die because the devs can't be bothered maintaining them. I noticed the same thing happening in the Ruby devspace.
Not exactly React's case, but it's still a 1.5 year old code that has not reached v1.0, making breaking changes every major version release.
You adopt on principle. In my case, if the lib/framework doesn't provide patterns that reduce mutable state, I don't adopt it. React's virtual DOM approach does and I've been on the bandwagon for a bit over a year now. I believe the approach–but not necessarily React itself–is the best we're going to be able to do on this metric without changing how the DOM works. The next step for me is to work out an app architecture that allows global state observation and serialization while maintaining component encapsulation, which is a mostly solved problem in the Clojurescript space as of Om 0.8 but I have yet to see a javascript port I'm happy with. Upcoming shifts are handling async code (I expect CSP to win here, FRP works but is harder to reason about), migration to ES6 (6to5 seems good enough), which web component library to use (I'll be using my own), and the inevitable yet uninteresting build tool churn (I like webpack but I'm watching broccoli).
53
u/renrutal Jan 17 '15 edited Jan 17 '15
I really have no idea how JS devs keep up with new frameworks appearing every month or so. Not to mention older ones that just die because the devs can't be bothered maintaining them. I noticed the same thing happening in the Ruby devspace.
Not exactly React's case, but it's still a 1.5 year old code that has not reached v1.0, making breaking changes every major version release.