Is javascript dying or reborn?
I apologize in advance for some revolutions in translation. I will be glad to hear sensible criticism and amendments, better in PM. Thank. - per.
Startups have a lot in common with JavaScript. When you first start, you need to be dynamic. You must be flexible. You should be able to instantly release a prototype that just works, and you need to be able to quickly and cheaply change it without recompiling your code. JavaScript appeared when the war between browsers was just beginning, and it crushed Java and Flash for the same reasons that startups crush markets and force out recognized players: speed and flexibility.
Today, JavaScript is no longer a startup, and not only startups use it. Companies of all sizes and levels of maturity make browser applications, and JavaScript is the language they use to do this. The claims that were once made to languages such as C / C ++ and Java are now being submitted to JavaScript, and these claims are related to the limitations of the language: performance and maintainability.
The latest generation of JavaScript engines has reached incredible heights of performance, but this is still not enough. Look at sites like YouTube and Hulu, or Facebook or EA gaming platforms. When you need to make a multimedia application, companies still turn to Flash performance. Providence Steve Jobs could have predicted the fate that eventually befall Flash, but we still have to work with it until JavaScript falls short in performance.
As soon as the amount of your code reaches hundreds of thousands of lines, and it is all written in such a dynamic language like JavaScript, the speed of development begins to suffer. If you make changes somewhere in one part of the code, there is no way to know that this will not lead to bugs elsewhere without starting the application. Testing can only aggravate the situation - lead to a large number of unforeseen expenses made in advance. The result is more bugs in the application or longer development cycles.
')
Someone has to do something with these limitations so that companies can innovate and make amazing web applications. Who is going to do it and how?
Prezi, LogMeIn and Ustream organized MLOC.js, a conference focused on how to improve JavaScript. Engineers from Google, Facebook, Mozilla, Groupon, and other companies working on serious technical issues gathered for three days in Budapest to discuss how they deal with the limitations of JavaScript. Their work will give confidence that JavaScript is not the only viable platform in the future, but the first one that will change our understanding of how to write applications on the web.
Here is my opinion: JavaScript is caught in an iron triangle created by him. We are all accustomed to the flexibility and freedom that it gives, and we do not want to give it up. At the same time, we want it to be lightning-fast, and it turns out that upon reaching a million lines of code, supporting such a flexible language becomes a problem. All three areas — flexibility, performance, and maintainability — are intertwined. When you achieve success in one area, one of the other two, or both, suffers.
This tells me that there is not one silver bullet that will solve these problems, but there may be many that will solve. JavaScript is a dynamic language that is excellent at pasting the web, and it is constant.
Business logic should work, and should work correctly. Static analysis in systems such as Dart or TypeScript is important to ensure that the most sensitive components of our application work — and will continue to work when our applications grow and evolve. We need more such tools for static analysis. Nevertheless, if you look at the browser market, it is unlikely that we will see widespread native support for these technologies in the near future.
It turns out that native support for new languages is not always required. Alon Zakai from Mozilla spoke about ASM.js, a subset of JavaScript that runs very quickly on modern browsers without modification. When speed matters, we should write to ASM.js. Or, even better, we can write our C code and have a compiler that generates ASM.js for us. If we do not talk about performance, we can apply this technique to other languages and other uses. The developers have almost done it, and all their efforts are listed on atl.js.
One of the best ways to make your code more supported is to write less code. Libraries like bacon.js or the Elm language briefly express the complex data dependencies in your application and unload the job of keeping the data current in the library. The result is less code for support and higher quality applications.
JavaScript does not go anywhere, but undergoes transformation. Developers create language variations and impressive libraries for better handling of specific use cases, including performance. In addition, there is progress in the creation of tools and static analysis. All of these trends affect how we write web applications. The MLOC.js conference clarified a lot.
For big players, those who use JavaScript every day, only one question remains: what will you do to make JavaScript become the most flexible, productive and scalable language that we have ever known?
Startups have a lot in common with JavaScript. When you first start, you need to be dynamic. You must be flexible. You should be able to instantly release a prototype that just works, and you need to be able to quickly and cheaply change it without recompiling your code. JavaScript appeared when the war between browsers was just beginning, and it crushed Java and Flash for the same reasons that startups crush markets and force out recognized players: speed and flexibility.
Today, JavaScript is no longer a startup, and not only startups use it. Companies of all sizes and levels of maturity make browser applications, and JavaScript is the language they use to do this. The claims that were once made to languages such as C / C ++ and Java are now being submitted to JavaScript, and these claims are related to the limitations of the language: performance and maintainability.
The latest generation of JavaScript engines has reached incredible heights of performance, but this is still not enough. Look at sites like YouTube and Hulu, or Facebook or EA gaming platforms. When you need to make a multimedia application, companies still turn to Flash performance. Providence Steve Jobs could have predicted the fate that eventually befall Flash, but we still have to work with it until JavaScript falls short in performance.
As soon as the amount of your code reaches hundreds of thousands of lines, and it is all written in such a dynamic language like JavaScript, the speed of development begins to suffer. If you make changes somewhere in one part of the code, there is no way to know that this will not lead to bugs elsewhere without starting the application. Testing can only aggravate the situation - lead to a large number of unforeseen expenses made in advance. The result is more bugs in the application or longer development cycles.
')
Someone has to do something with these limitations so that companies can innovate and make amazing web applications. Who is going to do it and how?
Prezi, LogMeIn and Ustream organized MLOC.js, a conference focused on how to improve JavaScript. Engineers from Google, Facebook, Mozilla, Groupon, and other companies working on serious technical issues gathered for three days in Budapest to discuss how they deal with the limitations of JavaScript. Their work will give confidence that JavaScript is not the only viable platform in the future, but the first one that will change our understanding of how to write applications on the web.
Here is my opinion: JavaScript is caught in an iron triangle created by him. We are all accustomed to the flexibility and freedom that it gives, and we do not want to give it up. At the same time, we want it to be lightning-fast, and it turns out that upon reaching a million lines of code, supporting such a flexible language becomes a problem. All three areas — flexibility, performance, and maintainability — are intertwined. When you achieve success in one area, one of the other two, or both, suffers.
This tells me that there is not one silver bullet that will solve these problems, but there may be many that will solve. JavaScript is a dynamic language that is excellent at pasting the web, and it is constant.
Business logic should work, and should work correctly. Static analysis in systems such as Dart or TypeScript is important to ensure that the most sensitive components of our application work — and will continue to work when our applications grow and evolve. We need more such tools for static analysis. Nevertheless, if you look at the browser market, it is unlikely that we will see widespread native support for these technologies in the near future.
It turns out that native support for new languages is not always required. Alon Zakai from Mozilla spoke about ASM.js, a subset of JavaScript that runs very quickly on modern browsers without modification. When speed matters, we should write to ASM.js. Or, even better, we can write our C code and have a compiler that generates ASM.js for us. If we do not talk about performance, we can apply this technique to other languages and other uses. The developers have almost done it, and all their efforts are listed on atl.js.
One of the best ways to make your code more supported is to write less code. Libraries like bacon.js or the Elm language briefly express the complex data dependencies in your application and unload the job of keeping the data current in the library. The result is less code for support and higher quality applications.
JavaScript does not go anywhere, but undergoes transformation. Developers create language variations and impressive libraries for better handling of specific use cases, including performance. In addition, there is progress in the creation of tools and static analysis. All of these trends affect how we write web applications. The MLOC.js conference clarified a lot.
For big players, those who use JavaScript every day, only one question remains: what will you do to make JavaScript become the most flexible, productive and scalable language that we have ever known?
Source: https://habr.com/ru/post/173915/
All Articles