Mengapa JavaScript tidak digunakan untuk pengembangan aplikasi klasik (perangkat lunak terkompilasi)? [Tutup]

14

Selama bertahun-tahun saya mengembangkan web dengan JavaScript, saya sampai pada kesimpulan bahwa itu adalah bahasa yang luar biasa kuat, dan Anda dapat melakukan hal-hal luar biasa dengannya.

Ini menawarkan serangkaian fitur yang kaya, seperti:

  • Pengetikan dinamis
  • Fungsi kelas satu
  • Fungsi bersarang
  • Penutupan
  • Berfungsi sebagai metode
  • Berfungsi sebagai konstruktor Obyek
  • Berbasis prototipe
  • Berbasis objek (hampir semuanya adalah objek)
  • Regex
  • Array dan Object literals

Bagi saya, hampir semuanya dapat dicapai dengan bahasa seperti ini, Anda juga dapat meniru pemrograman OO, karena ia memberikan kebebasan besar dan banyak gaya pengkodean yang berbeda.

Dengan lebih banyak fungsi kustom yang berorientasi pada perangkat lunak (I / O, FileSystem, perangkat Input, dll.) Saya pikir akan bagus untuk mengembangkan aplikasi bersama.

Padahal, sejauh yang saya tahu, itu hanya digunakan dalam pengembangan web atau dalam perangkat lunak yang ada sebagai bahasa scripting saja.

Hanya baru-baru ini, mungkin berkat Mesin V8, ini telah digunakan lebih banyak untuk jenis tugas lainnya (lihat node.js misalnya).

Mengapa sampai sekarang ini hanya akan diturunkan hanya untuk pengembangan web? Apa yang menjauhkannya dari pengembangan perangkat lunak?

Jose Faeti
sumber
8
Jika pengembangan web bukan (kasus khusus) pengembangan perangkat lunak, lalu apa sebenarnya itu? ...
Péter Török
@ Péter Török: Saya pikir Anda mengerti maksudnya. Maksud saya adalah bahwa sampai sekarang ini hanya digunakan sebagai bahasa scripting oleh perangkat lunak, untuk meningkatkan fitur. Ini tidak pernah digunakan untuk benar-benar memprogram aplikasi perangkat lunak untuk OS.
Jose Faeti
4
Saya melihat pengetikan dinamis sebagai kelemahan besar, dan saya juga ingin menyingkirkan nilai nol.
Jonas
2
Maksud Anda "pengembangan aplikasi klasik", bukan "pengembangan perangkat lunak", bukan? Lebih baik ubah heading Anda sesuai.
Doc Brown
2
@JoseFaeti untuk record windows 8 memungkinkan Anda melakukan pengembangan di HTML5 & JS
Raynos

Jawaban:

14

Baru-baru ini node.js telah membawa pengembangan sisi server ke depan. Jadi, sekarang mungkin untuk menulis JavaScript, untuk pengembangan.

Itu benar. Dalam sejarah, itu belum digunakan sebagai bahasa pengembangan. Tapi, hei, bahkan skrip di lingkungan klien (Agen Pengguna) adalah jenis pengembangan. Bukan?

Alasan utama yang saya dengar dan baca di banyak weblog adalah, orang tidak tahu tentang kekuatan dan keunikannya hingga beberapa tahun terakhir . Apa yang membuat ini terjadi, mungkin bahasa lain melakukan pekerjaan mereka dengan cukup baik, dan tidak ada yang pernah berpikir untuk membuat sesuatu yang paralel.

Saeed Neamati
sumber
Pasti seperti itu, dan sepertinya ada sesuatu yang bergerak sekarang :)
Jose Faeti
15

Dari sini :

Perhatikan bahwa saya mendasarkan semua argumen saya pada kasus penggunaan dunia nyata. Argumen balasan yang tidak dapat didukung dengan contoh penggunaan dalam aplikasi yang nyata, lengkap, menarik, bermanfaat tidak valid. Saya telah melihat "demo bahasa" kecil yang dimiliki semua orang, saya telah melihat posting blog yang merinci bagaimana prototipe dan pengetikan dinamis membuat beberapa contoh kecil yang sepele beberapa baris lebih pendek daripada di C #, tetapi itu tidak relevan untuk masalah Anda mengalami penulisan kode nyata daripada mikro-demo dan mainan. Jadi, inilah keluhan saya dengan JS:

a) Sihir 'ini'. Ini dia, kecuali kalau ini dia. JavaScript mendorong Anda untuk menggunakan fungsi anonim di semua tempat, kecuali mereka selalu berakhir dengan konteks yang tepat untuk variabel 'ini', jadi Anda akhirnya memiliki kode konyol seperti "var _ini = ini" di semua tempat dan kemudian menggunakannya di dalam panggilan balik Anda atau fungsi lainnya. Beberapa hari saya bersumpah bahwa jumlah fungsi yang saya tulis yang tidak menggunakan nama 'ini' yang diganti sebenarnya lebih kecil daripada jumlah yang melakukannya.

b) 1 + "1" - 1 = 10. Juga, "1" + 0 = "10". Ya, ini sebenarnya telah menyebabkan bug untuk aplikasi kami, di mana data yang diharapkan berupa angka dimuat dari file JSON sebagai string karena bug di aplikasi lain, dan hasilnya tidak baik. Semua kode pemuatan kami harus diperbarui untuk menambahkan satu ton konversi jenis di semua tempat. Ketika saya membutuhkan sesuatu untuk menjadi nomor, saya benar-benar sangat ingin nomor itu, bukan string atau objek atau null atau apa pun. Lua, yang sangat mirip dengan JavaScript dalam banyak hal, memperbaiki masalah ini dengan tidak cukup terbelakang untuk menggunakan operator yang sama untuk penambahan dan penggabungan string.

c) Global oleh variabel default. Jadi, bahkan jika Anda mengambil argumen bahwa pengetikan dinamis hanya "lebih mudah" karena Anda tidak harus berpikir tentang deklarasi variabel, JavaScript membuang argumen itu ke luar jendela dengan membuat Anda meletakkan 'var' di depan pengidentifikasi baru di semua tempat . Dan kemudian diam-diam sekrup Anda jika Anda lupa.

d) Prototipe, bukan kelas. Ada sangat sedikit aplikasi JavaScript dunia nyata berskala besar yang tidak menggunakan sistem kelas mereka sendiri untuk mengatasi ketidakgunaan yang tidak terpisahkan dari prototipe dalam arsitektur aplikasi besar. Aplikasi-aplikasi yang sama menggunakan minimal prototipe untuk memperluas tipe JavaScript dasar, dan hanya karena JS dirancang dengan buruk sehingga bahkan dua tipe built-in yang menarik disertai dengan kekurangan setengah fitur yang Anda harapkan dimiliki.

e) Ketidakmampuan untuk membuat jenis pass-by-value. Ini adalah masalah yang sering terjadi di hampir semua bahasa selain dari C ++ / D, sebenarnya. Bagi mereka yang menggunakan JavaScript untuk menulis aplikasi WebGL, lihat semua pustaka aljabar linier untuk JavaScript. Dalam aplikasi 3D, Anda hampir sering menggunakan vektor daripada skalar. Bayangkan jika setiap bilangan bulat di aplikasi Anda dilewatkan dengan referensi, sehingga "a = 1; b = a; b ++" membuat a dan b sama dengan 2. Setiap vektor komponen kecil tiga adalah objek lengkap yang lengkap. Mereka dilewatkan dengan referensi (sumber hampir setengah bug di game WebGL kami sejauh ini, pada kenyataannya). Mereka ada dalam jumlah besar, dialokasikan dengan tumpukan, dan pengumpulan sampah, yang memberikan tekanan besar pada GC yang dapat dan memang mengakibatkan GC berhenti bahkan di game WebGL yang sederhana, kecuali pengembang melompat melalui lingkaran rumit yang rumit untuk menghindari membuat vektor baru di semua tempat yang logis untuk membuat vektor baru. Anda tidak dapat memiliki operator kelebihan, sehingga Anda memiliki ekspresi yang sangat besar dan jelek untuk melakukan operasi dasar. Mengakses komponen individual lambat. Objek tidak secara bawaan dikemas dan karenanya sangat lambat untuk mendorong ke buffer vertex, kecuali jika Anda menerapkannya sebagai contoh Float32Array, yang membingungkan omong kosong dari pengoptimal dari kedua V8 dan SpiderMonkey saat ini. Apakah saya menyebutkan mereka lulus dengan referensi? Mengakses komponen individual lambat. Objek tidak secara bawaan dikemas dan karenanya sangat lambat untuk mendorong ke buffer vertex, kecuali jika Anda menerapkannya sebagai contoh Float32Array, yang membingungkan omong kosong dari pengoptimal dari kedua V8 dan SpiderMonkey saat ini. Apakah saya menyebutkan mereka lulus dengan referensi? Mengakses komponen individual lambat. Objek tidak secara bawaan dikemas dan karenanya sangat lambat untuk mendorong ke buffer vertex, kecuali jika Anda menerapkannya sebagai contoh Float32Array, yang membingungkan omong kosong dari pengoptimal dari kedua V8 dan SpiderMonkey saat ini. Apakah saya menyebutkan mereka lulus dengan referensi?

