Kelelahan Javascript

Beberapa hari yang lalu, saya bertemu dengan seorang teman & rekan sambil minum kopi.

Saulus: "Bagaimana kabarnya?"
Saya: “Kelelahan.”
Saulus: “Keluarga?”
Saya: “Tidak, Javascript.”

Lebih tepatnya, maksud saya React dan ekosistem Javascript yang menyertainya.

Sebagai permulaan, pertimbangkan itu

ditanya mengapa React luar biasa untuk pemula:

Jika Anda menggunakan React, Anda mungkin berbagi pengalaman yang sama dengan

:

Ada masalah besar dalam komunitas React yang melumpuhkan para pemula dan juga menghambat para ahli.

Terlalu Banyak Alat.

Di tempat kerja kuartal terakhir ini, kami dengan susah payah memulai tiga proyek baru di tempat kerja. Saya katakan "dengan susah payah" karena setiap proyek membutuhkan keputusan yang harus dibuat seputar perkakas tergantung pada ruang lingkup & kebutuhan.

Pada akhirnya, masalahnya adalah bahwa dengan memilih React (dan secara inheren JSX), Anda tanpa disadari telah memilih ke dalam kumpulan alat build, boilerplate, linter, & time-sink yang membingungkan untuk ditangani sebelum Anda bisa membuat apa pun.

Boilerplate & Generator Bukan Jawabannya.

Yeoman & Plop dapat mengurangi jumlah copy & paste yang Anda lakukan di antara proyek.

Namun, yang dihasilkan tidak pernah cocok satu-ke-satu, juga tidak bisa.

Pada skala dengan proyek yang cukup, sangat sulit untuk mem-back-port fitur & peningkatan dari satu aplikasi ke aplikasi lainnya, karena kode umum tidak diabstraksikan menjadi ketergantungan yang dapat diperbarui secara independen.

Ketika generator adalah solusi yang baik untuk kode yang berulang, solusi yang lebih baik adalah mengabstraksikannya menjadi API yang lebih sederhana.

Jika tidak, generator menjadi aplikasi yang membingungkan dan penuh logika itu sendiri karena permutasi dari kemungkinan kasus penggunaan, selamanya dalam perlombaan untuk tetap relevan dengan aplikasi yang dibuatnya.

Saya telah mengalami ini secara langsung dengan beberapa generator, termasuk evolution/wordpress saya sendiri .

Terlalu Banyak API. Terlalu Banyak Konfigurasi.

Contohnya bisa dilihat di

React-fetcher yang sangat baik , perpustakaan seperti Redux , React Router , Webpack , dan ekosistem React, sebagian besar, telah memilih modularisasi diskrit dengan mengorbankan API singkat dengan membongkar fondasi arsitektur mereka kepada pengguna dan, sebagai hasilnya, memperburuk pengalaman pengembang secara agregat.

Sendiri, API itu kecil, tetapi bahkan kurang dari segelintir menghasilkan kekacauan kode yang hampir tidak dapat dipahami untuk setiap mata baru.

Bahkan jika terdapat dalam proyek "boilerplate", di-scaffolded oleh generator, atau disimpan dalam file finalCreateStorev3SeriousThisTime.js , kami telah membuat sarang tikus kabel yang akan membuat plugin WordPress memerah.

Lebih Abstrak. Kurang Kode.

Tentu saja, API ini merupakan persyaratan untuk memiliki perpustakaan yang lebih kecil, terpisah, dapat diuji, dan oleh karena itu, berkualitas tinggi .

Namun, kita membutuhkan jalan tengah abstrak antara dependensi kabel dan pembangkit boilerplates .

Abstraksi diperlukan untuk mengurangi beban kognitif tentang cara kerja sesuatu sehingga Anda dapat fokus pada penciptaan.

Berjuang Melawan Garis Kode.

Setiap proyek dengan cakupan signifikan sudah memiliki sejumlah besar kode di belakangnya.

Pengembang aplikasi tidak harus menjadi ahli dalam dasar-dasar perpustakaan hanya untuk menggunakannya.

Oleh karena itu, instrumenting tooling harus bertujuan seminimal mungkin .

Pertimbangkan daftar alternatif yang disusun dengan tergesa-gesa ini :

• Sediakan API pembungkus atau pustaka yang didukung oleh penulis dan berpendirian untuk 90% kasus penggunaan teoretis.
  (Memotong boilerplate untuk React + Router + Redux saja akan menjadi peningkatan besar bagi banyak orang.)
• Publikasikan preset kasus penggunaan yang mirip dengan preset Babel (misalnya es2015 , react , dll.).
• Manfaatkan konvensi penamaan folder & file untuk menemukan rute, tindakan, pengujian, dan lainnya secara otomatis.
  (Ini sudah menjadi tempat umum untuk pengujian (mis. Mocha ) & melayani aset publik, tetapi entah bagaimana setiap proyek secara ajaib membutuhkan konfigurasi unicorn.)
• Perkakas Pengembangan Aplikasi Cepat (RAD) berbasis komunitas untuk secara signifikan menunda kebutuhan akan konfigurasi eksplisit hingga ruang lingkup dipadatkan.

Perkakas RAD

Mengikuti utas Twitter di atas, banyak yang mengakui bahwa tidak ada solusi satu ukuran untuk semua.

Namun, jika kita mulai dengan niat untuk hanya membangun prototipe, abstraksi yang mendasarinya tidak masalah.

Terkait,

menantang komunitas untuk merancang perkakas untuk pembuatan prototipe cepat , bahkan dengan biaya penyesuaian.

Sementara itu, saya mengetahui beberapa opsi yang dapat Anda gunakan hari ini untuk memulai proyek Anda berikutnya:

• kuncup
• nwb
• prot
• rackt-cli
• rwb

Tidak lama lagi, saya yakin itu akan menetap di tengah-tengah antara pengembangan dan penyesuaian yang cepat.

Bahkan, seorang teman saya merasakan pola yang sama muncul:

2016 kemungkinan akan melibatkan penggabungan proyek, alat, dan fitur bahasa yang serius dan terfokus untuk menggabungkan paket/alat/boilerplate terbaik dan tercerdas ke dalam proyek yang lebih formal. —

di State of the Union.js

Ini untuk 2016 yang menarik! :)