Tetap Native Sampai Akhir, Hingga Anda Membutuhkan Teks

• Di macOS, jika membuat UI chat Markdown hanya dengan SwiftUI, performa dasarnya cukup memadai, tetapi sulit mendukung pemilihan seluruh dokumen
• Jika dipindahkan ke NSTextView dan TextKit 2, pengujian dan pekerjaan performa di SwiftUI hilang, dan pada input streaming muncul lonjakan CPU
• Implementasi ulang dengan NSCollectionView menimbulkan kedipan sel, dan TextKit 2 murni juga punya performa yang lumayan tetapi integrasi streaming-nya kurang baik
• WebKit secara umum lebih cocok dalam rendering Markdown, performa, tipografi, dan tingkat kontrol, dan di Electron pun pekerjaan terkait teks bekerja secara bawaan
• Pada chat panjang dan rich text, SwiftUI serta SDK native Apple menjadi batasan, sementara pendekatan berbasis web lebih unggul dalam model teks dan rendering

---

Batasan UI Chat Markdown Native di macOS

• Jika membuat chat sederhana yang mendukung Markdown hanya dengan SwiftUI, performa dasarnya masih cukup baik, tetapi tidak memungkinkan memilih seluruh dokumen Markdown yang disusun dari primitive SwiftUI
• Jika dipindahkan ke NSTextView, dukungan TextKit 2 memang didapat, tetapi sebagian besar pengujian dan pekerjaan performa yang sudah dilakukan di SwiftUI menjadi hilang, dan hasilnya juga kurang cocok dengan SwiftUI
• Jika respons model dimasukkan ke NSTextView secara streaming, akan terjadi lonjakan CPU
• Bahkan jika diimplementasikan ulang dengan NSCollectionView, sel terus berkedip, dan perilaku ini sulit dihindari secara desain
• Prototipe TextKit 2 murni punya performa yang cukup baik, tetapi streaming tetap buruk dan kurang cocok dengan komponen modern
• Bahkan jika SwiftUI dihapus sepenuhnya dan hanya memakai AppKit, potongan teks yang terus bertambah tetap harus ditangani secara manual, dan pemilihan teks baru bisa dilakukan setelah banyak bagian berada dalam kondisi rusak
• Untuk mencapai tingkat yang mirip dengan perilaku dasar macOS, fitur yang secara alami diharapkan pengguna seperti menu konteks, pencarian kamus, pemilihan, aksesibilitas, dan interaksi teks harus disesuaikan kembali

Titik di Mana WebKit dan Electron Lebih Cocok

• Jika merender Markdown dengan WebKit, memang ada beberapa hal yang perlu diperhatikan, tetapi secara umum hasilnya berjalan baik, performanya bagus, tipografinya baik, dan tingkat kontrolnya juga memadai
• Jika membuat proyek Electron sederhana, pekerjaan teks, rendering Markdown, dan tipografi yang baik langsung bekerja secara bawaan, dan bahkan performa yang sulit didapat dari implementasi TextKit 2 murni juga bisa tercapai
• Di Electron pun integrasi macOS tetap tersedia, Git diff yang kompleks bisa dirender hanya dengan beberapa baris kode, dan ada contoh seperti diffs.com
• Bahkan setelah meninjau SwiftUI, AppKit, TextKit, hingga WebKit, tetap sulit memenuhi dengan baik kebutuhan sederhana berupa “chat yang mendukung Markdown dan memungkinkan pemilihan seluruh pesan”
• Menjadi semakin jelas mengapa aplikasi baru yang menekankan chat, rich text berformat panjang, dan tipografi fleksibel beralih ke pendekatan berbasis web
• SwiftUI cocok untuk layar sederhana yang tidak banyak melakukan scrolling, dan Swift tetap berguna di bagian yang membutuhkan performa tinggi
• Electron atau React Native dapat memperoleh performa yang cukup tinggi lewat interoperabilitas native, sambil mempertahankan model teks dan rendering yang lebih baik
• Dalam rendering rich text untuk chat berformat panjang, SwiftUI dan SDK native Apple berubah dari keunggulan menjadi batasan
• Diskusi terkait: Hacker News, Lobsters

[GN⁺]

Komentar Hacker News

• Baru-baru ini saya merilis editor teks untuk iOS yang memakai TextKit 2, dan performanya tetap tinggi bahkan pada file 5.000 baris
  Diuji dengan Moby Dick dari Project Gutenberg, dibuat antara Agustus 2025 hingga April 2026, dan pengembangannya masih berlanjut
  Setiap penekanan tombol di-styling ulang dalam 8ms, dan bahkan 20 input cepat tanpa debouncing atau render tertunda diproses dalam 150ms termasuk restyling penuh setelah tiap input
  Tag dan pencarian boolean selesai dalam 20ms, merender hanya area yang terlihat 25 kali lebih cepat daripada styling seluruh dokumen, dan juga mendukung refresh layar 120Hz
  Ukuran file aplikasi pada versi 1.0 adalah 722KB, dan versi 1.1 yang fiturnya bertambah tampaknya sekitar 950KB
  Jika tingkat seperti ini bisa dicapai di iOS, seharusnya di macOS kira-kira 10 kali lebih mudah
  https://www.gingerbeardman.com/apps/papertrail/

  • Kalau fitur inti produk berbayar itu editornya, saya paham. Tapi kalau rendering Markdown bukan fungsi utama aplikasi dan lebih mirip fitur kenyamanan yang diharapkan pengguna pada 2026, aneh rasanya harus membuat implementasi kustom level rendah dengan pola pikir bahwa itu akan memakan 8 bulan dan tetap perlu dikembangkan terus
    Bukan berarti “mustahil”, tapi saya jadi paham kenapa orang memilih teknologi web ketimbang native untuk hal seperti ini. Orang ingin membuat produk, bukan bertarung dengan batasan sistem
  • Dari sudut pandang seseorang yang pada 2012 membuat novel interaktif dengan NSString dan atribut, membuat roguelike dengan API glyph level rendah yang kini dibuang, serta membuat dua aplikasi chat dengan dukungan Markdown di SwiftUI dan satu game idle yang penuh trik iOS, reaksi ini akhirnya bisa diringkas sebagai masalah tingkat keahlian
  • 5.000 baris itu benar-benar kecil, jadi penjelasan ini membingungkan. Moby Dick yang katanya dipakai untuk pengujian tampaknya malah punya lebih dari 22.000 baris, dan Notepad bawaan Windows pun tidak tersendat pada file sebesar itu
    Kalau ini penampil teks, seharusnya minimal bisa menangani file yang satu atau dua orde magnitudo lebih besar. File JSON ratusan ribu baris itu umum, dan file CSV serta log bahkan lebih panjang
  • Kemungkinan besar implementasi Mac dari SwiftUI memang kurang bagus. Untuk aplikasi seperti ini, SwiftUI-on-Catalyst mungkin justru lebih baik, meski mungkin ada masalah lain
  • Saya sangat meragukan pernyataan bahwa kalau bisa di iOS maka di macOS akan 10 kali lebih mudah. Rasanya justru kebalikannya, dan saya ingin mendengar pengalaman orang yang benar-benar tahu

• Biasanya alasan memakai API native alih-alih web view adalah performa, tapi sekarang tampaknya tidak selalu begitu
  Mesin rendering browser sudah sangat matang, mendapat banyak akselerasi GPU, dan telah diuji stres selama lebih dari 10 tahun oleh aplikasi web yang makin membengkak
  Sebaliknya, SwiftUI tidak terasa cepat. System Settings versi baru yang dibuat ulang oleh Apple pun menyederhanakan UI menjadi deretan checkbox, tetapi perpindahan antarbagian kadang terasa lebih tersendat daripada memuat halaman web dari us-east-1

  • Masalah di sini bukan aplikasi native secara umum, melainkan SwiftUI
    Saya pernah membuat aplikasi native dengan Qt C++ dan QML, dan menunjukkan bahwa itu jauh lebih cepat serta memakai RAM jauh lebih sedikit dibanding aplikasi web yang setara
    Jadi secara umum, aplikasi web lebih lambat dan lebih boros sumber daya dibanding aplikasi native yang dirancang dengan baik
    [1] https://notes.alinpanaitiu.com/SwiftUI%20is%20convenient,%20...
    [2] https://x.com/daniel_nguyenx/status/1734495508746702936
    [3] https://rubymamistvalove.com/block-editor#8-performance
  • Meski begitu, masih ada perbedaan besar antara aplikasi native dan aplikasi browser yang paling ringan, dan itu makin terlihat pada perangkat berdaya rendah
    Saya dulunya pengembang web, tetapi dalam 6–12 bulan terakhir mulai membuat aplikasi native lintas platform, dan bahkan pada tugas sederhana pun kesenjangan performa cukup besar
  • Browser itu buruk di perangkat keras lama. Chromebook lawas itu umum dipakai, dan spesifikasinya cukup untuk penggunaan ringan atau tujuan tertentu, tetapi browser berjalan sangat lambat di sana
  • Untuk aplikasi web yang sederhana mungkin tidak masalah, tetapi pada aplikasi yang kompleks penurunannya terlihat jelas. Tidak perlu sampai monster seperti Jira; bahkan aplikasi yang sangat dioptimalkan seperti VS Code pun punya batas atas performa yang lebih rendah daripada aplikasi native
  • WebView pada akhirnya juga “native”
    Aneh jika membuang ribuan tahun-orang optimasi dan jutaan tahun-orang validasi di lingkungan nyata, lalu memutuskan untuk membuat ulang mesin rendering teks yang lebih buruk

• Di macOS, WebKit adalah framework OS native. Memakai WebKit untuk rendering Markdown terasa sepenuhnya masuk akal
  Tentu, merender semuanya dengan WebKit sama tidak masuk akalnya dengan merender semuanya dengan PDFKit. Tetapi untuk tampilan Markdown, WebKit adalah pilihan yang logis, dan itu tidak berarti harus membalik meja lalu pindah ke aplikasi web berbasis Chromium

  • Jika mesin HTML bisa merender teks kaya—yang mungkin merupakan hal tersulit untuk dirender di UI—lebih baik daripada library UI native, lalu kenapa tidak merender hal yang lebih mudah seperti tombol atau field teks dengan itu juga?
    Lagi pula, OS X sudah lama merender UI dengan DisplayPDF/Quartz
  • Perlu penjelasan kenapa rendering Markdown dengan WebKit dianggap tepat
  • Penulis aslinya tampaknya memaknai “native” sebagai hanya memakai elemen primitif Swift/ObjC
    Apakah WebKit dianggap curang karena juga ada di platform lain? Kalau begitu sekalian saja pakai Java
  • Saya tidak paham kenapa kita harus menganggap memakai WebKit untuk merender teks kaya sebagai sesuatu yang wajar
    Kalau merender teks dengan renderer HTML/CSS/JS itu “sepenuhnya tepat”, lalu area mana yang tidak tepat? Kenapa tidak merender semuanya dengan itu?
    Saya tidak mengerti logika dari “rendering teks itu tepat, tetapi rendering semuanya itu tidak masuk akal”
  • Faktanya, solusi yang sedang saya kerjakan sekarang adalah merender Markdown final dan streaming dengan WebKit
    Saya setuju bahwa di macOS, WebKit adalah framework OS native, jadi dalam arti itu memang “native”
    Tetapi itu juga mendukung poin yang lebih besar: untuk menangani teks kaya, Markdown, seleksi, tipografi, dan konten berformat panjang dengan baik, teknologi web dengan cepat menjadi satu-satunya pilihan yang praktis
    Bukan berarti memakai WebKit untuk tampilan Markdown itu salah; justru kemungkinan besar itu pilihan yang paling masuk akal. Masalahnya, solusi “native” di sini pada praktiknya adalah solusi rendering web
    Setiap WKWebView membawa mesin WebKit sendiri dengan overhead performa dan memori tersendiri, jadi tidak bisa begitu saja disebar ke mana-mana dan dianggap sebagai komponen macOS native gratis
    Yang membuat frustrasi adalah SwiftUI / AppKit / TextKit tidak memberi jalur yang bersih, modern, dan composable untuk UI seperti ini yang lebih baik daripada “pakai saja WebKit”

• Rasanya tidak masuk akal kalau hal sesederhana “membuat seluruh pesan bisa dipilih dalam chat yang memakai Markdown” saja tidak bisa dilakukan
  Di SwiftUI, ada renderer Markdown yang cukup matang. Lihat saja https://github.com/gonzalezreal/swift-markdown-ui dan pengganti generasi berikutnya https://github.com/gonzalezreal/textual
  Saya sudah memakainya sendiri dan tidak ada masalah. Bahkan saya yang bodoh karena tidak suka Swift atau SwiftUI dan lebih suka Objective-C bisa melakukannya tanpa bantuan LLM

  • Saya mencoba Textual tadi pagi, dan hasilnya kurang bagus
    Scroll Markdown statis yang selesai tidak lolos probe fokus baru, dengan p95 18,86ms yang melewati anggaran 16,7ms, dan maksimum 232,49ms
    Jalur update Markdown/kode real-time yang panjang juga gagal, p95 59,33ms versus 16,7ms, maksimum 75,94ms. Ini kasus stres yang terpisah tetapi terkait, saat menangani permukaan teks kaya yang besar selama pembaruan
    Ekspansi riwayat panjang secara teknis lolos, tetapi sulit dibilang frame-nya mulus: 120 putaran p95 21,35ms, 500 putaran 23,11ms, 1000 putaran 36,77ms
    Tidak buruk, tetapi sedikit lebih lambat daripada solusi saya, dan kesenjangan performa yang mirip itu tampaknya lebih berkaitan dengan SwiftUI daripada implementasi Textual itu sendiri
  • Bisakah itu menangani streaming teks baru tanpa flicker?
  • Kalau hanya merender dokumen Markdown sekali, atau dokumennya sederhana dan pendek, mungkin bisa
    Dulu saya memakai swift-markdown-ui di aplikasi, tetapi performanya sama sekali tidak mendekati wkwebview. Saat melakukan streaming dokumen besar dengan elemen sulit seperti tabel besar, blok kode, atau kutipan bertingkat, sampai-sampai muncul beachball, sedangkan saat memakai wkwebview hal seperti itu tidak terjadi
  • Library pertama tampaknya dipakai oleh aplikasi Claude iOS, dan terlihat bisa menangani seleksi teks serta streaming dengan performa yang cukup baik
  • Dari sudut pandang pengguna, aplikasi lama yang tidak berbasis HTML sering terlihat tidak mengikuti “aturan”. Teks yang seharusnya bisa dipilih malah tidak bisa, atau tidak bisa disalin dengan control/option C
    Lalu saya sadar bahwa browser dan teknologi di bawahnya memperkenalkan paradigma baru untuk UI, dan framework UI native tidak berhasil mengikutinya
    Saya merasakan itu bahkan sebagai orang yang lebih menyukai aplikasi native daripada aplikasi berbasis web

• Tunjukkan kodenya, atau keluar. Bahkan sekarang sudah ada sangat banyak aplikasi Mac/iOS native yang menangani rendering Markdown dan teks streaming dengan baik
  Saya cuma penasaran alasan apa yang dipakai di sini

  • Katanya, “Saya ingin bisa memilih seluruh dokumen Markdown yang dibuat dari elemen primitif SwiftUI,” tetapi siapa yang menginginkan itu? Penilaian produk seperti itu pada dasarnya berarti ingin membuat editor dokumen, sebuah area yang sudah sulit selama puluhan tahun dan tampaknya di luar cakupan UI chat LLM
    Kebanyakan akhirnya menetap pada dukungan seleksi hanya di dalam tiap blok berurutan, lalu menambahkan tombol salin untuk seluruh pesan
  • Kalau memang bisa tanpa web view, tinggal bagikan kodenya

• Fakta menariknya, Apple sendiri dulu pernah melakukan hal seperti ini
  macOS / AppKit lama memakai WebKit untuk merender teks kaya di dalam NSTextField native. Teks memang masalah yang sulit
  Selain itu, WebView native sangat cepat dan ringan, jadi tidak aneh memakainya sebagai mesin tata letak teks. Bahkan memakai WebView terpisah untuk tiap baris tabel pun bisa memberi performa yang sangat baik
  iMessage untuk Mac juga memakai WebView, begitu juga Adium. Jika Anda merender teks kaya/teks markup, maka HTML adalah alat yang sepenuhnya tepat

  • Di sini orang mencampuradukkan iOS dan Mac OS
    Mac tidak pernah memakai WebKit untuk rendering NSTextField. Saat iOS pertama kali dibuat, WebKit memang dipakai secara luas sebagai renderer teks, termasuk untuk kontrol UIKit, dan itu disebut “sweet solution”
    Namun itu ternyata terlalu berat dan merepotkan, sehingga pendekatan rendering teks ala Core Text/AppKit kemudian mengambil alih
  • Alur tulisan aslinya agak aneh
    Penulis menemukan bahwa rendering teks native yang kompleks itu sulit, lalu merender teks dengan pendekatan level rendah sambil mengeluh harus mengimplementasikan ulang interaksi native
    Lalu dia mencoba WebKit dan hasilnya sangat baik, tetapi kemudian meninggalkannya dan kembali ke situasi di mana dia harus mengimplementasikan ulang interaksi native lagi
    Secara pribadi, saya akan berhenti di titik saat WebKit bekerja dengan baik

• Saya ingat saat menjadi engineer junior pada 2015, saya mendapat tugas merender tautan yang bisa diklik di dalam paragraf pada aplikasi iOS
  Saat itu Swift baru saja muncul, jadi stack-nya murni ObjC/UIKit, dan itu benar-benar mimpi buruk. Saya berhasil membuatnya bekerja dengan susah payah
  Sejak sekitar 2016 saya hampir tidak menyentuh iOS, jadi saya mengira SwiftUI yang baru pasti sudah punya ini sebagai fitur bawaan, tetapi ternyata tidak; itu cukup gila

  • Secara harfiah memang ada Link
    https://developer.apple.com/documentation/swiftui/link
    Pada titik ini saya bahkan tidak tahu itu bisa dibuat lebih mudah lagi seperti apa
  • Qt sudah bisa melakukan ini dengan cukup mudah bahkan 10 tahun lalu
  • Bukankah ada NSLinkAttributeName?
  • Saya kira teks beratribut sudah lama menangani ini dengan baik, memangnya tidak?
  • Permintaan untuk menaruh tautan yang bisa diklik di dalam paragraf itu sendiri sejak awal sudah merupakan ide yang buruk

• “Begitu keluar dari layar sederhana, native masih sematang ini saja” ya memang wajar
  Tidak mungkin berharap itu menjadi matang kalau orang tidak mau menginvestasikan usaha yang cukup
  Karena lebih banyak usaha diarahkan ke teknologi web, orang pun terikat di sana. Mereka melihat native lalu berkata “belum cukup berkembang”, lalu kembali membuat lebih banyak hal di web, dan siklus itu terus berulang
  Di browser, karena semuanya sudah “langsung jalan”, hampir tidak ada yang mau berusaha memperbaiki native

  • Meski begitu, toolkit pengembangan UI native itu produk komersial, bukan? Bukan pengguna yang harus meyakinkan diri sendiri; pihak sanalah yang harus menjualnya kepada orang
    Salah satu alasan web jauh lebih matang adalah karena para pembuat OS komersial besar tidak mau mengikuti perkembangan zaman. Toolkit UI Windows benar-benar berantakan
  • Setuju. Pada akhirnya ini cuma keluhan bahwa belum banyak usaha dicurahkan untuk membuat penanganan Markdown cepat di Swift, sementara yang bersangkutan sendiri tidak berusaha berkontribusi ke sana

• Di aplikasi chat AI saya juga mengalami hal yang hampir sama. Tidak ada yang benar-benar beres
  Rendering Markdown lambat dan patah-patah, streaming juga lambat dan patah-patah, dan semuanya membuat UI macet
  Saya sudah mencoba setidaknya 5 komponen editor teks populer di GitHub untuk UIKit dan SwiftUI, dan semuanya rusak dalam satu atau lain cara, atau penuh bug dan lambat. Ini tidak masuk akal

• Ini memang masalah yang sulit. Saya pernah menulis panjang lebar tentang bagaimana saya menyelesaikannya saat membuat editor blok dari nol dengan Qt C++ dan QML
  Saya menghadapi masalah serupa seperti seleksi di antara blok yang tidak berkesinambungan, menampilkan Markdown sumber di bawah kursor, dan ukuran delegate yang berbeda-beda
  Berdasarkan pelajaran dari sana, saya sekarang sedang membuat klien LLM native dengan parser Markdown streaming
  [1] https://rubymamistvalove.com/block-editor
  [2] https://www.get-vox.com

[GN⁺]

Opini di Lobste.rs

