Tulis Sekali, Terapkan Di Mana Saja: Kapan Harus Native?

Write Once, Deploy Everywhere (WODE) telah menjadi janji banyak kerangka kerja pengembangan selama dekade terakhir, yang tujuannya adalah untuk meringankan kesulitan menulis beberapa aplikasi asli. Menentukan jalur mana yang harus diambil adalah salah satu keputusan paling kritis yang harus dibuat oleh manajer proyek karena biaya startup yang tinggi, dampaknya terhadap tim pengembangan, dan potensi ketidaklayakan untuk mundur.

Solusi hibrid seperti Ionic memanfaatkan teknologi web untuk merender aplikasi di seluruh platform, tetapi seringkali, produk akhir tidak memenuhi harapan pengguna akan tampilan dan nuansa asli .

Namun, bahkan istilah "asli" baru-baru ini telah dikacaukan oleh kerangka kerja yang dikompilasi ke kode asli (misalnya, React Native, Xamarin, dll.).

Artikel ini menguraikan pro dan kontra dari berbagai jalur pengembangan seluler dan membandingkannya dengan susunan tim, biaya, dan pengalaman pengguna dalam upaya memberdayakan manajer produk untuk membuat keputusan yang lebih tepat.

Tulis Sekali, Terapkan Di Mana Saja

Konsep Write Once, Deploy Everywhere mengacu pada kemampuan tim pengembangan untuk menulis aplikasi satu kali—menggunakan satu tumpukan pengembangan, abstrak platform tempat aplikasi akan di-deploy—namun mempertahankan kemampuan untuk menyebarkan aplikasi ke semua platform yang diinginkan, misalnya Android, iOS, Windows, dll. Idealnya, ini dilakukan tanpa mengorbankan pemeliharaan, kinerja, atau pengalaman pengguna (UX).

Metode alternatif - dan historis - dari pengembangan aplikasi seluler melibatkan proses langsung dengan menulis aplikasi terpisah untuk setiap platform, yang, tentu saja, membawa potensi biaya waktu dan sumber daya yang tinggi.

Secara umum, faktor-faktor yang perlu dipertimbangkan ketika memilih jalur pengembangan meliputi:

• Usia proyek
• Riasan dan ukuran tim pengembangan
• Platform yang diinginkan untuk distribusi
• Garis waktu yang diperlukan untuk memasarkan
• Bandwidth yang tersedia untuk diubah ke jalur lain jika harus

Sayangnya, menerapkan masing-masing faktor ini ke masing-masing jalur yang tersedia, serta mengarungi berbagai pendapat yang tersedia tentang masalah ini, bisa sangat menakutkan. Selain itu, proses ini sering membuat manajer proyek merasa tidak pasti tentang jalur mana yang terbaik untuk memenuhi persyaratan aplikasi.

Pada tingkat tinggi, jalur pengembangan seluler yang berbeda dapat dimasukkan ke dalam dua kategori: asli atau WODE, yaitu asli atau yang lainnya. Sederhananya, seseorang menulis aplikasi asli atau tidak. Kategori WODE selanjutnya dipecah menjadi dua kelompok:

• Kerangka kerja hibrida - kerangka kerja yang memanfaatkan teknologi web untuk membuat aplikasi di berbagai platform.
• Kerangka kerja non-hibrida - kerangka kerja yang menggunakan komponen UI asli (misalnya, tombol, bidang teks, dan bahkan pengelola tata letak) alih-alih merender tampilan web di dalam aplikasi seperti yang dilakukan kerangka kerja hibrid.

Sebagian besar kerangka kerja WODE adalah hibrida ; namun, untuk meningkatkan kinerja dan batasan UX dari kerangka kerja hybrid sambil tetap memberikan manfaat kerangka kerja WODE, tren saat ini adalah menuju non-hibrida . Karena tren ini, kerangka kerja seperti React Native, Xamarin, dan Appcelerator semakin populer.

Masing-masing jalur ini—native, hybrid, dan non-hybrid—memiliki kekuatan dan kelemahan yang berbeda, dan akibatnya, masing-masing memiliki kasus penggunaan berbeda yang paling cocok. Sisa artikel ini menguraikan pro dan kontra dari setiap jalur pengembangan seluler saat mempertimbangkan prioritas yang bersaing seperti susunan tim, biaya proyek, dan UX. Dengan pengecualian beberapa kasus penggunaan khusus, menulis aplikasi asli memaksimalkan pengalaman pengguna dengan biaya yang sedikit lebih tinggi.

