Deep-dive into the future of development. Stay ahead of the curve.

ReactiveConf covers all cutting-edge mobile and web tech stacks. We embrace diversity of thought, and we give you a snapshot of what’s coming next in web and mobile development.

ReactiveConf

This talk shows how quick and simple it can be to write end-to-end tests for web applications – if your testing tools are not fighting you all the time. I will go over writing E2E tests using Cypress.io, controlling the network during tests, using visual testing and setting up continuous integration to perform E2E tests on each commit.

Cypress.io – the State of the Art End-to-end Testing Tool

The monorepo odyssey

Giant cows, flying rabbits, and the moon — Humor and the unexpected as tools for productivity

Distributed markdown apps

The future is now. Or then. Or it will be soon be now, but now is then.

JavaScript and its ecosystem is ever evolving and JS fatigue can be real. It’s a lot to keep up with. Staying up to date on the ever moving system feels like a fool’s errand and to some degree it can be.

But in this talk we’re going to chat about a few things:

– what’s new and important now with ES2018, ES2019 and beyond
– what’s new and important in the JavaScript ecosystem and tooling
– how to sanely integrate new features, tools, and such into your existing codebase today.
– how to get the most of using VSCode with futurist code

Come chat about the future and how to touch it today.

Futurist Code Bases: Integrating JS of the Future Today

Typescript is in full hype mode right now. Twitter gives us a new hot take daily, but most of us haven’t seen the long term benefits. Dropbox switched to Typescript in 2015 and we’ve seen the good, the bad, and the ugly. 

In this talk we’ll take a step back from the hype and cover what we’ve learned over the past four years. We’ll discuss how static typing has helped us scale a codebase, and when it’s worth it just to write an any and move on with your life.

TypeScript: Seeing Past the Hype

Unlim.io

Progressive web apps can be difficult to support, hard to test, and _unfortunate_ to maintain. With Expo for web you can maximize code sharing between your native and web apps. The robust set of Unimodules provides you with unified APIs for things like camera, gestures, image picker, persistent storage, and more. 

Optimized for performance, Expo’s Babel preset enables you to do advanced tree-shaking which removes all unused platform code. New universal testing libraries make it easy to ensure your app is running as expected on all platforms. 

Expo web also provides a set of Webpack plugins for adding offline support and automatic generation of PWA assets. 

I’ll be discussing this, and possibly some future plans for supporting things like universal navigation, SSR, and connected applications with things like apple site association.

Expo for Web

How can we extract the most value from our front-end JavaScript errors, especially when users often don’t report them?

We’ll learn about the evolution of the browser’s global error event handler and how to work around its limitations — cross-browser idiosyncrasies, stack traces as unwieldy strings, minified code, and other fun stuff that we really look forward to dealing with! We’ll also look at libraries to make JavaScript stack traces more useful, along with other techniques for making our bugs a little less buggy.

Kicking Bugs and Logging Names: Errors in JavaScript Error Reporting

Are we there yet? Remix

Tech companies of all sizes have dropped the ball when it comes to the privacy of their users. Many users find themselves asking, “How could this breach have happened?” and “What happened to my data?”. Surprisingly, many of these large-scale data breaches have been 100% preventable. 

I’d like to walk through the pitfalls of some of the largest data breaches of the past few years, what we’ve learned from them and how engineering teams can avoid them going forward.

Learning from High Profile Failures

Can React and web technologies compete with native toolkits when it comes to making super complex, rich desktop apps? Can we go further and create better-than-native applications?? Sounds like a good challenge

This talk introduces how React, JavaScript and WebAssembly can be used to write new ambitious apps, or port existing ones – with the real-world example of my open-source game development software. I’ll show how to leverage the React ecosystem to create performant applications: architecture, patterns, typing, useful open-source modules… and how to go one step further and provide a better user experience as well as a better developer experience.

These apps are not web apps, they are not native apps, they are hybrid “Native Web Apps” and can provide the best of both worlds.

Native Web Apps: React and WebAssembly to Rewrite Native Apps

Real-time & Offline-ready Serverless GraphQL with AppSync

