Using new JavaScript features in the world of ES3
Hello colleagues.
Recently, we have occasionally returned to the topic of JavaScript. We are particularly interested in the next book in the “You Don't Know JS” series, dedicated to the ES6 standard (Kyle Simpson):
')
By the way, maybe someone has already watched the new book by Adam Boduh " JavaScript at Scale " and would like to see it in Russian?
About this in the survey. And under the cut - a critical (January) article by Mr. Cody Lindley, helping to think about how the world of JavaScript is ready for change.
In the world of JavaScript web development for large enterprises, such solutions are created and such tools are used, which should be at least as small as possible in ECMAScript 3 (ES3 standard). You may wonder - how can this be? In the end, ECMAScript 5 was ready in June 2011 and is supported by all modern browsers, including IE 9 (except for strict mode ).
In this article, we’ll talk about why many, if not all, JavaScript developers from large enterprises still have to consider ES3, and also discuss a number of strategies for those who want to use the features of ES5 / ES6 today. Finally, I will tell why I do not do it myself.
IE8 has not gone away. Get used to it.
Support for IE 8, 7, and even 6 can still remain an actual requirement in the enterprise. Whether you like it or not, do you agree with this? In other words, using the features of JavaScript ES5 or ES6 in the combat code - in many corporate environments is still a matter of the future.
The code created by corporate developers and the tools they work with should, in principle, support the ES3 environment. For example, most widgets in Kendo UI (excluding mobiles) are tested and supported in IE7 +. Even a cursory examination of virtually any JavaScript solution written for corporate developers makes sure that most of these solutions are built to ES3 standards.
This should not surprise anyone who has a hand in corporate development. However, it is sometimes difficult to come to terms with the fact that many of the newest JavaScript tools (for example, Angular 1.3) are being tested and developed without any regard for perfect work in pure ES3 environments, and they may not even take root there. At a minimum, there they can provoke serious trouble , require detour maneuvers and polyfill.
At present, corporate tools are often perceived and exalted as extremely reliable, first-class, time-tested, sharpened to solve only the most complex tasks that can arise for a programmer. But the reality is that most of the enterprise JavaScript code and related tools are written and standardized to a specification that was finalized 16 years ago.
Undoubtedly, the ES3 standard is time-tested, but about its high reliability and suitability for a large enterprise, I think many current JavaScript developers could argue. In the end, the possibilities of the new specifications of ES5 and ES6, by definition, were created specifically to correct the flaws of ES3 and to enable modern JavaScript to solve such complex tasks as are set before it today. And there is no doubt that the capabilities implemented only 16 years ago are not enough for modern JavaScript development.
What is the action plan for the developer?
Imagine how bleak it all sounds to the average JavaScript developer from a large corporation. As a JavaScript specialist, I myself would like all my colleagues to start working with new JavaScript features, without waiting for their finalization and implementation. Browsers and corporations, damn you!
But between the desired and the real big difference. I think that is why polyfills are made to imitate new features, people compile JavaScript for old browsers or even throw client code at all and learn Node. Do not laugh, it happens. The client and the browser can actually get so much for the developer that he throws himself headlong to look for a better runtime environment for JavaScript.
Seriously, the most reasonable thing for a corporate developer using the ES3 toolkit and writing code that works in the ES3 environment is simply to do the trick. I think no one bothers you to dream that someday you can forget about the support of the old browsers (ES3) and create only the modern native code under ES5 or ES6. Of course, enterprise developers will have to wait for the withering away of old browsers - frankly, in a large enterprise this will not happen soon.
WHY I DO NOT USE POLYPHILLES OR COMPILATION
Personally, I never tried to use large-scale polyfills and did not resort to compilation to make a working ES3-code from ES5 or ES6. Yes, I occasionally resorted to polyfills, but I never managed to cope with the difficulties and costs associated with the comprehensive use of polyfills or the compilation procedure (that is, to create a working ES3 code from the source code ES5 or ES6). Pitfalls, additional polyfill, restrictions on use and inadequate features - that's what kept me from this. For example, try simply reading about all the details related to using the features of ES6 when using the new 6to5 compiler.
This does not mean that I did not savor, did not program and did not use the new features of JavaScript, when I had such a chance. Do the same. The fact is that when I need support of the ES3 environment, I choose the path of least resistance, which is as follows: get by with such tools and write such code that is as close as possible to the “metal” of ES3. Finally, the mere fact that the tool requires ES5 + does not mean that it can work under the restrictions inherent in another third-party solution related to polyfills or compilation - of course, if this solution is not pre-tested and supplied with the necessary polyfills, for obvious reasons (file size, synchronization, duplication, etc.) is usually not done.
So, I almost did not resort to either the polyfill or the compilation. I believe that creating an application in JavaScript is in itself an incredibly complex enterprise. The slightest complications of a large corporate project, costs or bureaucracy (especially a third-party bureaucracy) are justified only if they give a principled gain in development. In my practice, such a gain would never have been achieved by adding new JavaScript features to the code base designed for ES3 - so difficult it is.
But not everyone will agree with me. Of course, each has its own permissible limit of additional complexity or justified risk. Therefore, in the framework of this article, I believe that you, unlike me, decided to use the features that appeared in later specifications in the base of the ES3 code (note: I'm talking about polyfills for third-party code).
Strategies for using new features of ES6 + JavaScript in the enterprise
In the rest of this article, we explore 3 strategies for using new features of ES6 + JavaScript in the enterprise.
STRATEGY 1. APPLICATION OF INTEGRATED POLYPHILLS
It’s very easy to polyfill the ES3 environment from the ES5 and ES6 standards (and even from ES7 ) - just include the shim.js file from the core.js project in an HTML document.
shim.js is included in the HTML document as the first JavaScript file to run / parse, and the rest of the JavaScript code that follows it can use the capabilities of the polyfills as native (below are examples of code from core.js).
Note that core.js not only provides a full set of ECMAScript-compatible polyfills, but also the following non-standard JavaScript features available when using core.js instead of shim.js.
STRATEGY 2. USE OF POLYPHILLES BY OPT-IN PRINCIPLE
Whether we like it or not, the above-mentioned plug-in polyfills add new features to the ES environment during execution. At any cost. If this does not suit you, then there is another option. The core.js project also offers explicitly plug-in (opt-in) polyfills that implement new features, but these features can also be used selectively by activating each of them separately. This practice is used in libraries like lodash, offering one global value (for example, _), to which all possibilities are tied.
To explicitly enable ES5 and ES6 features in your code, you can include the library.js file from core.js. You can then apply new ECMAScript capabilities as needed, by writing code that addresses those capabilities of the method that are tied to the global value of 'core'. A similar situation is implemented in the following code sample (example is taken from core.js).
STRATEGY 3. PRELIMINARY COMPILATION OF ES6 + IN ES5 WITH THE FOLLOWING POLYPHILLES FOR ES3
The standard features of ES5 and ES6 cannot be directly compiled into ES3 code (for example, use old features to write newer ones equivalent to them). Otherwise, you will seriously limit those opportunities. which could be broadcast. It would be realistic to use the preliminary compilation stage, in which the ES6 code is compiled into ES5, and then use the plugin polyfill shim.js to overcome the last stage to ES3.
To do this, you can use the new 6to5 transpiler and create a preliminary build task that uses gulp , which transforms ES6 into unmodified (vanilla) ES5. Then, according to the 6to5 documentation, to get a full runtime environment for ES6 , you also need to prepare this environment using the regenerate runtime , shim.js and ES6 module loader polyfills (note: I use client / shim.js from core.js, where ES3 support is provided.
An HTML file containing code compiled with 6to5 might look something like this:
Just do not forget that if you do it in a commercial code, then I strongly recommended to investigate absolutely all possible nuances .
What about third-party code?
Theoretically, if you polyfilled or polyfilled + precompiled the code to use the new JavaScript features in the ES3 environment, you can safely use third-party tools that work only in ES5 + environments, right? Not!
Practically the only way to safely use a third-party tool in an ES3 environment is to directly support your specific polyfill / compiler at the third-party code level. Otherwise, the premise from the first paragraph of this section remains very dumb and temporary. Remember, all this washing down of new opportunities in old environments is connected with one or another reefs, complex tricks and personal opinions. You should not expect a third-party developer to deal with such details, unless you personally saw that these developers are precisely oriented towards your environment. If you do not quite understand me, just note that third-party developers are unlikely to test polyfills and compiled output. As a rule, if ES5 + environment is required for parsing third-party code, then this means the real ES5 + environment.
Recently, we have occasionally returned to the topic of JavaScript. We are particularly interested in the next book in the “You Don't Know JS” series, dedicated to the ES6 standard (Kyle Simpson):
')
By the way, maybe someone has already watched the new book by Adam Boduh " JavaScript at Scale " and would like to see it in Russian?
About this in the survey. And under the cut - a critical (January) article by Mr. Cody Lindley, helping to think about how the world of JavaScript is ready for change.
In the world of JavaScript web development for large enterprises, such solutions are created and such tools are used, which should be at least as small as possible in ECMAScript 3 (ES3 standard). You may wonder - how can this be? In the end, ECMAScript 5 was ready in June 2011 and is supported by all modern browsers, including IE 9 (except for strict mode ).
In this article, we’ll talk about why many, if not all, JavaScript developers from large enterprises still have to consider ES3, and also discuss a number of strategies for those who want to use the features of ES5 / ES6 today. Finally, I will tell why I do not do it myself.
IE8 has not gone away. Get used to it.
Support for IE 8, 7, and even 6 can still remain an actual requirement in the enterprise. Whether you like it or not, do you agree with this? In other words, using the features of JavaScript ES5 or ES6 in the combat code - in many corporate environments is still a matter of the future.
The code created by corporate developers and the tools they work with should, in principle, support the ES3 environment. For example, most widgets in Kendo UI (excluding mobiles) are tested and supported in IE7 +. Even a cursory examination of virtually any JavaScript solution written for corporate developers makes sure that most of these solutions are built to ES3 standards.
This should not surprise anyone who has a hand in corporate development. However, it is sometimes difficult to come to terms with the fact that many of the newest JavaScript tools (for example, Angular 1.3) are being tested and developed without any regard for perfect work in pure ES3 environments, and they may not even take root there. At a minimum, there they can provoke serious trouble , require detour maneuvers and polyfill.
At present, corporate tools are often perceived and exalted as extremely reliable, first-class, time-tested, sharpened to solve only the most complex tasks that can arise for a programmer. But the reality is that most of the enterprise JavaScript code and related tools are written and standardized to a specification that was finalized 16 years ago.
Undoubtedly, the ES3 standard is time-tested, but about its high reliability and suitability for a large enterprise, I think many current JavaScript developers could argue. In the end, the possibilities of the new specifications of ES5 and ES6, by definition, were created specifically to correct the flaws of ES3 and to enable modern JavaScript to solve such complex tasks as are set before it today. And there is no doubt that the capabilities implemented only 16 years ago are not enough for modern JavaScript development.
What is the action plan for the developer?
Imagine how bleak it all sounds to the average JavaScript developer from a large corporation. As a JavaScript specialist, I myself would like all my colleagues to start working with new JavaScript features, without waiting for their finalization and implementation. Browsers and corporations, damn you!
But between the desired and the real big difference. I think that is why polyfills are made to imitate new features, people compile JavaScript for old browsers or even throw client code at all and learn Node. Do not laugh, it happens. The client and the browser can actually get so much for the developer that he throws himself headlong to look for a better runtime environment for JavaScript.
Seriously, the most reasonable thing for a corporate developer using the ES3 toolkit and writing code that works in the ES3 environment is simply to do the trick. I think no one bothers you to dream that someday you can forget about the support of the old browsers (ES3) and create only the modern native code under ES5 or ES6. Of course, enterprise developers will have to wait for the withering away of old browsers - frankly, in a large enterprise this will not happen soon.
WHY I DO NOT USE POLYPHILLES OR COMPILATION
Personally, I never tried to use large-scale polyfills and did not resort to compilation to make a working ES3-code from ES5 or ES6. Yes, I occasionally resorted to polyfills, but I never managed to cope with the difficulties and costs associated with the comprehensive use of polyfills or the compilation procedure (that is, to create a working ES3 code from the source code ES5 or ES6). Pitfalls, additional polyfill, restrictions on use and inadequate features - that's what kept me from this. For example, try simply reading about all the details related to using the features of ES6 when using the new 6to5 compiler.
This does not mean that I did not savor, did not program and did not use the new features of JavaScript, when I had such a chance. Do the same. The fact is that when I need support of the ES3 environment, I choose the path of least resistance, which is as follows: get by with such tools and write such code that is as close as possible to the “metal” of ES3. Finally, the mere fact that the tool requires ES5 + does not mean that it can work under the restrictions inherent in another third-party solution related to polyfills or compilation - of course, if this solution is not pre-tested and supplied with the necessary polyfills, for obvious reasons (file size, synchronization, duplication, etc.) is usually not done.
So, I almost did not resort to either the polyfill or the compilation. I believe that creating an application in JavaScript is in itself an incredibly complex enterprise. The slightest complications of a large corporate project, costs or bureaucracy (especially a third-party bureaucracy) are justified only if they give a principled gain in development. In my practice, such a gain would never have been achieved by adding new JavaScript features to the code base designed for ES3 - so difficult it is.
But not everyone will agree with me. Of course, each has its own permissible limit of additional complexity or justified risk. Therefore, in the framework of this article, I believe that you, unlike me, decided to use the features that appeared in later specifications in the base of the ES3 code (note: I'm talking about polyfills for third-party code).
Strategies for using new features of ES6 + JavaScript in the enterprise
In the rest of this article, we explore 3 strategies for using new features of ES6 + JavaScript in the enterprise.
STRATEGY 1. APPLICATION OF INTEGRATED POLYPHILLS
It’s very easy to polyfill the ES3 environment from the ES5 and ES6 standards (and even from ES7 ) - just include the shim.js file from the core.js project in an HTML document.
shim.js is included in the HTML document as the first JavaScript file to run / parse, and the rest of the JavaScript code that follows it can use the capabilities of the polyfills as native (below are examples of code from core.js).
console.log(Array.from(new Set([1, 2, 3, 2, 1]))); // => [1, 2, 3] console.log('*'.repeat(10)); // => '**********' Promise.resolve(32).then(console.log); // => 32 setImmediate(console.log, 42); // => 42 Note that core.js not only provides a full set of ECMAScript-compatible polyfills, but also the following non-standard JavaScript features available when using core.js instead of shim.js.
- Mozilla JavaScript: Array generics
- setTimeout / setInterval
- setImmediate
- console
- Object
- Dict
- Partial application
- Date formatting
- Array
- Number
- Escaping characters
STRATEGY 2. USE OF POLYPHILLES BY OPT-IN PRINCIPLE
Whether we like it or not, the above-mentioned plug-in polyfills add new features to the ES environment during execution. At any cost. If this does not suit you, then there is another option. The core.js project also offers explicitly plug-in (opt-in) polyfills that implement new features, but these features can also be used selectively by activating each of them separately. This practice is used in libraries like lodash, offering one global value (for example, _), to which all possibilities are tied.
To explicitly enable ES5 and ES6 features in your code, you can include the library.js file from core.js. You can then apply new ECMAScript capabilities as needed, by writing code that addresses those capabilities of the method that are tied to the global value of 'core'. A similar situation is implemented in the following code sample (example is taken from core.js).
var log = core.console.log; log(core.Array.from(new core.Set([1, 2, 3, 2, 1]))); // => [1, 2, 3] log(core.String.repeat('*', 10)); // => '**********' core.Promise.resolve(32).then(log); // => 32 core.setImmediate(log, 42); // => 42 STRATEGY 3. PRELIMINARY COMPILATION OF ES6 + IN ES5 WITH THE FOLLOWING POLYPHILLES FOR ES3
The standard features of ES5 and ES6 cannot be directly compiled into ES3 code (for example, use old features to write newer ones equivalent to them). Otherwise, you will seriously limit those opportunities. which could be broadcast. It would be realistic to use the preliminary compilation stage, in which the ES6 code is compiled into ES5, and then use the plugin polyfill shim.js to overcome the last stage to ES3.
To do this, you can use the new 6to5 transpiler and create a preliminary build task that uses gulp , which transforms ES6 into unmodified (vanilla) ES5. Then, according to the 6to5 documentation, to get a full runtime environment for ES6 , you also need to prepare this environment using the regenerate runtime , shim.js and ES6 module loader polyfills (note: I use client / shim.js from core.js, where ES3 support is provided.
An HTML file containing code compiled with 6to5 might look something like this:
<!DOCTYPE html> <html> <body> <script src="runtime.js"></script> <script src="client/shim.js"></script> <script src="es6-module-loader.js"></script> <script> System.parser = '6to5'; // es6-module-loader.js 6to5 // , 6to5 </script> </body> </html> Just do not forget that if you do it in a commercial code, then I strongly recommended to investigate absolutely all possible nuances .
What about third-party code?
Theoretically, if you polyfilled or polyfilled + precompiled the code to use the new JavaScript features in the ES3 environment, you can safely use third-party tools that work only in ES5 + environments, right? Not!
Practically the only way to safely use a third-party tool in an ES3 environment is to directly support your specific polyfill / compiler at the third-party code level. Otherwise, the premise from the first paragraph of this section remains very dumb and temporary. Remember, all this washing down of new opportunities in old environments is connected with one or another reefs, complex tricks and personal opinions. You should not expect a third-party developer to deal with such details, unless you personally saw that these developers are precisely oriented towards your environment. If you do not quite understand me, just note that third-party developers are unlikely to test polyfills and compiled output. As a rule, if ES5 + environment is required for parsing third-party code, then this means the real ES5 + environment.
Source: https://habr.com/ru/post/265223/
All Articles