HTML First

• Dengan terlebih dahulu memakai fitur native yang disediakan browser, saat membuat aplikasi web kita dapat mengurangi ketergantungan pada bahasa tambahan dan toolchain
• React meningkatkan keandalan pengembangan UI melalui pola seperti props, state, dan komponen, tetapi juga memindahkan pusat cara pengembangan dari HTML ke JavaScript
• Sementara itu, W3C, WHATWG, IETF, dan TC39 menambahkan ribuan peningkatan pada bahasa dasar web, dan ketika browser utama mengintegrasikannya, sebagian alasan mengapa React dulu dibutuhkan menjadi melemah
• HTML First bukanlah gerakan untuk meyakinkan developer yang puas dengan React, melainkan arus yang berupaya menyediakan bahasa bagi orang yang tertarik pada pendekatan berpusat pada HTML untuk merapikan pemikiran mereka dan berdiskusi dengan rekan kerja
• Ini lebih dekat dengan kesadaran praktis untuk meninjau kembali apakah software yang cepat dan aksesibel dapat dibuat hanya dengan bahasa dasar web dan fitur browser

---

Cara pengembangan yang dituju HTML First

• HTML First mengutamakan HTML, CSS, JavaScript, dan fitur native browser saat membuat software web
• Intinya adalah mengurangi lapisan abstraksi yang ditambahkan di atas platform web
  • Bahasa tambahan dan toolchain juga termasuk lapisan yang perlu dikurangi
• Tujuannya adalah cara pengembangan yang menempatkan fitur yang sudah disediakan browser sebagai pusat, lalu menambahkan alat di atasnya hanya jika diperlukan

Pengembangan web yang menjadi lebih kompleks setelah React

• Sebelum React, cara yang umum adalah menulis antarmuka dengan HTML dan melengkapi bagian yang tidak didukung HTML secara bawaan dengan alat seperti jQuery
  • Contoh utamanya adalah pengiriman request asinkron dan pembaruan DOM
• Library seperti React memecahkan berbagai masalah dalam pengembangan web yang lama
  • Pola props dan state, yang meneruskan data secara eksplisit dari elemen induk ke elemen anak, mengurangi jenis bug tertentu
  • UI, gaya, dan perilaku dibundel sebagai komponen, sehingga karya orang lain dapat dipasang dengan mudah ke codebase sendiri
• Untuk mendapatkan manfaat ini, developer harus beralih dari cara yang terutama memakai HTML ke cara yang terutama memakai JavaScript
  • JavaScript diperlakukan sebagai bahasa yang lebih kompleks
  • Banyak konsep dan alat yang diperkenalkan React juga harus ikut dipelajari
• Industri menerima kompromi ini meskipun kompleksitas meningkat, dan library semacam ini menjadi cara default untuk membuat aplikasi web
  • Developer baru sebelum React mempelajari HTML dan CSS terlebih dahulu, lalu JavaScript setelahnya
  • Setelah React, alurnya berubah menjadi mempelajari JavaScript dan React terlebih dahulu, baru sisanya

Titik peninjauan ulang yang muncul dari peningkatan platform web

• W3C, WHATWG, IETF, dan TC39 menambahkan ribuan peningkatan pada bahasa native web selama pendekatan React menyebar luas
  • Peningkatan ini diintegrasikan ke Chrome, Safari, Firefox, dan Edge
  • Banyak di antaranya secara langsung menangani sebagian alasan orang menggunakan React
• Seiring naiknya biaya pengembangan software dan peningkatan browser tersebar luas, makin banyak orang bertanya apakah lapisan tambahan itu masih diperlukan saat ini
• Gagasan HTML First masih termasuk minoritas di industri
• Pendekatan ini berfokus membantu orang yang sudah tertarik pada pengembangan berpusat pada HTML untuk memperkuat pemikiran mereka sendiri dan memperoleh bahasa serta konsep untuk berkomunikasi dengan rekan kerja
• Pesan intinya adalah bahwa membuat software web yang indah, cepat, mudah digunakan, dan aksesibel dengan terutama memakai bahasa dan fitur native web adalah hal yang mungkin, praktis, dan masuk akal

[GN⁺]

Pendapat Hacker News

• Saya suka idenya, tetapi jujur saja contohnya agak lemah
  Contoh pada bagian “jika memungkinkan, definisikan gaya dan perilaku sebagai atribut HTML inline” tampaknya tidak benar-benar berfungsi, dan jika ingin menambahkan lebih banyak gaya, strukturnya hanya membuat parameter string yang diberikan ke ClassList.add terus membesar
  Secara pribadi, menurut saya button:active { background: green; } jauh lebih mudah dibaca, tetapi penulis sepertinya menganggap ini rumit karena pendekatan “Locality of Behaviour”
  Saya setuju dengan pernyataan “jika membutuhkan library, gunakan library yang memanfaatkan atribut HTML, bukan yang berpusat pada JavaScript atau sintaks kustom”, tetapi contoh yang direkomendasikan, “on input put me into #output”, terasa lebih canggung daripada library yang dijadikan contoh buruk, dan rasanya JavaScript tanpa framework pun sudah cukup
  Sebagai contoh untuk “lebih sukai HTML ‘mentah’ daripada lapisan tersembunyi yang dikompilasi menjadi HTML”, penulis mengatakan jangan memakai helper tag ERB Rails, padahal helper-helper ini menangani cukup banyak hal yang akan menjadi berantakan jika ditulis langsung dengan template minimal. Contohnya melewatkan bagian-bagian realistis seperti ID DOM unik, tag Turbo, dan iterasi

  • Bagian “jika memungkinkan, definisikan gaya dan perilaku sebagai atribut HTML inline” juga mengganjal bagi saya
    Pengaturan gaya dan perilaku harus dipisahkan, dan pada skala yang bermakna, satu-satunya cara yang masuk akal untuk menghubungkan keduanya adalah melalui referensi
    Secara teknis, kita bisa memasukkan semua koneksi database SQL dan SQL yang di-hardcode dalam satu file panjang di sebuah aplikasi Python, tetapi itu kebiasaan buruk; prinsip ini terlihat serupa

• Bagian ini membingungkan: “jika membutuhkan library, gunakan library yang memanfaatkan atribut HTML, bukan yang berpusat pada JavaScript atau sintaks kustom”
  Namun contoh yang direkomendasikan adalah _hyperscript [0]. Ini adalah library yang berpusat pada sintaks kustom, hanya saja skrip dalam bahasa baru yang harus dipelajari dimasukkan ke dalam atribut HTML. Saya tidak tahu apakah ini serius
  [0] https://hyperscript.org

  • Sepertinya ini ditulis sebagai daftar tips untuk mempromosikan hyperscript
    Contohnya juga cukup lemah. Solusi murni, yaitu hanya tip pertama, juga bekerja sama baiknya
  • Setuju. Contoh yang memasukkan kalimat DSL yang sulit dipahami sebagai nilai pada atribut bernama _ benar-benar terlihat aneh dan membingungkan
    Lebih baik memasukkan pernyataan JavaScript murni ke dalam onclick yang eksplisit atau atribut event lain, sehingga langsung jelas apa yang terjadi
  • Kalau mengikuti saran penulis, Alpine.js mungkin rekomendasi yang lebih baik. Karena ia memakai atribut HTML dan JavaScript yang intuitif
  • hyperscript terkait dengan HTMX, jadi tampaknya ada orang-orang yang ingin mengangkatnya, tetapi menurut saya itu lebih dekat ke mainan yang menarik
  • Bisa saja penulis tertukar menempatkan contoh yang direkomendasikan dan yang tidak direkomendasikan

