Baru-baru ini, tim Qwintry memulai migrasi aktif ke Vue.js di semua proyek lama dan baru kami:- pada sistem berbasis Drupal lama (qwintry.com)
- di utas qwintry.com baru kami yang sepenuhnya ditulis ulang (backend di Yii2 / Node.js)
- dalam sistem B2B kami (diberdayakan oleh Yii2) (logistics.qwintry.com)
- di semua proyek internal dan publik kecil kami (terutama menggunakan PHP dan Node.js di backend)
Mengapa programmer kami memilih Vue.js, kata kepala pengembangan di Qwintry LLC . Anton Sidashin ➔Secara singkat tentang kami: proyek Qwintry digunakan oleh setengah juta pelanggan di seluruh dunia, kami memiliki dua gudang (di AS dan Jerman) menggunakan perangkat lunak cloud kami sendiri, dan kami adalah salah satu pengirim surat terbesar di AS dalam hal lalu lintas pengunjung dan keberangkatan. Kami membantu orang membeli barang di toko online AS dan mengelola paket mereka di akun pribadi kami, serta kami dapat menghemat pengiriman internasional secara signifikan. Kami menggunakan platform IT kami sendiri dan rantai pasokan untuk menyediakan pengiriman internasional berkualitas dengan harga yang baik.
Paket kami di pintu klien - dari ulasan pelangganQwintry memiliki basis kode yang agak besar, terutama terdiri dari PHP dan JS (+ Swift dan Java untuk aplikasi seluler).Kami memutuskan untuk menggunakan Vue.js setelah kami membangun aplikasi uji dengan fungsi yang identik - kalkulator kami - pada React, Vue.js dan Angular2. React.js
Popularitas React telah meroket dalam satu atau dua tahun terakhir, dan sekarang, mungkin, itu adalah pilihan default untuk pengembang JS yang ingin menulis sesuatu yang lebih rumit di frontend daripada paragraf tiga baris kode.Kami melihat beberapa SPA dan widget dinamis di React, kami menguji React Native (untuk iOS) dan Redux. Saya pikir React adalah langkah besar bagi dunia JS dalam hal kesadaran negara , dan itu menunjukkan kepada banyak orang apa pemrograman fungsional yang nyata dengan cara yang baik dan pragmatis. Saya juga berpikir bahwa React Native hebat - benar-benar mengubah seluruh lanskap pengembangan ponsel.Bereaksi merugikan saya:
Seringkali, kebersihan, kekebalan, dan ideologi mendominasi pendekatan pragmatis.
Jangan salah sangka. Saya menghargai kemurnian dan kesederhanaan pendekatan render () - tidak diragukan lagi ini adalah ide bagus yang bekerja dalam pengembangan nyata. Saya berbicara tentang hal-hal lain.Saya pikir tingkat kekakuan dan kebersihan ini dapat berguna ketika Anda memiliki 1.000 pengembang di perusahaan Anda - sekitar saat yang sama Anda memutuskan untuk mengembangkan sintaks Anda sendiri untuk menerjemahkan semua kode PHP Anda ke tipe statis . Atau ketika Anda adalah pengembang Haskell yang memutuskan untuk memahami JS. Tetapi sebagian besar perusahaan memiliki pengembang yang jauh lebih sedikit, anggaran lebih kecil dan tujuan yang berbeda dari tujuan Facebook. Saya akan membahas hal ini secara lebih rinci sedikit lebih jauh.BEJ menyebalkan
Tunggu sebentar! Saya tahu! Ini adalah "Javascript murni dengan sintaks khusus". Orang-orang kami yang menggambar desain dalam sketsa dan photoshop dan kemudian mengubahnya menjadi HTML, yang memiliki tenggat waktu yang sulit dan yang sekarang membuat formulir ini, membungkusnya dalam sejumlah div - sekarang - drum bersih dan "sederhana" ES6. Menerapkan beberapa desain untuk Bereaksi komponen bukan air mancur, karena JSX kurang mudah dibaca. Ketidakmampuan untuk menempatkan IF lama yang baik ke dalam beberapa blok kode HTML adalah buruk, dan tolong jangan percaya Bereaksi penggemar yang mengatakan bahwa "jika () adalah abad terakhir, dan sekarang semua programmer normal menggunakan operator ternary". Izinkan saya meyakinkan Anda: JSX masih merupakan gabungan dari HTML dan JS saat Anda membaca dan mengeditnya, bahkan jika nanti dikompilasi menjadi JS murni.<ul>
{items.map(item =>
<li key={item.id}>{item.name}</li>
)}
</ul>
Banyak pengembang berpikir (dan saya setuju dengan mereka untuk beberapa waktu) bahwa pembatasan sintaksis seperti itu akan membuat mereka lebih kuat dan membantu mereka menulis lebih banyak kode modular, karena pembatasan JSX (out of the box) memaksa Anda untuk meletakkan potongan kode dalam fungsi pembantu kecil dan menggunakannya di dalam render () berfungsi, seperti ini dan banyak orang lain telah menyarankan:stackoverflow.com/a/38231866/1132016JSX juga memaksa Anda untuk memecah komponen-in-15-lines-HTML menjadi 3 komponen, 5-baris-HTML-di-masing-masing. Jangan berpikir bahwa pendekatan ini membuat Anda menjadi pengembang yang lebih baik.Inilah masalahnya:Ketika Anda menulis komponen yang relatif kompleks - yang Anda mungkin tidak akan memposting besok di perwakilan publik di GitHub untuk menunjukkannya di HackerNews - pendekatan ini memecah komponen menjadi komponen super bodoh karena pembatasan JSX selalu menarik Anda keluar dari aliran, di yang Anda memecahkan masalah bisnis nyata. Tidak, saya tidak mengatakan bahwa gagasan komponen pecahan buruk atau tidak berfungsi. Anda harus mengetahui dengan jelas bahwa Anda perlu membagi fungsionalitas menjadi komponen-komponennya untuk menjaga kode Anda dalam keadaan terkendali. Tetapi Anda hanya harus melakukan ini ketika Anda berpikir bahwa entitas logis tertentu dalam kode Anda lebih baik menjadi komponen terpisah dengan alat peraga sendiri - dan tidakuntuk setiap dua atau tiga kondisi yang ditulis menggunakan operator ternary! Setiap kali Anda membuat komponen baru di sana-sini, Anda harus mengeluarkan upaya yang sangat spesifik dan mengganggu aliran Anda ., karena Anda perlu beralih dari pemikiran arsitek (ketika Anda sudah ingat keadaan model komponen saat ini dan Anda hanya perlu menambahkan HTML di sana-sini agar fungsi berfungsi) ke pemikiran manajer: Anda perlu membuat file terpisah untuk komponen, pikirkan tentang alat peraga komponen baru ini bagaimana mereka memetakan di negara bagian, bagaimana Anda akan meneruskan panggilan balik, dll. Akibatnya, kecepatan penulisan kode berkurang, karena Anda harus melakukan upaya modularitas prematur komponen di mana Anda mungkin tidak membutuhkannya, jika sintaks JSX lebih fleksibel. Menurut pendapat saya, modularitas prematur sangat mirip dengan optimasi prematur. Bagi saya dan tim kami, keterbacaan kode penting, tetapi masih sangat penting untuk menikmati penulisan kode. Itu tidak kerenketika bentuk sederhana dari kalkulator membutuhkan pembuatan 6 komponen, masing-masing dengan alat peraga sendiri.Seringkali hypermodularity juga buruk dari sudut pandang pemeliharaan, modifikasi atau aplikasi desain baru, karena untuk memperbarui html di widget, Anda perlu melompati beberapa file / fungsi dan memeriksa setiap bagian kecil HTML secara terpisah.Sekali lagi, saya tidak mengusulkan menulis monolit. Saya sarankan menggunakan komponen, bukan mikrokomponen untuk pemrograman sehari-hari. Ini tentang keseimbangan dan akal sehat.Bekerja dengan formulir dan Redux akan membuat Anda mencetak sepanjang hari
Bereaksi - ini tentang kebersihan dan aliran satu arah, ingat? Karena itulah LinkedStateMixin menjadi persona non grata., dan sekarang Anda harus menulis 10 fungsi untuk mendapatkan input dari 10 bidang formulir. Tidak, Anda bisa, tentu saja, menulis satu fungsi yang akan memeriksa e.target, tetapi pada akhirnya akan ada pohon kondisi dengan normalisasi data yang datang dari formulir yang ingin Anda menangis; oleh karena itu tidak ada yang melakukan itu. 80% dari fungsi-fungsi ini akan berisi satu baris dengan this.setState () atau panggilan untuk tindakan Redux. (Maka Anda mungkin harus membuat 10 konstanta lagi - satu untuk setiap tindakan). Saya pikir pendekatan ini akan dapat diterima jika Anda dapat menghasilkan semua kode ini hanya dengan memikirkannya ... Tapi saya tidak tahu ada editor IDE yang bisa sangat menyederhanakan penulisan boilerplate tersebut. Mengapa Anda harus mencetak begitu banyak? Karena orang-orang besar memutuskan bahwa pengikatan dua arah berbahaya dalam aplikasi perusahaan besar.Saya dapat mengonfirmasi bahwa pengikatan dua arah terkadang tidak begitu sederhana dan tidak dapat dibaca, tetapi sebagian besar ketakutan ini terkait dengan penderitaan umum orang-orang dari versi pertama Angular, di mana pengikatan dua arah mungkin bukan yang terbaik. Namun ... ini mungkin bukan kesalahan perhitungan terbesar bahkan di Angular. Lihatlah editor cepat saya, yang saya baru-baru ini muak dengan Vue.js untuk platform Drupal kami (saya minta maaf sebelumnya untuk desain, ini adalah backend UI untuk operator kami, dan para desainer sibuk membuat antarmuka untuk klien kami, jadi fungsi ini sedang menunggu untuk itu. jam untuk menjadi cantik):mungkin bukan kesalahan perhitungan terbesar bahkan di Angular. Lihatlah editor cepat saya, yang saya baru-baru ini muak dengan Vue.js untuk platform Drupal kami (saya minta maaf sebelumnya untuk desain, ini adalah backend UI untuk operator kami, dan para desainer sibuk membuat antarmuka untuk klien kami, jadi fungsi ini sedang menunggu untuk itu. jam untuk menjadi cantik):mungkin bukan kesalahan perhitungan terbesar bahkan di Angular. Lihatlah editor cepat saya, yang saya baru-baru ini muak dengan Vue.js untuk platform Drupal kami (saya minta maaf sebelumnya untuk desain, ini adalah backend UI untuk operator kami, dan para desainer sibuk membuat antarmuka untuk klien kami, jadi fungsi ini sedang menunggu untuk itu. jam untuk menjadi cantik):
Saya tidak dapat menampilkan kode karena alasan yang jelas, tetapi menulisnya di Vue sangat bagus, dan kode itu sangat mudah dibaca. Dan saya tahu pasti bahwa jika saya menulis fungsi terpisah untuk setiap bidang formulir, seperti dalam Bereaksi, saya pasti tidak akan melompat dari kebahagiaan.Redux juga bertele-tele dan membutuhkan banyak tulisan . Dan di Internet, mudah untuk menemukan pernyataan oleh pengembang yang menuduh Mobx mengubah Bereaksi menjadi Angular hanya karena Mobx menggunakan pengikatan data dua arah (lihat klausul # 1 tentang "kebersihan"). Tampaknya banyak orang pintar menilai "kebersihan" kode mereka lebih dari tugas bisnis yang cepat dan diselesaikan dengan baik (yang, pada prinsipnya, normal jika Anda tidak memiliki tenggat waktu).Pada saat yang sama, saya menganggap konsep Flux / Redux itu sendiri sangat keren. Redux sederhana dan memberikan tingkat kontrol yang luar biasa atas status aplikasi, dan memisahkan status dari potongan antarmuka murni - ini segera membuatnya lebih mudah untuk menulis tes. Namun, sayangnya, semua ini diberikan oleh jumlah coretan yang sangat besar. Ya, debugging perjalanan waktu sebagai efek samping sangat mengagumkan. Tetapi secara pribadi, saya siap untuk mengorbankannya demi penulisan kode berkecepatan tinggi, dan berpikir tentang apakah Anda memerlukan perjalanan waktu jika Anda perlu membuat konstanta untuk setiap bidang dalam formulir untuk itu.Kelebihan berlebihan dalam alat
Bereaksi bekerja dengan ruang lingkup asli pada Babel. Anda tidak akan membuat aplikasi Bereaksi nyata tanpa banyak paket npm yang layak, dimulai dengan kompiler ES5. Aplikasi sederhana berdasarkan build awal resmi dalam beban menerima sekitar 75 MB kode JS di node_modules. Ini bukan hal yang kritis dan lebih berhubungan dengan dunia JS secara keseluruhan daripada Bereaksi, tetapi masih menambah frustrasi dan gangguan.Putusan Bereaksi Saya - memungkinkan Anda untuk menulis kode yang bagus dan mudah dibaca, tetapi menulisnya banyak tidak menyenangkan. Nah, masalah bagi desainer tata letak yang tidak memiliki, dan tidak ingin memiliki ES6 di dalam HTML - jangan hilang.Sudut 1: Terlalu banyak kebebasan juga buruk
Angular 1 adalah kerangka kerja yang baik untuk waktunya, terletak di sudut yang berlawanan (dari React) dari peta JS imajiner tentang kebersihan dan keterbacaan kode. Sudut memungkinkan Anda untuk memulai dengan cepat, memungkinkan Anda menikmati menulis baris kode 1k pertama, dan kemudian secara praktis membuat Anda menulis kode yang tidak bekerja dengan baik. Anda kemungkinan akan tersesat dalam arahan, cakupan, dan aliran data dua arah yang menembus semua lapisan aplikasi Anda akan menjadi chord terakhir dari lagu angsa kode Anda, yang bahkan tidak akan disentuh oleh pengembang yang baru disewa oleh pengembang, karena sesuatu akan pecah. Mengapa ini terjadi? Angular.js dibuat pada tahun 2009, ketika dunia pengembangan front-end terlihat cukup sederhana dan tidak ada yang berpikir tentang kontrol yang baik atas keadaan aplikasi. Anda tidak boleh menyalahkan penulis - mereka hanya membuat pesaing untuk Backbone dengan beberapa chip baru dan ingin mencetak lebih sedikit (dan mereka melakukan semuanya, pertanyaan lain berapa biayanya).Angular2
Cukup buat aplikasi hello-world dan lihat jumlah file yang berakhir di lobak. Saya harus menggunakan naskah (dan saya tidak 100% yakin apa yang ingin saya lakukan setiap hari - tidak, kawan, mengetik statis di JS bukan obat mujarab, tapi sekali lagi saya harus mencetak, pemikiran bagus dari Eric Eliott mengenai topik ini)) dan kompiler untuk memulai. Ini cukup bagi kami untuk menunda Angular2 sampai waktu yang lebih baik. Saya malas, dan bagi saya itu terlalu banyak sebelum Anda mulai menulis kode nyata. Menurut pendapat saya, penulis Angular 2 sedang mencoba membangun sistem yang ideal untuk perusahaan yang akan mengalahkan React, alih-alih mencoba membangun kerangka kerja yang memecahkan masalah bisnis untuk pengguna biasa yang rata-rata. Mungkin saya salah, dan pendapat saya bisa berubah - saya tidak punya banyak pengalaman di Angular2, kami baru saja membangun aplikasi kalkulator tes, pada akhirnya. Halaman perbandingan yang bagus di Vue.js menyebut Angular2 sistem yang bagus, yang memiliki banyak gagasan yang sama dengan Vue.js.Vue.js
Vue.js adalah sesuatu yang telah saya tunggu-tunggu sejak lama (selanjutnya saya akan berbicara tentang Vue.js 2, yang telah menerima banyak perbaikan dibandingkan dengan versi pertama Vue, dan ini adalah versi stabil dari sistem saat ini). Bagi saya, dalam hal keanggunan dan keringkasan, serta berfokus pada solusi untuk masalah-masalah dunia nyata, Vue.js adalah terobosan terbesar di JS sejak hari saya dikejutkan oleh Jquery pada 2007. Jika Anda melihat grafik popularitas Vue.js, maka perhatikan bahwa tahun ini dia senang bukan hanya saya:On Vue Github - Top 1 proyek JS 2016 (antara lobak dengan kode sumber).Dengan popularitas di Google Trends, Vue.js pada tahun 2016 secara tajam mengungguli React (tentu saja, ini adalah suhu rata-rata di rumah sakit yang sangat besar, dan sangat bergantung pada permintaan yang dirumuskan - tanda popularitas yang sangat tidak langsung).https://www.google.com/trends/explore?q=vue.js,react.js,angular.jsVue.js adalah salah satu yang paling cepat berkembang (dalam hal komunitas atau setidaknya jumlah suka di github , dan pengguna Vue Dev Tools di chrome) solusi JS pada tahun 2016, dan saya yakin ini bukan hanya perpustakaan modis untuk para hipsters yang beralih ke kerangka JS baru setiap 3 bulan, atau pekerjaan departemen PR adalah hal besar perusahaan.Laravel telah menambahkan Vue.js ke kernel, dan ini adalah klaim serius.Pro Vue.js
Vue.js menjaga keseimbangan yang sangat baik antara keterbacaan, pemeliharaan kode dan kesenangannya, kode ini, penulisan. Keseimbangan ini terletak pada jarak yang kira-kira sama antara React dan Angular 1, dan jika Anda melihat pedoman vue.js, Anda akan segera melihat berapa banyak ide berguna yang ia pinjam dari sistem ini.Dari React Vue.js saya mengambil pendekatan komponen, properti, aliran data satu arah untuk hierarki komponen, kinerja, kemampuan untuk membuat di backend dan pentingnya manajemen negara yang tepat. Vue.js mengambil dari template serupa Angular1 dengan sintaks yang baik dan penjilidan dua arah, tetapi hanya di mana Anda benar-benar membutuhkannya dan tidak akan memungkinkan Anda untuk segera menembak kaki Anda (di dalam satu komponen). Sangat mudah untuk mulai menulis kode di bawah Vue.js - Saya melihat ini di tim kami. Vue.js tidak memerlukan kompiler default, jadi sangat mudah untuk menambahkan Vue.js ke basis kode lawas Anda dan mulai menyalin hash jQuery ke kode yang dapat dibaca.Jumlah sihir yang tepat
Vue.js sangat sederhana untuk bekerja baik dalam hal pendekatan HTML-sentris dan dari sudut pandang pengembang JS: Anda dapat membuat templat yang cukup kompleks tanpa kehilangan fokus pada tugas bisnis, dan templat HTML yang dihasilkan biasanya dibaca dengan baik bahkan ketika dia sudah besar. Pada saat ini, sebagai suatu peraturan, Anda telah membuat kemajuan yang baik dalam menyelesaikan masalah bisnis dan Anda mungkin ingin mengatur ulang template dan membaginya menjadi komponen yang lebih kecil - pada saat ini Anda melihat "gambar" seluruh aplikasi Anda jauh lebih baik daripada di awal. Pengalaman saya menunjukkan bahwa ini sangat berbeda dari pendekatan yang biasanya digunakan programmer Bereaksi, dan perbedaan ini menghemat banyak waktu dan upaya untuk programmer menggunakan Vue.js. Dalam Bereaksi Anda dipaksa untukmemecah komponen menjadi komponen mikro dan fungsi mikro tepat pada saat penulisan awal, "konsep" versi kode, jika tidak Anda akan secara harfiah dimakamkan dalam tumpukan kurung keriting dan HTML di antara mereka. Di Bereaksi, saya menghabiskan banyak waktu untuk memoles alat peraga dan merefaks komponen super kecil (yang, tentu saja, tidak akan pernah digunakan kembali) lagi dan lagi, karena saya tidak melihatnya dengan jelas ketika saya tiba-tiba perlu mengubah logika kode di tengah proses.Bentuk
Bekerja dengan formulir HTML di Vue.js adalah suatu kesenangan. Di sinilah pengikatan dua sisi sangat membantu. Bahkan dalam kasus-kasus sulit, tidak ada masalah, meskipun pengamat mungkin sekilas menyerupai Angular 1. Aliran data satu arah selalu siap melayani Anda ketika Anda membagi komponen.Teknologi
Jika Anda ingin kompilasi, linting, PostCSS dan ES6 tidak menjadi masalah . Komponen file tunggal tampaknya menjadi cara utama untuk menulis komponen publik di Vue.js 2. Omong-omong, gagasan Scoped CSS yang bekerja dalam komponen file tunggal di luar kotak adalah sesuatu yang terlihat sangat bagus dan dapat mengurangi kebutuhan akan aturan penamaan CSS yang ketat kelas dan teknologi seperti BEM .Manajemen negara
Vue.js memiliki manajemen negara yang cukup sederhana dan bermanfaat melalui metode data () dan props () - mereka bekerja dengan baik dalam pengembangan nyata. Jika jiwa meminta sesuatu yang lebih untuk manajemen negara, ada Vuex (yang, menurut saya, mirip dengan Mobx dalam Bereaksi - negara bisa berubah di sana). Saya pikir persentase yang baik dari aplikasi Vue.js tidak akan memerlukan manajemen negara melalui Vuex, tetapi senang memiliki alternatif.Performa
Temanya holistik, pada umumnya, keduanya bereaksi dan vue.js cepat. Namun demikian, ternyata, vue.js rata-rata terasa lebih cepat.Tautan yang luar biasa dari komentar di TodoMVC dijalankan dengan pengukuran:eigenmethod.imtqy.com/mol/app/bench/#bench=#2Ftodomvc%2Fbenchmark%2F#sample=angular2~angularjs ~mol~react~vue ~vanillajs#sort=fort#Dan di sini ada akun yang lebih detail (dari pihak yang berkepentingan) .Perbandingan benchmark terperinci dan dapat dipahami lainnya:stefankrause.net/js-frameworks-benchmark4/webdriver-ts/table.htmlCons VueJS
Kesalahan templat runtime
Terbesar: kesalahan runtime yang tidak menyenangkan di templat. Korban untuk kenyamanan menulis kode. Ini sangat mirip dengan Angular 1. Vue.js berhasil menghasilkan banyak peringatan berguna untuk kode JS: misalnya, ada peringatan ketika Anda mencoba untuk memutasikan alat peraga atau menggunakan metode data () secara tidak benar, pengaruh positif dari Bereaksi sangat terlihat di sini. Namun kesalahan templat runtime masih menjadi kelemahan Vue.js. Jejak tumpukan pengecualian seringkali tidak berguna dan mengarah ke metode internal Vue.js. Dalam kasus ini, dalam kelas kesalahan dan debugging ini, JSX seringkali lebih menyenangkan: karena kompilasi "dari JS ke JS", mengklik pada kesalahan di konsol browser biasanya mengarah ke tempat kesalahan ini terjadi pada kode.Perpustakaan
Infrastruktur Vue.js masih cukup muda. Bahkan, komponen stabil dari komunitas dapat dihitung dengan jari, dan banyak dari mereka dibangun untuk Vue.js 1, dan seringkali tidak begitu mudah bagi pemula untuk mencari tahu versi Vue.js mana yang dibangun untuk perpustakaan tertentu. Masalah ini dikurangi dengan fakta bahwa Anda dapat melakukan hal-hal keren di Vue.js tanpa mengalami banyak kebutuhan untuk perpustakaan pihak ketiga. Anda mungkin hanya memerlukan pustaka untuk permintaan Ajax ( vue-resource akan menjadi pilihan yang baik jika Anda tidak peduli dengan aplikasi isomorfik, jika tidak Axios ) dan mungkin Vue-router, yang dianggap sebagai perpustakaan dengan dukungan yang baik dari Vue.js.Komunitas berbahasa non-Inggris
Komentar Cina dalam kode sebagian besar repositori publik, dan ini tidak mengejutkan: Vue.js menjadi solusi yang sangat populer di Cina (Vue.js berbicara dalam bahasa Cina)Proyek satu orang.
Alih-alih, masalah potensial daripada yang sebenarnya, tetapi kadang-kadang Anda ingin bermain aman. Evan You adalah orang yang membangun Vue setelah bekerja di Google dan Meteor. Laravel, tentu saja, juga merupakan proyek pria lajang, namun ia masih sangat sukses, bukan?Vue.js di Drupal
Penafian: kami tidak berencana untuk menggunakan Drupal 8 dalam waktu dekat di Qwintry, karena kami pindah ke kerangka kerja PHP dan Node.js yang lebih modern, lebih cepat dan lebih sederhana, tetapi kode lawas kami adalah Drupal. Karena situs utama qwintry.com berjalan di Drupal, sangat penting bagi kami untuk memeriksa Vue.js dalam pertempuran di sini. Sejujurnya, saya tidak bangga dengan banyak bagian dari kode kami di repositori ini, kami berusaha untuk tidak masuk ke beberapa tempat yang menonjol sementara itu bekerja setidaknya entah bagaimana, tetapi proyek lama dengan sejarah ini berfungsi dengan cukup baik dan menghasilkan pendapatan kami, jadi kami menghormatinya, memperbaikinya, dan banyak fitur baru datang ke sini. Berikut adalah daftar hal-hal yang saya buat di Vue di Drupal: formulir editor entitas cepat yang mencakup pembuatan faktur pelanggan serta pengeditan cepat daftar produk.Di sini perlu untuk membangun API JSON sederhana untuk memuat dan menyimpan entitas - tidak ada yang istimewa, hanya beberapa panggilan balik. Dua dasbor, melalui Saas REST API dari produk yang kami gunakan untuk tim dukungan kami, sehingga operator tidak perlu menjalankan melalui halaman admin situs web individu untuk memeriksa informasi terkait dengan klien tertentu. Sekarang semua ini dibangun langsung ke profil klien di situs web kami. Saya tahu banyak pengembang backend masih terjebak pada 2010 dengan sistem kernel Ajax Drupal. Saya tahu betul betapa rumitnya kode Drupal ketika Anda mencoba membangun semacam bentuk multi-tahap yang kompleks menggunakan fungsi Ajax dari kernel - hampir tidak mungkin untuk mempertahankan kode tersebut nanti. Ya, saya berbicara tentang Anda, ctools_wizard_multistep_form (), dan Anda,melalui Saas REST API dari produk yang kami gunakan untuk tim dukungan kami, sehingga operator tidak harus menjalankan melalui halaman admin situs web individu untuk memeriksa informasi terkait dengan klien tertentu. Sekarang semua ini dibangun langsung ke profil klien di situs web kami. Saya tahu banyak pengembang backend masih terjebak pada 2010 dengan sistem kernel Ajax Drupal. Saya tahu betul betapa rumitnya kode Drupal ketika Anda mencoba membangun semacam bentuk multi-tahap yang kompleks menggunakan fungsi Ajax dari kernel - hampir tidak mungkin untuk mempertahankan kode tersebut nanti. Ya, saya berbicara tentang Anda, ctools_wizard_multistep_form (), dan Anda,melalui Saas REST API dari produk yang kami gunakan untuk tim dukungan kami, sehingga operator tidak harus menjalankan melalui halaman admin situs web individu untuk memeriksa informasi terkait dengan klien tertentu. Sekarang semua ini dibangun langsung ke profil klien di situs web kami. Saya tahu banyak pengembang backend masih terjebak pada 2010 dengan sistem kernel Ajax Drupal. Saya tahu betul betapa rumitnya kode Drupal ketika Anda mencoba membangun semacam bentuk multi-tahap yang kompleks menggunakan fungsi Ajax dari kernel - hampir tidak mungkin untuk mempertahankan kode tersebut nanti. Ya, saya berbicara tentang Anda, ctools_wizard_multistep_form (), dan Anda,Sekarang semua ini dibangun langsung ke profil klien di situs web kami. Saya tahu banyak pengembang backend masih terjebak pada 2010 dengan sistem kernel Ajax Drupal. Saya tahu betul betapa rumitnya kode Drupal ketika Anda mencoba membangun semacam bentuk multi-tahap yang kompleks menggunakan fungsi Ajax dari kernel - hampir tidak mungkin untuk mempertahankan kode tersebut nanti. Ya, saya berbicara tentang Anda, ctools_wizard_multistep_form (), dan Anda,Sekarang semua ini dibangun langsung ke profil klien di situs web kami. Saya tahu banyak pengembang backend masih terjebak pada 2010 dengan sistem kernel Ajax Drupal. Saya tahu betul betapa rumitnya kode Drupal ketika Anda mencoba membangun semacam bentuk multi-tahap yang kompleks menggunakan fungsi Ajax dari kernel - hampir tidak mungkin untuk mempertahankan kode tersebut nanti. Ya, saya berbicara tentang Anda, ctools_wizard_multistep_form (), dan Anda,ajax_render !Pada saat yang sama, pengembang ini didorong maju oleh persyaratan untuk antarmuka modern, tetapi kompleksitas infrastruktur JS modern mendorong mereka ke dalam depresi. Ya, saya mengenali diri saya setahun yang lalu. Jadi teman-teman, dengarkan aku! Anda tidak akan menemukan momen dan cara yang lebih baik untuk meningkatkan antarmuka Anda daripada saat ini, ambil Vue.js, masukkan ke dalam situs / semua / pustaka, tambahkan dengan drupal_add_js () ke templat dan mulai menulis kode. Anda akan terkejut melihat betapa mudahnya memelihara sistem di mana Drupal hanya bertanggung jawab atas JSON yang dihasilkan ketika semua kode klien, termasuk formulir, ditenagai sepenuhnya oleh Vue.js.Vue.js dalam Yii2
Fakta menyenangkan: Yii diciptakan oleh pengembang berbahasa Mandarin Qiang Xue. Dengan demikian, seseorang dapat memanggil Yii + Vue. Ia bukan hanya tumpukan, nama yang hampir mustahil untuk diucapkan pada percobaan pertama, tetapi juga tumpukan dengan warisan Cina (dalam cara yang baik). Untuk versi baru Qwintry.com (belum dipublikasikan), kami memilih Yii2, yang, menurut pendapat saya, adalah salah satu kerangka kerja PHP terbaik dan tercepat. Ini jelas tidak sepopuler Laravel, yang telah memimpin di dunia PHP, tetapi tumpukan Yii2 cukup baik bagi kita.(walaupun kami melihat Laravel dari waktu ke waktu, para pengembang di sana memanfaatkan, dan tentu saja, infrastruktur yang lebih matang dalam hal perpustakaan). Kami secara bertahap mengurangi jumlah HTML yang dihasilkan Yii2 dan PHP, lebih fokus pada REST API, yang menghasilkan JSON untuk sisi klien, berjalan di Vue.js / Swift / Java. Pendekatan API-pertama digunakan untuk sebagian besar model Rekaman Aktif kami di proyek. Di sini kita sudah serius tentang API dan itulah sebabnya kami menghabiskan banyak waktu untuk dokumentasi API yang baik, bahkan jika API ini tidak bersifat publik. Di bagian kode di mana bagian HTML dihasilkan di tingkat PHP, kami menggunakan solusi dan paket web kami sendiri untuk bundling dan penyebaran nyaman widget Yii2, yang, pada gilirannya, menggunakan komponen file tunggal Vue. Dengan PHP7 & MySQL terbaru, waktu respons backend Yii2 JSON kami tidak jauh berbeda dari Node.js backends (saya berbicara tentang kecepatan respons dari urutan 15-20 ms), ini bukan angka kosmik, terus terang, tapi ini lebih dari cukup untuk kebutuhan kita, dan, yang paling penting, ini 10-20 kali lebih cepat daripada apa yang bisa diberikannya situs Drupal lama kami. Pada saat yang sama, ini adalah PHP lama yang baik (dan membosankan, mungkin) dengan semua kekuatan perpustakaan komposer dan basis kode yang stabil. Responsif dari antarmuka yang dibangun di atas Yii2 & Vue.js sangat dapat diterima, dan, dari sudut pandang keterbacaan kode, semuanya sudah beres di sini juga.Responsif dari antarmuka yang dibangun di atas Yii2 & Vue.js sangat dapat diterima, dan, dari sudut pandang keterbacaan kode, semuanya sudah beres di sini juga.Responsif dari antarmuka yang dibangun di atas Yii2 & Vue.js sangat dapat diterima, dan, dari sudut pandang keterbacaan kode, semuanya sudah beres di sini juga.Kami juga menggunakan Vue.js di sejumlah proyek internal dan eksternal, di mana backend berjalan pada Node.js - Saya tidak akan menambahkan sesuatu yang baru di atas, semuanya berfungsi dengan baik.Kesimpulan
Kami telah menulis kode Vue.js setiap hari selama sekitar 4 bulan di berbagai proyek, dan hasilnya mengesankan. 4 bulan bukanlah apa-apa di dunia backend, tetapi untuk dunia JS ini adalah periode yang layak untuk mana lima kerangka kerja lahir dan mati :) Mari kita lihat apa yang terjadi selanjutnya. Saya pikir Vue.js akan menjadi solusi utama untuk JS dalam 16-24 bulan ke depan jika Evan You mengambil langkah yang tepat, setidaknya di antara tim back-end dan tim kecil front-end. React stack akan menjadi arus utama pada 2017, terutama jika React Native terus tumbuh dan meningkat pada kecepatan yang sama seperti sekarang.UPD: Artikel ini menghantam bagian atas HackerNews, dan ada terjadi diskusi yang berguna (250 + komentar): news.ycombinator.com/item?id=13151317Dalam Reddit atas webdev kami juga mengunjungi, 60 + komentar di sini. Komentar-pendapat lucu tentang Angular2 dari sana:Semua dokumentasi Google seperti membaca dokumen Microsoft sejak awal 2000-an.
"Menyiapkan proyek Angular adalah sepotong kue! Pastikan mutator prototipe referensi berkewarganegaraan mewarisi dari objek warisan loader memori dasar yang mengimplementasikan penyedia layanan MODOK (bukan bagian dari inti: lihat di sini untuk detail yang sama-sama tidak terbaca). Anda kemudian akan siap untuk mengkompilasi kernel Angular Anda, berhati-hati untuk menggunakan Webpack 2.3.9 (catatan: tidak 2.3.8 seperti yang disertakan dengan repositori). Ini semua yang perlu Anda ketahui untuk memulai proyek Angular yang hebat. Angular: membuat pengembangan menjadi sederhana dan menyenangkan lagi! ”
Pertanyaan dari pembaca:
JSX itu keren dan benar, tetapi Anda tidak terlalu! Jika Anda benar-benar menginginkan kondisi - memprogram komponen If Anda, ini adalah tiga baris!Tidak menyenangkan untuk memilih kerangka kerja, dan kemudian melakukan hal-hal seperti itu terhadapnya, setiap pengembang baru yang datang ke proyek akan bertanya kepada Anda tentang keputusan seperti itu, dan dalam komponen orang lain, mata Anda akan selalu tersandung pada keberagaman.Apalagi, jika komponen yang ditulis "dahi" akan mengalami masalah di mana komponen internal selalu dijalankan. Tetapi ada solusi yang lebih menarik: github.com/AlexGilleran/jsx-control-statementsJadi apa yang Anda sarankan, sayang, sekarang Anda perlu segera drop React dan tulis ulang semuanya ke Vue.js?Tidak, tidak! Bereaksi adalah kerangka kerja yang sangat baik, dan itu memungkinkan Anda untuk menulis kode yang dapat dibaca dan didukung, dan juga sejumlah besar perpustakaan berkualitas tinggi telah ditulis untuk itu (dan komponen mikro dan batasan JSX, yang saya “dimarahi” di atas, memainkan peran positif di sini, untuk perpustakaan umum ini adalah sudah sering dibenarkan), yang bukan untuk solusi JS lainnya. Jika Anda dan tim Anda senang dengan semua yang ada di BEJ dan Anda tidak repot-repot mengetik, mungkin tidak ada gunanya beralih ke Vue.js, permainan ini sama sekali tidak sebanding dengan lilin. Banyak pecinta JS baru-baru ini suka melompat dari satu kerangka kerja ke kerangka kerja lainnya. Jangan menyalahgunakannya, menurut saya, lebih baik menghabiskan waktu ini untuk sesuatu yang lebih menarik yang akan diperhatikan oleh pengguna proyek Anda.Tetapi jika Anda tidak dapat mulai menggunakan Bereaksi karena alat besar dan kesulitan lainnya, dan kode Anda muncul dengan jQuery atau Backbone berantakan, Vue.js bisa menjadi pilihan bagus, bukan akademis, sederhana dan ringkas.Saya tidak membaca keseluruhan artikel, tetapi dalam tajuk utama Anda mengatakan sesuatu yang negatif di sana tentang kekebalan, Anda mungkin bukan Ortodoks karena kurangnya pengalaman dan kebodohan Anda, Anda tidak mengerti betapa indahnya pendekatan fungsional!Mari kita pisahkan imunitas sebagai paradigma fungsional (kami sangat menghargai pendekatan fungsional, konsep imunitas dan kemurnian fungsi) dan kondisi terkini dari dunia JS dan perpustakaannya. Jika seorang pengembang, setelah membaca blog Facebook, dengan senang hati meraih Immutable.js dan memproduksinya, dan kemudian menyadari bahwa ia tidak memiliki dock yang sangat bagus, Lodash dan semua kode lainnya yang ditulis oleh pengembang generasi sebelumnya tidak bekerja dengannya (ya, saya tahu tentang pembungkus abadi di sekitar lodash, terima kasih), dan karena itu pengembang gagal tenggat waktu - ini berarti bahwa pengembang tidak membeli paradigma fungsional, melainkan gembar-gembor di sekitar perpustakaan tertentu. Jangan berpikir bahwa jika Facebook memiliki masalah nyata yang mereka selesaikan dengan menggunakan Immutable.js, maka ini berarti bahwa Anda akan memiliki masalah dengan urutan yang sama di halaman arahan atau SPA Anda.Kemungkinan besar tidakinvestor Anda akan kehabisan uang, Anda harus meluncurkan fitur yang berfungsi secepat mungkin, dan itu sudah cukup untuk kode menjadi normal dan tidak bermutasi di mana tidak perlu, itu tidak perlu menggunakan Immutable.js untuk ini (baca pendapat tentang Immutable.js, misalnya, di sini ). Secara terpisah, saya perhatikan bahwa sejumlah besar pengembang JS, yang pendapatnya saya lihat sebagai fitur pembunuh utama Immutable.js, disebut bukan kemurnian dan keandalan kode yang dihasilkan, tetapi - perhatian! - meningkatkan produktivitas (kita berbicara tentang perbandingan cepat struktur)! Sesuatu di dunia ini salah jika orang mendorong bagian fungsional tingkat ini demi peningkatan kinerja ke dalam proyek mereka. Tampaknya fashion telah kembali turun tangan ...Jika Anda ingin menyederhanakan hidup Anda, berhentilah bermutasi, beralihlah ke alat peraga, dan hal-hal sederhana ini akan meningkatkan kehidupan Anda saat ini.