WebAssembly Expired: Thoughts on JavaScript for Large Projects

At Auth0 – Most of our software is developed using Javascript. We use the language heavily on both front-end and back-end.

In this article ， we will explore the usefulness of Javascript as a universal language and take a brief look at Javascript development from concept to today. I’ll also interview some senior Auth0 developers on the rise and fall of using Javascript at scale and ultimately learn how WebAssembly has the potential to complete the picture and transform the language into a full-fledged development platform.

Javascript as a universal language

For today’s young developers, it seemed less clear in the past whether Javascript could be considered For a universal language – I think today we can answer this question with a definite ‘yes’. But Javascript is not exactly young：It was born in 1995，It is more than 20 years ago！

In more than 15 years，Javascript has It doesn’t have much traction outside of the web – it’s mostly used for front-end development. Many developers think of Javascript as nothing more than a necessary tool to achieve the interactive and responsive website of their dreams. There is no doubt that ‘even today’ Javascript does not have a portable module system in all common browsers’ even though import/export statements are part of the latest specification’. So ，in a sense，Javascript development evolved slowly as more developers found ways to expand its usage.

Some would say ，Just because you can do something doesn’t mean you should do it. When it comes to programming languages ​​- I think that’s a bit harsh. As developers – we tend to acquire certain tastes and styles. Some developers prefer classic programming languages ​​- while some developers fall in love with functional paradigms – while others prefer languages ​​that fit like a glove for mid-level or kitchen use. Who can say that Javascript, even in its past form, is not suitable for them?

Looking at the progress of Javascript over the years

Javascript started its life as the glue language of the Web. The creators of Netscape Navigator, the major web browser of the 1990s, believed that a language that designers and part-time programmers could use would make the web more dynamic. So in 1995，they appointed Brendan Eich to the board of directors. Eich’s mission was to create a Scheme-like language for browsers. If you’re not familiar with Scheme it’s a very simple language from the Lisp family. As with all Lisps “Scheme has very little syntax” so it’s easy to get started.

But，things didn’t go so smoothly. At the same time, Sun Microsystems has been promoting the integration of Java into Web browsers. Competition from Microsoft and its own technology doesn’t help either. So Javascript had to be developed in a hurry. And the rise of Java led Netscape to hope that their new language would complement it.

Eich was forced to come up with a prototype as quickly as possible. Some claim it was completed within weeks. The result is a dynamic language – whose syntax is similar to Java – but whose philosophy is very different. First of all – the object model of this new language is completely different from the Simula-derived Java object model. The initial prototype of the language was called Mocha which later became known as LiveScript.

For marketing reasons – LiveScript was quickly renamed to Javascript upon release. Java is on the rise – the name “Java” may spark more interest in the language.

This initial version was the first version of Javascript ， and it provided a surprising number of versions of what is known today as Javascript. In particular the “object model” based on prototypes and many functional aspects of the language “the semantics of closures” and the asynchronous nature of the API are set in stone. Unfortunately，its hasty development resulted in many quirks.

This version, while powerful in many ways, lacks significant features that would be useful when developing larger systems. An exception is an example.

The next few versions of Javascript will focus on making it widely available. The first step towards achieving this goal is to make it a standard. So ，standardization work started with ECMA，and later through ISO. ECMAScript was the name adopted after the standardization – very similar to the first version of Javascript included in Netscape Navigator. It wasn’t until ECMAScript 3 or Javascript 1.5 in 1999 that most of the Javascript we know and use today was complete. This version includes exception handling & # ，Objects etc）.

After that，Javascript entered a dark period. Competing groups have different ideas about Javascript development. Some people advocate using advanced features ，such as modules&#Script is a perfectly effective tool for many applications. Its increasingly widespread use on large systems is a testament to this – but it would be unwise to assume that it is the right tool for every situation.

WebAssembly has the potential to change all of this. Imagine it was possible to select a proven library for a new project within a company. Do you have an internal algorithm library implemented in C – no problem – compile it to WASM and load it into your application. Then develop any part of Javascript that makes sense. This is the kind of power that the web has been missing for years – and is finally just around the corner. Not just limited to the front end. It is expected that Node.js will also allow loading of WASM modules. In a sense, WebAssembly is a variant of the Javascript virtual machine from a language-centric to a general-purpose VM.

Since the release of the .NET platform in 2002, general-purpose virtual machines have soared. For example, Java has become a platform for new and existing languages. Scala and Clojure are perhaps the biggest representatives of this trend. The development of a completely new platform was based on the benefits of having a proven set of tools combined with the right language for the problem. And Javascript has become a rich platform.

The last few months have been exciting in WebAssembly ：Binaryen， A new compiler infrastructure that generates WASM files has started working on ；Firefox，Chrome and Edge has a working WebAssembly implementation behind the experimental flag – specs and design file sizes have increased. You can even try out the fully functional, runnable demo of ASM.js fallback with Unity examples. WebAssembly is just around the corner – but it’s still not ready.

At the same time large applications are being developed ，out of a need for Javascript or a lack of flexibility， The larger the application, the greater the chance of hitting the limits of large integer math, SIMD, threading, etc. WebAssembly is the missing addition to the Javascript ecosystem for years.

Conclusion

Javascript is the right tool for many applications. Features & #xff0c; Syntax familiarity & #xff0c; Asynchronous features & #xff0c; A large number of libraries and a strong community make it one of the best development platforms out there.

But the lack of flexibility when integrating with other solutions forces Javascript into inappropriate places. If all you have is a hammer then everything looks like a nail.

WebAssembly will completely change this situation – turning Javascript into a full-fledged development platform. WebAssembly is the last thing Javascript needs – and it’s not coming anytime soon.

From: https://www.sitepoint.com/webassembly-is-overdue-Javascript-for-large-projects/