74

The Future of JavaScript Will Be Less JavaScript – codeburst

 6 years ago
source link: https://codeburst.io/the-future-of-javascript-will-be-less-javascript-cea373eb57fd?gi=2f27f1032d9d
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.

The Future of JavaScript Will Be Less JavaScript

1*sjcDdQyTzVrb93AZ2HKbwg.jpeg

I can tell at least that in 3 years, JavaScript will gain more the status of a VM and lose the status of a language. Already today, not many people use raw JavaScript. You usually have some transpilation, at least e.g. Babel. In the future, Web Assembly will enable more innovation in that regards, and existing transpiling languages like Elm, TypeScript, PureScript will continue to improve.

The above is a comment by André Staltz on his Hashnode AMA. I’ve noticed similar comments made by other developers in 2017, ranging from those working on web frameworks to those working on new languages.

I think the status of a VM part of this comment was summed up nicely by Tom Dale in his article titled Compilers are the New Frameworks.

My current “investment thesis” is that what we call web frameworks are transforming from runtime libraries into optimizing compilers. When it comes to eking performance out of hand-authored JavaScript and accompanying runtime libraries, we’ve reached the point of diminishing returns.

JavaScript Today

Even with new languages like Elm, Reason, PureScript, and ClojureScript, these still compile to JavaScript which runs in your browser. Firefox and Chrome have made great strides in improving the speed and efficiency of JavaScript in 2017, so it’s safe to say JavaScript itself isn’t going anywhere.

Years ago we had tools like UglifyJS and Closure Compiler to help make the JavaScript we deployed run and load faster in the browser. In the last few years we’ve made our applications faster and more efficient on the web with tools like Babel, React, Webpack, Polymer, Redux, and dozens more that help you use next-generation JavaScript, bundle your assets, create and reuse components across your codebase, etc. We’ve developed techniques to bundle, load, parse, and run our JavaScript code faster and more efficiently as well.

Today and the Potential Future

But I do think that we will see less hand-written vanilla JavaScript being written and deployed by developers in the coming years — especially at companies where the applications they build are data-intensive and high-traffic. While we can optimize the hell out of our JavaScript code, Tom Dale argues that we should look at other high-performing native systems:

In the same way that a compiled Android binary bears little resemblance to the original Java source code, the assets we serve to users will be the aggressively-optimized output of sophisticated build tools.

Even today developers are writing JavaScript code that would look very strange to a developer 7 years ago. But this is good — it means developers are improving and building new tools that are keeping up with the evolution of browsers and requirements of large applications. Browsers are becoming faster and constantly improving to make the web better, e.g. concurrent JavaScript, parallelism in Firefox, and a faster DOM.

I think in the coming years we’ll see less vanilla JavaScript being written, and more compilation into JavaScript from different sources for the web platform. You can see some examples of this today:

  • WebAssembly in the Browser being used for things like encryption, audio mixing, game development, and more.
  • WebAssembly at PSPDFKit: “to completely avoid a server component that can read the PDF, we worked hard to compile our 500,000 LOC C++ core to WebAssembly and asm.js [to run in the browser].”
  • Svelte Framework: “rather than interpreting your application code at run time, your app is converted into ideal JavaScript at build time.”
  • cssnext: “transforms new CSS specs into more compatible CSS so you don’t need to wait for browser support.”
  • Jay Phelps on the current state of WASM: “there’s a very active and quickly moving proposal for exposing a built-in Garbage Collector, which is going to be one of the most important building blocks to have high-level languages target wasm and interop with JS objects and the DOM APIs.”
  • As mentioned above, languages that compile to JavaScript in order to optimize your code and make development easier, faster, etc. This includes new languages like Elm but also something that’s very popular in 2017, namely, React + bundling that produces optimal, minified JavaScript code from modularized code.

Conclusion

However JavaScript development ends up looking years from now, this doesn’t mean you shouldn’t learn about the JavaScript language and all its intricacies. All developers working on the web platform should understand how it works.

Finally, here’s someone very happy with the web. Some of you (including me) may need it with everyone always finding new ways to complain about the web and JavaScript as if every other platform is perfect.


About Joyk


Aggregate valuable and interesting links.
Joyk means Joy of geeK