Saya sedang menulis beberapa kode JavaScript untuk mem-parsing fungsi yang dimasukkan pengguna (untuk fungsionalitas seperti spreadsheet). Setelah mem-parsing rumus, saya bisa mengubahnya menjadi JavaScript dan menjalankannya eval()untuk menghasilkan hasilnya.

Namun, saya selalu menghindari menggunakan eval()jika saya bisa menghindarinya karena itu jahat (dan, benar atau salah, saya selalu berpikir itu bahkan lebih jahat dalam JavaScript, karena kode yang akan dievaluasi mungkin diubah oleh pengguna ).

Jadi, kapan boleh menggunakannya?

Saya ingin meluangkan waktu untuk membahas alasan pertanyaan Anda - bahwa eval () adalah " jahat ". Kata " jahat ", seperti yang digunakan oleh orang-orang bahasa pemrograman, biasanya berarti "berbahaya", atau lebih tepatnya "dapat menyebabkan banyak kerusakan dengan perintah yang tampak sederhana". Jadi, kapan boleh menggunakan sesuatu yang berbahaya? Ketika Anda tahu apa bahayanya, dan kapan Anda mengambil tindakan pencegahan yang sesuai.

Untuk intinya, mari kita lihat bahaya dalam penggunaan eval (). Mungkin ada banyak bahaya kecil yang tersembunyi seperti halnya yang lain, tetapi dua risiko besar - alasan mengapa eval () dianggap jahat - adalah kinerja dan injeksi kode.

• Performance - eval () menjalankan interpreter / compiler. Jika kode Anda dikompilasi, maka ini adalah hit besar, karena Anda perlu memanggil kompiler yang mungkin berat di tengah run-time. Namun, sebagian besar JavaScript masih merupakan bahasa yang diartikan, yang berarti bahwa memanggil eval () bukan hit kinerja besar dalam kasus umum (tetapi lihat komentar spesifik saya di bawah).
• Injeksi kode - eval () berpotensi menjalankan serangkaian kode di bawah hak yang lebih tinggi. Sebagai contoh, sebuah program yang berjalan sebagai administrator / root tidak akan pernah ingin mengevaluasi () input pengguna, karena input tersebut berpotensi menjadi "rm -rf / etc / file-penting" atau lebih buruk. Sekali lagi, JavaScript di peramban tidak memiliki masalah itu, karena program tetap berjalan di akun milik pengguna. JavaScript sisi server dapat mengalami masalah itu.

Aktif ke kasus spesifik Anda. Dari apa yang saya mengerti, Anda menghasilkan string sendiri, jadi dengan asumsi Anda berhati-hati untuk tidak membiarkan string seperti "rm -rf sesuatu-penting" dihasilkan, tidak ada risiko injeksi kode (tapi harap diingat, itu sangat sangat sulit untuk memastikan ini dalam kasus umum). Juga, jika Anda menjalankan di browser maka injeksi kode adalah risiko yang cukup kecil, saya percaya.

Adapun kinerja, Anda harus mempertimbangkan bahwa terhadap kemudahan pengkodean. Menurut pendapat saya, jika Anda menguraikan rumus, Anda sebaiknya menghitung hasilnya selama penguraian daripada menjalankan pengurai lain (yang ada di dalam eval ()). Tetapi mungkin lebih mudah untuk menggunakan kode eval (), dan kinerja mungkin tidak akan terlihat. Sepertinya eval () dalam hal ini tidak lebih jahat daripada fungsi lain yang mungkin bisa menghemat waktu Anda.

eval()itu tidak jahat. Atau, jika benar, itu jahat dengan cara yang sama bahwa refleksi, file / jaringan I / O, threading, dan IPC adalah "jahat" dalam bahasa lain.

Jika, untuk tujuan Anda , eval()lebih cepat dari interpretasi manual, atau membuat kode Anda lebih sederhana, atau lebih jelas ... maka Anda harus menggunakannya. Jika tidak, maka Anda seharusnya tidak. Sederhana seperti itu.

