Learning from React - part 1

Original post at: https://siderite.dev/blog/learning-from-react---part-1/
More to come.

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
• components were defined using both HTML-like language, Javascript, CSS and server .Net code bundled together, sometimes in the same file
• 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
• components are defined by bundling together HTML, Javascript/Typescript and CSS
• 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
• a clear separation of programming languages: HTML in html files, Javascript in .js files, server code in .cs files
• full (and simple) control over how things were rendered, displayed and sent to the server

Yet in the case of React, things are going in the opposite direction, going from MVC applications with clearly separated language files to these .jsx or .tsx files that contain javascript, html and even css in the same file, mixed together into components. Is that bad? Not really. It kind of looks bad, but the entire work is done on the client. There is no expensive interface between a server and a browser that would make the model, otherwise used successfully for decades in desktop applications, ineffective. It is basically Windows Forms in the browser, with some new ideas thrown in. As for the combination of languages in a single syntax, it can be abused, just like any technology, but it can also be done right: with state, logic and UI represented by different files and areas of the application. Yes, you need script to hide or show something based on data, but that script is part of the UI and different from the script used to represent logic. Just the language is the same.

"Is Siderite joining the React camp, then? Switching sides, going frontend and doing nasty magic with Javascript and designing web pages?" people will ask. A reasonable question, considering most of my close friends still think React is for people who can't code or too young to remember the .aspx hell. The answer is no! Yet just as with the UpdatePanel seniors that couldn't stop for a second to look a bit deeper into an idea and see how it could be done and then cruelly dismissing curious juniors, thinking that React can't teach you anything is just dumb.

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?