Forward + React Takeaways
This past week San Francisco was host to two big Javascript conferences: ReactConf at the Facebook campus, and the Forward 2 Web Technology Summit downtown. The great thing about it all happening at the same time was the crossover at the events, the reaction (pun not intended) and buzz surrounding the announcements and talks from ReactConf throughout Forward. A great deal was debated and talked about with regard to the nascent methods and tools in the modern programmer’s toolkit, and people seemed happy to take a step away from the hyperspeed changes we as Javascript developers are inundated with by the minute, and take stock of the current state of the art. In talks, conversations, and reflection, I keep coming back to two high-level observations:
Functional [Reactive] Programming is here to stay
This may be old news to some of you, but Javascript developers who have been stuck attempting to write highly complex, stateful apps by applying an MVC-ish model to the client have seemed to finally figure out there’s another model that could be more workable, and they are figuring it out in droves. When I attended Brian Lonsdorf’s FRP workshop in July 2014 during Forward 1 — right about the time Flux was open sourced — it was definitely something few people had even heard about. This time around, everyone from Douglas Crockford on down was talking about how to write Javascript in a functional style. Flux clones and functional libraries were everywhere, a Haskell flavored Javascript dialect (PureScript) was featured in at least two talks, ES6 has proper tail call recursion (even with 6to5!), the FRP workshops were sold out and overflowing, isomorphic is a hot word everyone wants to talk about, and the influence of React can be seen everywhere (even Angular 2.0 will encourage a Flux style architecture). Functional style does not solve all the problems of highly complex UIs, but it can go a long way to reducing the headaches caused by two way data binding and mutable state. React and other projects continue to push the front end paradigm, making it an exciting time to be building rich UIs.
Javascript Has Escaped the Browser
Of course the big news was React Native, which is a huge, huge deal. Don’t believe me? Read http://jlongster.com/First-Impressions-using-React-Native. But native apps aren't the only thing Javascript is ready to take over. Javascript is also being used in all sorts of IoT devices, robots and desktop applications (with Atom Shell!). The crazy thing is, the browser may now be the worst place for Javascript, because, as people are beginning to realize, there are two other parts of the browser that actually serve to get in the way more than anything. CSS and the DOM are mute, static players in a game that is moving much faster than they are. React circumvents many shortcomings of the DOM by creating it’s own, and it’s possible to pave over both with tools in ClojureScript, among others. Lots of people are doing or thinking about doing this, because they want to write ambitious apps or games that would be hamstrung by the weaker parts of the browser. There are obvious pitfalls to relying on Javascript for everything (even though isomorphic gives us some solutions) so let’s not get ahead of ourselves, but the reality is that the tool seems to be outstripping the platform. I've thought that web components would be the “next step” in the evolution of the web, but while we wait (…and wait) for them to become viable, some wonderful alternatives have raced into the picture.
Those are just my two biggest takeaways from a week of futurology. The pace of change in Javascript land shows no signs of slowing down, but we can console ourselves knowing that each new turn brings us another set of incredible tools and possibilities.
