react-future

weeks I've looked through the source for a lot of elements in the polymer catalogue [4]. This is probably going to come off as a bit rant-y and negative, and it's totally tangential to the topic, but I'm totally unconvinced that web components are the way forward. These APIs are too complicated and they rely on side-effects which are very difficult to trace and debug. It's code that says: Execute this side-effect and I'm going to hope that now my environment is in an expected state. Oh, you screwed up with a typo? Don't worry, I'll just fail silently, good luck debugging me! You import files and then you pray that it polluted your namespace with the correct globals. This is not an acceptable way for building web apps in 2016. In contrast, I've been using css-modules [5] for the last few months, and although it has its own shortcomings and problems, I love that it makes it makes your usage very explicit and easy to trace. If you look at the css-modules link, you'll see why it's so great: You're explicitly saying you want to pull in that stylesheet and reference that specific class. The same goes when you're using React: You import a component and you put it in the render function's return value. If you try rendering something invalid, it'll scream as you. You can debug this much more easily because you know the file that was referenced and the specific export that's being used. [0] https://treasure-data.github.io/redux-search/ [1] https://github.com/reactjs/react-future/tree/master/05%20-%2... [2] https://github.com/web-perf/react-worker-dom [3] http://blog.nparashuram.com/2015/12/react-web-worker-rendere... [4] https://elements.polymer-project.org/ [5] https://github.com/css-modules/css-modules#css-modules

ate.value} /> } }; } React.createClass stops being special/required and becomes a (handy) utility. Can potentially be moved into a separate package. Competition for mixin systems is now possible. Finally, this change opens up more possibilities for potential React-like frameworks to “interpret” React components. Of course we don't do that today, but it's still a nice property and may be handy later when you decide to switch to future React-like competitor. It's the anti-lock-in. [0]: http://jlongster.com/Modularity [1]: https://github.com/facebook/react/issues/613#issuecomment-29... [2]: https://github.com/reactjs/react-future/blob/master/01%20-%2...

cssist [3] https://github.com/js-next/react-style https://github.com/tenphi/jcss https://github.com/chenglou/RCSS

ault this is reasonably fast, but most importantly, when you have bottlenecks, you can improve performance without having to do drastic architecture changes. (1) You can implement shouldComponentUpdate at specific points and get huge speedup. We've released a perf tool that tells you where are the most impactful places to[2]. If you are bold, you can go the route of using immutable data structures all over the place like Om/the elm example and you're not going to have to worry about it. (2) At any point in time, you can skip React and go back to raw DOM operations for performance critical components. This is what Atom is doing and the rest of their UI is pure React. [1] https://github.com/reactjs/react-future/blob/master/01%20-%2... [2] http://facebook.github.io/react/docs/perf.html#perf.printwas...