Forem: Reactive Conference

The Concepts and Misconceptions of Reactive Programming

Ben Halpern — Thu, 06 Oct 2016 14:09:34 +0000

Reactive programming is a powerful, and sometimes misunderstood, programming paradigm. Few people have more to say on the topic than AndrÃ© Staltz, who will be speaking at upcoming Reactive Conference. I asked Andre to clarify some of the concepts and offer advice on when it might be a good idea to choose the reactive approach. If you are interested in these concepts, I hope you find his answers as helpful as I did.

Interview with AndrÃ© Staltz

How did you get into reactive programming?

Before joining Futurice, I had never heard of reactive programming. It was through work colleagues who were using Bacon.js, RxJS, RxJava, ReactiveCocoa, that I got curious about reactive programming and functional reactive programming. Soon enough, I was using RxJava extensively in an Android project, and had to learn Observables and operators the tough way: by using it for real to deliver software with deadlines. My learning process was guided by believing that "there must be the 'reactive' way to do this" and by sketching out dozens of marble diagrams on paper notes.

What are the common mental barriers developers have to overcome when learning and adopting reactive programming?

Most programmers exposed to reactive programming, me included, were used to "triggering", "updating", "dispatching", "firing" methods and procedures. Those are idioms and techniques opposite to reactive programming, where instead we try to declare what is "triggered by" or "updated by". The biggest challenge is simply to go through the mental revolution from "A changes B" to "B is changed by A". After that, the smaller challenges are learning Rx operators, where they apply, and common techniques.

Do you find people are confused by the difference between the naming of React, the Facebook library, and reactive programming?

Unfortunately, yes. reactive programming is ancient, even though it has become a modern approach through Rx and Akka and others. React, on the other hand, uses a few reactive techniques, and therefore borrowed the name. I like to compare these two to "car" and "carpet". There is a carpet inside your car, but cars and carpets are entirely different objects. There is some reactive programming in React, but these two are entirely different things. In fact, there is even some reactive programming in plain old callbacks, so I wouldn't consider reactive programming a noteworthy property in React.

Do you see instances where people choose React/Redux, when they would be much better served with purely reactive approach?

Yes, I do see those instances. However, I don't think that is always the case. There are even cases where people choose React/Redux (or any unidirectional data flow approach), when they would be better served with two-way data-binding, like in Vue.js. Each approach has its ideal use case. When it comes to the fully reactive approach, I think it works best for applications that need to handle incoming data from multiple different sources: WebSockets, Firebase, Sensor data, Keyboard, Kinect, to name a few. React/Redux works decently when you have only graphical UI in the browser, a few user events from clicks, and a single server to communicate with.

Are there problems that people could use reactive programming for that are typically overlooked?

There are many cases where reactive programming helps. RxJS and similar libaries are by far the best tool today to handle cancellation of all sorts, in the easiest possible way. Promises are not cancellable. This means you cannot stop an in-flight request built with fetch(). Even if you implement cancellation logic yourself with manual state bookkeeping and Ajax, the amount of code required is disappointing. It turns out that most frontend developers ignore cancellation because they believe hardware resources are plenty. However, with RxJS, cancellation is easy, idiomatic, and semi-automatic, so that you sprinkle a few operators and your code then handles complex asynchronous cancellation. RxJS is not just for cancellation, though.

What will you be talking about at Reactive Conf?

I will be talking about how we can go beyond console.log and the step-through debugger, and how we can develop new code visualization tools that help us understand and debug our applications. In particular, I'll guide people through the Cycle.js DevTool, a tool that visualizes the whole code in your application as a dataflow graph, and how you can observe the events flowing in real-time as you use the application.

What is Cycle.js and why did you create it?

Cycle.js is a JavaScript framework for building user interfaces. It allows you to build typical frontend applications like your favorite e-commerce single-page app, but also has a flexible architecture that knows how to accommodate different use cases like the use of game controllers, WebSockets, keyboard, Kinect, in a structured way with good separation of concerns. I created this primordially because I wanted to solve "User Interface Architecture". I wanted to have a guiding principle and essential tools to handle any kind of UI app I build. I believe JavaScript will power nearly all UIs in the future, and there has to be a common way of programming them with a focus on code readability and productivity.

What is important to the ongoing health and success of the Cycle.js project?

