Javascript: suction fractal
Once upon a time I came across an article about the disadvantages of PHP. And it seemed to me that Javascript is somewhat similar to PHP, and even more worthy of being called a bad design fractal. After all, all the troubles of PHP originally grew out of its narrow subject orientation. Javascript, while not having such an extensive standard library, despite its long attachment to working exclusively in the browser, was still more like an general language. It simply did not have such a general focus on working with text as in PHP. And this gave rise to minimalism in the design of the language. And this minimalism has created problems.
When I tried to solve the problems of minimalism with the help of libraries, it gave rise to new problems - with libraries. When I tried to solve problems with libraries, it caused problems with programmers. When I listened enough about my stupidity from programmers, I began to study the language more deeply. And new problems opened up before me. As a result, with the growth of experience, I came to the need to use the tools that the Javascript ecosystem provides. And they also created new problems, solving old ones. And all this reminds not even a fractal, but some kind of ugly labyrinth of bad design, from which one cannot get out.
Over the years of programming I have come across many languages, and they all have problems. But all these languages ​​are united by the fact that it is possible to list their main problems. In the case of Javascript, everything is different - I cannot enumerate everything that is wrong with this language. I just don’t know where to start, it seems to me that I’ll miss something, I don’t say anything, I can’t grasp the immensity. But at least I will try, if only for the sake of calmness of those who feel the same.
')
Javascript completely repeats the history of Perl, which at one time experienced a similar takeoff and almost the same problems, I would even say that Javascript is a wicked Perl parody 15-20 years later.
Perl was not originally a language created for web programming, especially for complex web applications. Similarly, Javascript - it was designed to create simple interactivity of pages, and then the burden of the client side fell upon his shoulders. Perl had flaws in the implementation of OOP on the same level as Javascript - OOP was, but very peculiar, and many did not like it. And there have been (and there are!) Many attempts to implement OOP through third-party libraries. Like in Javascript. There were also in Perl and praised closures, which then all for some reason did not care.
When, in the 90s and zero, everyone started to write on Perl sites, many web programmers did not have the highest qualifications. The students, sshniki, and even those who got into the hands of the employer went to the web. Now designers, layout designers and, of course, students are crammed into Javascript. Both languages ​​allow great liberties in terms of code design and the use of questionable constructions. The perloviki then (yes, to confess - even now) were proud of the complexity and freedom of their language, writing down brain structures, as well as labeling all the cursed noobs and underprogrammers who came to hand of programmers in other languages. Javascript programmers are now proud ... and, by the way, I am too lazy to rewrite the previous sentence in the present tense.
Both languages ​​initially had a clearly marked scope, from which they eventually got out, got a ruler around their hands and crawled back. Both acquired their own package managers, and if Perl has already passed the stage, when it was dangerous to trust the quality of the CPAN modules, then npm is still part of it.
Perl marked the beginning of PHP, the first version of which was written in Perl itself. Thus, an attempt was made to overcome the excessive complexity of Perl for web programming. And, similarly, we can observe how today there are more and more languages ​​to replace Javascript, claiming its scope and eliminating its disadvantages. These are Dart, CoffeeScript, and certainly others.
If you are too lazy to read everything to the end, then the main problem of Javascript is formulated by the phrase "the scope of the language put forward demands on it that it cannot satisfy." And this problem arose at the time of the creation of the language:
It was in May 1995, and nothing foreshadowed trouble. Unfortunately, the last one who knew what would become with the web infrastructure as much as 15 years after the creation of Javascript, ascended to the sky about 2,000 years ago. Although evil tongues say that if he knew what web applications would turn into today, they would not have ascended.
Meanwhile, the unhealthy hyipovism, from which we suffer so much now, was laid into the language at the very moment of its creation. The word Java is present in the title for a reason, but because the eponymous language at that time was rapidly gaining popularity. It was possible to push the newly-born bastard in such a way so well that so far (although much less often than 10 years ago) you can find novice programmers confusing these 2 languages. Far from programming customers will never see the difference between them. Just as Planed.
Rejecting the fussing with names, I note that the first time Javascript was very good, and the period of my greatest sympathy for him was at the time when jQuery appeared, but nodejs did not appear, and frameworks like Angular and Knockout did not gain popularity. The period is quite vague, but it clearly traces the time when the main problems of Javascript related to cross-browser compatibility have been solved, and the problems of productivity and expressiveness of the language have not yet become full-length. jQeury allowed, without a headache, to do what Javascript was originally intended to do — create interactive pages and make beautiful.
And, inspired by the success, the developers decided that you can write heavy client-side applications to Javascript. It was then that most of the problems of the language came to light , which even a person far from this area is not so hard to look for - the abundance of modules for Javascript in repositories like bower is a living guide to language problems. The fact is that most languages ​​are expanded by libraries, and Javascript widely represents a class of libraries, and even whole technologies, to solve the problems of the language itself.
But Javascript is not a pioneer here - the same Perl does not have an advanced implementation of OOP in the language standard, because of which, year after year, the number of modules that this very OOP implements is growing. But at least you can understand perlovikov - not stuffing as many modules as possible into the standard interpreter supply is official party policy. And it’s not that Perl particularly needed such support from the PLO, given the nature of its use. Another thing is important - largely due to this policy, the refusal to extend the syntax in favor of developers, Perl was left out. Despite all its advantages.
To understand the problem even deeper, let's look in the direction of PHP - possessing a huge number of flaws, starting as an interpreter without OOP at all, this language has gone through a tremendous path in the last 10 years. In it appeared name spaces, implementation of OOP on level comparable with Java, automatic loading of classes. The amount of syntactic sugar introduced into the language is enough to subject the diabetes genocide to an average web-studio. At the same time, Javascript trampled on the spot: the changes did not affect the problems that were already facing the language. The prototype OOP instead of the OOP has not gone anywhere, and the support of the modules has not appeared anywhere. All this was given to libraries.
Now on the horizon looms ECMA-6, which finally did add modules to the standard language. But only modules as syntactic units! The problem of autoload according to the naming, as well as the problem of dependency management is so solved and will not be. They will add the support of the PLO, which is usual to many, though without private members of the classes. However, even in the case of a standard, its introduction into everyday practice is not a matter of one day. The likelihood that these changes are already too late is very high, it seems to me that the community will most likely out of habit use require.js and its analogues. It also happened with the vaunted iterators and generators that are used by one and a half an esthete. So it will be simply because they are accustomed, because ecma-6 support will be absent in many, if not the most modern, but very common browsers. But in the standard there will be a new syntax for the description of functions! Isn't that what we dreamed about, what we have been missing all these years?
Subjectively, the whole history of the development of Javascript seems to me like dragging the blankets of standards onto myself by different browser developers. The incompatibility of getElementBy * in IE and Firefox of earlier versions is probably remembered by many, the E4X technology, which has lived for many years in the framework of Mozilla products. Probably there were many more such examples, but as a non-specialist, they are unknown to me. But the idea that HTML5 is not equally well supported by all browsers is in the air.
So, you are a Javascript programmer. Then, most likely, during the reading of the following text you will have a permanent desire to exclaim: “Holy saints, but finally learn the language you write! And these are programmers? ”Purely formally, a programmer must know the language in which he writes, this is logical. But no logic will replace facts - and the facts are such that a huge percentage of programmers use Javascript rather sporadically. Or often, but not so often to fill the bumps about all the rakes of the language, learning to bypass them.
You can endlessly splash saliva and shout that a good programmer must always evolve, that learning a new language is a trifling matter for a good programmer. But let me! Among those languages ​​that are represented in the web development industry, there is hardly any in which a programmer, having learned Javascript, will find something new for himself. For all its prevalence, Javascript is expressively poor, and its expanded features are either not new or not widely used in other languages. The same OOP, built on prototypes, suspiciously resembles Monkey Patching from other languages, and for some reason is not used there.
The financial motivation to learn Javascript is also highly questionable. To me, Perlovik with Mojlocious, this Django python player, the team of rubists with RoR, the PHP company with their bundle of frameworks, as well as the platoon of Java and C # programmers, will not pay us all anymore quirks of javascript. If the project suffers so much from our incompetence in Javascript in the client-side area, then the front-end vendor will be hired. Or the front-line team. And this is not an arrogance, but a division of labor. And common practice, by the way.
I really hope that this explanation will be enough to understand why so many programmers swear by using Javascript. And why they do not want to study it thoroughly, while they are not worthless programmers "unable to learn the language in which they write." In short, a language that is used by a huge number of people from time to time could have delivered fewer problems.
Further, I vow to promise that I will jump from a sick head to a healthy one and notice the problems not only of Javascript as a language, but also of all things related to it. Those. the problems of implementing DOM in browsers, the problems of standardizing the browsers themselves, the quality problems of libraries, as well as the problems of programmers, these writing libraries, are, in my opinion, the problems of the language itself. Because this language is the de facto standard for developing on the client side, and we all have to dance on what comes with this standard, and not just on what lies behind the syntax specification.
If, as a result of reading this passage, you have a feeling of disagreement somewhere lower than your back, then know that this is certainly not about you and not about your office. You are a good programmer, you work in a talented young team. And in the end I just could not get lucky many times with Javascript-programmers. This happens if you hang around on bodyshop and freelancing. But that moderately significant single percent, which works in serious companies, is the very image of a typical Javascript programmer, who is strong and daring, and in general ...
It was the bright representatives of the community of programmers in Javascript served as the last straw - without them, this article probably would not even be born. But they add to the problems of the language itself and its infrastructure add a touch of schizophrenia. Not among themselves, of course, but among those who are confronted with Javascript: on the one hand there are problems with the language, and on the other hand with sugary dithyrambs another silver bullet in the face of this language. At the same time, the last side has some slack in the logic built on the format “if something is popular, it means it has advantages”. This is fundamentally wrong, but self-esteem is always more expensive, and according to this logic can be omitted. Like everyone who dares to encroach on self-esteem.
Most of all about the virtues of Javascript, as a rule, we hear from front-end developers going through a period of professional development. They are very fond of appealing to the advantages of language on the backend, especially in the field of writing high-loaded applications. The interesting fact that this category of programmers will write such applications in only one case - in the hallucinogenic delirium caused by taking drugs bought at a higher-than-average-for-region salary, is lowered. And, perhaps, the point here is not even in young programmers, but in salary (often exceeding the total salary of the programmer's parents), which hurts according to self-esteem, which is why it swells to unimaginable sizes.
Contrary to the belief that programmers are not people, it is also common for many people from among programmers to unite around the ideas that dominate society. For, first, they can not understand and trample, and secondly, you can not understand and trample others. For the third and fourth number should be involved in the great and the feeling of elbow. But during discussions, as a rule, only the second paragraph emerges. And all these crowds of Javascript programmers (except for you, of course, dear reader) will be ready to take you to the rank of a degenerate for not sharing their enthusiasm for renamed technologies 30 years ago. You will be poked in the face with the merits of the language, spitting on the same person for the shortcomings mentioned, and at the same person wisely saying that this feature is not needed (yes, this is the good old LORovsky "not needed"), and this can be done differently. Sure you may! Since the ancient times, the human race has been famous for its inventiveness and adaptability, and a proud representative of the human race will replace a hammer that was not issued in time, with a stone. And the most inventive, in the absence of a stone, will be able to hammer nails with their heads. I am amazed at how these people sincerely believe that Javascript has some irreplaceable features that, in their opinion, are absent in other languages. My attempts to find something good in Javascript that was not in Python, Perl or Ruby fail again and again.
Of course, among Javascript programmers there are people who have switched to it after many years of experience writing code in other languages. And basically they are the ones who move this language forward. But their insignificant percentage of the percentage compared with the horde of yesterday's maker-ups, who were not particularly tempted before, fitting hacks to different browsers (although I sincerely bow to the maker-ups - it is their result that is always visible, and the requirements for the result are often technically unfeasible ). Also, Javascript is full of crowds of funny schoolchildren, trying in vain (and trying to?) To curb the duckling syndrome, after the first JS script. And also it is populated by hundreds of depressed students (the other thousands went to the beaten track of Java), who frantically try to understand: what the hell is in demand in the market? And where do freelancers who carefully keep favorite snippets for 5 years or more, and whose accumulated in professional isolation for 10 years self-appraisal simply prevents them from sharing their tips and best practices? And what to do with the inexhaustible streamlet of adherents of exclusively compiled programming languages, who secretly consider all those who write in interpreted languages, to be unfinished. But, succumbing to the pressure of news, they decide to throw their eyes (often due to prolonged unemployment) at JS, and they stick to it.
Among the most prominent representatives of the javascript jazz script are careerists, whose github is littered with forks of popular repositories in the same language. The commits come down to typos and writing documentation. The ability of this category of programmers to cast a shadow on the fence, reasoning abstrusely about the difference between closures and lambdas, can only be compared with their ability to liquidly gag at the very first independent project. To the credit of Javascript, it must be said that there were many such defectors during the rise of Python, Ruby, but the demand for web applications will continue to grow for a long time, and another hyip of the same level is not expected, so they will stay here for a long time.
The overall picture of the distribution of the level of professionalism among Javascript programmers painfully resembles the picture of the distribution of the income level of the population in the territory of the long-suffering 1/6 of the land. We have a solid and insignificant percentage of superstars that everyone looks into their mouths, but cannot repeat the result. We also have all those who can not repeat the result. The number of people oscillating around and near the energy barrier dividing the profession of a programmer and coder is simply incalculable.
And a huge number of people, multiplied by low qualifications and monstrous demand, gives rise to a high biased self-esteem, militant ignorance, or tactism along the lines of a frontend backend. In addition, all this is superimposed on the minimalism of Javascript itself and, as a result, the need to implement many basic things in a new way. And here it does not matter whether the library will be selected for this or something special will be written. For example, there will be conflicts in a team due to which notation is better to declare classes. Of course, you can get away from this conflict by moving to a conflict because of the choice of libraries for implementing OOP. Choosing from a variety of libraries that do roughly the same thing, and differing in the proportion of a unit of taste error, is also not easy - everyone wants to push through something different. Sometimes, just to prove to yourself and everyone else, that with his opinion in the team are considered. No, no, this can be a team of programmers in any language, just Javascript gives in today's reality a little more opportunities for such conflicts. Well, since healthy skepticism in the ranks of youth and enthusiastic people is often not yet formed, libraries are boldly introduced into the project, whose future is in question, and whose quality is beyond doubt (but can cause a sad smile). And since the programmer himself is often formed as weak as his skepticism, it is possible that different libraries are added to the project, which do the same thing. Only one library is dead and they prefer not to touch it, like the pages on it, and the second one can be connected to newly created pages.
Low qualifications lead to ignorance of standards, and high self-esteem leads to their ignoring. Both of these factors together lead to the fact that new standards are born, subjectively the best. A code-standard that operates within a company is good, and if it is not overly fanatical, then it is generally wonderful. But all this is good only as long as the standard code sees only a means of unification, and not a way to make the world a better place. And to see such a method in the code standard is not an easy thing - it requires the foresight of an 18-year-old, well, no less than a 25-year-old. And they will see. There is no ground for discord more fertile than questions in which there is no single correct opinion, which means that the battle of the CSW will decide everything. Will this ChSV in the environment of Javascript-programmers, which today is mostly youthful and intransigent, suffice?
Irreconcilable fighters for the perfect code on the next useless site balances many programmers who, in principle, do not care about the language and their work, they are interested in their own life, and not just another crusade in the name of perfect code and the best technologies. Often, these are guys without (specialized) education, but they have had the opportunity to quickly learn and work in the office for good money. They do their job as best they can, sometimes well, but not because they want to write perfect code, but because they want to do their job well. It is pleasant to work in these teams - if there is any timlid that sets the vector, the work will be carried out on time and without scandals. Thank you guys that you are.
But everything collapses when one of those programmers appears who sincerely believe that Javascript is the language in which our children will speak, and the code on it must come from the bottom of the soul. And for those who have a soul is unable to give birth to a code, clean as a tear of a child, whose first word was the word "var", it is necessary to spit into the soul to complete purification. What the home-grown Javascript gurus do, insincerely reveling in self-sacrifice from being in the midst of such mediocrity, and completely sincerely rotten this environment.Of course, the advance of world peace at the start of your use of Javascript by such its adherents is not declared, but is implied. They also imply that all the flaws found in the language are only a continuation of its merits, and if anyone disagrees with this, then this is non-sylotic. Although the only thing that can be blamed neosilitory - lack of faith. God save your team from such. Well, or let him be alone, but will be timlidom.
Unfortunately, these same people sincerely do not understand how you can not love Javascript, although you can list only two arguments available to them - their subjective love for the language, as well as its high popularity, which they mistakenly cause plus language, which in turn are indisputable ( see first argument). It’s hard to work with them, because the line between striving for perfection and ČSV is very thin, and conflicts at work are inevitable. Their own advice to use Javascript for their tasks can create a lasting illusion of a conversation with a traveling salesman. The discussion about the shortcomings of Javascript delivers a little pleasant.
Usually, after the peak of the language’s popularity passes, only those remain for it, for whom it really suits, for whom it really harmoniously writes to the work, and all its shortcomings can be neglected. Well, or those who are too lazy to retrain. In a conversation with these people, you can safely mention the shortcomings of the language - the reaction will be adequate or will be absent altogether. In the case of JS-fanboys, even complaining about some unpleasant trifle is fraught with aggression in their favor.
Even if we discard the problems of communication, then perfectionism and the desire to do something really good in a language in which there are a lot of flaws by design will not lead to anything good. And the loss of time to fight the language and the majority of programmers on it is unproductive.
Because of all this, even those good ideas that carry Javascript are broken about our perception of their carriers, which is similar to the perception of good by the hands of sexual minorities by the proletariat. I want to take and ... not to accept, not to accept these ideas, conveyed in such a vulgar way. And I would really like to use the example of Javascript programmers of their colleagues writing in PHP. Who just do their job, which, unlike the first, know about the shortcomings of their language as well as writing in Javascript about the merits of their own. Someday the hype around Javascript will subside, today's militant programmers will grow up or fall into the next fashionably new best language, but until then we have what we have.
Probably every language has strangeness in casting. Or rather, for each language, you can pick up an example of a synthetic expression, looking at the result of which the question “what did the authors smoke?” Climbs first, and only then, much later, after a thoughtful analysis, you ask yourself how much they smoked . Well, since this is an inevitable evil in almost any language, the main thing is that there should not be too much of this evil, or that evil constructs should be hidden in the back of the language, rarely falling into the daily code. But in Javascript all this dirty trick climbs out. Every single day.
It is not necessary to list everything, because no one will seriously engage in summing empty arrays or an array with an object, but those things that prevent many and with enviable regularity must be mentioned. In general, this section was added rather for a tick (as well as for the most stubborn adherents of Javascript (although it will not get even the most stubborn)), because for any language difficulties you can make snippets, make cheat sheets, and finally run into a rake and drive yourself into the subcortex ways to circumvent these problems.
With all the flawed rigor and minimalism that Javascript glitters with, it does not reach the level of rigor and consistency in Python, with about the same level of minimalism. Why, for example, such a number of different analogous values ​​of the textbook false? Interpretation of false in calculated expressions is a continuous headache - the problem of casting “empty” values ​​is in the language itself, this time. Secondly, the lion's share of time is spent interacting with objects embedded in a language or browser, and what each of them returns can only be remembered. Thirdly, there are still libraries written by someone unknown.
What are “null values”? This is a collective name for all those variants of the return value, when the function has not found anything, the calculation is impossible, an error has occurred, etc. Although there is no such term, this idiom is universally used by all programmers in all languages. And this is the cunning of Javascript, because it provides several options for such values. You can sincerely rejoice for you if you always know when to return false, null, and when undefined. Let us now rejoice together for those who do not know, but are not discouraged and are writing libraries that we may have to use with you.
Much depends on what the author of the library is namudril. There are many libraries, the quality is different, there are still standard objects that do not always behave logically. What does third-party libraries have to do with javascript itself? No, if you forget that it is still sometimes easier to use crutches like jQuery so that your code works independently of the browser.
A typical third-party function, depending on its logic, can return one of the following "empty" values:
It was said above about the problems of libraries, but there is no need to go far. What do you think your standard will give out a standard Date object, if you pass it an incorrect date to the input? An error? null? No - Object.
Since it was said above that there are many who write to Javascript, it is not uncommon for the C-person to write the same function like this:
Perl Buffer will issue
A PHP programmer can issue and:
However, in the case of such a call, only the first option will work correctly.
And the problem does not boil down to the banal memorization of truth tables of Javascript. At the moment, any serious website contains a fucking bunch of assorted libraries, ranging from giants like ExtJS and ending with a small script that you found on a githaba person who, judging by his other projects there and the date of the last update of the script, Javascript is rarely written, long, and most likely the first and last time.
But back to handling null values. Suppose we, paying tribute to fashion, write a certain site on nodejs. And we decided to register on it. Since we care about security, we want to make the password at least 8 characters long and allow it to use letters in different case and numbers. C Javascript is simple, because regular expressions are built into the language:
Now let's imagine that the password comes to us from somewhere in the request, or from some input, if we are talking about client side. And so it turned out that as a result of a typo or something you made a mistake you put something wrong in the password variable:
And characteristically, the user will continue. With a blank password, or with salt only, if one is provided. All this thanks to the features of Javascript:
Many copies are broken on this topic, it is nicer to someone, so that the interpreter hurts his hands for trying to add lines and numbers (and this is probably the most correct behavior), and someone wants the interpreter to interpret strings as numbers when possible. . That, too, you see, is often convenient when we know that at a higher level the variable has already passed through the validators, and there is still a number in it, albeit in a string representation.
Let's see how the interpretation of such numbers occurs in strings in different languages:
So parseInt and parseFloat are your best friends. Better Number though ...
Forget your pearl barley and pitonaÄŤy habits with passing the list of arguments through pop, shift, or whatever you use there.
Although the local variable arguments is an array of unnamed function arguments, it is not a complete Javascript array. And in order to work with it in the usual way, you should somehow convert it into a normal array, of the Array class. The most frequent snippet used for this is of this form.
Always carefully check the type and structure of the returned array, otherwise after several hours of debugging you may be surprised to find that:
Surely, Javascript professionals have an explanation for all this, but the problem will not disappear. The only consolation is that not every language guru without Google can explain why:
All these misunderstandings are subject to some laws, and are written in the depths of the specifications, but they are counterintuitive, and concern so basic things that I don’t want to go after them into the documentation.
Due to the fact that Javascript allows not to set; at the end of each line, you can write a function that, depending on the formatting, will return different values:
A poorly interpreted programming language that is least of all connected with mathematics but has arrays and does not have a foreach operator to walk through them. Those. the operator seems to be as it is, but unlike all other languages, this operator supports, the iteration occurs not by the values ​​of the array, but by the keys. What is actually very convenient in a certain class of algorithms that I almost never have to deal with in web development everyday.
And Someone likes to use the old-fashioned method:
For those who want to appease Kolbaechnogo deity has its own version:
I have my snippet for such a cycle, and you? Do not find that when there are as many as 3 ways in the language (apart from our own foreach for each self-respecting library), to do the same thing the basic thing, and for each method something is missing, something is wrong here? Do not find And this is all because you write to Javascript. But still think about why CoffeeScript and Dart still support iteration by list value:
If you want to see more Javascript features, then welcome to wtfjs.com . Just come back.
And this HYIP will be long, because everyone needs web applications, and because there is no real alternative. Because alternatives like Dart and CoffeeScript, with their advantages, do not have a pool of programmers who would satisfy the needs of the industry in the field of programming on the client side. To top it all there is a bunch of Legacy code that is not going anywhere.
Not less harm is caused by the fact that Javascript is attempted to be pushed into each hole, which is a consequence of copying, and this cramming energizes the language even more. Not all programmers believe that a virtual machine or codec in Javascript is a fun prototype, and not a real demonstration of the universality of the language. And this demonstration does not stop in any way, and new similar projects climb and climb, like miracles from a cattle grave.
The low level of programmers leads to the fact that the working tools for most are browser and firebug. And this is also the problem of Javascript - all the tools for it require nodeJS, which is logical in principle. But the installation of the same nodeJS is sometimes a headache even on unix-systems (in no small part due to hosters who prefer not to update the VPS templates unless absolutely necessary). On Windows, the situation has drastically improved in the last couple of years, and node and npm can even be installed without installing Cygwin. But installing other extensions under Windows is a minefield where you can explode even with a properly configured Cygwin. Therefore, a large percentage of front-end vendors ignore current advances in Javascript, saving themselves from the extra headache.
In general, not so many JavaScript scripters can configure the node, and install all the necessary modules to your project, as it may seem from the tone of the statements on the Internet. Issuing images of virtual machines with a working environment, so that each employee does not set everything up in a new way and does not waste time on an unnecessary routine, is a normal practice in many companies. But the problem is that among the same pythoners and perlovik, not to mention PHP programmers, the relative percentage of those who can deploy a heavy work environment is incomparably higher than the same percentage among Javascript programmers. And even among the percentage that may have the opinion that the tools could be better.
A radical improvement in the quality of tools is hardly to be expected in the near future - Google is not interested in making such an infusion of resources into the Javascript infrastructure, which was done for the development of the V8 engine. The community prefers to cut their bikes, rather than attach wheels to existing ones, so if it can bring the nodejs + npm bundle to the CPAN level, it will not be soon.
If the programmer believes that asynchrony makes his code faster, then either he is a professional who deals with very specific algorithms, or he does not quite understand what I mean. Or is he a supporter of formal righteousness to the detriment of common sense. In the web, especially in medium-sized and medium-sized projects, there is nothing much to parallelize, and in large ones, cunning caching has already taken root for heavy requests or pieces of content. Well, there are all threads there ...
It cannot be said that the asynchronous approach to data processing is meaningless in principle. In the case of the generation of some kind of heavy analytics, reports that operate with many parameters unrelated to each other, the use of callbacks can give a huge performance gain. No threads and no data sharing between threads. This is really awesome. So what's the problem? Yes, the number of such winning situations is vanishingly small.
Programming some business logic, we write algorithms, and the definition of the word “algorithm” says that it is “a set of instructions describing the procedure of actions of the contractor to achieve the result of solving a problem in a finite number of actions”. Order! Data must be processed in a specific order! You cannot, for example, get all the buyers of certain goods from the online store database if the input parameter of your algorithm is the name of the category of goods for which you need to calculate statistics. First you have to get a category by name, then products in this category, then a list of customers. In our example, it is possible to wrap it in three callbacks in a row, having a zero performance gain and a significant gain in unreadable code. A separate article is processing errors in such asynchronous-assembly algorithms,especially if the page display depends on which particular callback is dropped.
The example with an online store is simple, but 95% of the web consists precisely of this simplicity. And in general, how do you imagine the unwinding of kolbek chain chains in complex business logic? There are usually many problems with the understanding of the heap of abstractions that were thrown into the system over the years of meeting conflicting requirements. I'm not even sure that the IDE will be able to build call graphs in such a logic - the order of execution will be visible only in runtime. Of course, there are places when it is possible and necessary to parallelize data processing by scrolling through asynchronously run handlers. And these places are vanishingly small. Much less than it might seem to lovers of the node. But the overhead associated with the support of such asynchronous code - a lot.
By the way, this approach suspiciously recalls the good old threads, which, if not in PHP, then already in Perl and Python were available at the time of web 1.0. And it cannot be said that they were actively used, what then, what now. Yes, threads in python are gloriously slow because of GIL, but let me, isn’t nodejs itself limited to one processor core in the current process? Yes, the thread creation syntax is sometimes not as concise as callbacks, but the latter also do not improve readability, especially starting from the second level of nesting. And you will have a second level of nesting, because all I / O is asynchronous.
For some reason, concurrency in a single process has not taken root widely in web development. Overhead for creating threads? But the number of threads created for the generation of a web page (by analogy with callbacks) is small. And even if we assume that callbacks are an order of magnitude faster than threads, then rewriting algorithms taking into account the first ones is often saving on matches, and at the same time it is inconveniently “smears” the resulting algorithm by code. And that is typical, many do not like it, but because they write their crutchesto combat the features of asynchronous programming. That asynchrony that a node is capable of issuing is a very, very, very specialized piece. Approximately like an illusionist proctologist who is able to entertain a patient with tricks during an impartial procedure, and who thinks that the magician’s skill can fill his gaps in medical education.
To compare threads and callbacks is formally incorrect, but from a practical point of view, both technologies are actively used to somehow reduce the time spent waiting for the end of an I / O operation. I am ashamed to say this, but I really do not see the difference between the two technologies in terms of solving my problems when programming on the server side.
Initially, asynchrony in Javascript was a consequence of its application area — non-blocking handlers for the user interface. With no heavy computational algorithms. And the meaning of such an asynchronous model was not to speed things up, but to prevent the script from blocking the browser while waiting for an event or completion of loading something from the server. The nodejs philosophy, which says that saving on input-output first of all, appeared about 10 years after the appearance of Javascript itself, but there is a suspicion that the emphasis on callbacks was made due to the fact that the implementation of the flow model of parallelism in the framework of the Javascript interpreter architecture was would be impossible. But kolbeki in the language were. Therefore, the asynchrony of the node is not a gift from above, but one big compromise,so that everything is not so bad.
Thus, it turns out that all the praised asynchrony of Javascript in the browser is the usual event loop, which is implemented in dozens of graphic toolkits. And on the server, it is a consequence of the problems caused by porting this event loop to the server. And upon closer inspection, after all the beautiful speeches about how cool and useful this asynchronous programming is, the rotten callback of the inside always appears.
The whole stack of technologies, which revolves around Javascript, suspiciously resembles a parody of the ideology of UNIX: a bunch of small programs that do the most lousy work, sometimes duplicating each other. We have several wonderful browsers, each of which is good in its own way - some slow, some refuse to support the redirect by:
And one has several different and very widely used versions, about the incompatibility of which with the rest are legends. All of these browsers, of course, vary.and the degree of support for HTML5, this bunch of components, designed to correct the flaws of Flash and replace them with their flaws. The speed of this zoo, even if you only use a subset of features supported by all browsers, will give such a spread that Firefox or IE users will enjoy the slide show while the Chrome user squeezes all the juices from his computer, going through a simple pixel arcade , like the ones that were so common on game consoles in the 80s and 90s. It seems to me that now even the generation of Chrome-only sites is growing, as in the past were sites that were sharpened exclusively for IE. Or not sharpened, but overlooked to such an extent that they work normally only under one browser.
Even the only good thing in my opinion that is in Javascript is the vaunted speed of the node - and this is the result of thousands of dashed man-hours that the browser does not slow down when Vasin’s website challenges it with all its crooked scripts. Well, or at least slowed down not so much when Twitter is running in the next tab. This is a desperate attempt to make web applications even better. And this attempt was not one - asm.js was also one of the strategies for increasing Javascript performance.
The HTML5 problem description is too far beyond the scope of this article, and certainly worthy of a separate article. I hope that it will be written by those who tried to create something heavy on HTML5, or write games for mobile platforms using this technology. I just say that the presence of a large number of loosely coupled components, different game writing techniques, different Javascript programming approaches, lack of HTML5 technology focus on graphics, rather than a set of components, is the only event-loop for all HTML5 banners, games, applications, varying degrees browser support, different browsing speeds - all this casts doubt on the advantages of HTML5 + Javascript technology over Flash. And in terms of the quality of games, and in terms of ease of development.Even a professional IDE will have to take a big step towards HTML5 game developers.
The most annoying thing in Javascript is the illusion that you have a full-fledged language like Java or Python. There is everything on paper - regular expressions embedded in the language, the implementation of the OOP, albeit an alternative, as adherents of the language like to repeat. And there is asynchrony - it buzzed all the ears, and in fact all this translates into endless torment and dashing dancing on crutches.
There is almost no place to get to the word to the language itself - its share in the whole stack of technologies is so small. The same DOM is at the mercy of browsers, all input-output is given to libraries, modules and human support for the PLO is implemented by them. And wherever you look, in what area of ​​application do not take a look, right there from where a whisper of an enthusiastic JS-battle is heard, that they have a library for that. When libraries are used to use some kind of nonstandard or specialized functionality, this is normal, when libraries are used to extend a general-purpose language, this is also normal — Boost for C ++ is a great example (if you do not take into account its monster nature), but But when libraries are used for a highly specialized language, and without expanding its functionality, but simply hiding its flaws, this makes you wonder.
Take the same jQuery, its use is so wide that among the other libraries in Google CDN, the percentage of downloads is 89%. I and all my fellow programmers are using jQuery for the reason that I have already stumbled upon the features of working with the DOM in earlier versions of browsers. Now everything is certainly better, but we still use it out of harm's way. Javascript has a lot of libraries to overcome asynchrony, supposedly the greatest feature of a node, but there is an opinion in the community that you still end up writing your own — which suits your goals. Even in us there are a myriad number of different loaders. All of them, along with AMD notation, emphasizing the fact that there are no modules in Javascript, clearly hint that the modules are needed, but they are not. That is why everyone will write the implementation. It would seem that the necessary thing, but at least we will never wait for such a thing:
Because asynchrony, which does not habitually load modules in the correct order (I am happy for those who like require (["/ a / ab / ac", "b / ad / vr"]);), because this again changes the language itself, which will reach all browsers slowly and in different ways, because even when requirejs and AMD become the de facto standard for implementing modules, a huge number of libraries cannot work with it, and you have to write wrappers. And this is a natural problem if the modules do not study at the time of learning the language, but after months, and even years, when the programmer grows to large applications. And then, it grows from its own side, with its already formed requirements for what modules should look like.
Running through the npm repositories, you might think that you have a great number of libraries for Javascript. And yes and no - there are a lot of them, but the quality, the presence of bugs, problems with assembling for different platforms will make you think again. In any somewhat developed project, you will inevitably run into these problems. The repositories of any language during the take-off of its popularity (I think even Haskell cannot avoid this) are some big garbage dumps. A huge number of programmers attacking popularity are trying to push their libraries there, which are needed by one and a half to other programmers. Things that everyone needs are usually written slowly, reluctantly, bugs are closed for years and more by community forces. It should be felt - how shaking hands during the installation of the next module from CPAN in 2005, or from PyPI in 2008,and how today it has become a hassle-free routine, even under Windows. In any case, for most of the modules. And Javascript will go the same long way as other languages, before noting that such node functionality has already been implemented for nodejs, you will no longer want to give the speaker a ringing slap.
The best ones are always heard, this applies to people and technologies, and of course the projects that connect them both. The Internet is filled with success stories about how nodejs allowed a project to be implemented using a much smaller number of servers than a similar project written in Java would require. There you can also read that the use of Javascript as a single language for the frontend and backend has reduced the number of developers, and reduced the duplication of code.
What these superstars will not tell you is that their project required very specific algorithms that 90% of websites need as a dog a side pocket with a pocket Javascript directory. But no, they just say it, but amid the rest of the story, this annoying little thing flies past the brain of the “aspiring” programmer overwhelmed with delight. Also, this “aspiring” web developer will never know what price he had to pay to reduce the amount of code, and what the architecture of the project he had shot represented. But miracles do not happen - the more environments you need to make your code work, the more effort you will spend on it. More superstars never tell you about the myriad man-hours, which was fucking fixing problems with immature technology.The problems are so ridiculous that it is embarrassing to write about them, otherwise they may cast a shadow on the technology, or on the programmer himself.
Although this can be seen from the articles, not all readers are aware that this is about some kind of almost unique, piece project, often high-loaded, very often not having anything to do with what the average web programmer has written throughout his life. Medium in terms of the nature of the project, not abilities. Backbone, Angular, Knockout, all this already seems so ordinary, accessible today. But what is their scope? Are there so many sites you see around with their use? And how many sites, in your opinion, should be one-page web applications? And how many sites need to bring all the logic to the client side, turning the server application into a database API?
Of course, there are such applications, but usually, in order to make them work as seen in advertising articles, they have to be licked for a long time and a large team. The code at the same time acquires such crutches that even a large team may not be enough and a large team of seniors will be needed. Those who wrote something big on the same Angular, and so everyone knows, the only question is how did they perceive it - how minor flaws, or did they no longer communicate with him.
And the small web has not gone away. He still needs Javascript at the “beautiful to the site” level, he needs cheap and widely used hosting, he needs tons of specialists who can be easily found and will not extort 3 PHP site costs for a similar site on nodejs.
I take off my hat to the nodejs developers, or rather, to those who wrote and, most importantly, licked the V8 engine itself, thanks to which Javascript is capable of doing any other scripting language in terms of speed. It even steals up in speed to Java. This is what demand means, this is what competition between browsers means.
But at the same time, the subjective speed of the work of sites that are trying to push as much functionality as possible onto the client’s side is disheartening. There are 3 reasons for this:
And now, having the fastest interpretable programming language to date, programmers cannot fully use the speed that it can produce. And in part, this problem does not allow Flash to fully replace HTML5 + Javascript. With all the leakiness of Adobe Flash, with all the slowness of the Flash Player on systems other than Windows, with all the recent disregard by Adobe of its brainchild, with all this, Javascript and HTML5 do not have some of its important advantages. Such as the uniformity of the infrastructure for development and, which is especially important here, the unified execution environment - the Flash Player. Which, for games of comparable complexity, today shows a much higher subjective result than JS + HTML5. And the hellish speed of HTML5 games against benchmarks,who tear Flash to dust, is for me one of the greatest paradoxes.
In general, the speed of web applications in Javascript is a separate and extensive topic, and a separate topic deserves a separate article. Here it is . It is extremely doubtful that smartphones will make a qualitative breakthrough in performance in the near future. It is equally doubtful that full-featured web applications will be created in two forms - for desktop and mobile platforms. Those. On smartphones, we will receive either stubs from the functionality, or a portable heating pad with a built-in slideshow function. But even here there is a plus - more and more sites designed with REST in mind, as one of the requirements of the fat client part, are overgrown with native Android and iOS applications.
Those who love Javascript will continue to write on it, no matter what. And for those who have similar feelings, it will be nice to know that they are not the only ones who have problems with this language. I myself hope that due to the fact that web applications are a huge industry, and the size of applications is growing, a virtual machine with a unified bytecode will be built into the browsers, for which it will be easy to write a compiler for any language. And only then, having rejected the historical factor, the industry can critically select the language that is best suited for the needs of modern web programming.
When I tried to solve the problems of minimalism with the help of libraries, it gave rise to new problems - with libraries. When I tried to solve problems with libraries, it caused problems with programmers. When I listened enough about my stupidity from programmers, I began to study the language more deeply. And new problems opened up before me. As a result, with the growth of experience, I came to the need to use the tools that the Javascript ecosystem provides. And they also created new problems, solving old ones. And all this reminds not even a fractal, but some kind of ugly labyrinth of bad design, from which one cannot get out.
Over the years of programming I have come across many languages, and they all have problems. But all these languages ​​are united by the fact that it is possible to list their main problems. In the case of Javascript, everything is different - I cannot enumerate everything that is wrong with this language. I just don’t know where to start, it seems to me that I’ll miss something, I don’t say anything, I can’t grasp the immensity. But at least I will try, if only for the sake of calmness of those who feel the same.
')
Why is the problem still there?
Javascript completely repeats the history of Perl, which at one time experienced a similar takeoff and almost the same problems, I would even say that Javascript is a wicked Perl parody 15-20 years later.
Perl was not originally a language created for web programming, especially for complex web applications. Similarly, Javascript - it was designed to create simple interactivity of pages, and then the burden of the client side fell upon his shoulders. Perl had flaws in the implementation of OOP on the same level as Javascript - OOP was, but very peculiar, and many did not like it. And there have been (and there are!) Many attempts to implement OOP through third-party libraries. Like in Javascript. There were also in Perl and praised closures, which then all for some reason did not care.
When, in the 90s and zero, everyone started to write on Perl sites, many web programmers did not have the highest qualifications. The students, sshniki, and even those who got into the hands of the employer went to the web. Now designers, layout designers and, of course, students are crammed into Javascript. Both languages ​​allow great liberties in terms of code design and the use of questionable constructions. The perloviki then (yes, to confess - even now) were proud of the complexity and freedom of their language, writing down brain structures, as well as labeling all the cursed noobs and underprogrammers who came to hand of programmers in other languages. Javascript programmers are now proud ... and, by the way, I am too lazy to rewrite the previous sentence in the present tense.
Both languages ​​initially had a clearly marked scope, from which they eventually got out, got a ruler around their hands and crawled back. Both acquired their own package managers, and if Perl has already passed the stage, when it was dangerous to trust the quality of the CPAN modules, then npm is still part of it.
Perl marked the beginning of PHP, the first version of which was written in Perl itself. Thus, an attempt was made to overcome the excessive complexity of Perl for web programming. And, similarly, we can observe how today there are more and more languages ​​to replace Javascript, claiming its scope and eliminating its disadvantages. These are Dart, CoffeeScript, and certainly others.
Beginning of the End
If you are too lazy to read everything to the end, then the main problem of Javascript is formulated by the phrase "the scope of the language put forward demands on it that it cannot satisfy." And this problem arose at the time of the creation of the language:
JS was obliged to "look like Java", only smaller, to be that little dumb brother for Java. In addition, it should have been written in 10 days, otherwise we would have something worse than JS.
It was in May 1995, and nothing foreshadowed trouble. Unfortunately, the last one who knew what would become with the web infrastructure as much as 15 years after the creation of Javascript, ascended to the sky about 2,000 years ago. Although evil tongues say that if he knew what web applications would turn into today, they would not have ascended.
Meanwhile, the unhealthy hyipovism, from which we suffer so much now, was laid into the language at the very moment of its creation. The word Java is present in the title for a reason, but because the eponymous language at that time was rapidly gaining popularity. It was possible to push the newly-born bastard in such a way so well that so far (although much less often than 10 years ago) you can find novice programmers confusing these 2 languages. Far from programming customers will never see the difference between them. Just as Planed.
Rejecting the fussing with names, I note that the first time Javascript was very good, and the period of my greatest sympathy for him was at the time when jQuery appeared, but nodejs did not appear, and frameworks like Angular and Knockout did not gain popularity. The period is quite vague, but it clearly traces the time when the main problems of Javascript related to cross-browser compatibility have been solved, and the problems of productivity and expressiveness of the language have not yet become full-length. jQeury allowed, without a headache, to do what Javascript was originally intended to do — create interactive pages and make beautiful.
And, inspired by the success, the developers decided that you can write heavy client-side applications to Javascript. It was then that most of the problems of the language came to light , which even a person far from this area is not so hard to look for - the abundance of modules for Javascript in repositories like bower is a living guide to language problems. The fact is that most languages ​​are expanded by libraries, and Javascript widely represents a class of libraries, and even whole technologies, to solve the problems of the language itself.
But Javascript is not a pioneer here - the same Perl does not have an advanced implementation of OOP in the language standard, because of which, year after year, the number of modules that this very OOP implements is growing. But at least you can understand perlovikov - not stuffing as many modules as possible into the standard interpreter supply is official party policy. And it’s not that Perl particularly needed such support from the PLO, given the nature of its use. Another thing is important - largely due to this policy, the refusal to extend the syntax in favor of developers, Perl was left out. Despite all its advantages.
To understand the problem even deeper, let's look in the direction of PHP - possessing a huge number of flaws, starting as an interpreter without OOP at all, this language has gone through a tremendous path in the last 10 years. In it appeared name spaces, implementation of OOP on level comparable with Java, automatic loading of classes. The amount of syntactic sugar introduced into the language is enough to subject the diabetes genocide to an average web-studio. At the same time, Javascript trampled on the spot: the changes did not affect the problems that were already facing the language. The prototype OOP instead of the OOP has not gone anywhere, and the support of the modules has not appeared anywhere. All this was given to libraries.
Now on the horizon looms ECMA-6, which finally did add modules to the standard language. But only modules as syntactic units! The problem of autoload according to the naming, as well as the problem of dependency management is so solved and will not be. They will add the support of the PLO, which is usual to many, though without private members of the classes. However, even in the case of a standard, its introduction into everyday practice is not a matter of one day. The likelihood that these changes are already too late is very high, it seems to me that the community will most likely out of habit use require.js and its analogues. It also happened with the vaunted iterators and generators that are used by one and a half an esthete. So it will be simply because they are accustomed, because ecma-6 support will be absent in many, if not the most modern, but very common browsers. But in the standard there will be a new syntax for the description of functions! Isn't that what we dreamed about, what we have been missing all these years?
Subjectively, the whole history of the development of Javascript seems to me like dragging the blankets of standards onto myself by different browser developers. The incompatibility of getElementBy * in IE and Firefox of earlier versions is probably remembered by many, the E4X technology, which has lived for many years in the framework of Mozilla products. Probably there were many more such examples, but as a non-specialist, they are unknown to me. But the idea that HTML5 is not equally well supported by all browsers is in the air.
Before reading further
So, you are a Javascript programmer. Then, most likely, during the reading of the following text you will have a permanent desire to exclaim: “Holy saints, but finally learn the language you write! And these are programmers? ”Purely formally, a programmer must know the language in which he writes, this is logical. But no logic will replace facts - and the facts are such that a huge percentage of programmers use Javascript rather sporadically. Or often, but not so often to fill the bumps about all the rakes of the language, learning to bypass them.
You can endlessly splash saliva and shout that a good programmer must always evolve, that learning a new language is a trifling matter for a good programmer. But let me! Among those languages ​​that are represented in the web development industry, there is hardly any in which a programmer, having learned Javascript, will find something new for himself. For all its prevalence, Javascript is expressively poor, and its expanded features are either not new or not widely used in other languages. The same OOP, built on prototypes, suspiciously resembles Monkey Patching from other languages, and for some reason is not used there.
The financial motivation to learn Javascript is also highly questionable. To me, Perlovik with Mojlocious, this Django python player, the team of rubists with RoR, the PHP company with their bundle of frameworks, as well as the platoon of Java and C # programmers, will not pay us all anymore quirks of javascript. If the project suffers so much from our incompetence in Javascript in the client-side area, then the front-end vendor will be hired. Or the front-line team. And this is not an arrogance, but a division of labor. And common practice, by the way.
I really hope that this explanation will be enough to understand why so many programmers swear by using Javascript. And why they do not want to study it thoroughly, while they are not worthless programmers "unable to learn the language in which they write." In short, a language that is used by a huge number of people from time to time could have delivered fewer problems.
Further, I vow to promise that I will jump from a sick head to a healthy one and notice the problems not only of Javascript as a language, but also of all things related to it. Those. the problems of implementing DOM in browsers, the problems of standardizing the browsers themselves, the quality problems of libraries, as well as the problems of programmers, these writing libraries, are, in my opinion, the problems of the language itself. Because this language is the de facto standard for developing on the client side, and we all have to dance on what comes with this standard, and not just on what lies behind the syntax specification.
The main problem with Javascript is you
If, as a result of reading this passage, you have a feeling of disagreement somewhere lower than your back, then know that this is certainly not about you and not about your office. You are a good programmer, you work in a talented young team. And in the end I just could not get lucky many times with Javascript-programmers. This happens if you hang around on bodyshop and freelancing. But that moderately significant single percent, which works in serious companies, is the very image of a typical Javascript programmer, who is strong and daring, and in general ...
It was the bright representatives of the community of programmers in Javascript served as the last straw - without them, this article probably would not even be born. But they add to the problems of the language itself and its infrastructure add a touch of schizophrenia. Not among themselves, of course, but among those who are confronted with Javascript: on the one hand there are problems with the language, and on the other hand with sugary dithyrambs another silver bullet in the face of this language. At the same time, the last side has some slack in the logic built on the format “if something is popular, it means it has advantages”. This is fundamentally wrong, but self-esteem is always more expensive, and according to this logic can be omitted. Like everyone who dares to encroach on self-esteem.
Most of all about the virtues of Javascript, as a rule, we hear from front-end developers going through a period of professional development. They are very fond of appealing to the advantages of language on the backend, especially in the field of writing high-loaded applications. The interesting fact that this category of programmers will write such applications in only one case - in the hallucinogenic delirium caused by taking drugs bought at a higher-than-average-for-region salary, is lowered. And, perhaps, the point here is not even in young programmers, but in salary (often exceeding the total salary of the programmer's parents), which hurts according to self-esteem, which is why it swells to unimaginable sizes.
Contrary to the belief that programmers are not people, it is also common for many people from among programmers to unite around the ideas that dominate society. For, first, they can not understand and trample, and secondly, you can not understand and trample others. For the third and fourth number should be involved in the great and the feeling of elbow. But during discussions, as a rule, only the second paragraph emerges. And all these crowds of Javascript programmers (except for you, of course, dear reader) will be ready to take you to the rank of a degenerate for not sharing their enthusiasm for renamed technologies 30 years ago. You will be poked in the face with the merits of the language, spitting on the same person for the shortcomings mentioned, and at the same person wisely saying that this feature is not needed (yes, this is the good old LORovsky "not needed"), and this can be done differently. Sure you may! Since the ancient times, the human race has been famous for its inventiveness and adaptability, and a proud representative of the human race will replace a hammer that was not issued in time, with a stone. And the most inventive, in the absence of a stone, will be able to hammer nails with their heads. I am amazed at how these people sincerely believe that Javascript has some irreplaceable features that, in their opinion, are absent in other languages. My attempts to find something good in Javascript that was not in Python, Perl or Ruby fail again and again.
Of course, among Javascript programmers there are people who have switched to it after many years of experience writing code in other languages. And basically they are the ones who move this language forward. But their insignificant percentage of the percentage compared with the horde of yesterday's maker-ups, who were not particularly tempted before, fitting hacks to different browsers (although I sincerely bow to the maker-ups - it is their result that is always visible, and the requirements for the result are often technically unfeasible ). Also, Javascript is full of crowds of funny schoolchildren, trying in vain (and trying to?) To curb the duckling syndrome, after the first JS script. And also it is populated by hundreds of depressed students (the other thousands went to the beaten track of Java), who frantically try to understand: what the hell is in demand in the market? And where do freelancers who carefully keep favorite snippets for 5 years or more, and whose accumulated in professional isolation for 10 years self-appraisal simply prevents them from sharing their tips and best practices? And what to do with the inexhaustible streamlet of adherents of exclusively compiled programming languages, who secretly consider all those who write in interpreted languages, to be unfinished. But, succumbing to the pressure of news, they decide to throw their eyes (often due to prolonged unemployment) at JS, and they stick to it.
Among the most prominent representatives of the javascript jazz script are careerists, whose github is littered with forks of popular repositories in the same language. The commits come down to typos and writing documentation. The ability of this category of programmers to cast a shadow on the fence, reasoning abstrusely about the difference between closures and lambdas, can only be compared with their ability to liquidly gag at the very first independent project. To the credit of Javascript, it must be said that there were many such defectors during the rise of Python, Ruby, but the demand for web applications will continue to grow for a long time, and another hyip of the same level is not expected, so they will stay here for a long time.
The overall picture of the distribution of the level of professionalism among Javascript programmers painfully resembles the picture of the distribution of the income level of the population in the territory of the long-suffering 1/6 of the land. We have a solid and insignificant percentage of superstars that everyone looks into their mouths, but cannot repeat the result. We also have all those who can not repeat the result. The number of people oscillating around and near the energy barrier dividing the profession of a programmer and coder is simply incalculable.
And a huge number of people, multiplied by low qualifications and monstrous demand, gives rise to a high biased self-esteem, militant ignorance, or tactism along the lines of a frontend backend. In addition, all this is superimposed on the minimalism of Javascript itself and, as a result, the need to implement many basic things in a new way. And here it does not matter whether the library will be selected for this or something special will be written. For example, there will be conflicts in a team due to which notation is better to declare classes. Of course, you can get away from this conflict by moving to a conflict because of the choice of libraries for implementing OOP. Choosing from a variety of libraries that do roughly the same thing, and differing in the proportion of a unit of taste error, is also not easy - everyone wants to push through something different. Sometimes, just to prove to yourself and everyone else, that with his opinion in the team are considered. No, no, this can be a team of programmers in any language, just Javascript gives in today's reality a little more opportunities for such conflicts. Well, since healthy skepticism in the ranks of youth and enthusiastic people is often not yet formed, libraries are boldly introduced into the project, whose future is in question, and whose quality is beyond doubt (but can cause a sad smile). And since the programmer himself is often formed as weak as his skepticism, it is possible that different libraries are added to the project, which do the same thing. Only one library is dead and they prefer not to touch it, like the pages on it, and the second one can be connected to newly created pages.
Low qualifications lead to ignorance of standards, and high self-esteem leads to their ignoring. Both of these factors together lead to the fact that new standards are born, subjectively the best. A code-standard that operates within a company is good, and if it is not overly fanatical, then it is generally wonderful. But all this is good only as long as the standard code sees only a means of unification, and not a way to make the world a better place. And to see such a method in the code standard is not an easy thing - it requires the foresight of an 18-year-old, well, no less than a 25-year-old. And they will see. There is no ground for discord more fertile than questions in which there is no single correct opinion, which means that the battle of the CSW will decide everything. Will this ChSV in the environment of Javascript-programmers, which today is mostly youthful and intransigent, suffice?
Irreconcilable fighters for the perfect code on the next useless site balances many programmers who, in principle, do not care about the language and their work, they are interested in their own life, and not just another crusade in the name of perfect code and the best technologies. Often, these are guys without (specialized) education, but they have had the opportunity to quickly learn and work in the office for good money. They do their job as best they can, sometimes well, but not because they want to write perfect code, but because they want to do their job well. It is pleasant to work in these teams - if there is any timlid that sets the vector, the work will be carried out on time and without scandals. Thank you guys that you are.
But everything collapses when one of those programmers appears who sincerely believe that Javascript is the language in which our children will speak, and the code on it must come from the bottom of the soul. And for those who have a soul is unable to give birth to a code, clean as a tear of a child, whose first word was the word "var", it is necessary to spit into the soul to complete purification. What the home-grown Javascript gurus do, insincerely reveling in self-sacrifice from being in the midst of such mediocrity, and completely sincerely rotten this environment.Of course, the advance of world peace at the start of your use of Javascript by such its adherents is not declared, but is implied. They also imply that all the flaws found in the language are only a continuation of its merits, and if anyone disagrees with this, then this is non-sylotic. Although the only thing that can be blamed neosilitory - lack of faith. God save your team from such. Well, or let him be alone, but will be timlidom.
Unfortunately, these same people sincerely do not understand how you can not love Javascript, although you can list only two arguments available to them - their subjective love for the language, as well as its high popularity, which they mistakenly cause plus language, which in turn are indisputable ( see first argument). It’s hard to work with them, because the line between striving for perfection and ČSV is very thin, and conflicts at work are inevitable. Their own advice to use Javascript for their tasks can create a lasting illusion of a conversation with a traveling salesman. The discussion about the shortcomings of Javascript delivers a little pleasant.
Usually, after the peak of the language’s popularity passes, only those remain for it, for whom it really suits, for whom it really harmoniously writes to the work, and all its shortcomings can be neglected. Well, or those who are too lazy to retrain. In a conversation with these people, you can safely mention the shortcomings of the language - the reaction will be adequate or will be absent altogether. In the case of JS-fanboys, even complaining about some unpleasant trifle is fraught with aggression in their favor.
Even if we discard the problems of communication, then perfectionism and the desire to do something really good in a language in which there are a lot of flaws by design will not lead to anything good. And the loss of time to fight the language and the majority of programmers on it is unproductive.
Because of all this, even those good ideas that carry Javascript are broken about our perception of their carriers, which is similar to the perception of good by the hands of sexual minorities by the proletariat. I want to take and ... not to accept, not to accept these ideas, conveyed in such a vulgar way. And I would really like to use the example of Javascript programmers of their colleagues writing in PHP. Who just do their job, which, unlike the first, know about the shortcomings of their language as well as writing in Javascript about the merits of their own. Someday the hype around Javascript will subside, today's militant programmers will grow up or fall into the next fashionably new best language, but until then we have what we have.
Purely formal disadvantages
Probably every language has strangeness in casting. Or rather, for each language, you can pick up an example of a synthetic expression, looking at the result of which the question “what did the authors smoke?” Climbs first, and only then, much later, after a thoughtful analysis, you ask yourself how much they smoked . Well, since this is an inevitable evil in almost any language, the main thing is that there should not be too much of this evil, or that evil constructs should be hidden in the back of the language, rarely falling into the daily code. But in Javascript all this dirty trick climbs out. Every single day.
It is not necessary to list everything, because no one will seriously engage in summing empty arrays or an array with an object, but those things that prevent many and with enviable regularity must be mentioned. In general, this section was added rather for a tick (as well as for the most stubborn adherents of Javascript (although it will not get even the most stubborn)), because for any language difficulties you can make snippets, make cheat sheets, and finally run into a rake and drive yourself into the subcortex ways to circumvent these problems.
Null, comparison operators and everything, everything, everything
With all the flawed rigor and minimalism that Javascript glitters with, it does not reach the level of rigor and consistency in Python, with about the same level of minimalism. Why, for example, such a number of different analogous values ​​of the textbook false? Interpretation of false in calculated expressions is a continuous headache - the problem of casting “empty” values ​​is in the language itself, this time. Secondly, the lion's share of time is spent interacting with objects embedded in a language or browser, and what each of them returns can only be remembered. Thirdly, there are still libraries written by someone unknown.
What are “null values”? This is a collective name for all those variants of the return value, when the function has not found anything, the calculation is impossible, an error has occurred, etc. Although there is no such term, this idiom is universally used by all programmers in all languages. And this is the cunning of Javascript, because it provides several options for such values. You can sincerely rejoice for you if you always know when to return false, null, and when undefined. Let us now rejoice together for those who do not know, but are not discouraged and are writing libraries that we may have to use with you.
Much depends on what the author of the library is namudril. There are many libraries, the quality is different, there are still standard objects that do not always behave logically. What does third-party libraries have to do with javascript itself? No, if you forget that it is still sometimes easier to use crutches like jQuery so that your code works independently of the browser.
A typical third-party function, depending on its logic, can return one of the following "empty" values:
false // - false
undefined // ,
null // null
NaN // 1 / 0
{} // NULL, , " "
[] // ,
Object // ,
It was said above about the problems of libraries, but there is no need to go far. What do you think your standard will give out a standard Date object, if you pass it an incorrect date to the input? An error? null? No - Object.
var d = new Date("2012--12-01"); //
d.toJSON(); // null
d.getTime(); // NaN
d.toString(); //'Invalid Date'
d.toISOString() // - !
Since it was said above that there are many who write to Javascript, it is not uncommon for the C-person to write the same function like this:
function isEven(arg) {
if (arg % 2 == 0)
return 1;
else
return 0;
}
Perl Buffer will issue
function isEven(arg) {
if (arg % 2 == 0)
return 1;
else
return undefined;
}
A PHP programmer can issue and:
function isEven(arg) {
if (arg % 2 == 0)
return 1;
else
return null;
}
However, in the case of such a call, only the first option will work correctly.
if (isEven(3) == false) {
alert(", !");
}
And the problem does not boil down to the banal memorization of truth tables of Javascript. At the moment, any serious website contains a fucking bunch of assorted libraries, ranging from giants like ExtJS and ending with a small script that you found on a githaba person who, judging by his other projects there and the date of the last update of the script, Javascript is rarely written, long, and most likely the first and last time.
But back to handling null values. Suppose we, paying tribute to fashion, write a certain site on nodejs. And we decided to register on it. Since we care about security, we want to make the password at least 8 characters long and allow it to use letters in different case and numbers. C Javascript is simple, because regular expressions are built into the language:
/^[a-zA-Z0-9]{8,}$/.test('passworD1'); //
Now let's imagine that the password comes to us from somewhere in the request, or from some input, if we are talking about client side. And so it turned out that as a result of a typo or something you made a mistake you put something wrong in the password variable:
var request = {
"user" : "alex",
"password" : "sdjk23h78dg2"
};
// ,
if ( /^[a-zA-Z0-9]{8,}$/.test(request["pasword"]) ) {
save_user_to_database(request);
}
And characteristically, the user will continue. With a blank password, or with salt only, if one is provided. All this thanks to the features of Javascript:
/^[a-z]{1,10}$/.test(null); // true
/^[a-z]{1,10}$/.test(undefined); // true
Strings and numbers
Many copies are broken on this topic, it is nicer to someone, so that the interpreter hurts his hands for trying to add lines and numbers (and this is probably the most correct behavior), and someone wants the interpreter to interpret strings as numbers when possible. . That, too, you see, is often convenient when we know that at a higher level the variable has already passed through the validators, and there is still a number in it, albeit in a string representation.
Let's see how the interpretation of such numbers occurs in strings in different languages:
| Php | 34 | 32 |
| Python | mistake | mistake |
| Perl | 34 | 32 |
| Ruby | mistake | mistake |
| Javascript | '331' | 32 |
// , , , , ?
parseInt(null, 24) === 23 // true
Multiple arguments
Forget your pearl barley and pitonaÄŤy habits with passing the list of arguments through pop, shift, or whatever you use there.
function lastNegative() {
var negative = null;
while ( arguments.length ) {
negative = arguments.pop(); //
if (negative < 0)
break;
}
return negative;
}
Although the local variable arguments is an array of unnamed function arguments, it is not a complete Javascript array. And in order to work with it in the usual way, you should somehow convert it into a normal array, of the Array class. The most frequent snippet used for this is of this form.
var args = Array.prototype.slice.call(arguments);
Arrays
Always carefully check the type and structure of the returned array, otherwise after several hours of debugging you may be surprised to find that:
[] == true // false - ,
[1] == true // true - , - , true
[2] == true // false - , , true...
[true] == true // false - , true != true
// ?
[1 , 1] == true // false ...
// ?
[ [1], [1] ] == true // false
[ [ [ [1] ] ] ] == true // true
// !
new Array() == true // false
new Array(1) == true // false
new Array(1,2) == true // false
Surely, Javascript professionals have an explanation for all this, but the problem will not disappear. The only consolation is that not every language guru without Google can explain why:
new Array([],null,undefined,null) == ",,,"; // true
All these misunderstandings are subject to some laws, and are written in the depths of the specifications, but they are counterintuitive, and concern so basic things that I don’t want to go after them into the documentation.
Formatting
Due to the fact that Javascript allows not to set; at the end of each line, you can write a function that, depending on the formatting, will return different values:
function foo() {
return " , , ";
}
function bar() {
return
" , , ";
}
foo(); //
bar(); // undefined
Foreach operator
A poorly interpreted programming language that is least of all connected with mathematics but has arrays and does not have a foreach operator to walk through them. Those. the operator seems to be as it is, but unlike all other languages, this operator supports, the iteration occurs not by the values ​​of the array, but by the keys. What is actually very convenient in a certain class of algorithms that I almost never have to deal with in web development everyday.
for (index in ARRR) {
var value = obj[index];
console.log(value);
}
And Someone likes to use the old-fashioned method:
for (var index = 0; index < a.length; ++index) {
console.log(a[index]);
}
For those who want to appease Kolbaechnogo deity has its own version:
a.forEach(function(entry) {
console.log(entry);
});
I have my snippet for such a cycle, and you? Do not find that when there are as many as 3 ways in the language (apart from our own foreach for each self-respecting library), to do the same thing the basic thing, and for each method something is missing, something is wrong here? Do not find And this is all because you write to Javascript. But still think about why CoffeeScript and Dart still support iteration by list value:
# dart
for (var x in collection) {
print(x);
}
# coffeescript
for x in collection
print(x)
And that's not it
If you want to see more Javascript features, then welcome to wtfjs.com . Just come back.
Javascript as part of the whole
HYIP
And this HYIP will be long, because everyone needs web applications, and because there is no real alternative. Because alternatives like Dart and CoffeeScript, with their advantages, do not have a pool of programmers who would satisfy the needs of the industry in the field of programming on the client side. To top it all there is a bunch of Legacy code that is not going anywhere.
Not less harm is caused by the fact that Javascript is attempted to be pushed into each hole, which is a consequence of copying, and this cramming energizes the language even more. Not all programmers believe that a virtual machine or codec in Javascript is a fun prototype, and not a real demonstration of the universality of the language. And this demonstration does not stop in any way, and new similar projects climb and climb, like miracles from a cattle grave.
Tools
The low level of programmers leads to the fact that the working tools for most are browser and firebug. And this is also the problem of Javascript - all the tools for it require nodeJS, which is logical in principle. But the installation of the same nodeJS is sometimes a headache even on unix-systems (in no small part due to hosters who prefer not to update the VPS templates unless absolutely necessary). On Windows, the situation has drastically improved in the last couple of years, and node and npm can even be installed without installing Cygwin. But installing other extensions under Windows is a minefield where you can explode even with a properly configured Cygwin. Therefore, a large percentage of front-end vendors ignore current advances in Javascript, saving themselves from the extra headache.
In general, not so many JavaScript scripters can configure the node, and install all the necessary modules to your project, as it may seem from the tone of the statements on the Internet. Issuing images of virtual machines with a working environment, so that each employee does not set everything up in a new way and does not waste time on an unnecessary routine, is a normal practice in many companies. But the problem is that among the same pythoners and perlovik, not to mention PHP programmers, the relative percentage of those who can deploy a heavy work environment is incomparably higher than the same percentage among Javascript programmers. And even among the percentage that may have the opinion that the tools could be better.
A radical improvement in the quality of tools is hardly to be expected in the near future - Google is not interested in making such an infusion of resources into the Javascript infrastructure, which was done for the development of the V8 engine. The community prefers to cut their bikes, rather than attach wheels to existing ones, so if it can bring the nodejs + npm bundle to the CPAN level, it will not be soon.
Asynchrony
If the programmer believes that asynchrony makes his code faster, then either he is a professional who deals with very specific algorithms, or he does not quite understand what I mean. Or is he a supporter of formal righteousness to the detriment of common sense. In the web, especially in medium-sized and medium-sized projects, there is nothing much to parallelize, and in large ones, cunning caching has already taken root for heavy requests or pieces of content. Well, there are all threads there ...
It cannot be said that the asynchronous approach to data processing is meaningless in principle. In the case of the generation of some kind of heavy analytics, reports that operate with many parameters unrelated to each other, the use of callbacks can give a huge performance gain. No threads and no data sharing between threads. This is really awesome. So what's the problem? Yes, the number of such winning situations is vanishingly small.
Programming some business logic, we write algorithms, and the definition of the word “algorithm” says that it is “a set of instructions describing the procedure of actions of the contractor to achieve the result of solving a problem in a finite number of actions”. Order! Data must be processed in a specific order! You cannot, for example, get all the buyers of certain goods from the online store database if the input parameter of your algorithm is the name of the category of goods for which you need to calculate statistics. First you have to get a category by name, then products in this category, then a list of customers. In our example, it is possible to wrap it in three callbacks in a row, having a zero performance gain and a significant gain in unreadable code. A separate article is processing errors in such asynchronous-assembly algorithms,especially if the page display depends on which particular callback is dropped.
The example with an online store is simple, but 95% of the web consists precisely of this simplicity. And in general, how do you imagine the unwinding of kolbek chain chains in complex business logic? There are usually many problems with the understanding of the heap of abstractions that were thrown into the system over the years of meeting conflicting requirements. I'm not even sure that the IDE will be able to build call graphs in such a logic - the order of execution will be visible only in runtime. Of course, there are places when it is possible and necessary to parallelize data processing by scrolling through asynchronously run handlers. And these places are vanishingly small. Much less than it might seem to lovers of the node. But the overhead associated with the support of such asynchronous code - a lot.
By the way, this approach suspiciously recalls the good old threads, which, if not in PHP, then already in Perl and Python were available at the time of web 1.0. And it cannot be said that they were actively used, what then, what now. Yes, threads in python are gloriously slow because of GIL, but let me, isn’t nodejs itself limited to one processor core in the current process? Yes, the thread creation syntax is sometimes not as concise as callbacks, but the latter also do not improve readability, especially starting from the second level of nesting. And you will have a second level of nesting, because all I / O is asynchronous.
For some reason, concurrency in a single process has not taken root widely in web development. Overhead for creating threads? But the number of threads created for the generation of a web page (by analogy with callbacks) is small. And even if we assume that callbacks are an order of magnitude faster than threads, then rewriting algorithms taking into account the first ones is often saving on matches, and at the same time it is inconveniently “smears” the resulting algorithm by code. And that is typical, many do not like it, but because they write their crutchesto combat the features of asynchronous programming. That asynchrony that a node is capable of issuing is a very, very, very specialized piece. Approximately like an illusionist proctologist who is able to entertain a patient with tricks during an impartial procedure, and who thinks that the magician’s skill can fill his gaps in medical education.
To compare threads and callbacks is formally incorrect, but from a practical point of view, both technologies are actively used to somehow reduce the time spent waiting for the end of an I / O operation. I am ashamed to say this, but I really do not see the difference between the two technologies in terms of solving my problems when programming on the server side.
Initially, asynchrony in Javascript was a consequence of its application area — non-blocking handlers for the user interface. With no heavy computational algorithms. And the meaning of such an asynchronous model was not to speed things up, but to prevent the script from blocking the browser while waiting for an event or completion of loading something from the server. The nodejs philosophy, which says that saving on input-output first of all, appeared about 10 years after the appearance of Javascript itself, but there is a suspicion that the emphasis on callbacks was made due to the fact that the implementation of the flow model of parallelism in the framework of the Javascript interpreter architecture was would be impossible. But kolbeki in the language were. Therefore, the asynchrony of the node is not a gift from above, but one big compromise,so that everything is not so bad.
Thus, it turns out that all the praised asynchrony of Javascript in the browser is the usual event loop, which is implemented in dozens of graphic toolkits. And on the server, it is a consequence of the problems caused by porting this event loop to the server. And upon closer inspection, after all the beautiful speeches about how cool and useful this asynchronous programming is, the rotten callback of the inside always appears.
With crutches for life
The whole stack of technologies, which revolves around Javascript, suspiciously resembles a parody of the ideology of UNIX: a bunch of small programs that do the most lousy work, sometimes duplicating each other. We have several wonderful browsers, each of which is good in its own way - some slow, some refuse to support the redirect by:
location.href = 'http://habrahabr.ru/';
And one has several different and very widely used versions, about the incompatibility of which with the rest are legends. All of these browsers, of course, vary.and the degree of support for HTML5, this bunch of components, designed to correct the flaws of Flash and replace them with their flaws. The speed of this zoo, even if you only use a subset of features supported by all browsers, will give such a spread that Firefox or IE users will enjoy the slide show while the Chrome user squeezes all the juices from his computer, going through a simple pixel arcade , like the ones that were so common on game consoles in the 80s and 90s. It seems to me that now even the generation of Chrome-only sites is growing, as in the past were sites that were sharpened exclusively for IE. Or not sharpened, but overlooked to such an extent that they work normally only under one browser.
Even the only good thing in my opinion that is in Javascript is the vaunted speed of the node - and this is the result of thousands of dashed man-hours that the browser does not slow down when Vasin’s website challenges it with all its crooked scripts. Well, or at least slowed down not so much when Twitter is running in the next tab. This is a desperate attempt to make web applications even better. And this attempt was not one - asm.js was also one of the strategies for increasing Javascript performance.
The HTML5 problem description is too far beyond the scope of this article, and certainly worthy of a separate article. I hope that it will be written by those who tried to create something heavy on HTML5, or write games for mobile platforms using this technology. I just say that the presence of a large number of loosely coupled components, different game writing techniques, different Javascript programming approaches, lack of HTML5 technology focus on graphics, rather than a set of components, is the only event-loop for all HTML5 banners, games, applications, varying degrees browser support, different browsing speeds - all this casts doubt on the advantages of HTML5 + Javascript technology over Flash. And in terms of the quality of games, and in terms of ease of development.Even a professional IDE will have to take a big step towards HTML5 game developers.
As if everything is
The most annoying thing in Javascript is the illusion that you have a full-fledged language like Java or Python. There is everything on paper - regular expressions embedded in the language, the implementation of the OOP, albeit an alternative, as adherents of the language like to repeat. And there is asynchrony - it buzzed all the ears, and in fact all this translates into endless torment and dashing dancing on crutches.
There is almost no place to get to the word to the language itself - its share in the whole stack of technologies is so small. The same DOM is at the mercy of browsers, all input-output is given to libraries, modules and human support for the PLO is implemented by them. And wherever you look, in what area of ​​application do not take a look, right there from where a whisper of an enthusiastic JS-battle is heard, that they have a library for that. When libraries are used to use some kind of nonstandard or specialized functionality, this is normal, when libraries are used to extend a general-purpose language, this is also normal — Boost for C ++ is a great example (if you do not take into account its monster nature), but But when libraries are used for a highly specialized language, and without expanding its functionality, but simply hiding its flaws, this makes you wonder.
Take the same jQuery, its use is so wide that among the other libraries in Google CDN, the percentage of downloads is 89%. I and all my fellow programmers are using jQuery for the reason that I have already stumbled upon the features of working with the DOM in earlier versions of browsers. Now everything is certainly better, but we still use it out of harm's way. Javascript has a lot of libraries to overcome asynchrony, supposedly the greatest feature of a node, but there is an opinion in the community that you still end up writing your own — which suits your goals. Even in us there are a myriad number of different loaders. All of them, along with AMD notation, emphasizing the fact that there are no modules in Javascript, clearly hint that the modules are needed, but they are not. That is why everyone will write the implementation. It would seem that the necessary thing, but at least we will never wait for such a thing:
window.addLibraryPath("/js/vendor");
var $ = window.loadLibrary("JQuery");
window.loadLibrary("DataTables");
Because asynchrony, which does not habitually load modules in the correct order (I am happy for those who like require (["/ a / ab / ac", "b / ad / vr"]);), because this again changes the language itself, which will reach all browsers slowly and in different ways, because even when requirejs and AMD become the de facto standard for implementing modules, a huge number of libraries cannot work with it, and you have to write wrappers. And this is a natural problem if the modules do not study at the time of learning the language, but after months, and even years, when the programmer grows to large applications. And then, it grows from its own side, with its already formed requirements for what modules should look like.
Running through the npm repositories, you might think that you have a great number of libraries for Javascript. And yes and no - there are a lot of them, but the quality, the presence of bugs, problems with assembling for different platforms will make you think again. In any somewhat developed project, you will inevitably run into these problems. The repositories of any language during the take-off of its popularity (I think even Haskell cannot avoid this) are some big garbage dumps. A huge number of programmers attacking popularity are trying to push their libraries there, which are needed by one and a half to other programmers. Things that everyone needs are usually written slowly, reluctantly, bugs are closed for years and more by community forces. It should be felt - how shaking hands during the installation of the next module from CPAN in 2005, or from PyPI in 2008,and how today it has become a hassle-free routine, even under Windows. In any case, for most of the modules. And Javascript will go the same long way as other languages, before noting that such node functionality has already been implemented for nodejs, you will no longer want to give the speaker a ringing slap.
Incorrect projection
The best ones are always heard, this applies to people and technologies, and of course the projects that connect them both. The Internet is filled with success stories about how nodejs allowed a project to be implemented using a much smaller number of servers than a similar project written in Java would require. There you can also read that the use of Javascript as a single language for the frontend and backend has reduced the number of developers, and reduced the duplication of code.
What these superstars will not tell you is that their project required very specific algorithms that 90% of websites need as a dog a side pocket with a pocket Javascript directory. But no, they just say it, but amid the rest of the story, this annoying little thing flies past the brain of the “aspiring” programmer overwhelmed with delight. Also, this “aspiring” web developer will never know what price he had to pay to reduce the amount of code, and what the architecture of the project he had shot represented. But miracles do not happen - the more environments you need to make your code work, the more effort you will spend on it. More superstars never tell you about the myriad man-hours, which was fucking fixing problems with immature technology.The problems are so ridiculous that it is embarrassing to write about them, otherwise they may cast a shadow on the technology, or on the programmer himself.
Although this can be seen from the articles, not all readers are aware that this is about some kind of almost unique, piece project, often high-loaded, very often not having anything to do with what the average web programmer has written throughout his life. Medium in terms of the nature of the project, not abilities. Backbone, Angular, Knockout, all this already seems so ordinary, accessible today. But what is their scope? Are there so many sites you see around with their use? And how many sites, in your opinion, should be one-page web applications? And how many sites need to bring all the logic to the client side, turning the server application into a database API?
Of course, there are such applications, but usually, in order to make them work as seen in advertising articles, they have to be licked for a long time and a large team. The code at the same time acquires such crutches that even a large team may not be enough and a large team of seniors will be needed. Those who wrote something big on the same Angular, and so everyone knows, the only question is how did they perceive it - how minor flaws, or did they no longer communicate with him.
And the small web has not gone away. He still needs Javascript at the “beautiful to the site” level, he needs cheap and widely used hosting, he needs tons of specialists who can be easily found and will not extort 3 PHP site costs for a similar site on nodejs.
Work speed
I take off my hat to the nodejs developers, or rather, to those who wrote and, most importantly, licked the V8 engine itself, thanks to which Javascript is capable of doing any other scripting language in terms of speed. It even steals up in speed to Java. This is what demand means, this is what competition between browsers means.
But at the same time, the subjective speed of the work of sites that are trying to push as much functionality as possible onto the client’s side is disheartening. There are 3 reasons for this:
- . , - , , DOM . , , Javascript, - . .
- Javascript , : — , . — .
- , . , . , Javascript .
And now, having the fastest interpretable programming language to date, programmers cannot fully use the speed that it can produce. And in part, this problem does not allow Flash to fully replace HTML5 + Javascript. With all the leakiness of Adobe Flash, with all the slowness of the Flash Player on systems other than Windows, with all the recent disregard by Adobe of its brainchild, with all this, Javascript and HTML5 do not have some of its important advantages. Such as the uniformity of the infrastructure for development and, which is especially important here, the unified execution environment - the Flash Player. Which, for games of comparable complexity, today shows a much higher subjective result than JS + HTML5. And the hellish speed of HTML5 games against benchmarks,who tear Flash to dust, is for me one of the greatest paradoxes.
In general, the speed of web applications in Javascript is a separate and extensive topic, and a separate topic deserves a separate article. Here it is . It is extremely doubtful that smartphones will make a qualitative breakthrough in performance in the near future. It is equally doubtful that full-featured web applications will be created in two forms - for desktop and mobile platforms. Those. On smartphones, we will receive either stubs from the functionality, or a portable heating pad with a built-in slideshow function. But even here there is a plus - more and more sites designed with REST in mind, as one of the requirements of the fat client part, are overgrown with native Android and iOS applications.
Conclusion
Those who love Javascript will continue to write on it, no matter what. And for those who have similar feelings, it will be nice to know that they are not the only ones who have problems with this language. I myself hope that due to the fact that web applications are a huge industry, and the size of applications is growing, a virtual machine with a unified bytecode will be built into the browsers, for which it will be easy to write a compiler for any language. And only then, having rejected the historical factor, the industry can critically select the language that is best suited for the needs of modern web programming.
Source: https://habr.com/ru/post/215777/
All Articles