f) Tidak ada built-in termasuk atau memerlukan fungsionalitas. Serius, diam. Perpustakaan pihak ketiga ada tetapi hampir semua dari mereka memiliki semacam bug atau yang lain, tidak sedikit di antaranya merupakan masalah cache yang membingungkan di setidaknya Chrome yang membuat pengembangan aktual menjadi masalah di pantat.

g) Pengetikan dinamis. Ya, saya bersedia memulai argumen itu. Anda mulai memperhatikannya paling banyak saat Anda berhenti menulis aplikasi Web kecil atau halaman Web dan mulai menulis aplikasi besar di mana Anda sebenarnya memiliki data yang bertahan lebih dari satu klik mouse atau siklus permintaan / respons: tambahkan jenis objek yang salah ke suatu Array untuk diproses kemudian dan mendapatkan crash kemudian dari metode yang hilang atau anggota dalam sedikit kode yang sama sekali berbeda dari tempat kesalahan sebenarnya. Waktu yang menyenangkan. Ya, Java membuat pengetikan statis tampak jahat. Tidak, Java / C # / C ++ bukan satu-satunya cara untuk melakukan pengetikan statis. Ketik inferensi, pengikatan antarmuka implisit, dll. Memberi Anda semua keuntungan "mudah ditangani dan tidak banyak penekanan tombol" dari pengetikan dinamis tanpa semua bug. Bahasa Web paling populer kedua - ActionScript 3 - diketik secara statis, pada kenyataannya, meskipun identik dengan JS / ECMAScript. Selain itu, saya mendapatkan lebih banyak crash dari aplikasi Python di desktop Fedora saya daripada yang saya lakukan dari aplikasi C / C ++ (sebenarnya, tidak ada aplikasi C / C ++ di desktop crash saya, sekarang saya memikirkannya). Pengecualian anggota yang hilang == jauh lebih mudah untuk mengembangkan dan memelihara aplikasi, bukan?

h) Kecepatan. Ya, telah ada sejumlah upaya yang sangat besar oleh sejumlah besar pengembang yang sangat buruk dimasukkan ke dalam runtime bahasa untuk membuat JS hampir setengah dari kompiler C kelas rendah yang dapat ditulis oleh satu perguruan tinggi Junior dalam beberapa bulan. Dan LuaJIT berada di kapal yang sama dengan JS dalam hal keterbatasan bahasa mendasar tetapi tetap berhasil lebih baik daripada setiap implementasi JavaScript. Orang-orang yang tidak mengerti apa yang sebenarnya dilakukan oleh semua optimasi JS di V8ingin mengklaim JS dapat melakukan hal-hal luar biasa dengan bijaksana, tetapi kenyataannya adalah semua optimasi itu pada dasarnya hanya "berusaha sangat keras untuk menganalisis kode untuk mengetahui jenis variabel dan kemudian mengompilasinya seperti yang agak terbelakang secara statis-diketik. kompiler bahasa akan melakukannya. " Oh, dan ada tracing, tapi kemudian tracing juga berfungsi pada bahasa yang diketik secara statis (dan bekerja lebih baik karena kurangnya kebutuhan untuk tipe penjaga di kode mesin yang dihasilkan). Tidak ada satu pun dari optimasi whizbang yang ditemukan oleh atau untuk JS, pada kenyataannya; sebagian besar diambil dari penelitian JVM (Jawa jahat!) atau bahasa OOP klasik (prototipe mengagumkan!).

