The Ruhr Area is the biggest metropolitan area in Germany, with nearly 5.4 million inhabitants and of course, home to Zalando Tech Dortmund. Being the former industrial heart of Germany, it has made a terrific structural change towards services and information technologies in the last few years.

To reflect the growing impact of the Ruhr Area in the IT-sector and to strengthen the frontend community, RuhrJS was founded, an international JavaScript conference taking place from 2-3 July.

We wanted to summarize the most interesting talks we attended and give you an idea of our learnings and takeaways.

Magic MobX - Become a reactive wizard in 30 minutes (Michel Weststrate)

When you use ReactJS as a rendering library together with Redux for state management, do you think you have found the perfect technology stack for the next few years? You are a JavaScript developer, you should know better!

With MobX, developed by Michel Weststrate, an alternative application state management library has emerged that’s worth looking into.

MobX makes your application state fully reactive, so there is no need for a dispatcher or reducers to take care of your state, nor some complicated change detection algorithms.

With MobX the application state can be made observable, using the corresponding decorator:

class TodoList {
       @observable todos = [];
       @computed get unfinishedTodoCount() {
        return this.todos.filter(todo => !todo.finished).length;
        }
...
}

The @computed decorator ensures that unfinishedToDoCount updates if todo is modified.

Everything that should be triggered by state changes, like updating the ui, is handled by so called Reactions, annotated with the @observer decorator. You can turn your React components into reactive components with the following:

@observer
Class TodoListView extends Component {
    render() {
        return

                {this.props.todoList.todos.map(todo =>

                    )}

            Tasks left:
{this.props.todoList.unfinishedTodoCount}

    }
}

Application state will be changed using Actions (similar to Redux or Flux in general), but MobX itself isn’t picky about how this should be handled.

If you’re more interested in the pros and cons of using MobX or Redux, have a look into this linked discussion.

Sacrificial Architecture in Modern Web Development (Francesco Strazzullo)

Francesco opened up our minds about what developers very rarely consider when planning a new web application; notably that your architecture, frameworks or requirements will change during the application's lifetime.

Sacrificial Architecture, defined by Martin Fowler, means accepting now that in the near future you’ll have to throw away what you are currently building, partly or as a whole.

From the beginning you should consider your architecture to be flexible enough to easily renew deprecated components. This can be achieved with the correct modularity and a strong separation of logic, for example.

If you are using frameworks like Angular, design your way out of the framework by preventing framework specific code inside your business logic (one example is using the common Fetch API instead of the $http module).

Additionally, pay attention when separating business logic from your UI components. Use events to dispatch the changes and take care of them outside of your UI components instead of using business logic inside of them.

I think every developer knows that the code they write has a limited durability, but having never written code with this in mind, the talk was something of an eye opener.

Angular 2 Change Detection Explained (Pascal Precht)

We were particularly curious about this talk since our Team started to develop an Angular 2 application some months ago (which is in production now!) and we’ve already gained some experience working with the framework.

To understand the Angular 2 change detection it is important to understand when, how and why change detection is triggered. Pascal Precht pointed out that change detection has to happen whenever the state of your application is mutated. The cause of those mutations is always some asynchronous event, for example a user input or HTTP requests.

So how does Angular 2 know about such things? The answer is Zones. Pascal managed to explain the concept of Zones (a language feature in Dart which was ported to JavaScript) and the event loop on the fly during his talk which was very enlightening. Furthermore, he described some other core concepts like the component tree and pointed out the usefulness of the concept of immutability to improve performance during change detection. It was also interesting to see how some of the shown concepts converge with topics presented in another very interesting talk by Max Stoiber about Scaling React applications.

On NES Development (Fritz van Deventer)

Initially, a talk about NES development, only slightly related to JavaScript, did not match our criteria for “must see” presentations. However, Fritz van Deventer made a point of “doing new things” and widening your horizon, and the slides alone, partially shown on the NES, were worth it.

Furthermore, Fritz talked about how constraints are a beautiful thing, fostering innovation and creativity (think Twitter, think programming), why removing abstractions is a good idea (you actually understand things), and why “not invented here” is a dumb response most of the time.

You can check out the mentioned npm packages if you are interested in more details.

From our point of view, the RuhrJS was a worthwhile conference for us Dortmund folk. Every single talk had its right to exist, and the variety of topics was huge and well composed. A big thanks from our side goes to the organizer of the RuhrJS, 9Elements and Madeleine Neumann in particular. We are looking forward to subsequent conferences and are very excited about what’s to come for next year.