Zen won't call
It's 2017, which means that I’ve been doing masochism for a year and a half already. Two years ago I was cheerful and cheerful, now I do not want to joke or have fun. In 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 there are wonderful specialists working there.
Once, Den Abramov inspired thousands of specialists with a simple phrase a la “I enjoy my work” by simply adding redux
Why was redux created? To make life easier for the developer? For business needs? Not! In order for a hot restart of react templates to work.
Meanwhile, at that moment, absolutely parallel from Dan and not knowing his work, I was engaged in solving similar problems, but in a different ecosystem this did not require a global state. The ecosystem has died, events are not connected, its time has simply come ...
Dan talked about frustration, that he spends too much time reloading the page, but how much he gave frustration to the world after that, I wonder if he wonders how many hours he spent and will be spent in return?
Why are we here and what are we doing? I think each of us sooner or later asks this question. Outlining certain boundaries of the question, I also found the answer - I create applications for business, as quickly as possible, simple, stable, supported.
As someone said (maybe I?): "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 it?
For example, compare the creation of equivalent components in 2 stacks: redux / react and angular 1 (which was relevant at that time).
19 versus 7 and this still leaves the store, selectors settings and a ton of questions and changes related to problems of growing the stack behind the brackets. And so in almost all aspects. Please share in the comments the reverse experience, if any.
In general, I do not want to say that redux is something bad, after all, the whole industry cannot be mistaken? In a way redux made a revolution, brought functional programming to the masses, so to speak. And it doesn’t even matter if it is good or bad.
Yes, someone really needs a hot reload of business logic. And somewhere, the logic is easier to describe procedurally, rather than objectively. For some, you need micromanagement of the state.
But let's face it, most of us make interfaces for data management: the user changed, we saved on the server, the maximum - somehow reacted. By itself, this task is very simple, we coped with it with a bang even with jQuery, and after 5-10 years all of us will be replaced by robots, but for now we need to simplify ourselves and their lives, reduce the time and cost of development. Look at your reducers, are not 95% of all manipulations reduced to CRUD, and the remaining 5% may even settle in middlewares? So do we need a special reducer for every sneeze?
Perhaps it’s time to move on, to see how more mature stacks solved all these problems before us?
Somewhere deep in my soul there is a hope that everything will be fine with us. The last few months I have been researching and searching for forms and methods. The most tangible result of my creative experiments, although it lags far behind the train of thought.
This I do not PR, and 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 you to speak out!
The main thing that I have made for myself at the moment is that we should start calling a spade a spade, and not play role-playing games, for example:
Component containers - just components;
Representation components - widgets;
Store - database;
Selectors - ORM. And yes, we need not only getters but also setters;
We must stop adjusting to the dictation of tools, we must decide for ourselves how to do our work faster and better, and therefore the business more successfully. Must stop looking for killer features with 10% faster rendering speed. Do we need a standard, but not a “frontend”, but a Universal Application that works everywhere from the toilet to the spaceship?
An interesting performance comparison from the distant 2014.
Not everyone will understand, few will appreciate ...
Only registered users can participate in the survey. Please come in.
Why do we use redux?
- 16.4% Best tool, worse analogues. 57
- 17.2% I can cook it correctly. 60
- 22.7% Stackhel is enough for me, I don’t want to spend time on new technologies that may disappear tomorrow. 79
- 36% I don’t know. 125
- 7.4% inherited. 26