by Cedric Dugas on December 30, 2015
All that being said, as a web developer you need to listen to the wind. We are paid highly for our skills, that require we stay a sharp knife. The wind is blowing strongly in React & Redux direction recently, so I decided to dive right in and defect backbone.
Here a couple of thoughts about the React-Redux ecosystem:
The technologies overload is hard to overcome
Redux, react, flux, es6/7, webpack, jspm, tackle them one by one and everything should be okay, but combine all those at once and learning how to do apps with Redux suddenly becomes much harder.
Unfortunately, this is the problem we are faced with today. Starting a new stack is considered a greenfield project. The community encourages you to use all the new shiny tools, even in redux tutorials they code in ES6, we are in the transpiler generation.
Because of that, I hit a wall early on looking at Redux implementation examples. I could not figure out what was going on in redux reducers, this was because I had no idea you could use the spread operator to merge arrays and objects, example:
Redux is small but complex
Redux is also an application architecture that does not come with a boilerplate app architecture. Best practices are not fully standardized, for example, Redux let you completely loose on how to implement API call’s. This has it’s upsides & downsides, it’s not that it is hard, it’s just that you need to scrap all the bit & pieces to make it really work.
That leave us with a ton of github boilerplate projects all doing pretty much the same thing just a bit differently.
Is the jsx we know today the future of JSX?
React is awesome, it greatly simplify the rendering logic, add redux and magic start to happen with your UI state, it’s simple, its genius.
But is what we know today as JSX the future? I’m not so sure, we keep going back & forth on templating engine features. In any case, I do not like working with JSX like I do not like working with Jade. I like clean HTML, but that might be the old integrator in me talking.
Sharing plugins on npm is an adventure (and not a good one)
Remember the days where sharing a jQuery plugin was as simple as putting the js file into a repo & pushing it to Github? Gone now are those days. One of the best practices is to have a transpiled version to es5, using webpack CSS modules? Now you must find a way to remove that CSS or embed it in your code.
I must say, I decided to give up on this, only use ES6 & webpack CSS-module, add an include rule in my webpack config, so it transpile some node modules. Is my code less reusable, absolutely, but I love simplicity, and this is simple.
But there is friction, I am not sure if people will be inclined to open source as much as they did for jQuery & Angular. Add that to truly follow redux philosophy your components must use the redux store to retrieve & push states and that make for even less react-redux components.
What is the price today?
When I use a new technology I always think about a couple of things, ease of use, how much time to bring new developers up to speed? Is it faster to iterate apps? Has better performance overall? Right now I am not to sure the React-Redux combo checks all the boxes. Did we take the micro-libraries too far?
I do not feel devs will transition to Redux-react as easily as they did to Angular, and if I was at Facebook & cared for adoption rate, I would be concerned (I’m not saying they care about that). Angular2 is finally coming, has some cool bells & whistles, and it could well want to take back the space it lost.
One thing for sure, I am a bit tired, and I’m not alone.