Saat Anda mempercayai sumbernya.

Dalam kasus JSON, lebih atau kurang sulit untuk merusak sumbernya, karena berasal dari server web yang Anda kontrol. Selama JSON itu sendiri tidak mengandung data yang diunggah pengguna, tidak ada kelemahan utama untuk menggunakan eval.

Dalam semua kasus lain saya akan berusaha keras untuk memastikan data yang diberikan pengguna sesuai dengan aturan saya sebelum mengumpankannya ke eval ().

Mari kita dapatkan orang-orang nyata:

1. Setiap peramban utama sekarang memiliki konsol bawaan yang dapat digunakan peretas Anda dengan berlimpah untuk menjalankan fungsi apa pun dengan nilai apa pun - mengapa mereka repot-repot menggunakan pernyataan yang benar - bahkan jika mereka bisa?

2. Jika diperlukan 0,2 detik untuk mengkompilasi 2000 baris JavaScript, berapakah penurunan kinerja saya jika saya mengevaluasi empat baris JSON?

Bahkan penjelasan Crockford untuk 'eval is evil' lemah.

eval is Evil, Fungsi eval adalah fitur yang paling banyak disalahgunakan dari JavaScript. Hindari itu

Seperti yang dikatakan Crockford sendiri, "Pernyataan seperti ini cenderung menghasilkan neurosis irasional. Jangan membelinya."

Memahami eval dan mengetahui kapan itu mungkin berguna jauh lebih penting. Misalnya, eval adalah alat yang masuk akal untuk mengevaluasi respons server yang dihasilkan oleh perangkat lunak Anda.

BTW: Prototype.js memanggil eval secara langsung lima kali (termasuk di evalJSON () dan evalResponse ()). jQuery menggunakannya di parseJSON (via Function constructor).

Saya cenderung mengikuti saran Crockford untuk eval(), dan menghindarinya sama sekali. Bahkan cara-cara yang tampaknya membutuhkannya tidak. Misalnya, setTimeout()memungkinkan Anda untuk melewati fungsi daripada eval.

setTimeout(function() {
  alert('hi');
}, 1000);

Bahkan jika itu sumber yang tepercaya , saya tidak menggunakannya, karena kode yang dikembalikan oleh JSON mungkin kacau, yang paling baik bisa melakukan sesuatu yang tidak beres, paling buruk, mengekspos sesuatu yang buruk.

Saya melihat orang menganjurkan untuk tidak menggunakan eval, karena itu jahat , tapi saya melihat orang yang sama menggunakan Function dan setTimeout secara dinamis, jadi mereka menggunakan eval di bawah tenda : D

BTW, jika kotak pasir Anda tidak cukup yakin (misalnya, jika Anda bekerja di situs yang memungkinkan injeksi kode) eval adalah yang terakhir dari masalah Anda. Aturan dasar keamanan adalah bahwa semua input adalah jahat, tetapi dalam kasus JavaScript bahkan JavaScript itu sendiri bisa jahat, karena dalam JavaScript Anda dapat menimpa fungsi apa pun dan Anda tidak bisa memastikan Anda menggunakan yang asli, jadi, jika kode berbahaya dimulai sebelum Anda, Anda tidak dapat mempercayai fungsi bawaan JavaScript apa pun: D

Sekarang epilog untuk posting ini adalah:

Jika Anda BENAR - BENAR membutuhkannya (80% dari waktu eval TIDAK diperlukan) dan Anda yakin dengan apa yang Anda lakukan, cukup gunakan eval (atau Fungsi yang lebih baik;)), penutupan dan OOP mencakup 80/90% dari kasus di mana eval dapat diganti menggunakan jenis logika lain, sisanya adalah kode yang dihasilkan secara dinamis (misalnya, jika Anda sedang menulis penerjemah) dan seperti yang Anda katakan mengevaluasi JSON (di sini Anda dapat menggunakan evaluasi aman Crockford;))

