Simplifying confusing questions about Angular and React

Teena : I love Angular, It is everything inside a box and simple, You just need to know it, and create whatever app you want. You just need to know typescript, angular-cli, angular-cli commands, html, css, redux, state management, pre-built interfaces, rxjs, functional programming, reactive programming, functional reactive programming, component communication, two-way data binding, but it took me 1.5 years to get started and My hello world application is of just ~300KB.

Steve: What ! Are you crazy, 1.5 years to learn a framework, it's more time then the framework actually stay practical in market. You should Actually Try React.js, It's just so simple to learn, It just helps you to make small html component, which you can mix and create a bigger component, So simple right ?

Teena: Ok, so what's new, you create a view, that you could do in plain html as well with javascript? Why you need a library for that?

Steve: You don't understand, it's virtual DOM, not static html. It's new performance thing, You don't write javascript inside HTML like angular, you write html inside javascript, because You see, javascript is more powerful. It also support server side rendering, where you server is actually pushing the html snippets, which will be shown in runtime.

Teena: So you are doing it , because facebook said it ? everything javascript, no html?

Steve: Yeaahh! Isn't it simple? Very less to remember, just to understand the concept of JSX, higher order components, dumb components, etc.

Teena: Haah! Higher order components? Dumb components? i heard that before, We also do it in angular sometimes, we pass the inputs to dumb components. Because they are dumb. So what argument you have that you are doing it better in react? Do you think it is magic? You are writting everything in javascript. You might make code unreadable, How will you even debug, when everything is loaded in run time, Won't it make you code very complex? See in angular, html is for html and Javascript for Javascript. We have simple object oriented programming, we create a interface and a class. And then we create a object and play with it. Our code is much more readable and better for larger apps.

Steve: It's not completely true, object oriented programming is not necessarily better then functional programming approach, . Functional programming approach looks to make objects immutable, no side effects. So it's actually easy to debug , since your output is not affected by the environment. so you code is testable, since your output is predictable

Teena: Wow. that's interesting, Too bad my app is already written in Angular, So I can't use your theory. Just tell me one thing, who writes code for your state management, API calls etc.

Steve: I also agree, that angular app looks more organized, react has more layers to consider, and to make sure that everything goes in sync, we use a pattern, which keeps our view part and model part separated.

Teena: Like what !

Steve: We used to use flux, but now we are more inclined to redux, because everyone say so, You just keep all the properties of your app in one large javascript object, and you can subscribe to it. Important thing is it never mutate the state.

Teena: How that helps? not mutating the state.

Steve: See if you state is mutable, that means you need to pass different copies of your state object in different scopes, and you might not know that where and when the object properties has been changes, so yo avoid it, we need to create a new copy of state, whenever someone calls an update, so everyone has the latest properties. So you have more predictable output.

Teena: I see, I also heard from angular community also about it thorugh some ngrx library. So you mean to say , mutability is bad and immutability is new faad? Object oriented programming is bad and functional programming is future ? Why didn't we use it before then? And won't performance will be impacted if you keep creating new object copies everytime someone change a property?

Steve: Well, you have to decide as per your use case, whether you need mutability and immutability, If your application state is changing to rapidly, like playing a game of car, where speed is increasing rapidly, you can't afford to create new objects, it will be bad for performance. In that case mutable objects are better, On the other hand, if only few properties are changing, then immutability will give you more relief in long term. So you have to choose wisely, Don't worry about new object copies, those are inevitable in any case.

Teena: So where do we stop the conversation?

Steve: It stops at the use cases. Your choice of framework and approach depends domain specification, your learning curve, time limit to complete the project and many other things. hey wait what about performance?

Teena: I think, in the end javascript is javascript, if properly optimized both framework can give better performance, you just need create your strategy wisely. Webpack offers a lots of patterns like lazy loading, tree shaking etc. So we should focus on end product, instead of arguing about the framework related stuff.

Bye!