When Cerebral was released last year, it was a celebration of people gathering around an experiment. An experiment building a framework that understood the application it was running. A framework that would free us from getting lost building mental images of how the application works; letting us explore a graphical representation of the state, state changes, side effects, renders, and ultimately how these interact. With Cerebral 2 the experiment has matured into a framework that truly stands out in the JS jungle.
In this article we are going to talk about writing good code and what challenges we face reaching for it. Readable, declarative, composable and testable are all terms related to writing good code. Often pure functions is referred to as the solution, but writing web applications is mostly about side effects and complex asynchronous flows, concepts that are inherently impure. This article will explain a concept that allows us to inherit all these great attributes of pure functions and still embrace side effects and complex asynchronous flows.
In the world of web applications it is not enough to just write code. We also need a well thought out interface for our users to interact with the application. The web has changed a lot the last few years as we have moved from building static websites to full fledged complex applications. The workflow of writing code, collaborating with designers and push great products out the door is still changing as we explore this brave new world. In this article I am going to tell you about a collaboration where the designer treats the developer as a manufacturer of components, and how this idea can make very happy developers and designers.
Functional Reactive Programming concepts is really grabbing a hold in the community these days. Projects like Elm, Cycle JS, Angular2 and soon to come RxJs5 is all over twitter, at least on my account :) They are all about observables. If you have not heard of observables they can quickly be explained as a way to handle input over time. This input coming from a mouse click, messages over websocket or whatever really.
In the previous article we took a look at Elm and how we can structure Elm applications. It is important to divide logic into different files and allow views to share state and trigger any actions to change the state in the application. This is based on ideas from Flux, which allows us to structure and scale applications without causing a lot of pain.
I attended the Reactive Conference in Bratislava a couple of weeks ago. I even gave a talk on Cerebral if you want to check it out. One of the questions after the talk was “How does Cerebral relate to Redux?”. This is a difficult question to answer because they really try to solve different problems, but I would like the opportunity to answer a redefined question: “How does Flux differ from using a single state tree?”.
It has been a year since I first got into React and Webpack. I have many times expressed that Webpack is amazing, but hard to configure. That being truthy I think there is a different reason why developers does not adopt it. So I want to go head first and say; “Webpack is amazing, but it is hard to understand why”. In this article I will try to convey the core of what makes Webpack great. Then we are going to look at the very latest contributions to the Webpack/React ecosystem.
How we think about building web applications evolves quickly. It is not long ago Backbone was the mainstream choice for developing applications. It still is for a lot of developers. But a lot has happened since its release. We got Ember, Angular and the latest mainstream breaker was React with its Flux architecture.
The MVC (Model View Controller) architecture is referenced in almost all Frontend frameworks. Angular, Ember, Backbone etc, but is it really MVC they are implementing? And is Flux really a different architecture? In this article I am not going to go all academic on you, I am going to tell you about why I think Frontend frameworks are not implementing MVC correctly, and that Flux is actually a lot closer to traditional MVC than any of the other frameworks, but still does not quite “get us there.” This is a bold statement, but please read on and I will explain.
I have been writing about React, Webpack, Flux and Flux like architectures for quite some time now. All these ideas and thoughts have been churning around in my head and after watching this video on how Elm is able to control the state flow of your application everything just came together. I wanted to take what I have learned so far and build something that tries to solve all the challenges I have been writing about and at the same time bring something new to the table.
So Baobab is here in version 1.0. Let us quickly recap why Baobab is such a great tool for your application and then we will see what version 1.0 addresses in regards of complex state handling. I encourage you to read the initial article on Baobab first as it introduces why you would consider Baobab at all.
Note! The repo created for this article has quite a few updates. That said, it is within the same domain. So please read through for inspiration, but make sure you use the latest repo version to get the latest implementations.
I want to take a step back from React JS, FLUX and cursors for a minute. There is a concept that has always intrigued me, but I have never quite understood it in the context of creating an application. The concept is Functional Reactive Programming. There are quite a few articles on the subject, but none of them really explains this concept in the context of building an application.
So this little library Baobab continues to surprise me. The previous article I wrote on this used a strategy where you would lock up all your components, but have a dependency to the state tree of the application in each component that needed it. The individual components could point cursors into the state tree, allowing the component to extract state from the state tree and render itself whenever the cursor notified about a change. This optimized the rendering of React JS and gave a very good FLUX structure to your application.
My last months has been heavily devoted to understanding React JS and FLUX patterns. In parallell with this I have been helping out on an Angular project. Angular was chosen because the guy who got me involved is a Java developer, and of course he likes Angular. In these months working together there has been a lot of discussion on, “Why does Java developers love Angular?”. I have given my cents on React JS, using components, and the one way flow of FLUX. The discussions has not been in the form of “one is better than the other”, but despite his open mind, it was very difficult to explain what makes React JS and FLUX so great.
All standards, libraries, practices, architectures and patterns needs some time to evolve before becoming widely accepted. The flux architecture is no different. After Facebook released their React JS project the suggested flux architecture has evolved into many different shapes and colors. Some of them more accepted than others. In this article we are going to look at what challenges exists today with the flux architecture. We are also going to look at a solution that I think is a great contribution to the evolution of flux.
Note! This article has aged quite a bit. Though it still has valid points, I would suggest reading some of my laster articles on Webpack to get up to speed.
Note! This article is over a year old now. Though it still has valid points, I would suggest reading some of my laster articles to get up to speed.
Got into programming about 5 years ago and completely fell in love with it. The productivity you have working with the web platform is incredible. Going from idea to production can be done in a matter of hours. The momentum of new standards, new practices, ideas and solutions also keeps me on my toes, as there is always something new to dive into. The greatest thing about the web as a platform though is its open source community. Love contributing with ideas and thoughts on current and new developments in the world of web applications.
Currently running my own startup and doing consultancy. Please contact me on email@example.com if you have any questions or feedback.
A code sharing tool that supports NPM and modern worfklows
An state controller with its own debugger
This blog is built with EmptyBox. It is an isomorphic hackable blog project based on React JS.
Working on a project to explain the amazing features of Webpack and React JS.
A super flexible form component and form element concept for React JS.
A flux implementation for Angular using Yahoo Dispatcher and my own immutable-store project.
A tool that lets you very easily create and use immutable data structures.