Learning from React - part 1
- Posted in
Learning from React series:
- Part 1 (this one) - why examining React is useful even if you won't end up using it
- Part 2 - what Facebook wanted to do with React and how to get a grasp on it
- Part 3 - what is Reactive Programming all about?
- Part 4 - is React functional programming?
- Part 5 - Typescript, for better and for worse
- Part 6 - Single Page Applications are not where they wanted to be
A billion years ago, Microsoft was trying to push a web development model that simulated Windows Forms development: ASP.Net Web Forms. It featured several ideas:
- component based design (input fields were a component, you could bundle two together into another component, the page was a component, etc)
- each component was rendering itself
- the rendering of the component was done on the server side and pushed to the client
- data changes or queries came from the client to the server via event messages
- partial rendering was possible using UpdatePanels, which were a wrapper over ajax calls that called for partial content
- at the time many juniors were putting the entire page into an UpdatePanel and said they were doing AJAX while senior devs smugly told them how bad that was and that it shouldn't be done. I agreed with the senior devs, but I really disliked their uninformed condescending attitude, so I created a method of diffing the content sent previously and the new content and sending only the difference. This minimized the amount of data sent via the network about a hundred times.
Sound familiar? Because for me, learning React made me think of that almost immediately. React features:
- component based design
- each component renders itself
- the rendering of the component is done in the virtual DOM and pushed to the actual browser DOM
- data changes or queries are sent from the browser to the React code via event messages
- partial rendering is built in the system, by diffing the existing render tree with a newly generated one from data changes
At first look, an old guy like me would say "been there, done that. It's bad design and it will soon go away". But I was also motivated enough at the time of ASP.Net Forms to look into it, even under the hood, and understand the thing. To say it was badly designed would be stupid. It worked for many years and powered (and still does) thousands of big applications. The reason why Forms failed is because better ideas came along, not because it was a bad idea when it was created.
Let's look a little bit on what made Forms become obsolete: the MVC pattern, more specifically implemented by Ruby developers and taking the world by storm and ending up being adopted by Microsoft, too. But Model View Controller wasn't a new pattern, it has been used forever on desktop applications, so why was it such a blow to Forms? It was a lot of fashion elitism, but also that MVC molded itself better on web applications:
- a clear separation of concerns: data, logic and display
- the ability to push the display more towards the client, which was new but becoming increasingly easy in browsers
- full (and simple) control over how things were rendered, displayed and sent to the server
In this series I will explore not only React ideas, but also the underlying principles. React is just an example of reactive programming, which has been in use, even if less popular, for decades. It is now making a comeback because of microservices, another fashionable fad that has had implementations since 1990, but no one gave them the time of day. Ideas of data immutability are coming from functional programming, which is also making a comeback as it works great with big data. So why not try this thing out, iron out the kinks and learn what they did right?
Be the first to post a comment