To be honest, money. Not for myself, but for the contributors. We have reached the scale where as one person I cannot handle all issues and requests alone, and it's crucial to have core contributors. Tylor Steinberger and Frederik Krautwald are two people I am immensely grateful for helping build the framework as volunteers. We run this as a true grassroots open source project, not as a project belonging to a large tech company like Google or Facebook. Recently, we have set up a donation site for our contributors.

Would you like to point to any resources (a favorite talk of yours, a good tutorial, etc) for anyone looking to get into reactive programming?

I have three links: one is a talk I gave, another is a good introductory blog post written by someone else, and another is an unrelated but highly inspiring talk about asynchronous logic programming:

"The whole future declared in a var" by AndrÃ© Staltz

Understanding Reactive Programming and RxJS

"I See What You Mean" by Peter Alvaro

World-Class Conference in 90 Days, Part 1 – Speakers

Samuel Hapák — Sun, 02 Oct 2016 19:20:31 +0000

When we started organizing the first year of ReactiveConf, we had no guide to stick to. Today, we're finishing the works on its second year which takes place from October 26th to 28th in Bratislava, Slovakia, and I feel excited – and somehow relieved – that many people come asking me how we were able to set up such an outstanding event in such short amount of time.

The idea of ReactiveConf didn't come from me, though, it originated from Matej Ftacnik, my business partner, with whom we'd attended ReactEurope in Paris last year. Right after we landed back home, Matej said: “We have to bring this to Bratislava and make it the best React thing in Central and Eastern Europe!”

Nobody told him it's impossible to make a world-class app development conference in ninety days without any previous experience. So we just did it! And I hope the following lines will help you, inspire you, and make you avoid needless mistakes on your journey to be the founder of the next best conference in the world!

Building up a conference is a complicated matter, so I decided to split the article into several parts. In this one, I'll try to outline all the intricacies of getting the speakers come to your event.

Right People, Right Place

Let's make it clear right away: there's no great conference without great speakers. I'd rather hear an inspiring speech in an old garage than an average talk in a conference hall of a five-star hotel. So find yourself a passionate team, a resonant name, and set up a website with basic information. Speaker hunting is the biggest challenge you're going to face – and not only the first time but every year.

A good place to begin is other conferences all around the world. In our case, those were ReactEurope, React Rally, and the official React.js Conf from which we invited several speakers. Look for people who are exceptional, match your focus, and who are followed by the influencers in your field.

Don't be shy to check their Twitter accounts. Last year, I went through the Follow lists of Dan Abramov, David Nolen, or Christopher Chedeau – all real React visionaries. That helped me to find and eventually get fantastic speakers on board, primarily the niche ones.

The Cool Factor

Although it may not seem so, “niche” is an important word when it comes to your conference lineup. Such people are usually unknown to the mainstream audience, quite often they work on something too new or obscure, but they will freshen up your schedule and attract many influencers.

Speakers like Nikita Prokopov, AndrÃ© Staltz, or Victor Grishchenko were pretty exotic names in our agenda, but it was them who sparked the first interest in ReactiveConf from the community. After all, I found them all thanks to “My React List” on Abramov's Twitter account. It's a paradox, but these “unusual celebrities” eventually convinced many of the hottest names in React to join us.

Also, once you make your way into the influencers' consciousness, ask for the personal favorites. Last year, the ReactJS mastermind and one of our headliners Brent Vatne suggested Daniel Woelfel and Krzysztof Magiera, both experts in their respective fields, so we invited them to appear this year. They're both coming – along with Vatne!

Differentiate Yourself

Many speakers, mainly the most popular among the audience, receive tons of requests and invitations every month. Naturally, your task is to persuade them to come to your convention. But how to achieve this? Well, you'll have to come with a compelling story – ours was pretty solid!

ReactJS was the shiny new thing, and we were doing the second biggest React conference in the world. In 2015, everybody was saying that we were one big community, that Ember, Clojure, Elm, and other front end folks should learn from each other.

This message was repeatedly voiced, but we were the only conference to actually invite a significant number of people from various environments to meet and speak. Finally, such act was widely praised – I always take pride in the fact that even Christopher Chedeau tweeted that we had the best speaker lineup.

Never Give Up

Inviting speakers is still one of the toughest items on your list, especially when you've just started. So whoever you are getting connected to, approach them with an email explaining who you are, what you do (and have done), why you want them, what you want to achieve with your conference, and why you want them.

