Cycle.js: A Unified Theory of Everything for JavaScript

Nick Johnstone on what makes Cycle special, the two-year long ‘weekend project’, great community engagement, and the future of programming.

How did you get interested in Cycle?

I came across Cycle while looking for a JavaScript framework to build the front end of a game development tool I was working on. I tried out some different frameworks, and found I was just really happy working on Cycle applications. It was satisfying. Fundamentally, it was about the emotional response I had to the code I was writing.

Cycle is like the physicist’s dream of a unified theory of everything, but for JavaScript.

Cycle provides a set of opinions you can use to address any problem and come up with elegant solutions. Competing frameworks provide more rigid boundaries, but fail to identify any unified theory of how to build applications. Cycle is like the physicist’s dream of a unified theory of everything, but for JavaScript.

What are Cycle’s key technical philosophies?

1. Side effects are separate from application logic.

In a lot of JavaScript web applications, you can just change what the user is seeing anywhere in the code. But in Cycle, all of those events have to be separate from your main application. That provides a whole bunch of really nice benefits around readability, testability, and as a result, maintainability of the code.

2. There is no global state in the application.

You can always tell why something will change by looking at what it’s defined from. There’s no looking at data in the application and wondering how it was changed, because defining that is the first part of writing a Cycle application.

What are some cool examples of Cycle applications?

• Jan, one of our core team members, is working with Technical University Munich and DLR, the German equivalent of NASA, putting a monitoring satellite into orbit. He’s built a tool using Cycle to view the data in realtime.
• André, Cycle’s creator, is working on a native Android app for Scuttlebutt (a decentralised social network) using Cycle. As part of that, he’s contributed a lot of code to React Native. I’ve seen a few hints of what he’s working on and I’m really looking forward to it being publicly accessible.
• People have built a lot of cool art and games with Cycle. It’s a nice framework for putting together all sorts of applications that are very satisfying to interact with, like playing around with sliders in realtime to see colorful trees unfolding.

Built by @waynemaurer — source code here.

I have built a lot of things with Cycle. My partner Raquel and I built a tower defense game where you use letters to create words that become defenses (soon to be released). I built an app at work to help employees learn each other’s names and faces. I’ve built music creation apps, game development tools, apps to help communities share projects, and my own dev tools to help me manage my open source work.

How did you end up on the Cycle core team?

When I first encountered Cycle I was really jazzed, so I gave a talk about it at work. I only spent a couple hours preparing, and basically just ran through everything I’d learned. That talk is still the most viewed Cycle talk I’ve ever given, which is upsetting because it’s the least accurate. I was misinformed and just learning. But the original creator of Cycle, André Staltz, saw it, and we started talking.

I started working on a time travelling debugger for Cycle, which lets you scroll backwards through time to before a bug arose, to see what went wrong in the code. I thought it would just take a weekend. I produced something that looked like it worked on the surface but was a complete hack.

“This is amazing! But I don’t actually understand any of it.”

A couple days later I woke up to find that André had left this big issue with 10 paragraphs of dense text explaining how I could re-architect my time travelling debugger to get it working. I looked at that and thought, “This is amazing! But I don’t actually understand any of it.”

So I set off on a journey to get to the point where I could actually understand what André was talking about. I ended up building some useful pieces of technology to help with testing and other problems that needed addressing, and I began helping with community management. After a while, they needed more people to join the core team so I came on board.

My “weekend project” ended up taking two years. I did actually build a working time travelling debugger in the end, but it’s not fully released. I’m still slowly shaving away at that yak.

My “weekend project” ended up taking two years.

How do the core team and the community engage?

We primarily communicate through our chat channel, issues, pull requests, and Twitter. The core team spends a lot of time doing onboarding, helping new users, and answering questions. We have very in-depth discussions with the community on Github issues.

Developers tend to jump to solutions too soon, which can be damaging. While it’s often said that JavaScript itself was initially designed and written in only 10 days, we spend months thinking about major breaking changes in Cycle. We could move faster, but part of maintaining a sustainable community is taking the time to understand everyone’s concerns. If you want to go fast, go alone; if you want to go far, go together. We want to go far.

About half the code contributions in Cycle come from the core team, and half come from the wider community. It’s kind of self-defining, because if a member of the community starts contributing really high quality code, documentation, or support, and is prolific and dedicated, it won’t take long before they become a member of the core team.

If you want to go fast, go alone; if you want to go far, go together. We want to go far.

Why did Cycle start raising money?

Previously, André was working for a Finnish company, Futurice, which does awesome support for open source projects. They make direct financial contributions to projects and also pay their employees to contribute to open source. They started using Cycle internally, so André had time and budget to work on it.

In contrast, Tylor, a previous core team member who has made fantastic contributions, didn’t actually have the financial support to spend enough time on the project. He was working as a barista and had just taught himself to code a few months before.

André started looking for options to get funding for Tylor, and that led to our Open Collective. Subsequently, Tylor was able to leverage his Cycle experience into his first professional software job, and has gone on to work for a bunch of companies specifically because of his reputation in our community.

What does financial support enable?

Our Github issues are categorized as maybe, could, should, must. Any core team member can pick up anything marked as should or must and receive financial support from our Open Collective for working on it. We also cover time spent onboarding new community members and providing support.

Our financial backers are people and businesses who build applications with Cycle, so that’s who we serve. I’ve met a lot of them at various Cycle conferences, looking at the list of names and going, “Oh yeah cool! I know that guy Aron, he contributes hundreds of dollars a month, enabling us to build awesome features and fix all these bugs”. It’s a nice mixture of sustainable support from companies and individuals paying what they can for something they think is worthwhile.