Secara umum, pepatah “ Anda mendapatkan apa yang Anda bayar ” berlaku, jadi jika biaya lebih penting daripada pengalaman pelanggan, native mungkin bukan pilihan yang tepat. Namun, begitu UX menjadi vital, aplikasi asli menjadi pilihan yang jelas karena, untuk meningkatkan UX, aplikasi berbasis WODE mengeluarkan biaya yang cukup besar dalam bentuk waktu atau keahlian asli, yang mengalahkan tujuan memilih non-asli. jalur pengembangan terlebih dahulu.

Lebih jauh lagi, bahkan jika biaya itu dibayar, produk akhir berbasis WODE akan selalu memberikan UX yang lebih rendah jika dibandingkan dengan rekan aslinya. Akibatnya, native hampir selalu menjadi pilihan yang tepat untuk sebagian besar tim pengembangan dan untuk sebagian besar proyek.

Aplikasi Asli

Aplikasi asli ditulis dalam bahasa inti dari platform yang diberikan. Misalnya, aplikasi Android ditulis dalam Java, sedangkan aplikasi iOS ditulis dalam Obj-C atau Swift. Mereka membutuhkan insinyur pengembangan untuk memahami bahasa serta nuansa khusus platform, yang mencakup, misalnya, integrasi paket pihak ketiga, manajemen tata letak, interaksi sistem operasi (OS), dan sebagainya.

kelebihan

Sangat dapat disesuaikan . Karena setiap aplikasi ditulis menggunakan komponen asli, satu-satunya batasan untuk penyesuaian adalah antarmuka ke kerangka kerja yang mendasarinya, dan terkadang tidak demikian. Seperti yang akan dibuktikan oleh sebagian besar insinyur pengembangan asli, sering kali ada cara untuk menyelesaikan tugas tertentu meskipun antarmukanya terbatas.

Bukti sederhana dari ide ini dapat ditemukan dengan menelusuri komunitas dukungan untuk platform tertentu. Seseorang akan menemukan banyak contoh bagaimana menyelesaikan tugas yang mungkin “tidak dapat dipesan”, terlepas dari keterbatasan kerangka kerja yang mendasarinya.

Contoh nyata iOS dari tugas yang tampaknya sederhana mungkin untuk menampilkan overlay layar penuh, di atas semua elemen UI eksternal, misalnya, bilah tab, bilah navigasi, dll. Seperti yang ditunjukkan pada Gambar 1 , ini biasanya di luar cakupan lapisan UI normal saat ini sedang disajikan. Dengan demikian, untuk memiliki overlay layar penuh, itu harus ditambahkan ke lapisan tersembunyi di atas bilah tab di tumpukan tampilan. Kustomisasi semacam ini biasanya hanya mungkin dilakukan pada aplikasi asli.

Performa tertinggi . Seperti yang diharapkan, aplikasi asli menetapkan tolok ukur kinerja. Karena sebagian besar jenis kerangka kerja lainnya menambahkan satu atau lebih lapisan perantara, mereka secara inheren berjalan lebih lambat daripada aplikasi asli.

Paling bisa dipertahankan . Sistem operasi berubah terus-menerus. Periode. Ketika mereka melakukannya, tergantung pada apakah perubahan yang melanggar dibuat, aplikasi harus diperbarui secara tepat waktu agar tidak kehilangan bagian dari basis pengguna yang meningkatkan ke OS yang lebih baru. Jelas, semakin sedikit waktu yang berlalu antara saat perubahan tersedia untuk pengguna dan aplikasi diperbarui, semakin baik. Waktu ini diminimalkan ketika tidak ada dependensi yang perlu diperbarui untuk mendukung OS baru ini, seperti halnya ketika bekerja pada aplikasi asli.

Kontra

Sumber daya tambahan . Saat menulis aplikasi untuk beberapa platform, tim pengembangan biasanya terdiri dari satu atau lebih insinyur perangkat lunak seluler untuk setiap platform yang didukung. Ini, tentu saja, secara inheren meningkatkan ukuran dan biaya tim pengembangan. Ini juga membutuhkan tim insinyur untuk memiliki berbagai keterampilan, sebagai lawan memiliki basis keterampilan yang homogen. Ini berpotensi memecah tim terkait dengan dukungan dan kolaborasi.