Eval adalah komplementer untuk kompilasi yang digunakan dalam templating kode. Dengan template saya maksudkan bahwa Anda menulis generator template yang disederhanakan yang menghasilkan kode template yang berguna yang meningkatkan kecepatan pengembangan.

Saya telah menulis sebuah kerangka kerja, di mana pengembang tidak menggunakan EVAL, tetapi mereka menggunakan kerangka kerja kami dan pada gilirannya kerangka kerja itu harus menggunakan EVAL untuk menghasilkan template.

Kinerja EVAL dapat ditingkatkan dengan menggunakan metode berikut; alih-alih menjalankan skrip, Anda harus mengembalikan fungsi.

var a = eval("3 + 5");

Itu harus diatur sebagai

var f = eval("(function(a,b) { return a + b; })");

var a = f(3,5);

Caching f pasti akan meningkatkan kecepatan.

Chrome juga memungkinkan debugging fungsi-fungsi tersebut dengan sangat mudah.

Mengenai keamanan, menggunakan eval atau tidak tidak akan membuat perbedaan,

1. Pertama-tama, browser memanggil seluruh skrip di kotak pasir.
2. Kode apa pun yang jahat dalam EVAL, adalah jahat di peramban itu sendiri. Penyerang atau siapa pun dapat dengan mudah menyuntikkan node script di DOM dan melakukan apa saja jika ia dapat mengevaluasi apa pun. Tidak menggunakan EVAL tidak akan membuat perbedaan.
3. Sebagian besar keamanan sisi server buruk yang berbahaya. Validasi cookie yang buruk atau implementasi ACL yang buruk di server menyebabkan sebagian besar serangan.
4. Kerentanan Java baru-baru ini, dll. Ada di dalam kode asli Java. JavaScript telah dan dirancang untuk berjalan di kotak pasir, sedangkan applet dirancang untuk berjalan di luar kotak pasir dengan sertifikat, dll. Yang mengarah pada kerentanan dan banyak hal lainnya.
5. Menulis kode untuk meniru peramban tidaklah sulit. Yang harus Anda lakukan adalah membuat permintaan HTTP ke server dengan string agen pengguna favorit Anda. Lagi pula, semua alat pengujian membuat tiruan browser; jika seorang penyerang ingin melukaimu, EVAL adalah pilihan terakhir mereka. Mereka memiliki banyak cara lain untuk menangani keamanan sisi server Anda.
6. Browser DOM tidak memiliki akses ke file dan bukan nama pengguna. Bahkan tidak ada pada mesin yang eval dapat memberikan akses.

Jika keamanan sisi server Anda cukup kuat bagi siapa pun untuk menyerang dari mana saja, Anda tidak perlu khawatir tentang EVAL. Seperti yang saya sebutkan, jika EVAL tidak ada, penyerang memiliki banyak alat untuk meretas ke server Anda terlepas dari kemampuan EVAL browser Anda.

Eval hanya baik untuk menghasilkan beberapa template untuk melakukan pemrosesan string yang kompleks berdasarkan pada sesuatu yang tidak digunakan sebelumnya. Sebagai contoh, saya lebih suka

"FirstName + ' ' + LastName"

Sebagai lawan

"LastName + ' ' + FirstName"

Seperti nama tampilan saya, yang bisa berasal dari basis data dan yang tidak hardcoded.

Ketika debugging di Chrome (v28.0.1500.72), saya menemukan bahwa variabel tidak terikat dengan penutupan jika mereka tidak digunakan dalam fungsi bersarang yang menghasilkan penutupan. Saya kira, itu optimasi mesin JavaScript.

TETAPI : ketika eval()digunakan di dalam fungsi yang menyebabkan penutupan, SEMUA variabel fungsi luar terikat ke penutupan, bahkan jika mereka tidak digunakan sama sekali. Jika seseorang memiliki waktu untuk menguji apakah kebocoran memori dapat dihasilkan oleh itu, silakan beri saya komentar di bawah ini.

Ini kode pengujian saya:

(function () {
    var eval = function (arg) {
    };

    function evalTest() {
        var used = "used";
        var unused = "not used";

        (function () {
            used.toString();   // Variable "unused" is visible in debugger
            eval("1");
        })();
    }

    evalTest();
})();

(function () {
    var eval = function (arg) {
    };

    function evalTest() {
        var used = "used";
        var unused = "not used";

        (function () {
            used.toString();   // Variable "unused" is NOT visible in debugger
            var noval = eval;
            noval("1");
        })();
    }

    evalTest();
})();

(function () {
    var noval = function (arg) {
    };

    function evalTest() {
        var used = "used";
        var unused = "not used";

        (function () {
            used.toString();    // Variable "unused" is NOT visible in debugger
            noval("1");
        })();
    }

    evalTest();
})();

Yang ingin saya tunjukkan di sini adalah, bahwa eval () tidak harus merujuk ke eval()fungsi asli . Itu semua tergantung pada nama fungsinya . Jadi ketika memanggil asli eval()dengan nama alias (katakan var noval = eval;dan kemudian dalam fungsi batin noval(expression);) maka evaluasi expressionmungkin gagal ketika mengacu pada variabel yang harus menjadi bagian dari penutupan, tetapi sebenarnya tidak.

Microsoft menjelaskan mengapa eval () lambat di peramban mereka di Blog IE , Rekomendasi Kinerja JavaScript + IE Bagian 2: Inefisiensi Kode JavaScript .

Intinya

Jika Anda membuat atau membersihkan kode Anda eval, itu tidak pernah jahat .

Sedikit Lebih Detail

evalAdalah jahat jika berjalan di server menggunakan input yang dikirimkan oleh klien yang tidak dibuat oleh pengembang atau yang tidak dibersihkan oleh pengembang .

evaladalah tidak jahat jika berjalan pada klien, bahkan jika menggunakan input unsanitized dibuat oleh klien .

Jelas Anda harus selalu membersihkan input, karena memiliki kontrol atas apa yang dikonsumsi kode Anda.

Pemikiran

Klien dapat menjalankan kode arbitrer apa pun yang mereka inginkan, bahkan jika pengembang tidak mengkodekannya; Ini benar tidak hanya untuk apa yang disuarakan, tetapi panggilan untuk evaldirinya sendiri .

Satu-satunya contoh ketika Anda harus menggunakan eval () adalah ketika Anda perlu menjalankan JS dinamis dengan cepat. Saya berbicara tentang JS yang Anda unduh secara tidak sinkron dari server ...

... Dan 9 kali dari 10 Anda dapat dengan mudah menghindari melakukan itu dengan refactoring.

evaljarang pilihan yang tepat. Meskipun mungkin ada banyak contoh di mana Anda dapat mencapai apa yang perlu Anda capai dengan menggabungkan skrip bersama-sama dan menjalankannya dengan cepat, Anda biasanya memiliki teknik yang lebih kuat dan dapat dipelihara yang Anda inginkan: notasi asosiasi-array ( obj["prop"]sama dengan obj.prop) , penutupan, teknik berorientasi objek, teknik fungsional - gunakan saja.

Sejauh skrip klien berjalan, saya pikir masalah keamanan adalah titik diperdebatkan. Segala sesuatu yang dimuat ke dalam browser tunduk pada manipulasi dan harus diperlakukan seperti itu. Tidak ada risiko menggunakan pernyataan eval () ketika ada banyak cara yang lebih mudah untuk mengeksekusi kode JavaScript dan / atau memanipulasi objek di DOM, seperti bilah URL di browser Anda.

javascript:alert("hello");

Jika seseorang ingin memanipulasi DOM mereka, saya katakan berayun pergi. Keamanan untuk mencegah segala jenis serangan harus selalu menjadi tanggung jawab aplikasi server, titik.

Dari sudut pandang pragmatis, tidak ada manfaatnya menggunakan eval () dalam situasi di mana hal-hal dapat dilakukan sebaliknya. Namun, ada kasus khusus di mana eval HARUS digunakan. Ketika demikian, itu pasti bisa dilakukan tanpa risiko meledakkan halaman.

