Explain, pliz, why do we need react and vue?

Question

React

Several times I tried to figure it out and understand why we need react and vui.
But starting to study the documentation, I start to get nervous.
I am a PHP coder, I know html, css jquery.
here explain pliz, why react or vui?
If I need to display hello world on the page, even if dynamically replacing the title. Why all this extra code in dozens of lines? if on the same jquery you can display the title as well as in the continuation of the part of the question. As far as I can see, most sites based on react or wui cannot be opened outside the browser. those. get request will return something but not the site. What's the point of all this technology then?
<h1>this is it</h1>
$('h1').text('hello world');

Answer 1

This question has already been asked more than once or twice. There is only one correct answer: if you don’t understand why you need it, then you don’t need it.
Tools are created to solve certain problems. If you have not encountered these problems, then you will not be able to understand the meaning of the tools.
First you must discover the problematic. Face some difficulty. They will stumble upon a task that will require a lot of time and effort from you. And only a person who has jumped on a rake, it makes sense to tell how to get around this rake, to show what tools would help him solve his problem easier or faster. Otherwise, there will be no point.
UPD:

the question was about the practical ease of making changes.

martin_eden_msk , Here, I sketched a simple demo:

Give it a try and try to make changes.
Pay attention, there are no template files, no jsx, no preprocessors, no webpack, or anything else. This code can be simply inserted into any document, even into a site in php, and it will work.
I will even say more, many perceive Vue as a small, simple framework for writing such complex widgets, which will then be integrated into a site written in something else.

Answer 2

Well, since it's easier for you to do $('h1').text('hello world')than this.title = 'hello world', then continue to manipulate the DOM. You have not grown up to front-end frameworks yet.

Answer 3

I used to write in PHP. I wrote a lot. At first it was a mess of PHP and HTML code, then all sorts of template engines appeared, it became a little cleaner.
The projects grew, the code became more and more and I wanted to reuse some pieces. This is how I came to code management through Composer .
At some stage of development, I came across the fact that I had 2 different web interfaces doing the same thing. In addition, it was necessary to give part of the data to the logistics system. And it had to be automated. Then I already knew that there is such a thing - automated programming interfaces (APIs).
Hastily something was written and it worked. As a result, both web interfaces and the logistics system used the same functions. But to support 2 different interfaces was very gemorno. In those days, jQuery was the most important. It was very difficult to achieve the correct display, since the Javascript code was mixed with HTML, part of which was generated from PHP. There were errors. There was a lot of data, there were a lot of different scripts (hundreds), parts of the scripts were copies of each other with slight deviations. As a result, it took a lot of time, days, sometimes even weeks, to solve simple tasks like editing a row in a table with an update on the server.
Then I saw Mustache.js, it was the ancestor of Angular and React. Something like a template engine, but only on the client side. It worked only in one direction, displayed data in HTML, but then there was the same tin from jQuery.
Then I got acquainted with Angular1. The idea was simple - you write a template, you substitute data into it. It is displayed, by itself! No perversions for you, find a class or an identifier, or some other nonsense.
Coding just got easier. It became possible to create libraries of components and simply edit styles. It was possible to make a component for entering and checking mail, and use it in all projects at once and fix errors in one place, rather than running through hundreds of scripts and looking for this repeating cant in each.
At first, I also treated Angular with prejudice, so many troubles, are they worth it. But as soon as I began to face tasks more often, when I needed different interfaces to display the same data, this began to fade away.
While you are sawing simple things, all sorts of frameworks have not worked for you. You don't even need jQuery . But sometimes the ass begins when one cannot pull out the project alone, because it’s hard to fuck, and you also need to do it quickly. Therefore, it is better to separate, someone does the backend, someone front. It's just more convenient, and communicate through the API. At the beginning, you just write the specification for the API together, it takes a day or two. And then you bomb the month in parallel. Moreover, the trick of this approach is that there are tools that simply give out stubs for the code on the front. Those. if the front is written faster, then it is easier to test it and all that. Same with the backend. It can also be tested even if the front is not ready. Moreover, all these chips are especially cool when there are not two of you, but for example 20, and you live all over the world in different time zones, etc.

Answer 4

The answer to the question "why" lies in one succinct phrase: because it is difficult to synchronize the interface and state .
Imagine that you have a simple UI for some ToDoApp. You just need to make sure that when you enter a new task, it appears in the list, and when you click on the cross, it would be deleted on the contrary. As easy as pie!
But when you start solving a problem in native JS or ugly jQuery, you will end up writing a lot of boilerplate code. First of all, on DOM maintenance. Find an element, insert an element, add a class, an attribute to the element... as a result, you will get a footcloth for dozens of lines for such an elementary task, and we have not yet added many cool things, without which ToDoApp is not ToDoApp at all, such as: create different lists, schedules, a checkmark to cross out a task, etc. With the realization of all this, your sheet will grow, you will be tangled in it.
At this point, you can start cycling. Write some utilities to work with the DOM. Split index.js into multiple files, according to DDD or at least single responsibility. Let's even say that your application suddenly began to be used, you have a lot of business ideas. You start piling on features, the structure gets more and more confusing, there is more and more code, and the application starts to slow down. You do a little analysis and you realize that the problem is that the DOM is accessed too often - you pull it on every sneeze, because with jquery it's so easy! And what to do? Writing another bike to update the DOM in batches? And how to track changes in data from the server? That's a lot of work!
Luckily, all of the above, and much more, has already been resolved by Google, Facebook, and some talented enthusiasts. And we have Angular, Vue, React, Svelte, which offer you the ability to build fast, maintainable apps with minimal boilerplate and smart architecture.

Answer 5

in fact, this is necessary first of all to standardize development
for any capitalist, it is equally important to be independent of employees - for this they must work in the same template,
it doesn’t matter that studying this template and a bunch of standard tools is very difficult
, it pays off with the fact that you can fire anyone and always come new employees, fresh blood and it
looks like an IT sect and religion - these people inspire themselves and others that such tools make life easier I work to order, and if I do, I also write as it suits me, but if I want to work in the professional industry like everyone else, then I will have to know this
choose - either you work as it is convenient for you
or you suffer like everyone else and accept this belief, and believe that it makes work easier and in this happiness
, in fact, madness and inefficiency reign in IT - there are a lot of articles on Habré about this, the
main thing is money - that's why everything understand so badly
- the main thing in capitalism is squeezing money out of people
for this all slaves must believe in it-religion and be standard and work in one standard uncomfortable complex tool
and therefore fanatics will kill you and burn you at the stake if you say that it is inefficiently difficult and crazy

Answer 6

The PHP encoder itself

A PHP coder wouldn't be able to ask such a question, IMHO. Most likely you are a shitty coder in PHP, because PHP also has frameworks, and if you know how to PHP, you should have heard a lot about YII2, Laravel, Symfony, etc. And you should roughly understand why people develop frameworks, and what problems frameworks and their modules solve.
The correct answer is: automation, quick solution of the same type of problems, standardization of code, development of documentation for a specific framework in order to help developers make more concise and "beautiful" products than writing their own bike every time (which does not prevent them from writing it even on frameworks).
The same applies to JS frameworks, i.e. it already has ready-made development tools.

Answer 7

retrain speed
into SEOs, oh how sites fly in Google on such
correct sites, of course,
once the code is uploaded and then exchange via API - yes with compression - instant

Answer 8

I can say about React
No page reloads
Faster work
Convenient component approach
Easy to maintain