eval () предоставляет доступ к компилятору JavaScript, что в конечном итоге позволяет выполнить код позже. Аргументы, передаваемые функции, передаются компилятору JavaScript, после чего код выполняется.

Разработчики спорят о безопасности eval () . Он менее безопасен, но если вы абсолютно уверены, что ваш ввод дезинфицирован перед его передачей, то это не должно быть проблемой.

Кроме того, результаты eval () обычно работают медленнее, потому что код еще не скомпилирован и не кэширован. Очевидно, что использование этой функции приведет к падению производительности.

Это ' s также трудно отлаживать код, который возникает в результате использования eval () , потому что практически отсутствует контекстная информация (подумайте о номерах строк) о коде, который в конечном итоге выполняется.

С точки зрения веб-разработка, одно из наиболее популярных в настоящее время применений eval () - десериализация строки JSON обычно в контексте приложений Ajax; однако это не означает, что других применений не так много.

You might want to check this article, below is a direct quote from the page which sums up the power of eval.

The JavaScript EVAL command can be very powerful when using dynamic content in Web-based applications. EVAL can reduce code and eases interaction with data that is unknown во время загрузки, но есть недостатки принять во внимание.

Настоящая сила этой команды - ее умение работать с данными, которые не известно во время загрузки - например, данные, введенные пользователем. Как я уже упоминалось, EVAL принимает любую строку, вы предоставляете и выполняете его возврат результат, если таковой имеется. Вы можно использовать это для выполнения JavaScript где то, что вас просят execute не известно во время загрузки. За пример, если у нас есть расчет сценарий, который принимает приведенное уравнение пользователем и возвращает результат, вы можно использовать EVAL для выполнения calculation.

Недавно я экспериментировал с командой eval () , пытаясь придумать новое соглашение для нового проекта.

Я хотел вот что: я понравилась идея иметь частные , публичные и привилегированные методы, аля. Статья Дуга Крокфорда , но я хотел иметь возможность предоставлять общедоступные методы / переменные вверху моих классов, а не внизу, как обычно.

Рассмотрим это:

var Singleton = function() {
    // Private
    function _one() {
        // code...
    }

    function _two() {
        // code...
    }

    // Public
    return {
        one: _one,
        two: _two
    };
}();

С тремя ] eval () (две вложены в основной). Мне удалось получить такой синтаксис:

var Singleton = function() {
    // Public
    var $interface = {
        one: $forward,
        two: $forward
    };

    // Private
    function _one() {
        // code...
    }

    function _two() {
        // code...
    }

    // This does the magic
    return eval($init);
}('Singleton');

И вопреки всему и здравому смыслу он действительно работал. (Обратите внимание, что мне также нужен способ отладки моих пространств имен, поэтому вы можете видеть строку, переданную синглтону. $ init тоже позаботился об этом.)

В любом случае,

I don't think it's so much bad to use it as dangerous. People say don't use eval because it opens loopholes for abuse. It's OK to use it if your input is safe. It is used in Doug Crockford's JSON parser, for example, after the input has been checked using a regular expression to make sure there is no "dangerous" content.

The other reason people tell you not to use it is that if you use eval too much, people will start calling you Eval Knievel.