React.rocks - React Components and Demos - Interview with Jeff Winkler
Given there’s a lot going on in the React ecosystem, it can be difficult to keep up. Jeff Winkler maintains a service known as React.rocks↗ to alleviate this problem. To get a better idea of what the service is about, read on.
Can you tell a bit about yourself?
#
I am a full stack developer and I have been writing code for over 20 years. From museum kiosks to big enterprise software. I’ve been using React for a couple years. I’m a tool/feedback loop junkie. I’ve been lucky enough to work on a couple green-field ReactJS projects.
My wife and I live outside Boston and we have a five year old, it’s really fun to see through the eyes of a kid.
How would you describe React.rocks to someone who has never heard of it?
#
React.rocks has examples of things built with React. To be included, entries must have online demos and be open source. Visitors can go from screenshot to demo, then dive into the source code.
Entries are tagged to help find like examples. The entries are manually curated, at a rate of a couple a day. The site features bigger “apps” than single components.
Why did you develop React.rocks?
#
While learning React, I kept adding to a text file file cool things built with it. It wasn’t working, so building a site seemed like a good forcing function. A static site with no server was intriguing. Once I registered the domain, wanted to follow through with it!
I wanted to build a purely static site with ultra-fast performance. It’s to geek out on optimizing data transfer and size. Despite being image heavy, It’s 508K all-in.
What kind of challenges have you experienced while developing it?
#
The code base has been pretty stable. Challenges are more finding content. Each morning I read #reactjs. This takes a lot of time but is a good way to spot trends.
Sometimes it’s hard to get motivated to update the site, but finding new things built with React is invigorating.
What next?
#
I’ve been thinking performance a lot - how to benchmark the rendering of React components? How do you encode policies in Flow↗/ESLint↗ to keep an app fast as developers and component counts grow?
On the backend, Elixir↗ is very interesting to me. It’s a language built on the Erlang↗ VM that’s been powering telecomm for 30 years. Ground-up Immutability and functional style, multi-core ready.
I need to open source the code for React.rocks, to get contributions from smarter folks.
What does the future look like for React and front-end in general? Can you see any particular trends?
#
More fatigue! :) The JS/React communities will keep pushing the envelope and trying new things.
At the same time, there’s an awareness that React can be too “bazaar” for newcomers. The community has a ton of brainpower and energy. I think we’ll see some gentle guidance to harness that effort to improve onboarding and pave cowpaths. Ryan Florence’s React-project↗ looks promising.
GraphQL↗ will keep gathering steam. Diverse communities are excited by it. It’s declarative and batches expensive operations - just like React! Within a year I expect back-end ORMS/persistence layers to support GraphQL out of the box. It just makes sense to leverage the metadata.
React Native↗ optimizes for team throughput. I’d expect more success stories.. and a tipping point in a year or so.
Functional programming and Immutability are clearly good things. We’ll keep seeing attempts to move toward Elm↗-ish pure paradigms. ES2015 has the most momentum and user base.
App Shells, Service Workers, and WebGL all seem super interesting, with unexplored upsides.
Who should I interview next?
#
Ryan Florence, about the work he’s doing with react-project, a CLI for React.
Conclusion
#
Thanks for the interview Jeff! I hope React.rocks↗ continues to grow and flourish. It’s one of those community resources that it’s hard to live without. Keep it up!