• Saya paham maksudnya. Menggunakan fitur bawaan HTML itu rapi dan sederhana
  Namun 10 tahun lalu pun itu tidak praktis, dan sekarang juga masih begitu. Saya juga tidak merasa sesuatu seperti htmx secara khusus lebih baik daripada solusi yang lebih berat seperti React
  Setiap kali melihat pendekatan seperti ini, pertanyaan saya selalu sama. Seperti apa dropdown, multi-select, dan date picker-nya? Apakah date picker muncul di tiap browser? Ya. Apakah tampilan dan perilakunya konsisten di tiap browser? Tidak. Bisakah disamakan dengan styling? Juga tidak
  Multi-select juga serupa. Mengharuskan pengguna melakukan Shift/Ctrl-klik untuk memilih banyak item benar-benar tidak layak dari sudut pandang pengalaman pengguna. Elemen bawaan masih bekerja seperti itu dan tidak bisa diubah. Bukan hanya multi-select, elemen select biasa pun tampilannya buruk dan umumnya sulit diubah
  Ada alasan mengapa komponen pihak ketiga seperti ini muncul di setiap framework baru. Karena elemen bawaan saja tidak cukup. Ini sama seperti meskipun halaman Array di MDN menambah fitur bawaan setiap tahun, 90% proyek saya masih bergantung pada lodash. Memang sudah lebih baik dibanding 10 tahun lalu, tetapi masih kurang

  • Kalau berpikir cepat khusus untuk date picker, situs web dirancang untuk pengguna
    Pengguna bisa memakai browser yang berbeda-beda, tetapi satu pengguna kemungkinan besar memakai browser yang sama di semua situs web yang ia kunjungi
    Jadi menurut saya, lebih penting date picker konsisten di semua situs web dalam satu browser daripada konsisten di semua browser pada satu situs web. Tentu saja ceritanya berbeda jika membutuhkan fitur kustom
  • Pernyataan “mengharuskan Shift/Ctrl-klik untuk memilih banyak item benar-benar tidak layak dari sudut pandang UX” maksudnya multi-select tidak boleh dilakukan seperti itu? Kalau begitu, saya penasaran bagaimana seharusnya
    Saat ingin memilih 10 atau 15 item berurutan dalam daftar, untuk saat ini saya belum tahu UI yang lebih baik daripada Shift+klik
  • “Apakah tampilan dan perilakunya konsisten di tiap browser? Tidak” — terasa aneh kalau mengingat dulu look and feel native dianggap sebagai syarat wajib aplikasi desktop
    Daripada setiap komponen UI di semua situs web menciptakan gaya bodohnya sendiri, akan jauh lebih baik jika, di luar desain situs sebenarnya, semuanya mengikuti look and feel native browser. Tentu saja browser harus peduli untuk membuatnya terlihat bagus
  • Dari pembahasan lain, elemen input terkenal karena cara interaksinya sangat berbeda antar-browser, sedangkan sebagian besar elemen HTML lain memiliki perilaku representatif yang sudah ditetapkan

• Saya setuju dengan sebagian besar argumennya, tetapi tulisan ini terasa agak kontradiktif. Karena merekomendasikan Tailwind sekaligus mengatakan “hindari tahap build”
  Mendistribusikan resource CSS/JS yang sangat besar juga bertentangan dengan prinsip inklusivitas. Banyak orang tidak punya internet cepat atau komputer yang cukup kuat

  • Sekarang saya tidak memakai Tailwind, tetapi dari pengalaman saya Tailwind tidak membuat kita mendistribusikan resource CSS/JS yang sangat besar
    Sebenarnya saya sama sekali tidak tahu JavaScript sisi klien apa yang dikeluarkan Tailwind. Pengalaman terakhir saya adalah 2.x, jadi saya tidak yakin apakah ada yang berubah
    Untuk ukuran CSS pun pengalaman saya justru sebaliknya, output Tailwind biasanya jauh lebih kecil daripada CSS yang ditulis tangan
    Tentu saya juga tidak menentang CSS murni, tetapi membuatnya berantakan setidaknya sama mudahnya
  • Saya membuat library CSS atomik yang tidak membutuhkan tahap build. Kalau ada yang menginginkannya, ada di sini. Tentu, sedikit spoiler: tidak ada yang menginginkannya: https://casscss.github.io/cass/
  • Deno Fresh memakai Twind untuk menghindari tahap build: https://twind.dev/
    Namun sejauh yang saya ingat, ia tidak menyediakan semua fitur yang diberikan Tailwind penuh. Secara umum, Fresh sebenarnya dibangun cukup banyak di atas Preact dan Twind, dan saya merasa frustrasi karena hal itu tidak diungkapkan secara jujur bahwa kita harus menerima library-library itu terlebih dahulu
  • Tailwind punya CLI mandiri yang bisa dipakai sebagai tahap build
    Saya cukup setuju bahwa merekomendasikannya dalam konteks tulisan ini agak aneh, tetapi tahap build bisa dibuat sangat minimal, dan bagus juga bahwa hasilnya tetap berupa CSS yang bisa diperiksa
    Saya memakai Tailwind di situs pribadi, sementara sisanya sepenuhnya HTML murni. Menjalankan CLI dalam mode watch saat menulis style tidak terlalu mengganggu
  • Untuk opsi tanpa build, ada dua yang bagus: meng-host sendiri CDN Tailwind v3, atau memakai https://github.com/gnat/css-scope-inline
    Keduanya sangat cepat dan dapat mem-parse lebih dari 10.000 item

• Menarik secara teori atau contoh sederhana, tetapi saya ingin melihat proyek besar yang menerapkan ini dan perbedaan nyata apa yang dihasilkannya
  Sasaran di bagian awal tulisan sangat bagus, tetapi sarannya sendiri agak mengecewakan. Sulit membayangkan bagaimana ini akan bekerja di luar situasi yang sangat dasar, apalagi bagaimana sasaran-sasaran itu akan tercapai
  Saya setuju untuk memanfaatkan platform web semaksimal mungkin, dan sepenuhnya setuju untuk mengurangi kompleksitas sejauh mungkin. Namun saya sangat skeptis bahwa prinsip-prinsip ini akan mencapainya; malah tampak bisa menambah kompleksitas dengan menciptakan beberapa cara untuk melakukan hal yang sama
  Dengan niat baik, dari daftar ini saja tidak jelas apakah prinsip-prinsip ini sudah benar-benar diuji dalam praktik atau hanya diasumsikan akan bekerja seperti yang diharapkan

  • Saya tidak mengerti mengapa sebuah praktik harus bagus untuk proyek besar agar bisa disebut praktik yang baik
    Ini pertanyaan tulus. Orang sering mengajukan argumen ini, dan saya selalu tidak memahaminya
    Dari sudut pandang saya, 95% web adalah proyek kecil hingga menengah. Sebagian besar teknologi seharusnya berfokus pada ini. Pakai solusi sederhana untuk proyek sederhana, lalu tambahkan kompleksitas belakangan
  • Di tempat kerja saya pernah mencoba mendorong frontend bergaya HTML first, tetapi ketika kami merekrut developer frontend biasa, mereka pada dasarnya tidak memahaminya dan ingin membuat semuanya dengan div serta membiarkan VueJS mengendalikan semua logika dan konten
    Salah satu hal yang agak objektif yang kami hilangkan adalah aksesibilitas. Karena link dengan polosnya diimplementasikan ulang sebagai div yang diberi event listener klik, sebagian besar situs tidak bisa dinavigasi dengan keyboard
    Ini cukup mengkhawatirkan. Jika regulasi datang, kami akan kelabakan berusaha mengembalikan apa yang sudah kami buang
    Meski begitu, saya cukup setuju bahwa sulit menemukan contoh situs terkenal yang “HTML first”. Saya percaya pada pendekatan ini, tetapi belum melihat contoh nyata yang berjalan dengan baik. Namun alasannya mungkin murni soal pendidikan. Ketika HTML sudah menjadi kuat, pendidikan pengembangan frontend sudah telanjur sangat mengakar pada framework
  • Jika Anda developer frontend yang lebih muda daripada jQuery, mencoba memulai proyek dengan saran ini akan menjadi kesempatan bagus untuk mempelajari mengapa kita memakai hal-hal seperti tahap build dan betapa beratnya pengembangan sebelum HMR
    Sepertinya penulis belum benar-benar pernah melakukan ini pada proyek yang melibatkan lebih dari dua orang dan mendukung 99% browser yang ada. Selain itu, tampaknya ia juga tidak menjalankan kodenya sendiri. Mungkin layar saya saja yang tidak enak, tetapi onlick bukan handler untuk div
  • Kita sudah melupakan pelajaran lama. Backend first adalah mekanisme pertahanan terhadap orang-orang yang hanya percaya pada apa yang terlihat dan tidak percaya pada para ahli
    Jika kita membuat produk yang tampak berfungsi tetapi sebenarnya tidak, mereka tidak akan memahaminya. Lalu kita terdorong ke jalan overpromise dan underdeliver
    Salah satu manfaat unit test yang kurang dikenal adalah memberi lebih banyak jaminan kualitas sebelum kode yang tidak bisa dilihat manajemen disambungkan. Ini mempersempit fase canggung antara tampilan pertama muncul dan rilis
  • Setuju
    Pada 1999 saya membuat situs web pertama saya dengan HTML murni, CSS, dan JS murni, lalu meng-host-nya di Geocities
    Setelah itu saya membuat situs dan aplikasi dengan PHP/WordPress/Yii/Laravel, Ruby/Rails/Sinatra/Jekyll, React/Typescript, dan ClojureScript
    Sekarang React, komponen TSX, CSS-in-TS, Effects, dan Context terasa seperti rumah yang nyaman. Rasanya akhirnya kita punya bahasa pemrograman lengkap untuk web/frontend. Bahasa yang dibuat secara eksplisit untuk frontend di atas prinsip modern seperti pemrograman fungsional dan reaktif
    Baru sekarang saya merasa bisa melakukan pengembangan perangkat lunak. HTML, CSS, JS murni, dan PHP sebelumnya lebih terasa seperti hacking. Rails bagus untuk full-stack, tetapi tidak bersinar di frontend
    Kalau web stack sudah siap juga untuk aplikasi, saya akan melewatkan framework. Untuk saat ini saya akui mungkin sudah cukup untuk situs

• Tahun ini saya menyerah. Sekarang sudah mustahil terus bertarung melawan monster React, Vue, Angular dengan bundler, transpiler, dan segala macam pernak-pernik ikutannya
  Node dan npm melemparkan pesan bahwa bahkan proyek yang baru dibuat beberapa detik lalu punya “7 kerentanan serius dan 8 kerentanan kritis”. Harus mengunduh ribuan file, dan di dalamnya bisa saja ada hal-hal seperti wrapper nilai boolean
  Rasanya masa ketika server backend Python juga sekaligus menyajikan frontend sudah berakhir bagi saya

  • Marahlah! Marahlah melawan mesin!
    Sebenarnya Anda, maupun siapa pun, tidak benar-benar membutuhkan pembengkakan frontend JavaScript yang berat. Tinggal tolak saja
    Sajikan halaman ringan dari backend atau cache, dan jika benar-benar perlu, tangani hal-hal keren dengan CSS
    Sambut waktu render yang cepat dan aksesibilitas global
  • Tekan tombol keluar. Banyak hal baik dari web ada di Phoenix Liveview. Anda bisa membuat situs web responsif yang seksi tanpa mainan React/Node yang gila
    Tapi jujur saja, contoh-contoh di tulisan ini aneh. Saya tidak mengerti kenapa harus menulis tag murni sendiri alih-alih memakai helper form Phoenix yang otomatis mencetak error dan berbagai fitur kenyamanan. Saya paham semangatnya
  • Bisa. Coba saja pakai htmx

• Argumen intinya tampaknya adalah bahwa pengguna harus bisa menekan View Source dan memahami apa yang terjadi. Untuk situs web, saya setuju
  Untuk webapp, setidaknya yang lebih dari 50 baris, kemungkinan besar Anda akan ingin memakai bahasa bertipe. Secara teknis, Anda juga bisa memakai .js dengan anotasi tipe dalam komentar khusus dan compiler TypeScript, tetapi itu tidak terlalu menyenangkan
  Dulu saya cukup kuat tertarik pada gagasan ini, dan sedih melihat kebanyakan situs sekarang berupa satu gumpalan HTML sebaris yang tidak bisa dibaca. Ada keindahan dan keanggunan dalam mendistribusikan semuanya sebagai satu file HTML tanpa dependensi. Cukup 1 network request
  Pada akhirnya saya memang membuat “build system” demi kemudahan pengeditan, tetapi build system saya adalah cat. Jadinya seperti software portabel yang self-contained dalam satu file yang bisa dibaca manusia
  Dalam konteks yang sama, hal paling keren dari pengembangan web adalah Anda bisa membuat program interaktif pertama hanya dengan Notepad dan browser bawaan. Cukup seret file HTML ke browser. Rasanya seperti sihir
  Tambahan: saya menemukan kelebihan tak terduga dari HTML yang self-contained. Software menjadi kebal terhadap bit rot. Saat saya membuka proyek lama di Web Archive, file JS eksternalnya tidak tersimpan. Sedih. Sebaliknya, yang ini memuat dengan baik karena semua JS ada di dalam HTML. Menang
  https://web.archive.org/web/20210508133239id_/https://andai....
  Ini adalah homage untuk SodaPlay Constructor lama. Saya tidak sempat membuat editornya. Bebas lihat source-nya

  • Saya skeptis soal bagian ini. Sekarang ada banyak cara untuk mengintip “di balik tirai” lewat panel developer
    Ada tampilan DOM, tab network, tampilan heap, dan fitur bawaan untuk mempercantik tampilan JavaScript
    Tentu saja “view source” masih penting, tetapi saya ragu apakah kepentingannya masih semutlak yang dikatakan orang-orang HTMX
  • “Ada keindahan dan keanggunan dalam mendistribusikan semuanya sebagai satu file HTML tanpa dependensi. Cukup 1 network request”
    Sekarang ada URL data:, jadi ini makin mudah. Ini juga berguna untuk menghindari masalah URL file:// yang bahkan tidak membutuhkan server HTTP
  • Tambahan: ada proposal untuk memperluas anotasi tipe ke JavaScript, sehingga “subset yang cukup besar” dari TypeScript bisa dijalankan langsung di browser. Bagus!
    https://github.com/tc39/proposal-type-annotations
  • Menurut saya penulis tidak sedang menganjurkan sistem satu file. Sebagai gantinya, saya tidak ingin mengatakannya, tetapi

• “Lokalitas perilaku” adalah aturan yang didefinisikan terlalu longgar. Itu hanya menamai ulang sesuatu yang bertentangan dengan pemisahan kepentingan
  Menyebut CSS sebagai aksi menyeramkan dari kejauhan juga terlalu berlebihan. Ada prinsip-prinsip yang bagus, tetapi argumennya cukup lemah, dan sebenarnya bisa disampaikan jauh lebih sederhana

  • Dari sudut pandang seseorang yang berasal dari organisasi C# dengan terlalu banyak interface, saya melihatnya sebagai reaksi alami terhadap sistem yang terlalu diabstraksikan
    Jika untuk “mengubah tombol merah yang memantul menjadi tombol biru yang bergoyang” kita harus menelusuri labirin 3–7 interface dan class untuk mencari class mana yang perlu implementasi baru dan mana yang bisa digunakan ulang, pekerjaan yang terdengar seperti perubahan 10 menit berubah menjadi setengah hari mengumpat dalam hati kepada compiler atau developer sebelumnya
    Tentu saja abstraksi tetap perlu, tetapi juga harus ada cara mengelompokkan perilaku di satu tempat agar tidak perlu menyentuh 6 file hanya untuk memodifikasi satu komponen
    https://htmx.org/essays/locality-of-behaviour/#conflict-with...
  • Tailwind juga merupakan tahap build, dan sama-sama punya banyak “aksi menyeramkan dari kejauhan”. Kalau tidak begitu, orang tinggal memakai CSS inline saja
    Menggunakan Tailwind berarti mempercayai bahwa library pihak ketiga mengabstraksikan spesifikasi CSS untuk kita, dan bahwa semi-spesifikasi yang diabstraksikan itu akan dipatuhi sesuai konfigurasi build
  • Kalau “lokalitas perilaku” adalah aturan yang didefinisikan secara longgar, bukankah pemisahan kepentingan juga begitu?
    Apa yang harus dipisahkan? Di sepanjang garis apa kita membaginya? Bagaimana menentukan garis itu? Kapan layak memindahkan suatu kepentingan ke class, framework, markup, dan sebagainya yang berbeda? Kapan lebih baik membiarkannya tetap berdekatan?
    Jawabannya adalah “tergantung situasi”
    Jika tidak memisahkan apa pun, hasilnya menjadi spaghetti; jika selalu memisahkan semuanya semaksimal mungkin di mana pun, hasilnya menjadi kode yang terlalu diabstraksikan dan sama sulitnya dipelihara seperti spaghetti
  • Tujuan utama yang dinyatakan adalah “memperluas secara besar-besaran kelompok orang yang bisa bekerja pada codebase perangkat lunak web”. Ini cukup berbeda dari nasihat untuk programmer pada umumnya
    Jika default-nya bekerja dengan baik, kustomisasi bukan keharusan. Karena itu, keuntungan efisiensi dari CSS dan semacamnya ditempatkan di belakang kesederhanaan
  • Masalahnya multidimensi
    Jika HTML dilihat sebagai bahasa dokumen/presentasi, styling tidak bisa disangkal. CSS tidak hanya menambahkan styling, tetapi juga animasi
    Bagaimanapun, CSS juga bisa dilihat sebagai pemrograman berorientasi aspek
    Masalah sebenarnya yang digambarkan di sini adalah kurangnya tooling yang baik lintas bahasa dan framework

• Mengandalkan framework yang lebih sederhana saat memungkinkan memang masuk akal. Namun gagasan menghapus tahap build nyaris seperti lelucon total
  Buat saja tahap build lebih efisien, dan jika perlu jangan sertakan di production
  Saya juga tidak paham kenapa menambahkan atribut ke HTML harus diprioritaskan. Apakah tujuannya membuat dokumen lalu menghostingnya sebagai website? Di dunia lain mana lagi hal itu lebih disukai? CSS tidak sulit dinavigasi, dan justru praktik CSS yang lebih baik seharusnya didorong
  Script frontend memang bisa mengaburkan styling, tetapi jika tidak perlu, jangan bergantung pada cara itu. Menaruhnya di dokumen style lebih mudah daripada memasukkan atribut dengan JavaScript, jadi itu sudah jelas
  Sebagian nasihat seperti memakai hanya yang dibutuhkan memang masuk akal dan jelas. Namun sisanya membingungkan atau terang-terangan absurd. Saya juga tidak mengerti kenapa kemampuan menyalin seluruh halaman HTML diasumsikan sebagai hal yang baik. Jujur saja saya tidak peduli, dan meskipun HTML beberapa halaman tidak bisa dilihat, sudah ada secara harfiah jutaan resource untuk belajar HTML
  Secara umum, ini membuat saya mengernyit bingung

  • Banyak dari isi semacam ini adalah reaksi terhadap pemujaan kompleksitas di industri pengembangan web

• Seluruh tulisan ini adalah antipola dan nasihat buruk. Rasanya seperti ditulis oleh seseorang yang belum pernah mengalami growing pains saat membangun website yang kompleks
  Awalnya kami juga membuat website seperti ini, tetapi kemudian mulai rusak karena efek samping, nama class yang bertabrakan, dan observabilitas internal yang buruk, lalu React datang menyelamatkan
  Pola yang diinginkan adalah peningkatan progresif, dan output-nya harus berupa HTML yang bersih dan terkompresi, sementara JavaScript memperkaya HTML tersebut. Artinya, tahap build diperlukan. Ini kebalikan dari nasihat dalam tulisan ini

  • Membuat website dengan React juga punya jebakan, dan memakai React berarti memperkenalkan banyak kompleksitas
    Jika di backend belum memakai NodeJS, sebaiknya hindari ReactJS kecuali saat benar-benar diperlukan