Essential JavaScript libraries, tools, and frameworks you should know.

SetElement: function(el) ( this.list = document.createElement("ul"); el.appendChild(this.list); return this; )

Now we no longer have to store a reference to the container element. It is enough to create an element

and add it once to the tree.

The logic that improves performance is inside the update method:

"update": function(list) ( for (var i = 0; i< list.length; i++) { if (!this.rows[i]) { var row = document.createElement("LI"); row.textContent = list[i]; this.rows[i] = row; this.list.appendChild(row); } else if (this.rows[i].textContent !== list[i]) { this.rows[i].textContent = list[i]; } } if (list.length < this.rows.length) { for (var i = list.length; i < this.rows.length; i++) { if (this.rows[i] !== false) { this.list.removeChild(this.rows[i]); this.rows[i] = false; } } } return this; }

First for loop Iterates through all passed strings and creates elements if necessary

• . References to these elements are stored in the this.rows array. And if there is already an element there at a certain index, the framework only updates its textContent property if possible. The second loop removes elements if the size of the array is greater than the number of strings passed.

  Here's the result:

  
  

  The browser redraws only the part that has changed.

  The good news is that frameworks like React already work with the DOM correctly. Browsers are getting smarter and using tricks to re-render as little as possible. But still, it’s better to keep this in mind and check how the framework you choose works.

  I hope that in the near future we will no longer have to think about such things, and frameworks will take care of it themselves.

  Handling DOM Events

  JavaScript applications typically interact with the user through DOM events. Elements on the page send events, and our code processes them. Here's a piece of code in Backbone.js that performs an action if the user interacts with the page:

  Var Navigation = Backbone.View.extend(( "events": ( "click .header.menu": "toggleMenu" ), "toggleMenu": function() ( // ... ) ));

  So, there should be an element corresponding to the selector.header.menu and when the user clicks on it, we should show or hide the menu. The problem with this approach is that we tie JavaScript object to a specific DOM element. If we want to edit the markup and replace .menu with .main-menu , we will have to edit the JavaScript as well. I believe that controllers should be independent and should not be tightly coupled to the DOM.

  By defining functions, we delegate tasks to a JavaScript class. If these tasks are DOM event handlers, it makes sense to create them from HTML.

  I like the way AngularJS handles events.

  click me

  go is a function registered in our controller. If we follow this principle, we don't need to think about DOM selectors. We simply apply the behavior directly to the HTML nodes. This approach is good because it saves you from boring fiddling with the DOM.

  In general, I would be happy if this kind of logic was inside HTML. Interestingly, we spent a lot of time convincing developers to separate content (HTML) and behavior (JavaScript), we taught them to embed styles and scripts directly into HTML. But now I see that it can save us time and make our components more flexible. Of course, I don't mean something like this:

  banner text

  I'm talking about visual attributes that control the behavior of an element. For example:

  …

  This shouldn't look like programming JavaScript in HTML, rather it should feel like setting up configuration.

  Dependency management

  Dependency management is an important task in the development process. We usually depend on external functions, modules or libraries. In fact, we create dependencies all the time. We don't write everything in one method. We distribute application tasks into various functions, and then we connect them. Ideally, we want to encapsulate logic into modules that behave like black boxes. They know only those details that relate to their work, and nothing else.

  RequireJS is one of the popular dependency resolution tools. The idea is that the code is wrapped in a closure, into which the necessary modules are passed:

  Require(["ajax", "router"], function(ajax, router) ( // … ));

  This example function requires two modules: ajax and router. The magic require method reads the passed array and calls our function with the required arguments. The definition of router looks something like this:

  // router.js define(["jquery"], function($) ( return ( "apiMethod": function() ( // ... ) ) ));

  Note that there is another dependency - jQuery. Another important detail: we must return the public API of our module. Otherwise, the code requesting our module will not be able to access the functionality itself.

  AngularJS goes a little further and provides us with something called factory. We register our dependencies there and they magically become available in the controllers. For example:

  MyModule.factory("greeter", function($window) ( return ( "greet": function(text) ( $window.alert(text); ) ); )); function MyController($scope, greeter) ( $scope.sayHello = function() ( greeter.greet("Hello World"); )

  Generally speaking, this approach makes the job easier. We don't need to use functions like require to get to the dependency. All you have to do is print Right words in the argument list.

  Okay, both of these methods of dependency injection work, but each requires a different coding style. In the future, I would like to see frameworks that remove this limitation. It would be much more elegant to use metadata when creating variables. Now the language does not make it possible to do this. But it would be cool if you could do this:

  Var router:;

  If the dependency is located next to the variable definition, then we can be sure that this dependency is only injected if it is needed. RequireJS and AngularJS, for example, run on functional level. That is, it may happen that you use a module only in certain cases, but its initialization and implementation will always happen. In addition, we can only define dependencies in a strictly defined place. We are attached to this.

  Templates

  We often use templates. And we do this because of the need to separate data and HTML markup. How do modern frameworks work with templates? Here are the most common approaches:

  The pattern is defined in Hello, !

  This approach is often used because the templates are in HTML. This looks natural and makes sense, since HTML has tags. The browser does not render the contents of the elements, and the appearance pages it can't.

  The template is loaded via AJAX Backbone.View.extend(( "template": "my-view-template", "render": function() ( $.get("/templates/" + this.template + ".html", function(template) ( var html = $(template).tmpl(); )); ) ));

  We put our code in external files HTML and avoided use additional tags. But now we need more HTTP requests, and this is not always appropriate (by at least until HTTP2 support becomes wider).

  The template is part of the markup - the framework gets it from the DOM tree. This method relies on already generated HTML. We don't need to make additional HTTP requests, create new files, or additional elements.

  Template is part of the page markup var HelloMessage = React.createClass(( render: function() ( // Note: next line code // is not valid JavaScript. return Hello(this.props.name); ) ));

  This approach was introduced in React, which uses its own parser that turns an invalid piece of JavaScript into valid code.

  Template - not HTML

  Some frameworks don't use HTML directly at all. Instead, templates are stored as JSON or YAML.

  Lastly about templates

  Okay, what's next? I expect that with the framework of the future we will look at data separately and markup separately. So that they don't intersect. We don't want to deal with loading strings into HTML or passing data to special functions. We want to assign values ​​to variables and have the DOM update itself. Common two-way binding shouldn't be something extra, it should be mandatory basic functionality.

  In general, AngularJS behavior is closest to what is desired. It reads the template from the content of the provided page, and it implements magical two-way binding. However, it is not perfect yet. Sometimes there is flickering. This happens when the browser is rendering the HTML, but the AngularJS loading mechanisms have not yet started. In addition, AngularJS uses dirty check whether anything has changed. This approach is sometimes very costly. Hopefully all browsers will support Object.observe soon and the binding will be better.

  Sooner or later, every developer faces the question dynamic templates. Surely, there are parts in our applications that appear after downloading. With the framework it should be easy. We shouldn't have to worry about AJAX requests, and the API should be such that the process appears synchronous.

  Modularity

  I like when options can be turned on and off. And if we don’t use something, why keep it in the project code? It would be nice if the framework had a builder that generates a version with only the necessary modules. Like, for example, YUI, which has a configurator. We select the modules we want and get a minified and ready-to-use JavaScript file.

  Even so, there are frameworks that have something called core. In addition to it, we can use a pack of plugins (or modules). But we could improve this. Selection process the necessary opportunities should not include downloading files. We don't have to manually include them on the page. This somehow has to be part of the framework code.

  In addition to adequate installation capabilities, an ideal environment should allow for extensibility. We should be able to write our own plugins and share them with other developers. In other words, the environment should be conducive to writing modules. It is impossible to create a strong community without the existence of suitable conditions for developers.

  Open API

  Most frameworks provide an API for their core functionality. But using these APIs we can only get to those parts that the vendors have deemed necessary for us. And this is where hacks may come in handy. We want to get something, but there are no suitable tools for this. And you have to use tricks and take a detour. Consider this example:

  Var Framework = function() ( var router = new Router(); var factory = new ControllerFactory(); return ( "addRoute": function(path) ( var rData = router.resolve(path); var controller = factory.get (rData.controllerType); router.register(path, controller.handler); return controller; ) ) ); var AboutCtrl = Framework.addRoute("/about");

  This framework has a built-in router. We define the path and the controller is initialized automatically. When a user visits a specific URL, the router calls the handler method on the constructor. That's great, but what if we need to do small function JavaScript on URL match? For some reason, we don't want to create an additional controller. This won't work with the current API.

  We could do it differently, for example like this:

  Var Framework = function() ( var router = new Router(); var factory = new ControllerFactory(); return ( "createController": function(path) ( var rData = router.resolve(path); return factory.get(rData .controllerType); ) "addRoute": function(path, handler) ( router.register(path, handler); ) ) ) var AboutCtrl = Framework.createController(( "type": "about" )); Framework.addRoute("/about", AboutCtrl.handler);

  Note that the router does not stick out. It's not visible, but we can now control both the creation of the controller and the registration of the path in the router. Of course, the proposed option is suitable for our specific task. But it can be overly complicated because the controllers have to be created manually. When developing APIs, we are guided by the principle of single responsibility and reasoning do one thing and do it well. I see more and more frameworks decentralizing their functionality. In them complex methods are divided into smaller parts. And this is a good sign, I hope more frameworks will do this in the future.

  Testability

  There is no need to convince you to write tests for your code. The point is not only that you need to write tests, but that you need to write code that can be covered with tests. Sometimes this is incredibly difficult and time consuming. I am convinced that if we don’t write tests for something, even for something very small, then this is where bugs will start to appear in the application. This is especially true for client-side JavaScript. Multiple browsers, multiple operating systems, new specifications, new features and their polyfills - yes, there are a lot of reasons to start practicing test-driven development.

  There is something else that we will get from the tests. We not only make sure that our framework (application) works today. We make sure that it will work tomorrow and the day after tomorrow. If there is any new opportunity that we bring into the code, we write tests for it. And it is very important that we make sure that these tests are passed. But it is also important that previous tests are passed. This is how we ensure nothing is broken.

  I'd love to see more standardized utilities and methods for testing. I would like to use one utility to test all frameworks. It would also be nice if testing was somehow included in the development process. You should pay more attention to services like Travis CI. They act as an indicator not only for the programmer making the changes, but also for other contributors.

  I'm still working with PHP. I've had to deal with frameworks like WordPress. And a lot of people have asked me how I test my applications: what framework I use, how I run tests, whether I even have components. The truth is that I don't test anything. And that's why I don't have the components. The same applies to some JavaScript frameworks. Some of their parts are difficult to test because they are not broken down into components. Developers should think in this direction as well. Yes, they provide us with smart, elegant and working code. But the code must also be testable.

  Documentation

  I am sure that without good documentation any project will sooner or later fail. A bunch of frameworks and libraries are released every week. Documentation is the first thing a developer sees. Nobody wants to spend hours trying to find out what a certain utility does and what capabilities it has. Simply listing the core functionality is not enough. Especially for a large framework.

  I would divide good documentation into three parts:

  • What can I do - the documentation should teach the user and should do it correctly. No matter how cool or powerful our framework is, it needs to be explained. Some people prefer to watch videos, others read articles. In any case, the developer needs to show everything from the very basics to the complex parts of the framework.
  • API documentation is usually everywhere. Full list all public API methods, what parameters they have and what they return. Maybe some usage examples.
  • How it works - usually this section is not in the documentation. Well, if someone could explain the structure of the framework, even a simple diagram of the basic functionality and its relationships would already help. This would make the code transparent. This would help those developers who want to make their own changes.
  Conclusion

  The future is, of course, difficult to predict. But we can dream about it! It's important to talk about what we expect and what we want from JavaScript frameworks! If you have comments, suggestions or want to share your thoughts, write to Twitter with the hashtag

  Today we will talk about JavaScript.

  AngularJS

  One of the most popular JS developer tools was released in 2009. Thanks to its wide functionality (albeit not reaching Full-stack) and the support of its powerful creator, Angular quickly climbed to the top of the ranking of the best JS frameworks, and does not intend to climb down from there.

  As for recent releases, Angular 4.0.0 was officially released at the end of March (despite the fact that 2.0.0 was released only a year ago). This update speed is not due to the “crudeness” of the products being released, but to the fact that the first version contained many simplifications, which in inept hands led to errors, and in experienced hands to significant losses in performance, the second is a compromise transition, the third was skipped, and the fourth - this is a current product, modified based on all comments. True, there is a suspicion that it is not yet complete.

  And now more about the advantages. Firstly, it's convenience. You don’t have to worry about describing a dozen pop-up processes when processing one event; the work with templates and dependencies is really well implemented here, and creating a strictly personalized interface is not difficult.

  Secondly, Google is constantly releasing more and more high-quality libraries and plugins.

  Thirdly, in Angular, interaction with HTML is not replaced by the DOM model (HTML code is not mixed with scripts), which ultimately affects the ease of reading and testing of the code. In addition, Angular's capabilities are slightly broader than those of most popular JS frameworks.

  Disadvantages of this approach: low performance of busy interfaces and a sharp learning curve (it’s easy to start working, but the further you go, the harder).

  ReactJS

  

  This framework was created in 2013 by Jordan Wolk from Facebook. The low barrier to entry and ease of use have made ReactJS a popular product among enterprise developers, finding echoes in the hearts of the offices of companies such as Airbnb, Netflix Walmart, etc. Moreover, React is today considered the main tool for a JS developer, simply because Angular is a little complicated and redundant.

  The thing is that, unlike Angular, React is very limited in functionality. Moreover, some hardcore developers do not seriously consider ReactJS a framework, proposing a more understandable, but not entirely correct, definition of “a limited library for lazy people.”

  But this description reveals the main advantages of working with this framework quite accurately. Here you operate with templates and ready-made callback functions, creating your own front-end. For a beginner, everything is quite convenient and understandable, but, in fairness, in Angular things are no worse.

  The main convenience and at the same time the main complaint about React is JSX components. This is exactly the case when scripts are tightly mixed with HTML code, blurring the boundaries between the presentation and functionality of the component. There is nothing wrong with this, but understanding of the work and “correctness” suffer. In short, with React you save time and stress, which is often a key factor in the choice, but you lose a little self-respect.

  The main disadvantage, in addition to the very limitations of the approach, is that the official documentation is not the best. But either it was seriously reworked, or the critics’ expectations were initially very high, but I didn’t see anything fundamentally different from the tutorials that Microsoft or Google usually offer their clients.

  Vue.js

  

  The first version of Vue.js was built on the same principles as React, but excluding the use of JSX components. It was not a bad alternative, but before version 2.0 it was a rather crude library. And then it started. Just look at the statistics: crazy growth in popularity on GitHub, Google Trends and in developer preferences.

  To put it simply, Vue.js is a kind of compromise between React and Angular. Front-end code is easy to create, but at the same time read and edit. At the same time, this has absolutely no effect on the final performance; more precisely, it has an effect, but only in a positive direction.

  But there is negative sides, and they are quite significant. Firstly, there is a meager amount of documentation and third-party libraries. The project is young, developed essentially by one person, and experienced a surge in popularity only in 2016, so there is no need to talk about any stream of auxiliary tools.

  In addition, the demand for Vue.js is concentrated mainly in the China region, so there is no need to talk about the development of communities either. Secondly, another problem of growth is the large number runtime errors in templates. Over time, everything gets better, but this fact so far this refers to serious problems, and not rare misunderstandings.

  Ember.js

  

  Another variation on the theme “More templates - more benefits for the developer.” In essence, you won't see anything revolutionary here, Ember is essentially a simplified Angular. The main similarities are provided by two-way binding and capabilities that lie beyond the creation of a front-end interface.

  Implemented here MVC model. implemented according to strict configurations. From the point of view of mastering the tool by a beginner and ensuring speed of development, this is an almost ideal solution. But when you decide to leave this path beaten by the developers, you will immediately discover all the sharp pitfalls. These are the difficulties of customization, and too frequent radical changes to the version, and the associated quickly outdated standard FAQ on forums and communities.

  Meteor

  

  Meteor is far from the most popular framework, but it has a lot of advantages that the previously listed contenders are deprived of. Firstly, this is a true Full-stack developer tool. Secondly, you can write here at pure JavaScript. Third, integration with either Angular or React. Fourth, an almost ideal implementation of the mechanism for creating real-time web resources (examples are Mazda and Ikea online configurators). Moreover, all this is flavored with excellent official documentation, including training, and a large community of developers

  The disadvantages are not too significant: using Mongo as a database or others, but through Mongo Queries (in Angular, for example, there are no such restrictions), and the questionable security of the resulting product, which is quite natural for such functionality.

  At the same time, Meteor is relatively easy for a beginner to learn, and one or two days is enough for an experienced developer. However, unfortunately, neither this nor the efforts of developers who are constantly refining their product make it possible to overtake other today's contenders simply because full-stack is still very difficult for many. But maybe that's just because they haven't tasted Meteor.

  What frameworks do you use?

  Alina Arkhipova “JavaScript Frameworks: How To Make Your Choice”.

  JavaScript is one of the core technologies in world wide web. According to the survey results, JavaScript is the top language among front-end developers, and it doesn't look like it's losing popularity. This is why there are so many JavaScript frameworks available today that it is difficult to know which one is the most efficient.

  The more frameworks appear, the more controversy surrounds them. There's a lot of talk in the developer community about which frameworks are most effective for front-end development. Based on our research, we have identified the top five most talked about JavaScript frameworks. We described them in this article. Also in it we will share the experience of Yalantis: we will talk about which frameworks our front-end developers prefer.

  Review of popular JavaScript frameworks

  Every month a new JavaScript framework is released. Product owners may have difficulty making a choice. Frameworks are necessary. Their task is to speed up and facilitate the work process, as well as increase its productivity. Therefore, the choice of framework greatly influences the efficiency and productivity of the development process. Let's compare the top JavaScript frameworks.

  Angular

  Angular is a full-featured framework released in 2010 by Google. The company continues to regularly release updates. For example, in March 2018 latest version Angular 6 brought many improvements including new engine rendering for faster and smaller applications.

  Today Angular is one of the most popular front-end frameworks. Many developers choose Angular because they see it as the key to simplifying development. Thanks to its templates, front-end professionals can easily use Angular to create dynamic single-page web applications with a lot of mutable data. Additionally, Angular has a Model-View-Controller (MVC) that makes testing easier and more accessible.

  React.js

  React.js is a framework released by the Facebook team in 2013. Large companies including Dropbox, PayPal, BBC, Atlassian and Instagram use React as their main front-end tool.

  React is great for applications and websites with complex logic representation. React also allows reuse components within the application, so that developers do not have to create similar components over and over again. With React, developers can focus on building complex functionality. Thanks to a special negotiation algorithm called Virtual DOM, front-end developers receive a significant increase in productivity. They can develop faster because they don't have to update views after every small change.

  Vue.js

  Vue.js is a fairly new JavaScript framework created by Evan Yu. Its main goal is to make user interface development more organized.

  Many front-end experts claim that this is an excellent tool for beginners. It is very easy to understand because it focuses on the layers of presentation. Vue.js works without Babel, a transpiler that converts JavaScript code into old version ES5, which runs in all browsers. Not using Babel speeds up development. Vue.js templates are valid HTML, so integration is easy. This framework is a good solution for developing lightweight applications.

  Ember.js

  The Ember.js framework was created in 2011. It has been used to create many good websites famous companies, including Kickstarter, Heroku and LinkedIn.

  Ember.js is regularly updated and provides full package functions. This framework is effective for developing complex web applications, and its string-based templating system helps speed up loading times. Ember.js focuses on scalability, so developers can easily work with both mobile and web projects.

  Next.js

  Next.js is an unusual JavaScript framework. It was developed by the React team as an additional tool for server-side rendering. When working with React and Next.js, the development process becomes easier, just like when using Vue.js.

  Next.js has these worthy of mention features like automatic code splitting and page-based routing on the client side. Additionally, Next.js has full CSS support (called styled-jsx) to make styling the user interface much easier.

  These five popular JavaScript libraries and frameworks have a lot in common. For example, they all have an efficient component architecture and documentation system. The functionality they provide is aimed at reducing development time, which benefits both product owners and developers.

  Choosing the best UI framework should always depend on the project specification as well as the skill of the developer. Now we will tell you what developers choose at Yalantis.

  Which frameworks do Yalantis front-end developers choose?

  The front-end development team at Yalantis often works with JavaScript frameworks. Over the past few years, we have tested a variety of frameworks to find the most efficient and beneficial tool.

  Today we prefer to work with two well-known JavaScript frameworks - Angular and React. But why just these two? Let's take a closer look at the functionality they offer to front-end developers.

  Angular

  The Google team has developed one of the most popular JavaScript frameworks today. Angular has gained notable popularity due to its support for two-way data binding, efficient templates, and simple documentation.

  Efficient, component-based system. Components and directives have replaced controllers and application areas as the building blocks of applications. Component classes are individual blocks, making them reusable and easy to add to existing applications.

  Two-way data binding. This feature reduces the amount of time required to write code. Developers can make changes to models and views simultaneously, without waiting for UI elements to render.

  TypeScript. Angular training resources and documentation are based on TypeScript, so it's hard to avoid. TypeScript may seem complicated to some developers, but there is nothing wrong with it. Many new features become available much faster for TypeScript than for other languages. Moreover, TypeScript provides object-oriented programming patterns and optional static type checking, which is useful for large applications.

  Convenient templates. Templates in Angular are presented in HTML, so developers can create functional applications even if they don't know much JavaScript. The browser processes the templates and generates rendering instructions, also known as directives.

  Simple documentation. All the official Angular documentation is short and simple, so even less experienced developers can quickly pick up the basics.

  Supporting a strong community. The Angular framework is a Google product, so naturally it has a lot of fans and people who support it. Developers can easily find a lot of advice on blogs and forums.

  Let's summarize. The Angular framework is top instrument for front-end development, providing a lot different functions. Building applications with Angular benefits both businesses and developers. First of all, Angular is supported by Google, so this framework is regularly updated and its functionality is constantly improved. Secondly, unlike many other frameworks, Angular is available under the MIT license. It is important for businesses and developers to use licensed tools as they are more reliable.

  React

  React is a revolutionary JavaScript framework that occupies a leading position in the rankings of JavaScript frameworks. It is very popular among GitHub users, who have given it more than 95 thousand stars. But what makes React so special?

  Increased productivity. React has a unique feature called Virtual DOM that makes coding more efficient. When developers make small changes, they don't need to update the entire view. Changes go through the Virtual DOM, which re-renders only the desired part of the page. This approach takes less time and saves developer effort.

  JSX. Declarative JavaScript syntax that helps you create neat, readable code. JSX also helps you combine components into a single executable.

  Ease of learning. If developers know JavaScript, they can start using React straight away. Developers can skip the manuals because React is simple and well organized. To become a React professional, you will need to become familiar with JSX.

  Components that can be reused. React, like Angular, has a component-based architecture. This means that when using the React framework, developers can view components as the building blocks of an application. The most big advantage This is because ready-made components can be used in various parts of the application. This increases development speed.

  Facebook and community support. React is supervised by one of the tech giants - Facebook. The Facebook team knows how to work with complex web applications, so the React framework is focused on increasing productivity. The React community is one of the largest (when compared to the communities of other popular front-end development frameworks). There are many blogs, plugins and SDKs related to React. Therefore, if a developer has any problems with this framework, he can easily find answers on the Internet.

  In general, the React framework is effective tool to develop the user interface. Its functionality improves development by reducing the time it takes to write code, which is a big benefit for businesses and developers. Plus, React is easy to learn, so developers can start using it without any prior training. Lastly, it has great community and Facebook support, so this framework is sure to have updates and new cool features.

  We've covered five top JavaScript frameworks, but the choice is yours. Compare performance, architecture, learning curve, documentation, organization, and community support when making your decision.

  From the author: before talking about JavaScript frameworks, let's define what I mean by the word “framework”, since the term is quite vague. By framework I mean a library that defines the structure of all aspects and levels of an application and facilitates development. Levels, in in this case, these are databases, models, controllers, displayables, views, networks, etc.

  Frameworks help solve most known issues problems that arise when working with applications. They contain ready-made design solutions as well as carefully developed guidelines; in this regard they should not cause any difficulties.

  Good frameworks have well-thought-out default parameters and operate on the convention-over-configuration principle. One of the leaders among frameworks is my favorite - Ruby on Rails. In the field of JavaScript, these are Angular and Ember.

  Now that we've cleared everything up, I'd like to answer the question posed in the title: Which JavaScript frameworks are worth mastering in 2018?

  My answer: None.

  Now I will explain why.

  As long as your work doesn't require you to use a framework, you don't need to master it just to master it. I mean, you don't have to learn how to use it. This knowledge will become outdated very quickly.

  But it’s definitely worth finding out on what principle the framework works. This is very valuable knowledge. If you are looking into frameworks to find Good work, knowing how it works is much more useful than knowing how to use it.

  Learn to use the framework only when the need arises.

  In my opinion, to become a sought-after developer, you need to master more important skills:

  Learn everything you can about the JavaScript language itself: its strengths and weaknesses, new features. Learn to create and use various data structures in JavaScript.

  Explore work environment JavaScript, such as Node and browsers, and how single threaded they are. Learn about their APIs and limitations, the event loop, and the OS call stack. Make sure you feel comfortable with the topic of browser development tools.

  Learn to pass code from client to server and preload source data. Learn to minimize loading javascript and execute parsing browsers, and load JavaScript on demand.

  Learn about the benefits of functional programming and use them. Whenever possible, try to explain rather than point out.

  Check out the little ones JavaScript libraries that do one thing and do it well. Choose libraries with the smallest API and don't focus on the API, rather focus on what these libraries can do.

  Learn to build APIs with scalable data (consider GraphQL).

  Check out CSS work and learn to minimize it using JavaScript application code. Explore the new Flexbox and Grid layouts. Find out more about responsive design UI

  Learn to add static types to JavaScript using TypeScript (or Flow) and learn where to focus on types versus testing.

  Thank you for your time.