Development Mode/Production Mode

# Brandon Benvie (13 years ago)

Forgive me if this has been discussed before but I read back as much as I could and couldn't find a reference. With all the discussion that has happened in the past about various modes, ES6 strict opt-in, etc. there never seems to be mention of the concept of an optional especially strict mode specifically designed for development. The premise is this: when I developer something I want as many early errors as possible and nothing hidden away behind some abstraction, so it can be fixed. When something goes live it just needs to work, or gracefully fail, hopefully landing in error handlers that were provided, while sending home debug information. All of the discussion I've seen doesn't seen to be from this kind of angle, more of all or nothing it seems.

There isn't some sort of mode toggle under discussions for ES6 that is specifically anticipated as a dev/production toggle, is there?

# Wes Garland (13 years ago)

In a similar vein, I would personally like to have zero-cost-when-not-debugging assert() statements, and am hopeful that statically-linked modules might lead the way.

We currently have LOW cost assert() statements, but these are still not suitable for hot loops. We can turn them into zero-cost with some pre-processing, but to actually guarantee that the program is the same with and without the asserts (ignoring side effects of the argument) means that the pre-processor needs to be much trickier than a simple sed statement. Especially given ASI.

As a data point, we compile all our code through Mozilla's SpiderMonkey engine with JSOPTION_STRICT, which pre-dates ES5 strict mode, during our build phase. It catches a few things for us that would otherwise cause a bit of head-scratching, like functions that don't always return value.

# David Bruant (13 years ago)

Le 01/04/2012 13:38, Wes Garland a écrit :

In a similar vein, I would personally like to have zero-cost-when-not-debugging assert() statements, and am hopeful that statically-linked modules might lead the way.

It seems to me that what you're asking for is macros, isn't it? I read hints here and there that it's a very hard problem that is being worked on for a later ES version.

# John J Barton (13 years ago)

On Tue, Apr 3, 2012 at 7:03 AM, David Bruant <bruant.d at gmail.com> wrote:

Le 01/04/2012 13:38, Wes Garland a écrit :

In a similar vein, I would personally like to have

zero-cost-when-not-debugging assert() statements, and am hopeful that statically-linked modules might lead the way.

It seems to me that what you're asking for is macros, isn't it? I read hints here and there that it's a very hard problem that is being worked on for a later ES version.

Since most JS is compiled in the run time, macros are not zero cost.

Since most JS runs in a sophisticated JIT capable of dead code elimination, const debug = false; or similar solutions should be able to make the run-time overhead for assert() insignificant. If you are after the last 0.1% a compressor should be able to accomplish this as well.

jjb

# David Bruant (13 years ago)

Le 03/04/2012 17:12, John J Barton a écrit :

On Tue, Apr 3, 2012 at 7:03 AM, David Bruant <bruant.d at gmail.com <mailto:bruant.d at gmail.com>> wrote:

Le 01/04/2012 13:38, Wes Garland a écrit :

    In a similar vein, I would personally like to have
    zero-cost-when-not-debugging assert() statements, and am
    hopeful that statically-linked modules might lead the way.

It seems to me that what you're asking for is macros, isn't it?
I read hints here and there that it's a very hard problem that is
being worked on for a later ES version.

Since most JS is compiled in the run time, macros are not zero cost.

Wes mentionned: "As a data point, we compile all our code through Mozilla's SpiderMonkey engine with JSOPTION_STRICT, which pre-dates ES5 strict mode, during our build phase."

It seems to me that it would be equivalent work to remove macros with such a compilation phase, making the macro cost effectively zero in run-time phase.

Since most JS runs in a sophisticated JIT capable of dead code elimination, const debug = false;

Macros would probably also be less intrusive than a top-scope variable, but I may be wrong on this part.