i) Tidak mungkin IntelliSense. Ingin melihat metode apa yang ada pada variabel yang Anda dapatkan di sana pada baris 187 dari foo.js di editor teks Anda? Sangat buruk. Telusuri kode tersebut sampai Anda mengetahui di mana kode itu diinisialisasi, kemudian telusuri kode untuk mengetahui apa yang ada pada prototipe-nya. Dan kemudian berharap tidak ada kode yang secara dinamis mengubah prototipe di belakang Anda. Faktanya, jalankan saja di browser dan atur breakpoints, karena menemukan sesuatu yang berguna tentang nilai dengan cara lain pada dasarnya tidak mungkin untuk basis kode apa pun yang lebih besar dari situs toy_web_app.html yang digunakan para pembela JavaScript untuk memuliakan kemudahan dan kesederhanaan JavaScript. Beberapa editor kode berusaha sangat keras untuk berbuat lebih baik, dan hampir agak berhasil untuk kasus yang sangat sederhana, kadang-kadang, sekali.

j) Tidak ada keuntungan. JavaScript bahkan tidak istimewa dibandingkan dengan bahasa yang diketik secara dinamis lainnya. Itu tidak mampu melakukan sesuatu yang menarik sama sekali yang tidak dapat juga dilakukan oleh Lua, Python, Ruby, dll bahasa. JS tidak memiliki sisi positifnya dibandingkan dengan bahasa lain yang umumnya tersedia. Oh, kecuali itu berjalan secara native di browser Web tanpa plugin. Yang merupakan satu-satunya alasan di dunia mengapa ini sangat populer. Bahkan, itu satu-satunya alasan acara itu ada. Jika seseorang 10 tahun yang lalu baru saja berpikir, "heck, mari kita letakkan bahasa yang dirancang dengan baik dan mapan ke dalam peramban kami dan minta orang lain untuk melakukan hal yang sama alih-alih membuat semua orang menggunakan peretasan kecil konyol yang dibuat NetScape ini dengan , "Web akan terlihat jauh berbeda (lebih baik) hari ini. Bayangkan saja masa depan jika Chrome menjatuhkan Python ke Chrome sebagai bahasa yang didukung. Atau sebenarnya, bayangkan ini: Google memasukkan C / C ++ ke Chrome sebagai bahasa yang didukung (http://code.google.com/p/nativeclient/).

17 dari 26
sumber
Ini adalah posting yang sangat menarik. Saya ingin tahu melihat kasus penggunaannya yang membentuk dasar dari argumennya. Saya tidak setuju dengan poinnya, tapi saya telah mengembangkan aplikasi JS ukuran perusahaan selama hampir 10 tahun dan belum mengalami beberapa hal yang dia sebutkan (khususnya, poin pertamanya tentang "keajaiban ini"). Pergi pada pengalaman saya sendiri, argumen terhadap javascript seperti yang ada di posting ini cenderung dibuat oleh orang-orang dengan latar belakang oop tradisional yang berat ... dalam hal ini, saya akan mengerti kebingungannya.
Tn. JavaScript
Sangat menarik untuk melihat bahwa pada tahun 2016, jawabannya sekarang sepenuhnya usang oleh evolusi bahasa.
Stephan Bijzitter
@Pak. JavaScript Hai. Apakah Anda tahu serangkaian tutorial yang berkonsentrasi pada penyelesaian contoh masalah dunia nyata daripada hanya menjelajahi JavaScript dan fitur serta mekanismenya? Saya tidak beruntung dengan pencarian kata kunci. Sebagai contoh, alih-alih melalui tautan tutorial terperinci dan jutaan contoh dan fitur, di mana saya menemukan gudang tutorial kecil tentang cara membuat aplikasi GUI untuk mengelola beberapa sistem asuransi atau dokter atau sekolah atau bagian operasional dari supermarket? Terima kasih
Yosua
12

Mengapa?

JavaScript bahasa yang paling disalahpahami

Kami berada di zaman kegelapan dan masih bagi komunitas pengembangan umum untuk menerima bahwa JavaScript adalah bahasa yang kuat dan serbaguna. Itu tidak mainstream.

Satu-satunya kemajuan baru-baru ini adalah node.js telah menjadi buzz-bertele-tele dan orang-orang mulai menerima bahwa javascript memiliki kegunaan lain ..

Saya telah mengawasi pengembangan JS & HTML5 untuk windows 8 dan reaksi dari komunitas NET. "Ya Tuhan, mengapa?".

Ini hanya fakta bahwa sebagian besar pengembang non-web masih melihat JavaScript sebagai bahasa mainan yang Anda gunakan untuk membuat mereka menggulir menu di browser Anda.

Memang JavaScript tidak selaras dengan "praktik pembangunan modern". Bagi saya JavaScript masih merupakan bahasa peretasan yang saya gunakan dengan vim & internet adalah dokumentasi saya. Tidak ada IDE, tidak ada alat pengembangan, tidak ada auto-complete atau "intellisense", tidak ada klik dan seret GUI.

Di dunia Java dan pengembang .NET mereka terikat dengan GUI & IDE mereka dan tidak akan dapat memprogram di vim.

Raynos
sumber
1
Saya setuju dengan Anda kecuali "Tidak ada IDE, tidak ada alat pengembangan, tidak ada pelengkapan otomatis atau" intellisense ", tidak ada klik dan seret GUI." Sebenarnya Anda bisa mendapatkan semua itu menggunakan banyak berbagai IDE di luar sana, saya menggunakan Visual Studio misalnya dan itu sangat bagus.
Jose Faeti
1
@JoseFaeti maaf, Visual Studio bukan IDE javascript. Saya lebih cepat di vim kemudian di VS2010. Ini berarti VS2010 adalah JS IDE yang bocor.
Raynos
2
@ Raynos, "Saya lebih cepat di vim daripada di VS2010. Ini berarti VS2010 adalah IDE JS yang bocor." - atau mungkin ini berarti Anda tidak tahu VS dan juga vim.
Péter Török
2
Sama sekali tidak, tapi saya tidak akan membangun antarmuka RIA di Silverlight karena saya suka Resharper dan LINQ, atau aplikasi ASP.Net MVC dengan lapisan jQuery yang tipis, karena sekali lagi .Net friendly, ketika ada klien yang kaya bahasa Javascript di tangan yang lebih cocok untuk pekerjaan itu.
sa93
1
Hanya menambahkan suara saya ke paduan suara orang yang menyatakan bahwa ada IDE JavaScript. Terus terang konyol untuk mengklaim sebaliknya. Anda mungkin tidak menyukai IDE dan mereka mungkin tidak sempurna, tetapi mereka masih IDE. Atau sudahkah saya membayangkan intellisense dan penyelesaian kode VS ketika bekerja dengan JS?
Ian Newson
10

Daftar Anda tidak mengandung apa pun tentang menulis file ke sistem, yang merupakan bagian besar dari pengembangan perangkat lunak.

Orang tidak akan berpikir untuk menggunakan JS untuk membangun aplikasi karena itu adalah bahasa skrip de facto untuk web, dan Anda akan selalu menggunakan alat yang tepat untuk pekerjaan itu.

Mengapa menulis hektar JS untuk menulis file ketika itu adalah operasi sepele di Java / .NET / C / C ++?

Dengan mengatakan itu, seperti yang orang lain sebutkan, node.js dan perpustakaannya telah membuat operasi sisi server sepele dan dengan node.js menjadi populer, mempelajarinya akan menjadi keterampilan untuk CV, karena Anda akan dapat mempertahankan / memperluas / membangun aplikasi dengan itu.

StuperUser
sumber
1
+1 benar-benar lupa bagaimana perpustakaan stdio agak penting.
Raynos
1
Untuk filesystem seperti yang Anda katakan, kami memiliki API penyimpanan lokal sekarang, meskipun Anda tidak akan mengandalkannya untuk daya tahan yang serius. Namun menulis ke sistem file tidak harus langsung, javascript Anda bisa membuat panggilan tenang ke server yang (ditulis dalam LOLCode atau C atau JS sendiri) yang menulis ke beberapa bentuk penyimpanan.
sa93
1
Di sisi server. API file NodeJS hanya sepele seperti C dll ... <- jika Anda melakukan IO dengan benar di C (non blocking). Juga panggilan Ajax dengan bungkus waras bisa 2-3 baris. MyLib.Ajax.post ('/ persistence / Something', {data: blahObj})
sa93
@ sa93 tolong jangan membingungkan lingkungan host browser dengan JavaScript. localStorage adalah API host di browser. Itu tidak didefinisikan dalam spesifikasi ES5.
Raynos
1
@reinierpost Writing files to the file system has been replaced with HTTP POST.Tidak jika Anda menulis API yang menangani pos.
StuperUser
5

Sebagian besar bahasa yang umum digunakan lebih kuat dan dirancang lebih baik daripada JavaScript. Semua fitur yang Anda sebutkan didukung oleh bahasa dinamis lain seperti Python atau Ruby yang secara keseluruhan dirancang lebih baik. Dan beberapa fitur yang Anda sebutkan belum tentu diinginkan - banyak yang akan menganggap pengetikan statis dengan inferensi jenis lebih baik daripada pengetikan dinamis, jika Anda punya pilihan.

Saya tidak mengatakan ini untuk diss JavaScript. Saya cukup menikmati bekerja dengan JS ketika mengembangkan web. Tetapi dengan melihatnya secara objektif, JS memiliki sejumlah kelemahan dibandingkan dengan bahasa lain:

  • Banyak kekurangan yang tidak dapat diperbaiki. Banyak kesalahan dibuat ketika awalnya mengembangkan JS. Tidak perlu menyebutkannya di sini, mereka didokumentasikan dengan baik. Semua bahasa memiliki kesalahan dalam desain awal yang kemudian diperbaiki. Perbedaannya dengan JS adalah bahasanya dikembangkan dan dirilis jauh dengan cepat dan kesalahan ini tidak pernah bisa diperbaiki karena persyaratan kompatibilitas ke belakang di browser.
  • Proses yang sangat lambat untuk memperkenalkan perbaikan dan fitur baru. Karena semua vendor browser harus setuju dan mungkin bahkan karena berbagai alasan politik ingin memperlambat pengembangan bahasa. Lihatlah C # yang sebenarnya merupakan bahasa yang lebih baru dari JS. Ketika C # diperkenalkan itu tidak memiliki misalnya. fungsi penutupan atau urutan yang lebih tinggi seperti JS, tetapi setelah beberapa iterasi sekarang memiliki semua itu dan lebih lanjut fitur seperti sintaks Linq dan async yang hanya bisa membuat iri pengembang JavaScript.
  • Perpustakaan standar yang miskin. Bahasa modern seperti Python, Ruby atau apa pun yang berbasis Java atau .net memiliki pustaka standar yang luas untuk hampir semua hal yang Anda perlukan. Di JS Anda bahkan tidak bisa membaca file tanpa pustaka pihak ke-3. Anda menyebut Regex, tetapi semua bahasa modern memiliki itu dan ribuan hal lainnya.
  • Bahasa-bahasa lain telah menangkap beberapa kelebihan JavaScript. Fitur seperti penutupan dan fungsi kelas satu sangat kuat jika dibandingkan dengan bahasa statis kikuk seperti Java sepuluh tahun yang lalu, tetapi bahasa yang dinamis dan fungsional telah lama memiliki fitur ini, dan bahkan Java, bahasa yang cukup konservatif, telah menambahkan ini di Java 8.

Satu-satunya fitur yang benar-benar membedakan JavaScript dari bahasa modern lainnya adalah pewarisan berbasis prototipe (berbeda dengan berbasis kelas), dan keunggulan model ini meragukan karena semua orang hanya menggunakannya untuk meniru warisan berdasarkan kelas pula.

Tidak ada alasan untuk memilih JavaScript jika Anda memiliki pilihan untuk memilih bahasa modern lainnya. Satu-satunya alasan adalah jika itu satu-satunya bahasa yang Anda tahu.

JacquesB
sumber