Financial support brings an increased level of stability and trust to the project. We have the resources to fix bugs, land new features, and do hard work that needs to be done. Unpaid work, especially if only one person is doing the bulk of it, is not a sustainable model. By having a financial incentive, we can bring as many people into the core team as the community financially supports.

Financial support brings an increased level of stability and trust. People don’t have to worry about the project imploding.

People don’t have to worry about the original author or a key contributor just deciding to work on something else and the project imploding. If the founder wants to walk away from Cycle someday, work will continue. If a core team member needs to move on, the resource they were getting paid can go to someone else who can have a positive impact on the project. We have a sustainable process so we can ensure the project stays stable and secure.

How do you want to grow the budget for Cycle?

We’re definitely interested in funding more people to work on Cycle. We want to keep bringing on core team members. There’s no point in leaving money in the bank — we want to invest it all as quickly as possible so the project gets better, people will build more cool applications, and more people will support us.

Finding contributors, to both the code and the budget, has come naturally so far, with very little marketing. I think André is still a bit confused about how Cycle got popular in the first place. I’ve heard him say “I don’t know how we got 7000 Github stars — I didn’t even post it anywhere.”

People like writing Cycle applications because there’s something fundamentally satisfying about it — and that feeling is what powers our funding.

There’s just something special about Cycle. Once people get past the initial learning curve, they have that same emotional response I had to it. People like writing Cycle applications because there’s something fundamentally satisfying about it — and that feeling is what powers our funding.

How should open source be resourced generally?

The open source ecosystem sucks in a lot of ways, and the free market is not doing an adequate job of addressing the issues. Money shouldn’t be what drives us. We should be doing it for the love. We should be doing open source because we have software inside us that’s screaming to get out. But people should also get paid for their work. And that’s totally a conflict.

We should be doing open source because we have software inside us that’s screaming to get out.

Finding the right model is really difficult. I’m now in the position of having to decide between spending a couple hours working on an unpaid project, or a couple hours working on Cycle where I will get paid. I still contribute to projects where I’m not reimbursed for the majority of my open source work, but it’s something that starts to play in your mind.

We need to shift users of open source from consumers to contributors. If you use open source code, you have an obligation to look after it, technically and financially. We’re all in this together. It’s not somebody else’s code, it’s our code.

We need to shift users of open source from consumers to contributors. It’s not somebody else’s code, it’s our code.

How can we shift to a culture of contribution?

I feel a sense of obligation to treat others how I’d like to be treated. I’d like people to fix my bugs, implement new features, and help maintain code I write if they value it. So that’s what I do: fix bugs, raise issues, improve documentation. You recognize how you want the world to operate ideally and just act as if it were that way — and that can become how it is.

When I have a bunch of open source projects that all need work, I can either spend a long time doing it all myself or I can spend a short time writing up a description of what needs to be done, and then support others. I once had five projects going simultaneously, so I wrote up a few issues for each. Then I posted on Twitter saying “If you want to contribute to open source, here are a bunch of opportunities. If you’re willing to work on these, I’ll support you to get your code merged and review it for you.” That support is what everyone wants when they start contributing.

It’s so much less scary to respond to an invitation than to send a pull request not knowing if the maintainer is going to bite your head off or just ignore you. Open source is made of people, and people, especially on the internet, don’t always interact in ideal ways. Some maintainers don’t even say thank you when they merge pull requests!

It’s so much less scary to respond to an invitation than to send a pull request not knowing if the maintainer is going to bite your head off or just ignore you.

I remember one of the first open source projects I contributed to was Loomio. I saw a Github issue where someone had responded to a comment in a kind of terse, abrasive way. But someone else right after said, “Hey I’m not sure if you realise, but the tone and language you used actually degraded from the overall point and was potentially quite hurtful.” And then the first person immediately apologised and offered more context and a nicely worded message.

We have to put deliberate effort into being kind in our online communication, especially if we have users complaining and making demands. User entitlement is unfortunately common, but you fight that by being unfailingly kind. I’m not always perfect at it; sometimes I get frustrated. It takes a lot of work, using that smiling kitty emoji. That’s who I like to be on the internet, because I think it’s worth it.

We have to put deliberate effort into being kind in our online communication. It takes a lot of work, using that smiling kitty emoji.

What’s your vision for the future of Cycle?

I’m not super attached to the current implementation of Cycle becoming the most successful framework in the world. We’re not backed by Google, Microsoft, or Facebook, so we should probably just accept that’s not going to happen. But we can share ideas that change the way people think about programming and influence the community.

On top of basic project stability, we now have the resources for more experimental stuff that would traditionally never be supported in open source. We can make the present project better, and also make the future better. The ideas and philosophies coming out of Cycle paint a picture of what the future of programming could look like, and it’s very different from what we’re doing now.

The ideas and philosophies coming out of Cycle paint a picture of what the future of programming could look like.

At the last Cycle conference in Sweden, I talked about the next big ridiculous project I want to take on: a visual editor that could reveal interesting data and structures not necessarily visible in the traditional lines of source code in a file.

Then André gave his take on the future of Cycle, and even though we hadn’t talked about it beforehand, he’d effectively come to similar conclusions. He suggested investigating building a custom programming language to make it possible.

What I want to see carry on from this project is the underlying philosophy about how to build software. That’s what truly matters.

Cycle Conf was sponsored by Verizon, who enabled me to fly across the world and give that talk. They also donated $10,000 to our Open Collective, which has supported so much work. Building a visual editor and potentially a new programming language is actually something we can think about doing soon.

Even the ideal amazing future, where Cycle becomes really successful and there are no frustrations or rough edges, will only ever go so far. JavaScript is not the language of the future. What I want to see carry on from this project is the underlying philosophy about how to build software. That’s what truly matters.

Support Cycle.js on Open Collective, and follow Nick’s work on Github.