Frontend - fashion destroying projects

This story is a personal opinion based on observations while working on various projects.





Entering team development

During my freelance work, there were no problems with choosing a technology stack, everything was simple, I consulted with friends, read various sources and chose the right stack. These were popular things because there was more information on them, more ready-made projects where you could spy on the right solution and more answers on Stack Overflow if you faced any problem. This made the work less stressful.





But when I started working as a team, stacking became a mystery. My head was constantly spinning: Why? Why? Where did this come from? What's the approach? I didnโ€™t understand why one team had some technologies, while the other had others, although everyone was essentially doing the same thing.





It was also very interesting and not clear why some people on the project with foam at the mouth proved the superiority of the chosen path, while in the other team others did the same, but in a different way and different approaches in technologies that I described from the previous team were simply ridiculed ...





At that time, I was just going with the flow and delving into it. I didn't have time to study philosophy, I just needed to improve my skills. Therefore, while working on the project, I was completely imbued with the ideas of the technical inspirers and accepted them as my own.





Sometimes the time came and I had to move on to other projects. And again there came a time of great surprises, when the seemingly standard, technically identical and well-established modern frontend, in the new team took on an absolutely perverse appearance under the hood and absolutely identical at the output.





Understanding what is happening

Probably you need to start with the understanding that truth does not exist and everyone is free to do what he wants, so long as it does not harm the overall process and result. Considering that there are +10 solutions to any problem on the front.





The work starts with choosing a base stack, whatever it may be, but then there is a lot of potential for different variations. The already existing base of the written code is also added, because many things, or if to say not all, have already been written and it remains only to adapt them to fit your needs.





. , -, - . .





, . , - .





, , - , . , , , , .





, , , , , , โ€œ โ€ , .





. , . , JS TS. , . โ€œ !โ€ , , . , React Router. , history React. : โ€œ history spa, React?โ€ - , , .





. , . , , , 100 , 100 , , . , , , ?





Go ahead

โ€œ โ€. , gitHubโ€™. โ€œWow Rustโ€, โ€œWow React-Reasonโ€. !





, โ€œ โ€. , . , . , .





1 . N , - , .





2 . , , .





- , , , , : โ€œ - x1,5 , , , . , , .โ€





: โ€œ ?โ€ : โ€œ โ€ฆโ€.





, , , . , .





.





And the management, after the leader leaves, will go to hh.ru and drive in the search for โ€œRustโ€ or โ€œReasonโ€ gets a proud 0. And to the delight of the team, they will return to development in their good old, understandable repository.





The conclusion from this whole story can be said that all fashionable technologies are well suited for expanding the developer's horizons and for raising skills. But until large, complex, working projects developed by wise developers appear on them, probably it would not be worthwhile to independently introduce all this "Fashion" into production.








All Articles