Building your own real-world, secure & scalable GraphQL API is a lot of work. With AppSync, robust GraphQL APIs including schema, resolvers, and data sources are created & configured automatically and instantly through either the AWS Amplify CLI or the AppSync console, abstracting away much of the complexity traditionally involved with setting up a new GraphQL backend.

In this talk, I’ll demonstrate and discuss the more interesting and powerful functionality that AppSync offers and do so in a way that developers will walk away with a confident understanding of how AppSync works and can be extended to help them in their day to day.

We’ll also create a real AppSync API & connect to a React application in a demo to demonstrate what we discussed in the talk in a live coding exercise, showing how to create queries, mutations & subscriptions directly from a client-side application.

Full Stack Development in the Era of Serverless Computing

Electron is one of the most popular platforms today for building cross-platform desktop applications. We shipped v1 of our code editor, Onivim, using Electron, and while it was wonderful to leverage web technologies and frameworks like ReactJS, we faced numerous performance challenges.

In order to meet our performance goals, we decided to re-architect and move to a native solution based on ReasonML. In the process, we built a new desktop application framework called Revery, which lets us enjoy the ReactJS & Redux style of development… but with native code performance! This move has drastically improved our startup time, responsiveness, and memory usage. In addition, we’ve been able to take a new approach to our core architecture – leveraging functional programming principles.

We’ll discuss our journey of shipping a cross-platform desktop app with this new technology stack, and share our successes and challenges in migrating from TypeScript/React/Electron to ReasonML/Revery for Onivim v2.

Onivim 2: Re-Architecting for Performance

Vue.js 3 is just around the corner and along with many exciting improvements it introduces a new, function-based API to design components, called Composition API.

In this talk, the attendees will get an overview of the new Composition API and learn how they can use it to improve code quality and reusability.

Motivation for Composition API:
We all love how Vue is very easy to pick up and makes building small to medium scale applications a breeze. But today as Vue’s adoption grows, many users are also using Vue to build large scale projects – ones that are iterated on and maintained over a long timeframe, by a team of multiple developers. Over the years we have witnessed some of these projects run into the limits of the programming model entailed by Vue’s current API. The problems can be summarized into two categories:

The code of complex components become harder to reason about as features grow over time. This happens particularly when developers are reading code they did not write themselves. The root cause is that Vue’s existing API forces code organization by options, but in some cases it makes more sense to organize code by logical concerns.
Lack of a clean and cost-free mechanism for extracting and reusing logic between multiple components.

