Zen will not call

It's 2017 in the yard, which means that I have been doing masochism for a year and a half. Two years ago I was cheerful and cheerful, now I don't want to joke or have fun. For two years, redux made me a fatalist. My confidence in the terrible future of the so-called “frontend” is increasing every day. In the end, Sberbank made redux the foundation of its stack, and these guys won't choose a good one. Joke! I am sure that wonderful specialists work there.

Past

Once Den Abramov inspired thousands of specialists with a simple phrase a la “I enjoy my work,” simply adding water redux. And the fact that I understood in recent years, my pleasure! == pleasure Dan.

Why was redux created? To facilitate the life of the developer? For business needs? Not! To make the hot reload of templates react.
')
Meanwhile, at that moment, absolutely parallel to Dehn and not knowing his work, I was engaged in solving similar problems, but in another ecosystem this did not require a global state. The ecosystem is dead, events are not related, its time has just come ...

Dan talked about frustration, about how he spends too much time reloading the page, but how much frustration he gave the world after that, I wonder if he wonders how many hours he had and will be spent in return?

Real

Why are we here and what are we doing at all? I think each of us sooner or later asked this question. Outlining some of the boundaries of the question, I found and the answer - I create applications for business, as quickly as possible, simply, stably, maintained.

As someone (can I?) Said: "The value of the tool is directly proportional to the amount of work that it simplifies."

And let's honestly answer a simple question, is this statement true for redux and others like him?

For example, let's compare the creation of equivalent components in 2 stacks: redux / react and angular 1 (which was relevant at that time).



19 vs 7 and this is still leaving behind the settings store, selectors and a ton of questions and changes related to the problems of growing up the stack. And so in almost all aspects. Please share in the feedback feedback experience, if any.

Actually, I do not want to say that redux is something bad, after all, can't the whole industry be wrong? In its own way, redux made a revolution, brought functional programming to the masses, so to speak. And it doesn't even matter whether it is good or bad.

Yes, someone really needs a hot reboot of business logic. And somewhere logic is easier to describe procedurally, not objectively. For something you need a micromanagement state.

But let's face it, most of us make interfaces for data management: the user has changed, we have saved on the server, the maximum - we have somehow reacted. By itself, this task is very simple, we coped with it with a bang with jQuery, and in 5-10 years robots will replace us all, but for now we need to simplify both ourselves and their life, reduce the time and cost of development. Take a look at your reducers, aren't 95% of all CRUD manipulations reduced, and the remaining 5% can be completely settled in middlewares? So do we need a special reducer for every sneeze?

Maybe it's time to move on, see how all these problems solved up to us more mature stacks?

Future

Somewhere in the depths of my soul there is a hope that everything will be fine with us. For the past few months I have been researching and searching for forms and methods. The most tangible result of my creative experiments, even though he is far behind the train of thought.

This is not PR, and I do not urge to try. This is an attempt to imagine what universal applications should look like. I am sure that every second of you has something to say about this, I urge, speak out!

The main thing that I have taken out for myself at the moment is that we should start calling things by their proper names and not play role-playing games, for example:

Components containers are simply components;
The components of the representation are widgets;
Store - database;
Selectors - ORM. And yes, we need not only getters but also setters;

We must stop adjusting to the dictation of the tools, we must decide how we can do our work faster and better, and consequently the business is more successful. Should stop looking for killer features with a 10% increased rendering speed. We need a standard, but no longer a “frontend”, but a Universal Application that works everywhere, from the toilet to the spacecraft?

PS

An interesting performance comparison from the distant 2014.