Is Strict mode enough for JavaScript? The Chrome V8 team is proposing an extension to Strict mode to be called Strong mode which allows bigger changes in the language than are possible with the requirement of backward compatibility. 

The V8 team cites two reasons for wanting to further restrict JavaScript's flexibility: 

Performance Optimising JavaScript is hard

Usability JavaScript comes with many surprises and complex implicit behaviours

The performance issues seem to targeting Mozilla's asm.js and the usability has typed variations of JavaScript like TypeScript in its sights.

Rather than defining a subset that is more efficient, like asm.js, or a superset that can be compiled to JavaScript, like TypeScript, Google is suggesting a new "mode" - Strong Mode. It sounds impressive.

Interestingly, Strong mode is claimed to be a true subset of JavaScript and any program that runs correctly with Strong mode turned on should run under unrestricted JavaScript. Strong mode also includes Strict mode. 

Essentially, Strong mode imposes a set of restrictions on JavaScript aimed to make it more robust and easier to optimize. Many things that are legal in permissive JavaScript will cause an error to be flagged.

The list of features that are removed is long but the following points give you some idea of how Strong mode behaves:

• you can no longer delete properties - using delete is a syntax error
  
  
• arrays behave more like conventional arrays - no holes, you can't access an element beyond the end of the array, no non-index properties and arrays are fixed length
  
  
• functions have to be called with all parameters used
  
  
• function declarations are immutable bindings
  
  
• eval is disallowed and using eval is a syntax error
  
  
• a type error is thrown if the operands to any numeric operator are not numbers

You can see that the intention is to remove anything that might be confusing. 

If Strong mode is a tidying up of JavaScript then the second proposal is more radical. The V8 team is planning to implement SoundScript - a typed version of JavaScript based on TypeScript.

If we have TypeScript why do we need SoundScript?

The V8 team argues that we need the optional typing built into the VM. This will allow types to be used in the interactive development environment and the VM can use types to implement optimizations and runtime type checks.  As TypeScript is compiled to JavaScript it cannot achieve any of of these aims. SoundScript makes Strong mode possible and more effective - the two are seen as fitting together and making each other better. 

So are these good ideas?

Yes and no. 

First this is just a Google proposal and as such there is no guarantee that any other JavaScript engine will adopt Strong mode and SoundScript. 

There is an intention to get both incorporated into the next ECMAScript standard, but what reception this plan meets is to be seen. 

Most interesting is the following FAQ:

Q: How does SoundScript compare to asm.js?

A: They have different goals: asm.js is a low-level language designed to be a compilation target for other (mostly low-level) languages. SoundScript is a user-facing type system for direct use of JavaScript as a high-level language. Both are complementary, both are useful, and V8 is committed to both.

Despite this reassurance you can see Google's proposals as a counter-proposal to Mozilla's (and now Microsoft's) asm.js. 

Finally there is the doubt, even the V8 team admit that this is research, that JavaScript can be retrofitted with a type system implemented in the VM without introducing latencies caused by the JIT compilation. 

It might be simpler all round to leave JavaScript as it is and implement tools that make it possible to impose rules like those proposed in Strong mode and interactive type assignment. You don't always need to modify a language to provide improvements in the development environment. 

Comments

Make a Comment or View Existing Comments Using Disqus

or email your comment to: comments@i-programmer.info