Is there life without standards in javascript?
Prehistory
A new project begins, a clever team of people from 7 are assembled, a roadmap is scheduled, deadlines and a budget are agreed, everything seems to be going according to plan, and there is no limit to the developers happiness. You can hear phrases: “Finally you don’t have to write to (substitute angular 1, jquery, vanilla js) and you can use truly modern, trendy and fast frameworks! Here in this project, everything will be exactly as it should be: each method will be documented, 100% code coverage, CI integration, scrum with estimeytami, webpack, babel and a glass with a Retak smoothie ... ”All together there are old buggy applications in which no one can understand, and praise the new, which, according to their judgment, will be just fire. Familiar situation, is not it? But if you ever come across this scenario, then you know perfectly well what happens after 3-4 months of active work. - yes, modern design, yes, we react, yes hot module replacement is wildly convenient and yes, we have flexbox and you can forget about the float left, but does this really make the product a quality product? And what about the documentation, tests and other things?
“Yes, there JSDoc does not work correctly with es7 decorators. Running tests is generally configured, but now we don’t have time to write them ... ”And from CI, at best, only git hooks and automatic build are used. But the whole horror lies in the / src / components folder ... Often, if there is more than one person in a team, the code turns into unreadable noodles, since each developer has his own unique vision of the “correct” structure and syntax. This leads to the fact that code written by one developer will be hard to maintain by another.
But we have frameworks.
You can say: “But you can just use the framework and follow its guidelines” - but in reality the picture is even worse: frameworks on the contrary encourage choice. Let us examine, as an example, one of the most popular of them - React . He has it even written in the pros ! Undoubtedly, the ability to easily replace the template engine or library for AJAX requests is good and shows the flexibility of the architectural solution, but when we have the opportunity to use the old es5 syntax, or JSX syntax, or the functional stateless component in general, it starts to scare . The abundance of choice leads to the fact that the eyes constantly rush from one syntax to another
')
In pursuit of HYIP
Component 1
import React, {Component} from 'react' import PropTypes from 'prop-types' /** * Person component is used to show the first name and last name of the user */ class PersonComponent extends Component { static propTypes = { item: PropTypes.object }; static defaultProps = { item: {} }; render() { return ( <div className="item"> <p>{this.props.item.firstName}</p> <p>{this.props.item.lastName}</p> </div> ) } } Component 2
var createReactClass = require('create-react-class'); var PersonComponent = createReactClass({ /** * Person component is used to show the first name and last name of the user */ render: function() { return ( <div className="item"> <p>{this.props.item.firstName}</p> <p>{this.props.item.lastName}</p> </div> ) } }); PersonComponent.propTypes = { item: PropTypes.object }; PersonComponent.defaultProps = { item: {} }; Yes, it is the same component. It has documentation, is compact, and, you won’t believe, the tests are also in place, but the problem lies in a completely different ... In other programming languages ​​such as Go or C # there is a strict sequence of parts of the code. For example, in C # you can always find "using" at the beginning of the file, in all third-party libraries and frameworks. In Go, always at the beginning there is the name of the module and imports. Developers in these languages ​​do not change the context and always work with the same structure and syntax. Programming in javascript, we lose this advantage ... Many of us do not even see the problem! We have become accustomed to rebuild typescript to expand the functionality of the library. Make inheritance using lodash to another. In the third use the old "require" instead of "import". And at the same time have the main part of the code in es6 and gradually add async / await because it is fashionable ...
But you can do something, right?
Undoubtedly, you can use libraries to validate the code (essentially, what any normal IDE should do), but for this you need to download a couple of tens of megabytes of additional npm packages, spend a lot of time reading the documentation, competent configuration, setting up and adjusting their work. You can also add pre-commit hooks, which necessarily some developer on Windows will not work correctly due to the peculiarities of the path. And finally, the cherry on the cake is the need to integrate all of this with a webpack, to which an incompatible version is released every six months. Yes ... At such moments, you are especially jealous of developers in other languages ​​...
In conclusion
JavaScript is gaining tremendous popularity. Thanks to nodejs, it is already added to every second smart kettle, microwave and refrigerator. You can buy smart insoles for shoes, the SDK of which will be written by hipsters in the next pseudo-language with a huge amount of syntactic sugar. As my girl doctor says: “Excess sugar causes diabetes” ...
Source: https://habr.com/ru/post/345326/
All Articles