The APIs proposed in this RFC provide the users with more flexibility when organizing component code. Instead of being forced to always organize code by options, code can now be organized as functions each dealing with a specific feature. The APIs also make it more straightforward to extract and reuse logic between components, or even outside components. We will show how these goals are achieved in the Detailed Design (https://vue-composition-api-rfc.netlify.com/#detailed-design) section.

You can find the details for composition api in the RFC page (https://vue-composition-api-rfc.netlify.com/#summary).

Vue 3 and Composition API

Remember loving to read comics on a Sunday afternoon when you were a kid? Maybe you don’t. In the past, traditional print comics have made it impossible for blind and visually-impaired readers to experience their heroes’ adventures first-hand. Today an increasing number of initiatives like comic book stores for the blind aim to overcome this challenge.

What if I told you that the web platform empowers us to even create comics for literally everyone?

Alongside a demo application, you see how accessibility best practices enable you to craft an immersive webcomic experience that is not only engaging for the sighted but accessible for everyone.

Crafting Comics for Literally Everyone

PWA vs Native

When you’re building a component library or a design system, you’d want to visualize how the growing number of components look in their different states and variations. One way to achieve this would be writing every possible variation of the component by hand. This is a manual process, harder to maintain and means a lot of lines of code. 

What do we all have in common as developers? We hate all those 3 things.

In this talk, you’ll find out how you can automate your component variation rendering process and improve your workflow by applying the Cartesian Component concept. The code will be presented in React but the concept is applicable to the components written in other frameworks as well

How a 16th Century French Mathematician Helped Build a Design System

Amr gives an excellent talk on privilege, diversity, and inclusivity. He adds the missing context to these terms, and shows how they can impact our products from a pragmatic perspective.

Belonging to an underrepresented group in the European tech scene myself, I most of the times struggle with colleagues who undervalue the principles of diversity and empathy.

I realised that these topics are rarely debated within the tech scene logically and pragmatically without pointing fingers.

Do you believe political correctness and empathy are buzzwords that limit the society rather than contribute to its advancement? Do you think talking about topics like diversity quotas, privilege doesn’t make much sense and you would rather spend this time talking about the latest in technology?

In this talk I would like to take the chance to try and add the missing contexts to such terms and arguments, moreover, I will try to go through various examples on how it can impact your product from a very pragmatic prospective.

Privilege as a Technical Debt

All our software is a bundle of decisions. But despite the fact that some decisions can have a long-lasting, crippling effect on our app, we make most of them based on guesses.

But what if the best decision is indecision? What if you could postpone most of your decision until you gather enough facts in order to make the optimal one?

In this talk, we will learn why deferring decisions can result in a much better, simpler code base. We’ll see examples of decisions we think we have to take on day 1 of the project, yet, can (and should) be postponed and see how practices like Spikes and the right design of your application will allow that to happen.

Indecisions Are Not All Bad

Sean gives an amazing overview of Rust, for JS developers.

Thanks to wasm, Rust can reach the platform with the largest reach: the browser. We’ll take a look at how thanks to the impressive language design, thoughtful compiler error messages, and great documentation, JavaScripters can unlock high-performance concurrency and graphics thanks to Rust. 

We’ll step through Rust/wasm/JS interop, see what it’s like to get a reference to a canvas instance, to communicate with services workers, and to pass data between all the pieces involved. We’ll take a look at what’s enabled, as well as pitfalls around the data boundaries involved, and the size of the final payload, so that it’s clear where the cost of introducing Rust is outweighed by its benefits. 

Finally, we’ll speculate on how the web may develop, with a Rust-core/JavaScript-surface design, combining high performance, safety, while maintaining ease-of-use.

Rust in the Browser for Javascripters: New Frontiers, New Possibilities

As GraphQL moves into the mainstream, the tooling & ecosystem has grown and has made it possible to do much more with GraphQL than using it as just a data layer. In this talk, I’ll show how developers are using GraphQL as an API gateway to accomplish things that you may have never thought possible.

More details:

When we think of GraphQL at the resolver level, we typically associate some type of database as the resolver data source, but in practice a resolver is simply a function. What this means is that we can do much more with our GraphQL APIs & our resolvers than we ever thought possible, including things like taking existing REST APIs & transforming them into GraphQL APIs (http resolvers), passing the query to Lambda or serverless functions for processing & returning the response via a GraphQL query (for things like AI & ML), geospatial & time-based queries (passing the query to Elasticsearch), & even VR & AR apps (passing in user location / app info & using the subscription to transmit image assets). 

In this talk, I’ll walk through what this looks like in theory & in practice, demoing 4 different applications that implement this functionality & showing the code that make the magic happen.

Curious Use Cases of GraphQL

Nuxt.js is a framework based on Vue.js giving you all the tools to create any kind of applications (Universal, SPA and Statically Generated) while keeping performances and best practices at the top. 

Sebastien will demonstrate how to create a web application quickly by using Nuxt.js and explaining how it works under the hood. Giving you confidence for your next Vue applications.

Be Lazy, Be Smart, Be Nuxt

We all love our privacy as we should. Web and web monetization, today, however, works differently and is reliant on tracking our activities exposing us to the web. 

Almost all publishers and content creators rely on advertising to monetize their content which inherently relies on tracking to allow them to continue to survive. To allow the web to deliver monetization for Publishers and content creators while keeping users private, we created Brave Rewards. 

In this talk, Nejc will provide a vision for what a new, private web looks like and how everyone can join in and contribute to the future of the private web together.

Brave Rewards, a New Way to Think About the Web

Day #1 wrap up

Backpressure—resistance opposing the desired flow of data through software—from massive scale, to death by a thousand cuts, it’s something nearly every software engineer will have to deal with at some point on the client and server. 

For some, it’s a frequent problem. But the term itself isn’t nearly as understood and recognized. 

In this talk, we’ll discover what backpressure really is, when it happens, and the strategies you can apply to deal with it.

Backpressure: Resistance is NOT Futile

As technology advances and the applications we build become more complex, the tools that we use to secure the data shared within these products need to follow suit. We need to ensure that we deliver a high standard of protection to users, allowing them them to seamlessly use the product without thinking about security or any potential threat. Even just a thought of any risk could lose us our customers’ trust and therefore millions in investment and in turn threaten our entire business as a whole (including our jobs).

A security breach is a very real problem, both personally as an individual and professionally in a business sense. But we as developers can help fix this problem. In very recent years there has been a number of incidents involving npm dependencies pushing vulnerabilities to consumers or exposing data. This led to the npm team purchasing a security tool to prevent future incidents. These incidents can easily be stopped and further prevented from happening again. NPM is the first main carrier of personal information and it, therefore, should be where we start to repair these issues.

In this talk, we will look back on the previous incidents and do a postmortem investigation on what happened, and how it could have been prevented. We will then take a further look into tools and products that can help protect our applications going forward and some basic best security practices that we all should follow, no matter our application.

Protecting your npm Dependencies

Open-source modules on the NPM ecosystem are undoubtedly awesome. However, they also represent an undeniable and massive risk. You’re introducing someone else’s code into your system, often with little or no scrutiny. 

The wrong package can introduce severe vulnerabilities into your application, exposing your application and your user’s data. 

This talk will use a sample application, Goof, which uses various vulnerable dependencies, which we will exploit as an attacker would. For each issue, we’ll explain why it happened, show its impact, and – most importantly – see how to avoid or fix it.

StrangerDanger: Finding Security Vulnerabilities Before They Find You

How does PWA concept play with YOUR favorite framework? React, Angular, Vue, #FrameworkOfTheWeek? In my technical session, we’ll check what major frameworks creators prepared for us regarding scaffolding / adding PWA features (spoiler: only basic features), and switch to Workbox. 

We’ll see that Workbox is a library providing many sophisticated service worker features in a simple, developer-friendly form. Also, we’ll talk about another advantage of Workbox – the flexibility: you build your own service worker and automate some tasks using this library. 

As the outcome, you’ll be ready to make a production-ready PWA from the app built on any framework.

Many Frameworks – One PWA Solution

The next billion users face environmental factors that are vastly different to most developers.

This talk will take a fresh approach to address the needs of users in remote or austere environments by building on top of current PWA standards for a web resilient web experience.

Resiliency and PWAs

Butter-smooth animations

“Breaking Out of Box” or Writing a Wasm-based Gameboy Emulator in Rust for Frontend-Developers

Everyone wants to put us in a box, but today we’re going to break out – no webpack, no v8, none of the dizzying 1,000 levels of magic and abstraction that we alternatively enjoy and wrestle with day to day. Instead, we’ll take a journey to simpler times with a gameboy emulator, where every line of code we write maps to an exact cycle count on a known CPU.

We’ll simultaneously learn about this newfangled language called “Rust,” and how it allows us to express the low-level designs of this ancient CPU while sussing out high-level, zero-cost abstractions for our modern code. We’ll compile a web-assembly (“wasm”) binary to run in the browser to explore interop between Rust, wasm, and JavaScript, and see what a full toolchain looks like.

Finally, our journey near its end, we’ll reflect on why we would care about stories about low-level CPU programming; what we lose and gain from JavaScript’s wonderful abstractions, and most importantly, what it all means to us as engineers.

“Breaking Out of Box” or Writing a Wasm-based Gameboy Emulator in Rust for Frontend-Developers

GraphQL has exploded in popularity since its public launch in 2015, and PostgreSQL is still going strong after 20 years of development, gaining market share and impressive features at an ever-increasing rate. These tools can pair beautifully, in particular, because they’re both strongly typed and declarative. 

In this talk, we’ll learn how combining these two technologies can lead to massively increased software development and delivery speed, faster APIs, fewer bugs, and ultimately enable you to focus on delivering value on the frontend rather than maintaining three different layers of data models and associated logic on the backend (DB, application, API).

Increasing Velocity with GraphQL and PostgreSQL

We all love the modern JavaScript stack, but why does it sometimes feel like it takes us weeks to achieve what Rails developers can do in one afternoon? 

In this talk, I’ll use my own experience building Vulcan.js –a full-stack GraphQL JavaScript framework– to explore what a modern “Rails for JavaScript” would look like, and seek out the path to reclaiming our lost productivity.

Vulcan.js: Building the “Rails for JavaScript”

Vue composition API

The Expedition

Lightning Talk

What if it was possible to build backend features for our react apps in the same way that we use redux in our react apps? 

In this live-coding demo, I will show you how we’ll add backend business logic using the redux abstractions of dispatching actions, writing reducers as pure functions and subscribing to updated state. 

Our backend will be completely serverless and using open-source and managed services so that we’re not actually deploying and maintaining any servers. We will use GraphQL mutations from our react app to dispatch actions. These will trigger serverless functions which are pure and return the modified state, which will be persisted safely on a cloud-managed database. 

Portions of your app that are subscribed to the state using GraphQL subscriptions (live-queries) will automatically update! 

You will witness the raw awesomeness of being able to use javascript and graphql in a pattern that you are comfortable with to build backend features from scratch.

Live-coding demo – Build your own backend in the `redux` style with GraphQL mutations (dispatch), `pure` serverless functions (reducers), and GraphQL subscriptions (updated state)

You know that fear. The fear of changing something in your CSS. Deleting a CSS rule is a lesson in getting yourself to calm down, telling yourself that it’s OK, you are absolutely _sure_ that deleting that rule won’t change anything.

And only manual testing can assuage that fear. And yet, even then, you’re still frightened that you haven’t checked _everything_, and that you missed something. Not to mention that it’s amazingly boring.

Never fear again! Testing your CSS code, testing the _visual_ aspects of your code, is now possible, and I will show how. A slew of new Saas tools have come to the forefront which enable us to write tests that check that everything is the same that it was (even if we moved from BEM to CSS-in-JS).

So grab that keyboard, refactor your CSS, because writing tests for it is now possible!

Don’t Believe the Rumors: Writing Tests for CSS is Possible

Why is the financial services industry struggling to embrace fintech?

Welcome to Global Tribal Banking

The Web has changed a lot since its beginning as a platform for static articles. At first, Web applications did not exist. Then they began to appear in the form of servers generating HTML on the fly. PHP was huge, then fell by the wayside as JS rose. Flash came and went. Today, the Web has become the biggest application delivery platform in history and based on its past, the one thing we can be certain of is that more changes are yet to come.

What, specifically, might those changes be? What differences might the Web of 2020 have to the the Web of 2019? What about the Web of 2025? What would the impact be on Web developers? In this talk, Richard draws on his 12 years of professional Web development experience, and history of being an early adopter of technologies like React in 2013 and Elm in 2014, to make and justify some concrete predictions about the future of the Web in both 2020 and 2025.

Predicting the Future of the Web

Day #2 wrap up

The web & mobile ecosystem is huge and diverse. New and amazing ideas emerge non stop. When this conference finishes you will have heard a lot of new exciting ideas, tools, and projects. 

What are the things that you should start learning now to stay tech relevant tomorrow? One thing is for sure, you can’t master them all.

How to Stay Tech Relevant

This talk is the inception of debugging the Firefox devtools’ debugger which is built using React and Redux. All of us love to ‘console’ log our code, but there are other effective techniques that will help accelerate the debug loop cycle. 

In this talk, I will present the various available browser devtools debugging techniques using practical examples from the community to debug the development of the debugger project!

Debugging the Debugger

5 steps to avoid lawyers in digital business

- JS – what is good, what is bad – a brief overview of when JS shows himself on the good side and when on the bad side
- Comparison of type systems. Dynamic weak versus static strong
- ReasonML what is it?
- The main benefits that you can get when using RML
- Syntax examples
- Types
- Type inference
- A general overview of the workflow
- BuckleScript
- Work with third-party code, package managers
- How can we use JS in RML
- Editors support

Reasonable Reasons for ReasonML

How can you make sure that your web app performance stays high? Google Analytics and measuring loading times will no longer cut it in the single-page apps world. What defines performance from the user perspective anyway?

In this talk we’ll go through the thought process of performance monitoring in production (and if it’s even a good idea), see what we can measure, what React has to offer, and how to integrate all parts into a solution that automatically reports performance issues to developers.

Profiling React Web Apps in Production

Through a series of animated demos and funny failed experiments, join me on my journey towards building a musical game where the controller is a digital piano!

Highlights include:

– Using the Web MIDI API with Elm via JavaScript interop to get input from a digital piano directly in the web browser
– Exploring SVG animations in the Elm ecosystem
– Elm’s best features from the perspective of a beginner who recently fell in love with the language
– Silly and instructive beginner mistakes (how not to use Elm!)

Building my first Elm app was a two-for-one deal: learn functional programming and learn to sight-read sheet music! By the end of this talk, I hope you’ll be equally excited to combine these web technologies in your own creative adventures.

Building a Music Learning Game with Elm, Web MIDI, and SVG Animation

Is it possible to write one application for all possible platforms and devices? How to design such architecture of your application which will allow you to share components, application logic and even more? 

We will speak about how to create and manage this kind of project, what are the pros and cons and how you will save valuable time. In the end, your application can share code between mobile, web and even television platforms!

React Everywhere

Mobile web apps have long been considered inferior to native mobile apps. Mark Zuckerberg’s assertion in 2012 that use of HTML5 in the Facebook app was “the biggest mistake we made as a company” and similar statements have reinforced the idea that mobile web apps are too slow and clunky to provide a satisfying user experience. 

To a large extent, these attitudes are now outdated. Mobile devices have made incredible improvements in performance, access to native hardware and many other areas over the past few years. 

In this talk, we examine in detail the reasons for negative attitudes about mobile web apps among developers. We then ask whether these attitudes still make sense today. 

We also discuss the role of Progressive Web Apps (PWAs) and how newer frameworks like React Native should influence developers’ decisions about which route to take when developing a modern mobile app.

What’s Wrong with Mobile Apps Anyway

The frontend platform team at productboard is responsible for facilitating discussions about the future of the frontend stack, maintaining long term technical roadmap and improving the productivity of front-end engineers. 

In this talk, we will discuss arguments for frontend platform teams and look at potential caveats of platform teams and how to overcome them.

Establishing Platform Teams to Utilize the Economy of Scale

The new way of coding React components using a pure functional style. The speech compares the coding style of React components using 1) Javascript classes and 2) pure functional style with hooks. 