<html>
    <body>
        <textarea id="output"></textarea><br/>
        <input type="text" id="input" />
        <button id="button" onclick="execute()">eval</button>

        <script type="text/javascript">
            var execute = function(){
                var inputEl = document.getElementById('input');
                var toEval = inputEl.value;
                var outputEl = document.getElementById('output');
                var output = "";

                try {
                    output = eval(toEval);
                }
                catch(err){
                    for(var key in err){
                        output += key + ": " + err[key] + "\r\n";
                    }
                }
                outputEl.value = output;
            }
        </script>
    <body>
</html>

Di sisi server, eval berguna ketika berhadapan dengan skrip eksternal seperti sql atau influxdb atau mongo. Di mana validasi khusus saat runtime dapat dilakukan tanpa menggunakan kembali layanan Anda.

Misalnya layanan pencapaian dengan metadata berikut

{
  "568ff113-abcd-f123-84c5-871fe2007cf0": {
    "msg_enum": "quest/registration",
    "timely": "all_times",
    "scope": [
      "quest/daily-active"
    ],
    "query": "`SELECT COUNT(point) AS valid from \"${userId}/dump/quest/daily-active\" LIMIT 1`",
    "validator": "valid > 0",
    "reward_external": "ewallet",
    "reward_external_payload": "`{\"token\": \"${token}\", \"userId\": \"${userId}\", \"amountIn\": 1, \"conversionType\": \"quest/registration:silver\", \"exchangeProvider\":\"provider/achievement\",\"exchangeType\":\"payment/quest/registration\"}`"
  },
  "efdfb506-1234-abcd-9d4a-7d624c564332": {
    "msg_enum": "quest/daily-active",
    "timely": "daily",
    "scope": [
      "quest/daily-active"
    ],
    "query": "`SELECT COUNT(point) AS valid from \"${userId}/dump/quest/daily-active\" WHERE time >= '${today}' ${ENV.DAILY_OFFSET} LIMIT 1`",
    "validator": "valid > 0",
    "reward_external": "ewallet",
    "reward_external_payload": "`{\"token\": \"${token}\", \"userId\": \"${userId}\", \"amountIn\": 1, \"conversionType\": \"quest/daily-active:silver\", \"exchangeProvider\":\"provider/achievement\",\"exchangeType\":\"payment/quest/daily-active\"}`"
  }
}

Yang kemudian memungkinkan,

• Injeksi langsung objek / nilai melalui string literal dalam json, berguna untuk templating teks

• Dapat digunakan sebagai pembanding, misalkan kita membuat aturan bagaimana memvalidasi pencarian atau acara di CMS

Kontra dari ini:

• Dapat terjadi kesalahan dalam kode dan memecah hal-hal dalam layanan, jika tidak sepenuhnya diuji.

• Jika seorang hacker dapat menulis skrip di sistem Anda, maka Anda cukup banyak yang kacau.

• Salah satu cara untuk memvalidasi skrip Anda adalah menyimpan hash skrip Anda di tempat yang aman, sehingga Anda dapat memeriksanya sebelum berjalan.

Saya pikir setiap kasus eval dibenarkan jarang terjadi. Anda lebih mungkin menggunakannya berpikir bahwa itu dibenarkan daripada Anda menggunakannya ketika itu sebenarnya dibenarkan.

Masalah keamanan adalah yang paling terkenal. Tetapi juga perlu diperhatikan bahwa JavaScript menggunakan kompilasi JIT dan ini bekerja sangat buruk dengan eval. Eval agaknya seperti kotak hitam ke kompiler, dan JavaScript harus dapat memprediksi kode sebelumnya (sampai batas tertentu) agar dapat dengan aman dan benar menerapkan optimasi dan pelingkupan kinerja. Dalam beberapa kasus, dampak kinerja bahkan dapat memengaruhi kode lain di luar eval.