Be persistent, and don't give up. Have they not replied yet? Try it again! Go to Twitter, Facebook, or Github, and address them. And be willing to meet any special conditions and requests the speakers might have.

Don't be surprised if they say “No” to your offer, however. For every speaker, each conference is a huge commitment – they spend a long time traveling and getting ready for their talk. Also, their boss may not be thrilled by losing a productive team member for a series of days.

In our case, the argument which convinced most of the speakers' superiors was that Slovakia is a great country for talent hiring. Yes, companies such as Facebook and Google know it, and they've recruited here many talented and creative programmers in the recent years, but we're still a relatively new and mostly undiscovered area.

Each country is different, of course, so come up with something original and fitting to your situation.

Get Yourself Introduced

Wherever you are setting up your conference, nonetheless, you must never forget to use your network. Last year, I called Evan Czaplicki, a developer of Elm language, but he couldn't come, so he recommended Richard Feldman, his colleague at NoRedInk and a fellow Elm and React enthusiast. Needless to say, he's coming to ReactiveConf again this year!

Ask your friends to introduce you. If there's a person who can recommend you to the speaker you're eager to lead the lineup, get in touch with them right away. And when the speaker declines? Ask them to propose your project to their friends and connections; they'll usually be happy to do that.

Also, bear in mind that we are one interconnected community so many speakers may be hesitant at first, but even the best speakers can be convinced when you start adding (even relatively unknown) speakers to your website. A page full of names, talks, and synopses - in two words: great content - is a must if you're serious about your thing and want to get anyone with renomÃ©.

Build Your Credibility

But don't let the fact that this is the first year of the conference play against you. Sure, first-class speakers want to come to first-class events, so what can you do to get them when you're starting and have no history?

The number of people and the length of the conference are crucial. It's much more simple getting the speakers you want for a three-day long project for five hundred attendees than a single day event for a hundred people. And go international, don't be local.

You may not have thought about this, but the ticket price also plays a huge role. Don't sell yourself for fifty euros a piece – you've put a lot of energy into bringing the crÃ¨me de la crÃ¨me to your conference, and you're about to launch the next best tech event out there, so make the world know your worth. After all, you're probably trying to convince cool people to come to a cool place and hang out with other cool people.

Fun Comes First – But Problems Too

You must always remind yourself, however, that it doesn't matter if a complete newcomer or Mark Zuckerberg is coming to your conference. All speakers are your guests, friends, and the superstars of your conference, and you have to treat them with equal respect and kindness.

Make it all fun for them. Tell them to bring their partners and families, arrange and pay their travels and stay, assign them a personal assistant to fulfill all their wishes. Send a cab to transfer them from and to the airport. And not just that: we organize special trips and throw speakers-only dinners. Last year we did a banquet at the Bratislava castle, the most exclusive place in the whole city. Treating your guests as VIPs costs money, time, and effort, so you'd better count with all that beforehand.

As hard as you may try, though, there's always a risk some speakers may cancel, and that you'll have to find appropriate substitutions. In such case, ask the speaker to spread the word about your conference to their network, and let them try to find the alternative. Just don't be a bitter betty about the whole situation – your bad attitude won't help anyone. Stay as positive and flexible as you can.

Make Your Own Stars

Getting to know new people, listening to new ideas, and being excited from new concepts is why we do ReactiveConf in the first place. It's also the reason why we started doing Lightning Talks, a sort of competition, where we give an opportunity to great new minds to share their innovative thoughts to the audience.

Anyone can apply for their five minutes of fame at ReactiveConf – they just have to send us an enlightening pitch! We gather all the entries, and later we let the attendees pick the ideas they want to hear most about via Twitter and other social media before the conference.

This way, we discovered Ossi Hanhinen last year, an Elm and Elixir expert, who then started co-organising his own Elm meet ups in Helsinki and published his article in the prestigious Hacker Bits magazine.

I can't even express how proud I am that our conference is not only a blossoming business and an exciting event but also a platform where the community can meet, share and grow.

–––––
ReactiveConf is a web and mobile app development conference, of which Samuel Hapak is a co-organizer.

ReactiveConf is taking place from October 26th to 28th 2016 in Bratislava, Slovakia.

The Practical Dev brings you 20% discount on tickets using devto code.

Past and future of client-side routing

Thomas Roch — Fri, 23 Sep 2016 22:28:25 +0000