Siklus perkembangan yang lebih lambat . Aplikasi asli berpotensi memiliki siklus pengembangan yang lebih lambat hanya karena aplikasi terpisah harus ditulis untuk setiap platform yang diinginkan. Kasus ekstremnya adalah ketika ada seorang insinyur pengembangan seluler dalam tim karena setiap aplikasi pada dasarnya ditulis secara seri.

Kinerja rendah . Mungkin tampak aneh untuk memiliki kinerja baik sebagai pro dan kontra. Di satu sisi, aplikasi asli memberi pengembang cukup ruang untuk membuat aplikasi berkinerja tinggi yang disetel dengan baik. Namun, di sisi lain, mereka juga memberi pengembang tali yang cukup untuk menggantung diri. Jika mereka tidak tahu apa yang mereka lakukan, pada akhirnya, mereka akan mendapatkan aplikasi di bawah standar.

Catatan: Secara umum, ini berlaku untuk semua jalur framework (native, hybrid, dan non-hybrid). Jika insinyur yang mengembangkan aplikasi memiliki keterampilan yang tidak memadai untuk apa yang mereka coba, aplikasi yang dihasilkan kemungkinan tidak akan memenuhi persyaratan desain atau diterima dengan baik oleh pengguna.

Aplikasi Hibrida

Aplikasi hybrid biasanya ditulis menggunakan HTML/CSS/LESS untuk mendesain antarmuka pengguna: "V" dalam pola desain MVC. "C," atau pengontrol, kemudian biasanya ditulis dalam JavaScript - idealnya, menggunakan kerangka kerja JavaScript MVC seperti AngularJS. Penggunaan kerangka kerja seperti AngularJS memungkinkan pemisahan kelas dan tanggung jawab yang lebih baik daripada biasanya hanya menggunakan jQuery.

Contoh dari jenis tumpukan kerangka kerja hibrida ini adalah lapisan tampilan ionik yang didukung oleh AngularJS, yang pada akhirnya dikonversi dan dirender dalam tampilan web pada platform yang diinginkan menggunakan PhoneGap dan Cordova. Jelas, jenis kerangka kerja WODE ini datang dengan biaya kompleksitas tambahan.

Selain itu, penggunaan JavaScript membawa serta keterbatasan berbasis desain dan masalah berbasis bahasa. Tujuan artikel ini bukan untuk memperdebatkan kelebihan atau kekurangan dari satu bahasa; namun, sebagai manajer proyek, pilihan untuk menggunakan JavaScript di tumpukan teknis seluler tidak boleh dianggap enteng. Berikut ini adalah beberapa contoh artikel yang ditulis dengan baik tentang mengapa JavaScript harus dihindari jika memungkinkan:

• Masalah JavaScript
  
• Mengapa saya bukan React Native Developer

kelebihan

Tim pengembangan minimal . Kerangka kerja hibrid memungkinkan tim pengembangan kecil—dan khususnya tim yang basis pengetahuan utamanya adalah pengembangan web—untuk dengan cepat menghasilkan aplikasi sederhana di berbagai platform. Hal ini memungkinkan manajer proyek untuk menjaga timnya tetap kecil serta menghilangkan kebutuhan timnya untuk mempelajari bahasa dan kerangka kerja asli untuk berbagai platform.

Siklus perkembangan yang lebih cepat . Selain tim yang lebih kecil, kerangka kerja hybrid menghasilkan siklus pengembangan yang lebih cepat saat diterapkan ke beberapa platform karena hanya satu lapisan tampilan yang perlu dirancang menggunakan teknologi web.

Kontra

UX yang berpotensi buruk . Kelemahan dari hanya harus menulis satu lapisan tampilan adalah yang tersisa dengan satu lapisan tampilan. Ini dapat menghasilkan UX yang buruk karena pendekatan satu ukuran untuk semua desain UI gagal memberikan tampilan dan nuansa aplikasi yang nyaman dan akrab bagi pengguna di semua platform. Selain itu, karena aplikasi hibrid pada dasarnya adalah tampilan web yang disematkan di dalam UI, aplikasi ini dapat memberi kesan kepada pengguna bahwa mereka benar-benar melihat halaman web alih-alih berinteraksi dengan aplikasi asli. Pengalaman ini hampir selalu berdampak negatif pada kepuasan pengguna, dan pada akhirnya retensi.