Jika Anda ingin tahu lebih banyak: https://github.com/getify/You-Dont-Know-JS/blob/master/scope%20%26%20closures/ch2.md#eval

Tidak apa-apa untuk menggunakannya jika Anda memiliki kontrol penuh atas kode yang diberikan ke evalfungsi.

Hanya selama pengujian, jika memungkinkan. Perhatikan juga bahwa eval () jauh lebih lambat daripada evaluator JSON dll. Khusus lainnya.

Tidak ada alasan untuk tidak menggunakan eval () selama Anda dapat memastikan bahwa sumber kode berasal dari Anda atau pengguna yang sebenarnya. Meskipun ia dapat memanipulasi apa yang dikirim ke fungsi eval (), itu bukan masalah keamanan, karena ia dapat memanipulasi kode sumber situs web dan karenanya dapat mengubah kode JavaScript itu sendiri.

Jadi ... kapan tidak menggunakan eval ()? Eval () seharusnya tidak digunakan ketika ada kemungkinan pihak ketiga dapat mengubahnya. Seperti mencegat koneksi antara klien dan server Anda (tetapi jika itu masalah, gunakan HTTPS). Anda tidak boleh eval () untuk kode parsing yang ditulis oleh orang lain seperti di forum.

Jika benar-benar dibutuhkan, eval bukanlah kejahatan. Tetapi 99,9% dari penggunaan eval yang saya temukan tidak diperlukan (tidak termasuk barang setTimeout).

Bagi saya kejahatan bukanlah kinerja atau bahkan masalah keamanan (yah, secara tidak langsung itu adalah keduanya). Semua penggunaan eval yang tidak perlu seperti itu menambah neraka pemeliharaan. Alat refactoring terlempar. Mencari kode itu sulit. Efek yang tidak diantisipasi dari evals itu sangat banyak.

Kapan eval () JavaScript tidak jahat?

Saya selalu berusaha untuk tidak menggunakan eval . Hampir selalu, solusi yang lebih bersih dan terawat tersedia. Eval tidak diperlukan bahkan untuk penguraian JSON . Eval menambah neraka pemeliharaan . Bukan tanpa alasan, itu disukai oleh master seperti Douglas Crockford.

Tapi saya menemukan satu contoh di mana itu harus digunakan:

Ketika Anda perlu menyampaikan ekspresi.

Sebagai contoh, saya memiliki fungsi yang membangun google.maps.ImageMapTypeobjek umum untuk saya, tetapi saya harus memberi tahu resepnya, bagaimana seharusnya membangun URL ubin dari parameter zoomdan coord:

my_func({
    name: "OSM",
    tileURLexpr: '"http://tile.openstreetmap.org/"+b+"/"+a.x+"/"+a.y+".png"',
    ...
});

function my_func(opts)
{
    return new google.maps.ImageMapType({
        getTileUrl: function (coord, zoom) {
            var b = zoom;
            var a = coord;
            return eval(opts.tileURLexpr);
        },
        ....
    });
}

Contoh saya menggunakan eval: import .

Bagaimana biasanya dilakukan.

var components = require('components');
var Button = components.Button;
var ComboBox = components.ComboBox;
var CheckBox = components.CheckBox;
...
// That quickly gets very boring

Tetapi dengan bantuan evaldan fungsi pembantu kecil itu mendapatkan tampilan yang jauh lebih baik:

var components = require('components');
eval(importable('components', 'Button', 'ComboBox', 'CheckBox', ...));

importable mungkin terlihat seperti (versi ini tidak mendukung impor anggota konkret).

function importable(path) {
    var name;
    var pkg = eval(path);
    var result = '\n';

    for (name in pkg) {
        result += 'if (name !== undefined) throw "import error: name already exists";\n'.replace(/name/g, name);
    }

    for (name in pkg) {
        result += 'var name = path.name;\n'.replace(/name/g, name).replace('path', path);
    }
    return result;
}

Eval tidak jahat, hanya disalahgunakan.