I've been given the opportunity to speak at ReactiveConf next month where I'll talk about client application routing. I have been experimenting with and working on routing for nearly two years, and it all began when I started to slowly transition from Angular to React. In June last year, the first React Europe conference took place in Paris. I watched it online, and during his Keynote, Christopher Chedeau (AKA Vjeux) said, talking about routers in React:

We've only seen one player. Is there any innovation going on? (...) Innovation already happened a few years before. And it happened in the Ember community.

At the time, I was working on the first release of router5, a framework and client agnostic routing solution. It is interesting to try to understand what has influenced routing until recently and shaped our "mental model", and why we've believed routing was for most parts a solved problem.

The way we do routing in client applications has been influenced by server-side routing. On servers, routing is some sort of stateless pattern matching. For a given request, a route is matched and a page is returned after execution of a controller method or callback. We have translated this "route => page" approach to clients by making routers responsible for rendering route-level components in single page applications: "route => view" or "route => component". Client applications are not stateless and deal with state transitions (including route transitions), but the server way of approaching routing has led us to hide state away.

If this short introduction makes you want to hear more about routing and new ways to approach it, then don't forget ReactiveConf next month!

How Igor Minar and the AngularJS Team Build Software

Ben Halpern — Wed, 21 Sep 2016 14:14:25 +0000

Software development can be as much about choosing the right technology as it is building it. Decisions like which front end JavaScript frameworks to tie your application's future to are difficult because there is so much to consider about the present and future of needs. The landscape has been in shift for quite some time and you might find wholly different outlooks depending on who you talk to. There are a lot of considerations in choosing a JavaScript framework, ranging from the technical minutia of message passing and data flow, the supporting built tools and module ecosystems and various learning curves.

At the core, though, the decision might be less about the API details and more about the outlook for the project, getting a sense for how the team operates and thinks about software. The success and failure of open source web projects like Node, Rails, etc. depend on a lot of factors in teamwork, leadership and vision. Extremely well-funded projects like Famous.js have failed and projects maintained by a few people in their spare time sometimes thrive.

I will be attending Reactive Conference next month, where Igor Minar is going to discuss how the web ecosystem shaped its application framework. Igor is the leader of the Angular project, the popular JavaScript framework developed by Google. I reached out to him to ask some question I had about how the Angular team operates, from his perspective. With Angular 2.0 having been recently released, it's worth getting a feel for how the project lead treats development strategy and community, for your consideration when mapping your own application's future.

Igor is a busy individual, so I am grateful that he was able to answer a few questions.

Questions for Igor Minar

How does the team make decisions and weigh input from the greater community?

There are two primary ways this is done. First, all of the development is done in the open and we make all of our design docs and meeting notes public. This allows the community to weigh in and point out missing requirements or overlooked designed flaws. Second, we are in daily contact with many members of our community that provide valuable feedback and highlight issues that we might have missed.

How do you balance thinking about short term needs and future-proofing the project?

It depends on if we are talking about public API or internal implementation. With the public API, we tend to be conservative because mistakes here could be very costly to fix, often it makes more sense to provide a workaround for a short term need then change the framework. When talking about the internals of the framework, the focus is on maintainability and malleability because that's what allows us to evolve the framework.

How does the team deal with any technical debt that may accrue, or deal with conflicts of design?

In the ideal world all technical debt could be avoided, but that's not possible in a world with deadlines. The most important thing for me is that everyone contributing to the code-base feels a sense of ownership and responsibility for it. This combined with various checks during our CI testing helps to decrease but not prevent the amount of technical debt. When the accrued debt starts to interfere with our ability to get stuff done or when we have a bit of down time, we go back and clean things up.

How do you approach coding for a framework or library differently than coding for an application?

The biggest difference between building an application and building a framework is that applications interface with people that (relatively) easily adjust to changes. If you move a button by a few pixels or change its color, people will most likely be able to use your application just as before. If you make a minor change to a frequently used api of a framework all the applications that use that api will stop working. This makes it much easier to iterate on an application compared to a framework.

Advice for someone interested in contributing to the project.

Start small and be persistent. We review lots of community contributions and only very few can be merged as is. Many people want to contribute to Angular and make big changes, but these are often the changes that get turned down. Not because they didn't originate in the core team, but because of how the change was implemented and how it integrates with the rest of code base. By starting small, for example with documentation changes and bug fixes, you get to learn about our testing, documentation and other requirements.