Mahal untuk menyesuaikan . Meningkatkan UX dengan merancang UI yang disesuaikan untuk setiap platform menghasilkan kerangka kerja UI yang kompleks dan unik yang bisa mahal untuk dibuat dan sulit dipertahankan seiring waktu. Selanjutnya, untuk membuat elemen UI yang akan membantu membuat aplikasi seseorang menonjol (misalnya, animasi, tampilan kustom, dll.), komponen jembatan yang disesuaikan harus dibuat untuk menerjemahkan desain UI tingkat tinggi menjadi sesuatu yang kerangka tingkat lebih rendah , seperti Cordova, akan mengerti. Secara umum, semakin seseorang menyesuaikan dan meningkatkan UX dari aplikasi hybrid, semakin mengurangi manfaat dari siklus desain yang cepat dan murah.

Kinerja yang lebih rendah . Karena aplikasi hibrid merender tampilan aplikasi dalam tampilan web, ada potensi besar untuk membuat kesalahan implementasi saat berhadapan dengan kerangka kerja OS (misalnya, jaringan, Bluetooth, kontak pada perangkat, dll.), yang mengakibatkan penurunan kinerja yang sangat parah. Perlu juga dicatat bahwa, meskipun kinerja sangat diperhatikan karena semuanya ditampilkan melalui tampilan web, kinerja maksimum aplikasi hibrida akan selalu sedikit lebih rendah daripada rekan asli mereka.

Manajemen plugin non-sepele . Ingat fitur kustom yang tim desain menghabiskan waktu berminggu-minggu untuk memoles, yang diikuti oleh beberapa minggu lagi sementara tim pengembangan membuat komponen jembatan yang diperlukan sehingga Cordova dapat bekerja dengan mereka? Yah, mereka tidak akan berfungsi kecuali ada plugin Cordova yang mendukung untuk apa yang coba dicapai oleh tim. Ini berarti salah satu dari dua hal: baik tim membuatnya sendiri atau plugin pihak ketiga yang sesuai perlu ditemukan yang berfungsi. Sayangnya, lebih sering daripada tidak, opsi dua tidak ada. Akibatnya, diperlukan waktu pengembangan tambahan untuk membuat plugin khusus, diikuti dengan upaya dukungan build—dari waktu ke waktu—untuk mengelola perpustakaan plugin Cordova yang terus bertambah yang diperlukan oleh aplikasi. Tentu saja, ketika pembaruan Cordova terjadi, ada kemungkinan besar bahwa plugin ini juga perlu diperbarui.

keterlambatan dukungan OS . Masalah komponen jembatan bertingkat/plugin Cordova yang disebutkan sebelumnya semakin diperburuk ketika OS mengubah fungsionalitas inti. Setelah Cordova, PhoneGap, dan Ionic telah diperbarui untuk mendukung perubahan, ada kemungkinan bahwa plugin kustom dan komponen jembatan perlu diperbarui juga. Terlepas dari urutan besarnya pekerjaan ini akan membutuhkan, itu menghasilkan waktu tambahan selama aplikasi tidak mendukung pengguna akhir yang telah memperbarui ke OS baru. Ini, tentu saja, adalah skenario terburuk di mana perubahan yang tidak kompatibel dan tidak kompatibel dibuat oleh Apple atau Google, yang tidak pernah terjadi… kan? Secara umum, kerangka kerja perantara apa pun yang berada di luar kendali pengembang dan harus diperbarui terlebih dahulu hanya berfungsi untuk menunda proses. Akhirnya, mengandalkan kerangka kerja perantara dapat menjadi sakit kepala bagi manajer proyek untuk membuat rencana karena waktu kerangka kerja ini tidak diketahui.

Aplikasi Non-hibrida

Aplikasi non-hibrida memulai kehidupan seperti rekan-rekan hibrida mereka - lapisan UI dirancang dalam bahasa platform non-asli: React Native menggunakan HTML/CSS yang didukung oleh JavaScript atau Xamarin, yang didasarkan pada C# karena akar .NET-nya.