Jika Anda membuat kode yang masuk ke dalamnya atau bisa memercayainya, tidak apa-apa. Orang-orang terus berbicara tentang bagaimana input pengguna tidak masalah dengan eval. Yah semacam ~

Jika ada input pengguna yang masuk ke server, maka kembali ke klien, dan kode itu digunakan dalam eval tanpa disanitasi. Selamat, Anda telah membuka kotak pandora untuk mengirim data pengguna kepada siapa pun.

Tergantung di mana eval berada, banyak situs web menggunakan SPA, dan eval dapat membuatnya lebih mudah bagi pengguna untuk mengakses internal aplikasi yang kalau tidak pasti tidak mudah. Sekarang mereka dapat membuat ekstensi peramban palsu yang dapat merekam ke eval itu dan mencuri data lagi.

Hanya harus mencari tahu apa gunanya Anda menggunakan eval. Membuat kode tidak terlalu ideal ketika Anda bisa membuat metode untuk melakukan hal semacam itu, menggunakan objek, atau sejenisnya.

Sekarang contoh yang bagus untuk menggunakan eval. Server Anda sedang membaca file kesombongan yang telah Anda buat. Banyak params URL dibuat dalam format {myParam}. Jadi Anda ingin membaca URL dan kemudian mengonversinya menjadi string template tanpa harus melakukan penggantian yang rumit karena Anda memiliki banyak titik akhir. Jadi, Anda dapat melakukan sesuatu seperti ini. Perhatikan ini adalah contoh yang sangat sederhana.

const params = { id: 5 };

const route = '/api/user/{id}';
route.replace(/{/g, '${params.');

// use eval(route); to do something

Pembuatan kode. Baru-baru ini saya menulis sebuah perpustakaan bernama Hyperbars yang menjembatani kesenjangan antara virtual-dom dan setang . Ini dilakukan dengan mem- parsing templat templat dan mengubahnya menjadi hiperscript . Hyperscript dibuat sebagai string terlebih dahulu dan sebelum mengembalikannya, eval()untuk mengubahnya menjadi kode yang dapat dieksekusi. Saya telah menemukan eval()dalam situasi khusus ini kebalikan dari kejahatan.

Pada dasarnya dari

<div>
    {{#each names}}
        <span>{{this}}</span>
    {{/each}}
</div>

Untuk ini

(function (state) {
    var Runtime = Hyperbars.Runtime;
    var context = state;
    return h('div', {}, [Runtime.each(context['names'], context, function (context, parent, options) {
        return [h('span', {}, [options['@index'], context])]
    })])
}.bind({}))

Kinerja eval()bukan masalah dalam situasi seperti ini juga karena Anda hanya perlu menafsirkan string yang dihasilkan sekali dan kemudian menggunakan kembali hasil yang dapat dieksekusi berkali-kali.

Anda dapat melihat bagaimana pembuatan kode tercapai jika Anda penasaran di sini .

Keyakinan saya adalah bahwa eval adalah fungsi yang sangat kuat untuk aplikasi web sisi klien dan aman ... Sama amannya dengan JavaScript, padahal sebenarnya tidak. :-) Masalah keamanan pada dasarnya adalah masalah sisi server karena, sekarang, dengan alat seperti Firebug, Anda dapat menyerang aplikasi JavaScript apa pun.

Eval berguna untuk pembuatan kode ketika Anda tidak memiliki makro.

Sebagai contoh (bodoh), jika Anda menulis kompiler Brainfuck , Anda mungkin ingin membangun fungsi yang melakukan urutan instruksi sebagai string, dan mengevaluasi untuk mengembalikan fungsi.

Saat Anda menguraikan struktur JSON dengan fungsi parse (misalnya, jQuery.parseJSON), ia mengharapkan struktur sempurna dari file JSON (setiap nama properti menggunakan tanda kutip ganda). Namun, JavaScript lebih fleksibel. Oleh karena itu, Anda dapat menggunakan eval () untuk menghindarinya.