Learning from React - part 1
Tags: programming, essay, react, aspnet
Published: 2021-05-28 21:33:01

---
title: Learning from React - part 1
published: true
date: 2021-05-28 21:28:50 UTC
tags: programming,essay,react,aspnet
canonical_url: https://siderite.dev/blog/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](https://en.wikipedia.org/wiki/ASP.NET_Web_Forms "a web application framework and one of several programming models supported by the Microsoft ASP.NET technology. Web Forms applications can be written in any programming language which supports the Common Language Runtime, such as C# or Visual Basic. The main building blocks of Web Forms pages are server controls, which are reusable components responsible for rendering HTML markup and responding to events."). 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](https://docs.microsoft.com/en-us/dotnet/api/system.web.ui.updatepanel "Enables sections of a page to be partially rendered without a browser form submit."), 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](/blog/compressing-updatepanel-output.html/ "Some say it is bad to place your entire page in an UpdatePanel. But I want to! So this little thing sends only the changes inside an UpdatePanel, getting up to 99%reduction in amount of data sent to the client! It is the next logical step from 'ajaxifying' a site.") 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](https://reactjs.org/ "an open-source front-end JavaScript library for building user interfaces or UI components. It is maintained by Facebook and a community of individual developers and companies.") 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](https://en.wikipedia.org/wiki/ASP.NET_MVC "a web application framework developed by Microsoft that implements the model–view–controller (MVC) pattern. It is no longer in active development. It is open-source software, apart from the ASP.NET Web Forms component, which is proprietary."), 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](https://en.wikipedia.org/wiki/Reactive_programming "a declarative programming paradigm concerned with data streams and the propagation of change. With this paradigm, it's possible to express static (e.g., arrays) or dynamic (e.g., event emitters) data streams with ease, and also communicate that an inferred dependency within the associated execution model exists, which facilitates the automatic propagation of the changed data flow."), which has been in use, even if less popular, for decades. It is now making a comeback because of [microservices](https://en.wikipedia.org/wiki/Microservices "a variant of the service-oriented architecture (SOA) structural style – arranges an application as a collection of loosely coupled services. In a microservices architecture, services are fine-grained and the protocols are lightweight."), 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](https://en.wikipedia.org/wiki/Functional_programming "a programming paradigm where programs are constructed by applying and composing functions. It is a declarative programming paradigm in which function definitions are trees of expressions that map values to other values, rather than a sequence of imperative statements which update the running state of the program."), 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?