If there's one thing that has been bubbling below for a couple of years now, it must be reactive programming. There have been solutions, such as RxJS or bacon.js, but they haven't quite made it to the mainstream yet. I feel the time for that might be close, though.
I am a UI developer at Futurice in Finland, with extensive knowledge in reactive programming. In my daily work I build web apps and Android applications, and on my free time I build open source libraries such as Cycle.js and contribute to ReactiveX.
A lot of people have read the Introduction to Reactive Programming you've been missing that I wrote in the summer of 2014, or have seen RxMarbles. That is how most people know me.
Cycle.js is a framework where your app is described as a simple function taking an event stream as input and outputting an event stream. These event streams might sound magical, but they are pretty simple. They are similar to arrays in reality, except they evolve over time instead of being static.
A simple Cycle.js app might take an array-like sequence of clicks and output an array-like sequence of DOM elements. So essentially coding is just describing how to dynamically transform a stream of user events into a stream of interface elements.
I started developing Cycle.js after I took React for a spin and was disappointed with its API. I initially got really excited about the Virtual DOM concept in React, but could not understand why the API is built on OOP classes, state mutation, and imperative event handlers. There is a mismatch between React’s foundational ideas (reactive rendering and UI as pure function of state) and its implementation means (OOP, classes, imperative programming).
Cycle.js is a React alternative where implementation matches foundational ideas by applying functional and reactive programming to the extreme. The result is a tiny API surface where everything is either a function or an RxJS Observable.
I have been slowly learning more about hard core functional programming, in other words Haskell. I have also been experimenting with Elm, a more approachable Haskell alternative for the Web.
I have many plans on what to develop next. My time will probably be mainly focused on improving Cycle.js: making it simpler to use, building integrations with React Native, integrating the upcoming rewritten RxJS by Netflix, etc. But I hope to join efforts with the pure functional programming community, be it Haskell, Elm, or PureScript.
Functional programming is definitely a trend in the front-end community. React is also at the center of this trend. I recall Sebastian Markbåge mentioned multiple times in his interview at React Europe that React is all about functional programming and how to introduce it in a clever way to people unfamiliar with this paradigm.
The community will need to actively experiment with alternatives, and we need to start considering transpiled functional languages (PureScript, Elm) more and more if our techniques are mainly functional anyway. I am not convinced we have stable best practices and good guiding principles in how to architect applications. Cycle.js is just one attempt at finding that guiding principle.
Evan Czaplicki. I was skeptic about Elm before meeting him, but after meeting him in person, I strongly believe his work with Elm is doing a great service to the whole community in bringing functional programming to a level most of us can digest. Evan has vision, is enthusiastic, reads Computer Science papers, and has a ton of great and wild ideas.
Thanks a lot for the interview André! Perhaps a programming model as demonstrated by Cycle.js is the future. It always takes time for the community to warm up to the ideas. Interestingly there's a proof of concept that implements thisless React, inspired by Cycle.js of course!
If this interview made you interested in Cycle.js, consider the following resources: