It's time to ditch Medium for good! 🌈⚡️

Introducing Devblog by Hashnode. Blog on your domain for FREE. Highly customizable and optimized for developers.

Learn more

I am André Staltz. Ask me anything.

Hi, I'm a programmer and I spend most of my time building transparent software. My passion is to pull ideas from the future and realize them in the present. In particular, my areas of focus are: user interfaces, reactive programming, JavaScript, and peer-to-peer networks.

Ask André Staltz about:

  • JavaScript
  • CycleJS
  • User Interfaces
  • Reactive Programming
  • Peer-to-peer Networks
  • Programming Advices
  • Playing guitar 🎸

Thanks for the questions! While answering I got a ton more questions, this was nice.

If I could leave one last comment, I recommend: make it your identity to be a learner. I believe programming is about constant learning. Celebrate failures because they teach you what doesn't work, so you can focus on other alternatives that might work. Keep track of small lessons you learned every week. Don't be afraid to look into the source code of any library you use. Don't be afraid to debug it. Don't get lazy. Don't be afraid of reading or trying that different language. Draw on paper. Read articles. Be curious. Put yourself in uncomfortable new situations. Make it your identity to be a learner. I'm one too.

Ask a Question

60 discussions

What are some pros and cons of using CycleJS over React?

Good question. First I'd like to clarify that this not so simple to answer, because Cycle.js is a framework and React is a UI library (or half a framework), so it's similar to asking the Pros and Cons of Cars overs Engines. So I'll assume the question is Cycle.js versus React+Redux+Etc.

I'll start with React+Redux+etc:


  • Large ecosystem means it's more common to find supporting libraries, jobs, conferences, etc
  • Has more familiar concepts if you come from an OOP background, such as class usage, setState, event handler callbacks
  • Does component encapsulation well and transparently so once you have a third-party component, you don't need to worry much about it, just pass it some props


  • As it's not a framework, you will see a lot of corner-cases unanswered. Before Redux, state management solutions were (too) varied. A similar situation happens now with effects management (redux-loop? redux-observable? redux-sagas?). The React core team usually answers "use what you feel like, it's a matter of style" because they are focused on building React for Facebook and it's not their priority to provide a full frontend framework for the rest of the world. With React+Redux, there is a solution for any problem on npm, but you have to find it and make the choice yourself
  • Too much usage of classes brings out the ugly parts of JavaScript, specially the this keyword and its common headaches
  • Redux isn't evolving, and it was built as a tool to demonstrate a proof of concept for a conference talk. There are plenty of pain points (managing hundreds of action types is the largest one IMO) that most people just got used to and don't experience anymore to be painful



  • It's a framework and is meant to provide a comprehensive answer for multiple aspects of frontend development. We have official ways of doing: DOM interaction, HTTP effects, state management, SSR, Time effects, and for cases that are lacking, we give a guideline how to structure the application. The result is an overall very consistent architecture for webapps, that uses basically the same simple approach
  • No this keyword in sight, meaning you only use functions and streams. This aides testing quite a lot, and you never get this bound to the wrong thing or bound to undefined.
  • It has a property called "fractal architecture": every component is a Cycle.js app that could be run separately. (This isn't true in the case of some parts of Redux-based apps, for instance)
  • Cycle.js for a long time had "stateless functional components", "componentDidCatch", no react-id attributes, features that React is still rolling out
  • You can use React (and React Native) as UI library within Cycle.js! This repo is a demo of that, despite being early techniques not yet official


  • Much smaller community (about 500x smaller last time I measured)
  • You need to learn streams and reactive programming (it's not hard, just very different and requires some brain rewiring)
  • Handling lists of component instances is surprisingly a hard thing in Cycle.js (this issue but we're landing on a solution soon to be official
  • Doing chained HTTP requests isn't the best developer experience

Overall, I wouldn't pick a winner. Some people are keen on choosing a winning technology, but I prefer to see cross-pollination. For instance, if we could finally have seamless conversions between React components and Web Components, that would mean the big React ecosystem would be unlocked for Angular developers, Vue developers, jQuery developers, Cycle.js developers. Another example is React within Cycle.js, a technique I've been using. Yet another, not yet real, example is: React community picking some ideas from Cycle.js (perhaps fractal state management with lenses? or time as a dependency This way we all win.

Reply to this…

Share your programming knowledge and learn from the best developers on Hashnode

Get started

Which active programmers do you look up to and follow closely?

In random order (and twitter accounts):

P2P and/or cool ideas

Functional programming or just programming

Reply to this…

Hi André, What major front end framework (Angular, React, Vue, or any other) do you think is better to work with FRP?

I would say React, because it's a UI library, not a framework, and you have a bit more freedom to choose how to solve problems. You can include a reactive programming library like most.js or RxJS, and handle functional and reactive programming architecture however you want, and only for DOM rendering using React. With other (full) frameworks it's a bit harder to customize that.

Note: I am not saying "React is FRP", I'm just saying "you can build your own custom FRP and use React in the middle".

Reply to this…

How would the JavaScript eco-system look like after 10 years? What's your opinion? 🤓

10 years is a bit too far for making good predictions (for instance, 10 years ago was 2007, not even AngularJS v1 existed!).

I can tell at least that in 3 years, JavaScript will gain more the status of a VM and lose the status of a language. Already today, not many people use raw JavaScript. You usually have some transpilation, at least e.g. Babel. In the future, Web Assembly will enable more innovation in that regards, and existing transpiling languages like Elm, TypeScript, PureScript will continue to improve.

Reply to this…

Given an opportunity to be 20 years old again, how would you start your programming career today? 🤓

At that time, the hot technologies were Java, MySQL, Hibernate, and maybe Flash. I was at the University and I studied a bit too much of math (like 4 courses on Linear Algebra). I really wished I had studied more about compilers, and all sorts of programming paradigms, from Assembly to concatenative languages, to very high level languages like Haskell. Stretch your brain as much as you can while you're young. It's not so much about what things are useful, it's mostly about opening your mind as much as possible.

Reply to this…

Load more responses