Namun, di situlah kesamaan berakhir. Aplikasi non-hibrida mengkompilasi ke kode asli dan merender aplikasi menggunakan komponen platform-asli alih-alih merender melalui tampilan web. Ini menghasilkan kerangka kerja WODE yang, setidaknya di permukaan, memiliki yang terbaik dari kedua dunia.

Seperti yang telah dibahas sebelumnya, memilih untuk menggunakan JavaScript tidak boleh menjadi keputusan yang dibuat dengan mudah, dan mungkin akan menjadi pemecah kesepakatan bagi tim pengembangan yang tidak ingin belajar atau tidak tertarik menggunakan JavaScript.

kelebihan

Performa lebih tinggi dari hybrid . Seperti yang diharapkan, non-hibrida secara inheren memiliki kinerja yang lebih tinggi daripada aplikasi hibrid karena kemampuannya untuk merender aplikasi menggunakan komponen UI asli (tombol, tampilan, pengelola tata letak, dll.) alih-alih mengandalkan tampilan web yang disematkan. Tentu saja, pengembang masih bebas untuk membuat aplikasi yang berkinerja luar biasa atau buruk. Manfaat aplikasi non-hibrida hanyalah bahwa mereka memiliki dasar kinerja yang lebih tinggi jika dibandingkan dengan aplikasi hibrida serupa.

Tim pengembangan minimal . Mirip dengan kerangka kerja hibrid, non-hibrida memungkinkan tim pengembangan kecil—dan khususnya tim yang basis pengetahuan utamanya adalah pengembangan web—untuk dengan cepat menghasilkan aplikasi sederhana di berbagai platform. Hal ini memungkinkan manajer proyek untuk menjaga tim mereka tetap kecil dan mencegah tim mempelajari bahasa dan kerangka kerja asli untuk berbagai platform.

Siklus perkembangan yang lebih cepat . Selain tim yang lebih kecil, kerangka kerja non-hibrida memberikan siklus pengembangan yang lebih cepat saat menerapkan ke beberapa platform, karena hanya satu lapisan tampilan yang perlu dirancang.

Iterasi lebih cepat (Bereaksi) . Kerangka kerja React menyediakan fitur hebat yang memungkinkan perubahan pada aplikasi dirender secara real time: tidak perlu mengkompilasi ulang, membangun kembali, dll. Akibatnya, emulator React adalah alat pengembangan yang sangat kuat yang secara dramatis mengurangi durasi setiap implementasi siklus.

Kontra

Mahal untuk menyesuaikan . Sama seperti mitra hibridanya, ketika aplikasi non-hibrida memerlukan UX untuk ditingkatkan dengan merancang UI yang disesuaikan untuk setiap platform, itu menghasilkan komponen UI yang kompleks dan unik yang bisa mahal untuk dibuat dan sulit untuk dipelihara dari waktu ke waktu. Ini juga berarti menulis komponen jembatan yang disesuaikan untuk melengkapi celah dalam dukungan elemen asli kerangka kerja. Seperti hybrid, biaya ini mengurangi manfaat dari siklus desain yang cepat dan murah, tetapi tidak seperti aplikasi hybrid, komponen bridge ditulis untuk setiap platform yang diinginkan dalam bahasa aslinya . Ini berarti bahwa alih-alih aplikasi non-hibrida menjadi alternatif yang fleksibel untuk tim yang terutama terdiri dari pengembang web, tim yang memilih jalur non-hibrida harus mempelajari tidak hanya bahasa kerangka kerja tertentu (misalnya, JSX atau C#) tetapi juga bahasa asli setiap platform (Java, Obj-C, atau Swift).

Ketergantungan pihak ketiga . Batasan ini mengambil dua bentuk yang berbeda. Dalam kasus React Native, ia mengambil bentuk banyak dependensi, yaitu, kira-kira 650. Hasilnya adalah bahwa ada peluang yang sangat bagus pada waktu tertentu bahwa satu atau lebih dari dependensi tersebut kedaluwarsa. Ini juga berarti bahwa jika terjadi perubahan tingkat OS yang besar, ada kemungkinan besar bahwa sebagian besar atau semua dependensi tersebut perlu diperbarui. Anugrah potensial yang menyelamatkan adalah bahwa Facebook menggunakan React, jadi seseorang akan memiliki gorila seberat 300 pon di sudut mereka.

Dalam kasus Xamarin, masalah ketergantungan pihak ketiga adalah sangat sulit untuk mengintegrasikannya sejak awal. Xamarin mengetahui masalah ini dan menyediakan alat utilitas yang disebut Sharpie. Tujuan alat ini adalah untuk membantu beberapa integrasi, tetapi sayangnya, Sharpie sering mencoba untuk mengkompilasi dan menautkan sumber daya yang salah, yang memaksa pengembang untuk melakukan tugas yang memakan waktu dengan susah payah untuk secara manual memodifikasi parameter kompilasi tingkat rendah agar berhasil menyelesaikan integrasi.

keterlambatan dukungan OS . Aplikasi non-hibrida diganggu oleh masalah yang sama dengan aplikasi hybrid. Kerangka kerja perantara apa pun yang berada di luar kendali pengembang dan harus diperbarui terlebih dahulu hanya berfungsi untuk menunda proses pembaruan aplikasi seseorang untuk mendukung pengguna mutakhir. Selain itu, seperti yang dinyatakan sebelumnya, mengandalkan kerangka kerja perantara dapat menjadi sakit kepala bagi manajer proyek untuk membuat rencana karena waktu kerangka kerja ini tidak diketahui.

Dukungan jangka panjang (React Native) . Masalah ini khusus untuk React Native dan berkaitan dengan fakta aneh bahwa, hingga saat ini, Facebook belum berkomitmen pada rencana dukungan jangka panjang untuk kerangka kerjanya. Dapat dikatakan bahwa ini adalah risiko rendah karena perusahaan menggunakan kerangka kerja sendiri untuk aplikasi selulernya, tetapi perlu jeda bagi manajer proyek mana pun untuk mempertimbangkan mengapa Facebook menolak mengomentari masalah ini.

Memilih Pendekatan yang Tepat

Ketika biaya bukan merupakan pertimbangan utama, Gambar 2 menunjukkan bahwa menulis aplikasi asli hampir selalu merupakan pilihan terbaik saat memanfaatkan susunan tim pengembangan terhadap persyaratan aplikasi. Ketika ada lebih sedikit insinyur pengembangan daripada jumlah platform yang diinginkan, itu menjadi sedikit lebih menarik. Dalam hal ini, menggunakan React adalah pilihan yang tepat jika tim berada di bawah jadwal rilis yang sangat ketat; jika tidak, menjadi native masih merupakan pilihan terbaik.

Ketika tim utamanya adalah tim pengembangan web, dan UX yang disesuaikan diperlukan, lebih baik meminta beberapa anggota tim mengganti topi atau menambahkan beberapa anggota tim untuk menjadikan aplikasi seseorang asli. Sebenarnya tidak ada opsi kerangka kerja yang layak dan dapat dipelihara jika aplikasi memerlukan elemen khusus, yang dilakukan oleh banyak aplikasi.

Namun, jika UX khusus tidak diperlukan, maka, tergantung pada jadwal rilis, mungkin lebih baik menggunakan Ionic atau React. Jika satu tim tidak punya waktu untuk mempelajari BEJ, maka Ionic adalah pilihan yang tepat. Jika tidak, lebih baik memilih React karena sudah membutuhkan banyak dependensi pihak ketiga, dan menambahkan lebih banyak tidak akan memengaruhi siklus pengembangan seseorang.

Setelah biaya proyek menjadi perhatian utama, biasanya, susunan tim yang ada menjadi kurang menjadi prioritas karena langkah pertama adalah menempatkan tim yang tepat untuk melaksanakan rencana proyek untuk biaya yang diproyeksikan. Seperti yang ditunjukkan pada Gambar 3 , aplikasi asli memiliki biaya awal yang lebih tinggi daripada rekan WODE mereka, tetapi juga potensi UX yang lebih tinggi. Selain itu, aplikasi WODE akan selalu terbatas dalam UX mereka, terlepas dari berapa banyak uang dan sumber daya yang diterapkan untuk proyek tersebut.

Saya harap artikel ini menjelaskan pro dan kontra dari berbagai jalur pengembangan seluler, serta membantu dalam menimbang susunan tim terhadap persyaratan aplikasi dan biaya proyek. Pesannya bukan untuk menyampaikan bahwa kerangka kerja WODE lebih rendah dan tidak boleh dicari, melainkan bahwa meskipun ada kasus penggunaan yang valid untuk tidak menggunakan yang asli, orang harus sepenuhnya memahami konsekuensi dari melakukannya.