Jawaban dari perspektif front-end:
Jangan dengarkan semua orang yang mengatakan itu tidak dapat dilakukan, karena layanan web eksperimental San Francisco State University yang saya tulis bersama pada tahun 1996 akhirnya pergi ke surga Internet beberapa tahun yang lalu, dan tidak pernah memerlukan perbaikan kompatibilitas browser tunggal pada waktu itu ; itu hampir setengah dari target 40 tahun Anda. Dan front-end berbasis-JavaScript ini saya buat pada tahun 1998 untuk proyek Stanford Research Institute digantikan dengan sesuatu yang lebih mencolok beberapa tahun kemudian, tetapi tidak ada alasan UI asli masih tidak dapat berjalan hari ini dengan perbaikan kompatibilitas kecil.
Kuncinya adalah memastikan aplikasi Anda hanya menggunakan standar W3C / ECMA yang didukung secara luas dan memiliki desain yang bersih di bawah kendali Anda. Sementara banyak aplikasi web yang ditulis dengan teknologi era 90-an yang trendi tidak akan berfungsi dengan baik atau sama sekali hari ini, aplikasi web era 90-an yang ditulis dengan standar utama masih dilakukan. Mereka mungkin terlihat ketinggalan jaman, tetapi mereka bekerja.
Tujuannya di sini bukan untuk menulis aplikasi web yang akan naik di server mereka dan tetap di sana selama 40 tahun tanpa ada yang menyentuhnya lagi. Ini untuk membangun fondasi yang masih dapat digunakan puluhan tahun ke depan, yang dapat tumbuh untuk mendukung fitur-fitur baru tanpa harus dibangun kembali dari awal.
Pertama-tama, Anda harus membuat kode dengan standar resmi dan hanya dengan standar resmi. Tidak ada fitur JavaScript yang bukan bagian dari standar ECMAScript yang telah diratifikasi; ES5.1 adalah versi saat ini dan umumnya didukung sehingga aman untuk ditargetkan. Demikian juga, versi HTML5, CSS, dan Unicode saat ini bagus. Tidak ada fitur eksperimental JavaScript, CSS3 atau HTML (yang dengan awalan vendor atau tanpa perjanjian 100% antara browser). Dan tidak ada peretas yang kompatibel dengan peramban khusus. Anda dapat mulai menggunakan fitur baru setelah standar dan semua orang mendukungnya tanpa awalan.
Dukungan ES5 akan berarti menjatuhkan IE8 atau yang lebih lama, yang saya sarankan pula karena memerlukan peramban khusus peramban yang tidak akan berguna dalam beberapa tahun. Saya menyarankan Mode Ketat ES5 untuk kesempatan terbaik di umur panjang, yang sebenarnya menetapkan kompatibilitas browser dasar Anda di IE10 dan versi terbaru dari semua orang . Browser tersebut juga memiliki dukungan asli untuk banyak fitur validasi form HTML5 dan placeholder, yang akan berguna untuk waktu yang sangat lama.
Edisi baru ECMAScript mempertahankan kompatibilitas dengan versi yang lebih lama, jadi akan lebih mudah untuk mengadopsi fitur yang akan datang jika kode Anda ditulis sesuai dengan standar saat ini. Sebagai contoh, kelas yang didefinisikan menggunakan class
sintaks yang akan datang akan sepenuhnya dipertukarkan dengan kelas yang didefinisikan dengan constructor.prototype
sintaksis saat ini . Jadi dalam lima tahun pengembang dapat menulis ulang kelas ke dalam format ES6 berdasarkan file per file tanpa melanggar apa pun - dengan asumsi, tentu saja, bahwa Anda juga memiliki tes unit yang baik.
Kedua, hindari kerangka kerja aplikasi JavaScript yang trendi, terutama jika mereka mengubah cara Anda membuat kode aplikasi Anda. Backbone adalah hal yang paling disukai, kemudian SproutCore dan Ember, dan sekarang Angular adalah kerangka yang disukai semua orang untuk dipromosikan. Mereka mungkin berguna, tetapi mereka juga memiliki kesamaan: mereka sering merusak aplikasi dan memerlukan perubahan kode ketika versi baru keluar dan umur panjangnya dipertanyakan. Saya baru-baru ini memperbarui aplikasi 1,1 Angular ke 1,2, dan sedikit harus ditulis ulang. Demikian juga, beralih dari Backbone 2 ke 3 membutuhkan banyak perubahan HTML. Standar bergerak lambat karena suatu alasan, tetapi kerangka kerja ini bergerak cepat dan hal-hal yang melanggar secara berkala adalah biayanya.
Plus, standar resmi baru sering meninggalkan kerangka kerja lama yang usang, dan ketika itu terjadi kerangka kerja itu bermutasi (dengan melanggar perubahan) atau tertinggal. Anda tahu apa yang akan terjadi pada semua perpustakaan janji yang bersaing di dunia begitu ECMAScript 6 disahkan dan semua browser mendukung kelas Janji standarnya? Mereka akan menjadi usang dan pengembang mereka akan berhenti memperbarui mereka. Jika Anda memilih kerangka kerja yang tepat, kode Anda mungkin beradaptasi dengan cukup baik, dan jika Anda menebak dengan buruk Anda akan melihat refactoring besar.
Jadi, jika Anda berpikir untuk mengadopsi perpustakaan pihak ketiga atau kerangka kerja, tanyakan pada diri sendiri seberapa sulit untuk menghapus di masa depan. Jika kerangka kerja seperti Angular yang tidak dapat dihapus tanpa membangun kembali aplikasi Anda dari awal, itu pertanda baik itu tidak dapat digunakan dalam arsitektur 40 tahun. Jika ini adalah widget kalender pihak ketiga yang Anda abstraksi dengan middleware khusus, menggantinya akan memakan waktu beberapa jam.
Ketiga, berikan struktur aplikasi yang bagus dan bersih. Bahkan jika Anda tidak menggunakan kerangka kerja aplikasi Anda masih dapat memanfaatkan alat pengembang, membuat skrip, dan desain bersih yang bagus. Saya pribadi penggemar manajemen ketergantungan Closure Toolkit karena ringan dan biaya operasionalnya sepenuhnya dihapus saat membuat aplikasi Anda. LessCSS dan SCSS juga merupakan alat yang hebat untuk mengatur lembar gaya Anda dan membangun lembar gaya CSS berbasis standar untuk rilis.
Anda juga dapat mengatur kode Anda sendiri ke dalam kelas sekali pakai dengan struktur MVC. Itu akan membuatnya lebih mudah untuk kembali beberapa tahun ke depan dan tahu apa yang Anda pikirkan ketika Anda menulis sesuatu, dan hanya mengganti bagian-bagian yang membutuhkannya.
Anda juga harus mengikuti saran W3C dan menjaga informasi presentasi sepenuhnya dari HTML Anda. (Itu termasuk menipu seperti memberi elemen nama kelas presentasional, seperti "teks hijau besar" dan "lebar dua kolom"). Jika HTML Anda semantik dan CSS bersifat presentasional, akan jauh lebih mudah untuk mempertahankan dan mengadaptasinya ke platform baru di masa depan. Ini juga akan lebih mudah untuk menambahkan dukungan untuk browser khusus untuk orang buta atau cacat.
Keempat, mengotomatiskan tes Anda dan pastikan Anda memiliki cakupan hampir penuh. Tulis tes unit untuk setiap kelas, baik di sisi server atau di JavaScript. Di ujung depan, pastikan setiap kelas berkinerja sesuai dengan spesifikasinya di setiap browser yang didukung. Otomatiskan tes ini dari bot build Anda untuk setiap komit. Ini penting untuk umur panjang dan keandalan, karena Anda dapat menangkap bug lebih awal bahkan ketika browser saat ini mengaburkannya. Kerangka kerja pengujian berbasis Jasmine dan Google Penutupan baik.
Anda juga ingin menjalankan tes fungsional UI penuh, yang Selenium / WebDriver pandai. Pada dasarnya, Anda menulis sebuah program yang melangkah melalui UI Anda dan menggunakannya seolah-olah seseorang sedang mengujinya. Hubungkan mereka ke bot build juga.
Terakhir, karena orang lain telah menyebutkan data Anda adalah raja. Pikirkan model penyimpanan data Anda dan pastikan itu dibangun untuk bertahan lama. Pastikan skema data Anda solid, dan pastikan itu telah diuji secara menyeluruh di setiap komit. Dan pastikan arsitektur server Anda scalable. Ini bahkan lebih penting daripada apa pun yang Anda lakukan di ujung depan.