• Saya setuju bahwa untuk layout teks yang kompleks, webview memang cocok, tetapi saya tidak yakin harus sampai memilih Electron hanya demi kemudahan
  Electron pada dasarnya adalah pembungkus untuk WebView, tetapi karena membawa seluruh mesin Chromium sekaligus, ukuran aplikasi menjadi terlalu besar sebagai harga dari kemudahan itu
  Pada 2001~2002, saya pernah mengimplementasikan layout teks gelembung percakapan ikonik iChat dengan NSTextView dan berbagai akal-akalan, dan meski dibantu Hideki Itamura, perancang teks AppKit, tetap cukup menyiksa. Sekarang hal itu menjadi jauh lebih sederhana dengan HTML+CSS
  • Saat harus mendukung banyak sistem, pada akhirnya kesederhanaan sangat berarti
    Saya pernah terlibat dalam aplikasi yang memakai Tauri, lalu setelah diubah agar memakai Chromium melalui Electron, hasilnya bekerja jauh lebih baik. Yang juga penting, targetnya mencakup rentang yang sangat luas, dari win7 sampai win11
    Keluarga Tauri terlihat menarik karena memakai webview sistem, tetapi di Windows itu berarti Chrome atau Edge, di macOS berarti Safari, dan di lingkungan lain pada dasarnya bergantung pada keberuntungan. Pada akhirnya, prediktabilitas dan kematanganlah yang menang, dan entah kenapa performanya juga lebih baik
  • Menurut saya ini adalah soal pilihan pribadi. Baik ukuran aplikasi maupun penggunaan RAM, jika Anda siap membayar harga demi kemudahan, tampaknya jutaan pengguna aplikasi seperti Visual Studio Code juga setuju
    Pada akhirnya saya lebih menginginkan perangkat lunak yang lebih baik daripada sekadar memuaskan grafik htop
    Inti tulisan blog itu bukan “semua orang harus memilih Electron”, melainkan bahwa kini saya paham mengapa bahkan perusahaan yang punya sumber daya dan uang tetap memilih Electron atau teknologi web. Setidaknya menurut standar saya, itu memberi pengalaman pengguna yang baik sambil berkompromi di bagian yang tepat
    Banyak orang membela TextKit 2 milik Apple atau framework teks native lainnya, tetapi hampir tidak ada editor teks populer dan berkinerja tinggi yang dibuat hanya dengan Apple SDK. Xcode melakukannya dengan cukup baik, dan mungkin satu-satunya contoh nyata yang mendekati penggunaan di lapangan. Zed, Sublime Text, Visual Studio Code, dan IDE JetBrains semuanya memakai solusi rendering teks mereka sendiri, tentu ada alasannya
• Salah satu masalahnya adalah orang-orang yang membuat perangkat lunak mengembangkan di komputer dan ponsel yang termasuk 0,1% terbaik di dunia
  Karena itu, bahkan jika dibuat dengan cara terburuk sekalipun, di lingkungan mereka sendiri semuanya bisa terlihat baik-baik saja
  Sementara itu, semua orang lain yang memakai perangkat dengan spesifikasi jauh lebih rendah harus terus menanggung perangkat lunak yang gemuk dan lambat
• Saya penasaran bagaimana keadaan GTK/Qt belakangan ini. Sudah lama saya tidak mengerjakan GUI
  • Sejauh yang saya pahami, pekerjaan seperti ini juga tampaknya bisa diimplementasikan di Qt tanpa webview
    Hanya saja, penulisnya tampaknya tidak mengeksplorasi sampai ke arah itu di sini
• Saya penasaran bagaimana jika Electron dibandingkan dengan Flutter
  Dari luar, Flutter tampak seperti jawaban untuk pertanyaan “bagaimana kalau dari Chromium kita hanya sisakan Skia sebagai renderer lalu memakainya untuk aplikasi GUI?”. Seharusnya ini menjadi alat lintas platform yang lebih ringan daripada Electron tetapi dengan kemampuan yang serupa
• Penulis https://github.com/stevengharris/MarkupEditor mengusulkan bahwa tulisan ini adalah salah satu solusi yang cukup baik yang tersedia saat ini: https://blog.krzyzanowskim.com/2025/08/14/textkit-2-the-promised-land/
  • Namun, MarkupEditor tidak memakai TextKit2, melainkan WebView. Di README juga tertulis bahwa MarkupEditor berinteraksi dengan dokumen HTML yang memakai satu DIV contentEditable, dan menggunakan subclass dari WKWebView
    Ironisnya, mesin teks native Apple memakai model data yang jauh lebih baik daripada pohon HTML DOM, yaitu string dan atribut gaya yang dikodekan berdasarkan panjang run
    Mengedit teks di DOM nyaris seperti mimpi buruk, karena area seleksi sering melintasi banyak elemen di banyak lapisan, sehingga harus dipecah dan digabung dengan cara yang sangat rumit. Saat dulu pertama kali mencoba build Safari dengan dukungan contenteditable, saya mengirim sangat banyak laporan bug, dan sampai sekarang pun banyak editor rich text web yang rusak saat memotong atau menempel item daftar
    Pada akhirnya, rasanya ini mirip dengan pertarungan CISC vs RISC pada era 90~00-an. Arsitektur yang ‘lebih inferior’ justru menerima lebih banyak sumber daya dan akhirnya melahirkan implementasi yang lebih unggul