Some advanced concepts of using custom hooks and developer and code performance are presented. 

The speech is for React practitioners (i.e hardcore ? ).

React Custom Hooks

Making a New ContentEditable Editor

The choice of the technical stack is very important, isn’t it? Libraries, frameworks, languages, all of these things can help a product to develop, but can also lead to a catastrophic collapse.

Five years ago, at Wrike, we chose Dart as the main language for frontend development. Since then, we have written more than a million and a half lines of code and our R&D team has grown almost tenfold. But we never thought that choosing one single language could lead to such consequences!

The story about how we chose a language and where we were wrong (and where we were right) and why your choice can cost you so much.

Butterfly Effect: the Story about One Technical Decision

Thanks to modern component-oriented architectures, the front-end community has been naturally gravitating towards design systems as a way of standardising our respective design languages into reusable components. 

When done successfully, it suddenly becomes trivial to translate standard designs into code. In fact, we may even find that this translation step starts to feel somewhat redundant. 

In a world of components, how should our design processes change? How should our tooling change? How should we, as front-end developers, better enable this change? 

In this talk, we’ll look at the current state of design and development, and where we could go – if we’re willing to push for it.

Rethinking Design Practices

What if you could predict user behavior with smart UIs? 

In this talk, we will explore how we can make adaptive and intelligent user interfaces that learn from how individual users use your apps, and personalize the interface and features just for them, in real-time. 

With probability-driven statecharts, decision trees, reinforcement learning and more, UIs can be developed in such a way that it automatically adapts to the user’s behavior

Mind-Reading with Intelligent & Adaptive UIs

Performance has many faces, and one of those is TTI which is the time your users
have to wait before being able to use your app, we’ll explore a few techniques we could use to reduce that time gap to make your users happier and ultimately making your app more successful.

Optimising React’s TTI

As our company and (especially) tech teams grow, our need for better deployment processes increases too. We started with tedious, manual tasks and through a process of continuous improvement over the course of the past 6 years, reached full automation. 

This is the story of how we have achieved it.

ReactiveConf 2019

Oct 30 - Nov 1 | Prague, Czech Republic