Ngobrolin WASM
Ringkasan Episode
Bantu KoreksiWebAssembly dibahas dengan mundur dulu ke kata assembly itu sendiri — istilah yang bisa terasa asing bagi siapa pun yang belajar otodidak dari HTML, CSS, dan JavaScript, karena ketiganya sudah berada jauh di atas lapisan itu. Assembly adalah bahasa yang paling dekat dengan mesin sebelum kode biner: menjumlahkan dua angka saja berarti mengalokasikan memori, menyimpan nilainya, mengambilnya dari alamat tertentu, lalu menyimpan hasilnya lagi. Istilah tingkat rendah pun diluruskan — maksudnya bukan buruk atau sederhana, melainkan makin sedikit lapisan penerjemah antara kode dan perangkat kerasnya. Dari situ WebAssembly dijelaskan sebagai format biner yang berjalan di browser dengan kecepatan mendekati aplikasi asli. Bahasa sumbernya dimulai dari C++ dan Rust, lalu menyusul Java, Kotlin, Dart dan Golang; rantai kompilasinya lewat Emscripten dan LLVM, dan Google serta Adobe sempat berkolaborasi membawa proxying API ke sana. Contoh-contohnya yang membuat gagasan ini konkret: Figma, yang dulu mustahil ada di web dan kini justru jadi pengguna WebAssembly; Photoshop yang menyusul ke browser; FFmpeg yang dijalankan langsung di sisi klien sehingga video tidak perlu diunggah ke server lebih dulu; TensorFlow Lite yang modelnya dikompilasi agar bisa berjalan real-time; sampai PHP Wasm, yang membuat PHP pun bisa hidup di dalam browser. Pembatasnya tetap jelas — untuk pekerjaan berat semacam itulah WebAssembly masuk akal, bukan untuk hal yang sudah cukup ditangani JavaScript atau service worker.
Poin-poin Utama
- •Assembly adalah bahasa paling dekat dengan mesin sebelum kode biner: menjumlahkan dua angka berarti mengalokasikan memori, menyimpannya, mengambilnya dari alamat, lalu menyimpan hasilnya lagi
- •Tingkat rendah bukan berarti buruk atau sederhana, melainkan makin sedikit lapisan penerjemah antara kode dan perangkat kerasnya
- •Bahasa sumbernya dimulai dari C++ dan Rust, lalu menyusul Java, Kotlin, Dart dan Golang, dengan rantai kompilasi lewat Emscripten dan LLVM
- •Figma dulu mustahil ada di web dan kini justru jadi salah satu pengguna WebAssembly, disusul Photoshop yang pindah ke browser
- •FFmpeg bisa dijalankan langsung di sisi klien, sehingga video tidak perlu diunggah ke server lebih dulu sebelum diproses
- •TensorFlow Lite dikompilasi ke WebAssembly supaya modelnya bisa berjalan real-time di browser
- •PHP Wasm membuat PHP pun bisa hidup di dalam browser — tapi pembatasnya tetap: WebAssembly untuk pekerjaan berat, bukan untuk yang sudah cukup ditangani JavaScript atau service worker
Halo, selamat malam, selamat hari Selasa bertemu lagi dengan informasi lengkap kita bertiga ada Eka, ada Ivan dan juga ada saya Riza.
Selasa malam waktunya?
Selasa malam waktunya ngobrolin web.
Ngobrolin web.
Kita sudah di episode ke 47.
Sudah hampir setahun ya?
Episode 47, hampir. Yang sebetulnya yang 48, karena kita nge-penninya dari 0.
Ya, tapi tetap saja openingnya belum compact juga ya.
Kita kayaknya harus ada latihan, harus latihan kayak latihan jingo gitu ya.
Ya, jadi malam hari ini kebetulan sekali ada rekan kita yang berhalangan untuk live, jadi kita rekaman ya, rekaman.
Tapi nggak usah khawatir, saya dan teman-teman nanti akan...
Saya juga bakal hadir kok.
Bakal hadir di hari Selasa malamnya, ada chat, nanti silahkan dikomentarin aja di chat, kita tetap akan coba berusaha untuk merespon atau menjawab pertanyaan-pertanyaan dari teman-teman.
Jadi malam hari ini topiknya adalah tentang web assembly.
Atau wasm.
Wasm ya.
Ya, wasm ini sebenarnya bukan topik yang baru, ya udah cukup lama dan... / Itu sering banget nyebut ini. / Sering banget.
Tapi nggak pernah menyuruh, nggak pernah didrive kayak cuma sekilas-sekilas aja sambil bahas macam-macam topik lain.
Jadi sebenarnya secara nggak langsung wasm itu terbukti relevan ya.
Karena misalnya kita ngobrolin API-nya project FUBU atau ngobrolin apa update terbaru dari Google I/O kemarin, wasm selalu masuk.
Nah berarti itu kan kayak pertanda lah, pertanda bahwa emang, emang waktunya belajar wasm.
Walaupun aku sendiri sebetulnya belum pernah pakai sama sekali.
Teman-teman gimana, ada yang beneran udah pernah pakai atau... / Explore-explore?
Saya pernah pakai, tetapi nggak pernah membuat.
Hanya tahu pakai doang ceritanya. / Akan yang pakai, iya.
Nanti saya demo-in juga sekalian ya. / Wih mantap.
Saya juga, apa, explore gara-gara jadi topik untuk Google I/O Extended.
Dan terus dilanjutkan dengan demo. / Itu salah satu manfaat ngasih toke. / Betul, betul. Sekali plus esplorasi, belajar.
Udah pengen banget explore, cuma belum kesempatan.
Sama sih, kayak Ivan, cuma pakai, belum sempet sampai kompilasi dan lain-lain.
Lihat transkrip lengkap (1683 segmen lagi)
Tapi pakai yang udah jadi, binary-nya, dicoba di web, dijalankan di web gitu.
Tapi kalau mulai dari awal, di kompilasi itu belum.
Mudah-mudahan nanti ada waktu, jadi kita bisa sharing-sharing lagi.
Oke, jadi apa itu WASM?
Mungkin kita mulai dari apa ya, assembly-nya sendiri. Apa itu assembly?
Mungkin ada teman-teman di sini yang belajarnya otoridak seperti Eka ya.
Yang tidak mendapatkan topik tentang assembly. / Nggak ngerti sama sekali apa itu. / Nggak ngerti sama sekali itu apa itu assembly gitu kan.
Sampai baca ini ya, barusan waktu itu maksudnya pas liat WASM-WASM,
baca artikel, ya baru tahu pas baca artikel itu.
Tapi sebelum, kalau cuma belajar HTML, CSS, JavaScript, bahkan konsep-konsep programan yang umum,
kan itu sebetulnya udah masuk high-level language ya.
Jadi ya, sebelumnya sama sekali nggak ada konsep tentang assembly atau apa, binary.
Binary, ya.
Ada teman-teman dulu di kuliah, dapat nggak? / Dapat assembly itu, tapi saya nggak mau sebut umur,
tapi waktu awal-awal itu belajar algoritma dan pemograman, terus kemudian sebelum masuk ke paskal,
kita tuh ada dikasih assembly, bukan assembly, assembly.
Ini saya masih ingat tuh sinteksnya call, goto, if else, ya.
Semua sebanyak, ya ada.
Bacanya itu kayak kita tuh menaruh, bener-bener kalau kayak simple-nya aja ya di PHP,
kalau kita mau menambahkan sebuah bilangan, kita tuh cuma tinggal variable a ditambah dengan 1 tambah 1.
Kalau kita di assembly tuh saya masih ingat tuh saya harus allocate memori, allocate address-nya,
terus kemudian taruh value-nya, terus kemudian waktu saya mau jumlahkan itu,
saya allocate dulu, terus ngambil dari address yang mana tadi,
terus tambahkan baru nanti safe ulang di alokasi memori yang baru.
Lebih tepatnya sebenar-benar step-by-step gitu, step-by-step.
Jadi singkatnya assembly itu adalah bahasa yang paling low-level sebelum bahasa mesin 0.1.0.1.
Dan dia bahasanya primitif, fiturnya sedikit, mungkin cuma ada tambah operasi matematika saja pun
cuma ada beberapa gitu, nggak semua.
Kalau kita mau kali, mau bagi itu kayaknya harus manual pake tambah, pake operasi yang lain.
Jadi nggak. / Jangan bahas lagi soal floating point.
Bisa pecah kepala soal floating point di assembly.
Iya, jadi ya gitu lah kira-kira. Apa ini? / Ini kan. / Oh iya, bentuknya seperti ini.
Jadi kita hanya bisa memindah-mindahkan variable, kemudian isinya itu cuma bisa ditambah.
Kalau kita mau kali itu ya tambah, berapa kali gitu kan ditambah-tambah terus.
Tapi di sini waktu saya belajar ini itu adalah dasar bagaimana memahami algoritma.
Oh gitu? / Jadi benar-benar kayak mengerti algoritma itu dari sini saya tuh.
Kan ada bahasa, / Perbedaannya gimana? / Belajar Alpro kan ada ibaratnya apa itu bahasa yang kayak bukan...
Seudocode? / Seudocode, nah jadi Seudocode itu kan non-programming language. / Lenggut agnostik.
Lenggut agnostik. / Iya, betul. Jadi dari Seudocode kita belajarnya ke assembly dan Pascal.
Oh iya, unik juga ya. / Tapi sederhana banget, cuma kayak tambah-tambah kurang-kurang.
Pokoknya mengerti dulu bagaimana alokasi di memory, baru saya ke Pascal.
Jadi kalau teman-teman biasanya tahu low-level language itu C, C++ gitu ya, apa lagi?
Pascal tadi ya, sudah disibutkan itu ini lebih low-level lagi.
Lebih low-level daripada C dan C++. / C aja ada banyak loh. / Iya, dan betul.
Dan si assembly ini, dia bergantung kepada jenis arsitektur prosesor.
Kalau prosesornya, ya CPU. / Karena dia komunikasi langsung sama hardware ya? / Dengan mesin.
Sama hardwarenya. / Dan bahkan konsep low-level language aja,
maksudnya dulu-dulu pas pertama kali ya baca-baca artikel tentang web assembly atau semacamnya kan,
suka nemu istilah low-level language.
Nah, ini kan kalau nggak belajar dari awal, ini mungkin agak rancu kan.
Low-level itu apakah maksudnya jelek atau sederhana atau gimana kan, padahal maksudnya bukan itu.
Di sini yang dimaksud low itu kayak closer to the metal atau makin dekat dengan hardware itu dianggap low-level.
Jadi abstraksi dari computer instruction set architecture atau komando-komando untuk mesin itu tidak banyak abstraksinya.
Jadi sedekat mungkin dengan mesin itu disebut low-level. / Low-level.
Semakin low-level bahasanya, semakin sulit kita pahami ya.
Karena dekat dengan mesin, jauh dengan manusia kan.
Itu kan kayak tadi tuh yang ada perbandingan assembly versus PHP atau JavaScript.
Kalau tadi assembly language, apa sih mau menambahkan value variable A dan variable B aja kayak ribet banget kan?
Harus move to, harus store variable value dimana, terus store dimana, terus ditambahin store dimana.
Sedangkan kalau kita pakai PHP sama JavaScript, secara konsep walaupun syntaxnya bisa macem-macem, secara konsep kan dekat dengan bahasa manusia.
Misalnya X sama dengan A tambah B itu kan kayak kita ngomong sama orang, sedangkan assembly kita ngomong sama mesin.
Semakin rendah level bahasa pomograman, performanya semakin tinggi tapi semakin sulit dipahami manusia.
Semakin tinggi level pomograman, semakin mudah dipahami manusia, tapi secara performance semakin jauh lah dari mesin.
Karena dia harus melewati, mungkin kayak di-company kali ya, kayak semacam diterjemahkan di berbagai abstraction layer dan bahkan ini layer-layernya pun banyak nih.
Kalau yang paling low itu machine code cuma 0 sama 1, 2. Kayaknya ini nggak realistis ya, expect manusia kita buat nulis ini langsung.
Cuma berarti, cuma tetap ada ini bagian dari layer-nya. Lalu atasnya sedikit baru assembly language.
Higher level dibanding ini, tapi masih dianggap low level language. Bahkan C pun yang selama ini.
Selama ini aku nganggep sih sebagai low level language kan, tapi ternyata ini mid-level language.
Oh, high level. Sudah lebih tinggi. Maksudnya C itu sudah lebih tinggi ya, sudah mid-level betul-betul.
Menyebar tadi antara...
High level kan.
Jadi dia mungkin...
Ada alok-alok memori, gue masih ingat tuh. Dia ada kodenya alok memori.
Ya, memorinya harus kita benar-benar manage sendiri, nggak ada gearbase collector, jadi harus di-manage manual.
Itu peringkat paling atas, maksudnya peringkat paling tinggi dari kelompok low level programming language ya.
Yang menyebatkan dengan tingkat-tingkatnya atasnya C++ dan lain-lain.
Betul. Belum lagi kita ngomongin tentang, ya, tentang ada bahasa yang menggunakan virtual machine seperti Java Virtual Machine,
Erlang Virtual Machine, dan lain-lain. Ada juga yang interpreter, ada yang compile, gitu kan.
Dan biasanya kalau...
Biasanya si bahasa-bahasa yang high level itu dia bisa...
Tujuan akhirnya itu bisa ke antara ke assembly atau ke C.
Jadi kayak Python itu kan dia sebenarnya layer di atasnya C.
PSP juga layer di atasnya dulu ada mod-mod itu kan C juga kan. Apa? Apache dan lain-lain kan.
Jadi bahasa yang high level itu biasanya dia berdiri di atas bahasa-bahasa low level atau bahasa yang middle level.
Nah, kalau V8 itu punya JavaScript runner, JavaScript interpreter itu pakai C++... C++ kan ya?
Eh, pakai apa sih? C++ kan.
Berarti kan dari JavaScript C++ dan C.
C++ dan C itu sebenarnya kurang lebih satu level ya, menghasilkan binary yang sama.
Karena C++ itu cuma nambahin OOP aja, Object Oriented Programming di bahasa C.
Kalau C itu kan prosedural ya, kalau nggak salah ya, prosedural language.
Jadi dia lumayan primitif, primitif. Bukan fungsional tapi prosedural.
Berarti C++ itu buat memudahkan developer-nya, biar nulisnya enak gitu kan.
Sebenarnya itu adalah bahasa yang sama kayak C, cuma dengan DX yang lebih baik berarti ya.
Ya maksudnya lebih friendly lah, OOP kan. Enak maksudnya bisa bikin class dan lain-lain.
Sama juga dengan kalau teman-teman ada yang tahu Objective C itu juga versi Object Oriented C yang dikembangkan oleh Apple.
Yang akhirnya menjadi Swift sekarang.
Dulu kan kalau mau bikin iOS app, Objective C.
Objective C, C itu banyak ya. Ada Borlan C. Jadi tergantung kompilernya.
Borlan C, ada Turbo C, Delphi. Delphi itu Borlan ya.
Ada GCC kalau sekarang ya, GCC.
GCC kan dari C ini kan. Dari Linux ya.
Terus bukan. GCC? Unix?
Kan, apa itu namanya, yang temannya Unix dan plus apa, terus jadi Linux.
Apa itu? Unix dan?
Ya itu kompilernya lah intinya, bukan-bukan.
Oh bukan.
Ya, ada Borlan, ada banyak ya.
Karena ini semua sendiri, diatasnya ada yang itu library-library yang dibuat untuk supaya bisa jadi operating system.
Maksudnya function-function, API-API, tambahan.
Dan hampir semua OS bisa dibilang menggunakan bahasa pemograman C atau C++ ya.
Termasuk juga V8 yang digunakan oleh JavaScript, salah satu runtimenya JavaScript.
Nah istilah assembly muncul dari situ.
Jadi ini adalah versi paling dekat ke mesin, dalam tanda kutip, untuk bisa diakses oleh web.
Jadi dia formatnya binary, yang bisa dijalankan di web tanpa mengganggu thread utama dari web tersebut.
Karena kan kalau web itu kan, JavaScript itu jalan di single thread ya.
Ketika misalkan kita loading something, si web assembly ini berada di thread yang terpisah.
Pasti UI-nya tidak terganggu.
Dengan demikian, berarti ibaratnya web assembly ini adalah assembly yang berjalan diatas web,
tetapi langsung bisa mengakses low level.
Ya, low level itu tadi.
Low level-nya, ini tergantung ya.
Ya, mungkin kalau saya bisa simpulkan sedikit, assembly itu diambil gara-gara apa ya,
jadi hampir semua bahasa terbuka untuk menargetkan web assembly sebagai target kompilasi.
Kira-kira seperti itu. Makanya disebut sebagai assembly.
Atau itu konsep yang sudah dipakai sebelumnya kelihatannya ya.
Memang.
Yang ini?
Terus pola itu dipakai untuk JavaScript, dipasangkan dengan web assembly. Terus ada penjelasan lebih detailnya lagi.
Scroll ke bawah.
Bawah lagi.
Nah, ini juga harus kita bahas nih. Nanti ya.
Nah, nanti aja. Nah, konsepnya ini low level, assembly like language, blablabla.
And provide language such as blablabla.
Jadi, kelihatannya pakai konsep yang udah ada, assembly untuk menjembatani.
Nah, ini kan berarti web assembly dibuat untuk menjembatani.
Terus didesain untuk berjalan bersama JavaScript.
Nah, yang tadi dibahas masa bisa skill-less kan.
Jadi, JavaScript-nya jalan di main thread browser.
Sementara web assembly-nya jalan sendiri, dia punya thread sendiri berarti ya.
Gak mengganggu rendering, misalnya rendering UI yang biasa kita bahas soal performance.
Misalnya untuk user interaction atau nge-click input, itu kan semua di handle main thread.
Nah, ini berarti operasinya berjalan terpisahkan ya.
Oh, iya. Ada petasan.
Iya, ini pada petasan.
Oh, lagi ada cara ya.
Oke, ini yang menarik ya. Ada near native performance.
Jadi, performance-nya luar biasa kencang.
Dan bahasa yang bisa dikompilasi ke web assembly.
Dimulai dari C++ dan Rust, dan kemudian belakangan muncul bahasa-bahasa dynamic dan high level
seperti Java, Kotlin, Dart, Golang, dan lain-lain.
Nanti juga kita akan bahas.
Dan kalau mau disederhanakan, ini gak tahu bener atau salah ya.
Kalau mau disederhanakan, seolah-olah kita bisa punya back-end tapi di browser.
Kira-kira kayak gitu lah web assembly.
Oh, menarik.
Maksudnya cara lihat kayak gitu.
Seolah-olah. Kenapa? Karena kalau dulu misalkan kita mau bikin seperti Figma lah.
Figma adalah salah satu pengguna yang menggunakan assembly kan.
Misalkan dulu Figma kan gak mungkin di web.
Harus di desktop, aplikasi desktop kan.
Nah sekarang dengan mudahnya di client, seolah-olah kita punya mesin engine-nya itu gak perlu di server.
Jadi misalkan kalau yang saya contohkan waktu demo kemarin itu
misalkan saya mau bikin aplikasi converter video.
Kalau yang versi client server kan videonya kita upload ke server.
Setelah di upload, di process, di konversi, kemudian hasil konversi videonya balik lagi ke client baru bisa di play kan.
Baru bisa di download atau di running.
Oh, berarti masih bisa mengcompile itu ya FFmpeg ya?
FFmpeg, iya.
Nah, FFmpeg itu bisa ditaro di browser sehingga gak ada tuh process upload ke server dulu.
Jadi prosesnya semua dijalankan di sisi client.
Jadi seolah-olah back-end yang konversi itu dipindahin ke client gitu, ke browser.
Dan ada keunggulan, ada keunggulan lebih bagus lagi karena dia apa itu tadi closer to the metal lah.
Maksudnya near native performance, performanya lebih baik ya.
Kan sebelumnya nih kalau buat ya bisa dibilang akal-akalan atau maksudnya feature yang powerful kayak gitu kan.
Sebelumnya orang suka nyoba ngelik itu dilakukan di service worker.
Server, ya atau service worker.
Terpisah, maksudnya dia suruh kerja sendiri.
Pas udah selesai dibalikin semacam broadcast message ke main thread.
Nah, tapi kan kalau cuma fetch data atau apa yang ringan, ya itu kan bisa di handle oleh service worker yang punya kesama.
Ya bisa dibilang punya kesamaan dalam hal kita bisa nyuruh, kayak dari browser, bisa nyuruh suatu pekerjaan diproses di tempat lain.
Untuk membebaskan main thread kesamanya itu.
Tapi kan kalau, apa, untuk operasi yang berat atau butuh bahasa-bahasa yang seperti C atau C++,
atau butuh performa yang bagus punya yang hal-hal yang kompleks dan berat, ya itu kayak Figma, Photoshop, dll.
Nah, berarti itu kan kalau di service worker tetap aja bakal lambat dan kurang optimal, ya.
Berarti di sini web assembly bisa jadi apa, bisa jadi solusi.
Kelebihannya lagi, ketika file wasmnya sudah berhasil didownload di tahap awal, itu bahkan internet putus pun nggak masalah.
Jadi kalau misalkan tadi client server...
Ya karena servernya di situ, di browser.
Betul. Kalau misalkan tadi client server ketika kita upload, misalkan baru 50% tiba-tiba internet putus,
harus ulang lagi kan uploadnya kan.
Begitu juga pas pada saat proses tiba-tiba internet mati nggak bisa download gitu.
Tapi kalau web assembly ini, ketika di awal dia sudah loading, sudah selesai, itu internet putus, internet mati bisa dijalan secara offline.
Nah, kelebihan yang lain adalah yang kepikiran, misalkan ada data yang sifatnya credential,
yang tidak boleh di-upload ke server.
Ya misalkan data KTP dan lain-lain, itu bisa menggunakan solusi web assembly-nya juga.
Karena datanya nggak bakal lari kemana-mana di client aja.
Cuman melihat kekurangannya adalah performa dari aplikasi kita itu sangat tergantung kepada mesin si user-nya.
Kalau mesin user-nya kentang gitu ya, berarti jalannya lambat.
Kalau dia cepat ya berarti.
Another case yang saya pernah kerjakan dulu, itu menjalankan TensorFlow Lite.
Jadi TensorFlow-nya di-compile, modelnya di-compile jadi web assembly.
Terus kemudian supaya bisa real-time yang kayak di bandara itu kan.
Tapi pakai web ya, kalau di bandara kan biasanya nggak tahu pakai apa, kayaknya pakai aplikasi.
Kalau kita cuma tinggal monitor, terus kemudian bisa ngedetek suhu maybe, atau ngedetek wajah, face detection.
Itu aplikasinya jalan di browser, bisa.
Ini nggak perlu send ke server, terus detect, terus balik.
Itu kan kelamaan gitu ya, kelamaan.
Prosesnya lama, memakan waktu yang lama dan server-nya juga, kita harus maintain server-nya kan.
Harus scaling server-nya, kalau user-nya udah banyak ya udah, kita harus gedein server-nya kan.
Kalau ini kita bisa cheating dengan cara yang memanfaatkan mesin-mesin si client.
Atau sejalan dengan ide-nya Ivan tadi juga, sekarang kan ada tuh yang baru muncul.
Kita bakal bicarain sih tentang ini, last continuous model lama yang punya Facebook, Meta.
Itu bisa jalankan dengan itu kan, di lokal kan, lama dan CPP.
Itu kalau kita kompilasi ke web assembly, itu bisa langsung jalan di browser.
Nggak perlu kayak check GPT kan, dia ke server dulu kan.
Kalau ini jalannya di lokal lagi.
Kita kalau misalnya punya chatbot yang untuk meindikan si client kita.
Self-hostage itu tempatnya client.
Self-hostage, data-nya nggak, dan data-nya tidak perlu ke server.
Jadi kalau misalkan ada perusahaan-perusahaan yang curiga, "Wah data kita dipakai buat trending berikutnya nih."
Atau dipakai di spying gitu kan, nah ini bisa jalan di lokal.
Nah ini itu sih relevan banget, terutama di luar kan kayak privacy concern udah makin strictly regulated ya.
Apa, regulasi atau hukum tentang privacy data kita disimpan di server yang di wilayah mana.
Terus kayak apa, user berhak tahu data yang disimpan itu apa aja.
Itu kan makin lama, makin ketat.
Nah ini bisa jadi salah satu solusi.
Jadi kalau tanya data-nya di mana ya, data-mu sendiri ya di mesin.
Masing-masing.
Masing-masing user data-nya ya di mesin mereka masing-masing.
Ya, jadi walaupun si web assembly ini kayak dicanangkan atau digadangkan oleh Google,
tapi sebenarnya kalau melihat sejarah, awalnya itu adalah sm.js.
Itu keluarannya Mozilla awalnya.
Kayaknya banyak ya kalau dari dulu awalnya dari Mozilla, malah waktu apa, terus berevolusi,
terus tiba-tiba identik dengan Google atau Chrome, Chromium.
Ya, Chromium, ini kan salah satunya.
Was the first browser to support sm.js?
Firefox berdua itu tahun berapa coba, ya ampun.
It is under the name Odin Monkey, Chrome edit sm.js support in version 61.
Jadi ya udah lumayan lama sebenarnya.
Dulu saya ingat banget waktu Firefox, apa sm.js jalan di Firefox itu demo-nya itu Quake ya,
kalau gak salah ya, game Quake bisa dijalankan di browser.
Nah itu dulu, nah baru kemudian.
Waduh 2013, udah 10 tahun lalu dong.
10 tahun yang lalu, kita ketinggalan, kita ketinggalan gak juga sih.
Nah itu dia cerita singkat tentang asalmu, asal kenapa dipakai istilah assembly dan apa itu web assembly.
Jadi web assembly performa bagus, near native performance, terus flexible dalam artian
kita bisa menggunakan bahasa apapun di luar JavaScript yang nantinya akan ditandemkan dengan JavaScript.
Itu sisi menariknya dari web assembly.
Dan dengan adanya opsi web assembly ini bisa banyak perubahan,
kalau saya sebut perubahan pragmatik, perubahan business model dan lain-lain.
Contohnya kalau misalkan sekarang ya ada Photoshop.
Photoshop sekarang sudah bisa jalan di web kan.
Kalau dulu kan Photoshop itu aplikasi desktop,
kemudian kalau kita mau beli, kita harus beli, kemudian kita dapat serial number kan.
Terus kita install lah gitu kan, kira-kira kayak gitu ya, dikasih CD kalau zaman dulu ya.
Kalau sekarang mungkin tinggal download.
Nah, si Photoshop ini business modelnya agak berubah sekarang.
Dia pakai sistem subscription.
Karena yang lama-kelamaan serial number ya kan.
Kalau dulu, kalau di jobnya sih yang nge-train rental CD bajakan.
Sudah bajakan di rental gitu ya.
Serial numbernya ditulis aja di sleeve-nya atau pas.
Nah, pertamanya gitu.
Terus kan lama-lama ketahuan ya, nggak business gampang itu.
Kan ada keygain. Ada keygain dan biasanya pas buka keygain itu ada musiknya gitu.
Music MIDI gitu ya, music MIDI.
Itu khas banget.
Dan biasanya kadang malah artinya juga ASCII art sambil generate keygain.
Jadi ya, maksudnya Adobe sender juga lah.
Gue sekarang takut banget loh buka keygain.
Gue kalau buka keygain tuh bukanya di virtual machine.
Kalau dulu cuek ya.
Oh, cuek. Orang windows-nya juga sama.
Bajakan juga.
Daripada kena virus brontox.
Enggak.
Dulu kenapa bajakan? Karena kita mau beli yang asli nggak bisa.
Nggak ada akses kesana. Nggak ada yang jual.
Nggak ada yang jual juga.
Nggak ada yang jual.
Apalagi itu.
Mencari pemenaran.
Itu lah jaman dulu.
Padahal bisa Linux ya.
Padahal bisa Linux.
Jim.
Jim.
Anyway, jadi dengan adanya WebAssembly ini, Photoshop bisa dibuka di web.
Dan dia bisa mengubah bisnis modelnya.
Dan menariknya, Photoshop ini tidak menulis ulang apa yang sudah dilakukan selama berpuluh-puluh tahun dengan Photoshop desktop-nya.
Dia pakai codebase yang hampir sama dikompilasi ke WebAssembly.
Ya, bayangin berapa lama dan berapa model yang harus dikeluarin kalau rewrite semua dari awal.
Sedikit side story.
Pas saya ke Bangalore, pesawatnya yang sudah di-schedule itu.
Saat sudah setelah di-schedule dan pagi-pagi berangkat, di sebelah saya itu adalah engineernya Adobe Illustrator.
Dia lagi mau ke Bangalore juga? Iya, dia baru pulang honeymoon di Bali ceritanya.
Dan dia sedang mau pulang ke Bangalore, mau lanjut kerja dan dia itu engineer Illustrator.
Projek yang sedang dia kerjakan adalah meng-conversi Illustrator application ke web.
Dan WebAssembly, dia cerita ya semuanya WebAssembly, ada modul-modulnya.
Jadi intinya dia ambil tiket itu kerjanya modul-modul tertentu jadi WebAssembly modulnya.
Jadi kayak WebAssembly kecil-kecil banyak, jadi tergantung yang mana, tools yang mana gitu.
Di refactor aja ya, tetap ada butuh apa ya?
Oh banyak, komplikasinya banyak, komplikasinya banyak. Gak semudah yang kita bayangkan.
Gak semudah itu, komandan. Gak semudah itu, komandan.
Gak semudah itu, komandan.
Masih banyak, tapi core, tapi core codenya misalnya gini, algoritm.
Contoh ya, kalau mau pakai pen atau apa yang mengubah pixel apa, kan core-nya algoritmnya sama.
Namun saat mau di-convert ke WebAssembly, ada parameter-parameter yang perlu diubah.
Dan setelah waktu diubah, parameternya gak kompatibel.
Jadi dia harus rewrite sebagian, kayak gitu lah.
Gak semudah itu sih.
Tapi ya itulah, dan proyeknya lama loh, setahun juga proyeknya.
Iya, tapi yang sisi menarik dari cerita tersebut adalah, dia tetap bekerja dengan bahasa yang dia kuasai, kan?
Dia gak perlu belajar bahasa baru, atau dia gak perlu digantikan oleh developer front-end JavaScript yang harus menulis ulang si Hadoop.
Oh dia C++ Hardcoder.
Iya, maksudnya itu.
Gak mengerti JavaScript sama sekali.
Jadi orang-orang yang sudah ekspertis di sana, sudah biasa mengerjakan Adobe, Photoshop, Illustrator dan lain-lain, dia tetap ada kerjaan.
Bukan tergantikan oleh front-end.
Bukan tergantikan juga.
Ya.
Langsung di lay-off gitu ya.
Berapa kali lipat programmer baru kan buat ngulis JavaScript front-end, dan ya itu dari segi waktu, dari segi biaya, kayak itu gak realistis sama sekali.
Ya, jadi ya itulah kelebihan.
Jadi kalau misalkan teman-teman punya software yang dulu jalan di desktop, yang masih digunakan, atau bahkan mungkin jalan di DOS gitu ya, yang udah gak ada lagi DOS juga, gak ada, yang ada emulatornya aja.
Ya, bisa mungkin jadi konsiderasi buat di kombilasi ke WebAssembly, terus bisa jadi aplikasi web.
Nah, terus kalau teman-teman nonton yang episode featuring Mas Thomas Steiner waktu itu, yang bahas legu app itu kan kasusnya juga sama kayak yang Photoshop ini.
Mereka udah punya aplikasi native, ya C++ juga, ya itu kayak di-porting dan di-adjust untuk web dengan WebAssembly juga.
Jadi kasusnya sama, kelihatannya penggunaan yang paling umum kayak gitu ya, untuk aplikasi kompleks, yang mostnya tergelong kompleksan, yang selama ini udah ada existing codebase di native, terus di kodenya pakai C++. Nah, butuh di-adjust untuk dijalani di web. Nah, itu use case yang paling umum kita lihat sekarang.
Betul, kecuali Figma. Figma itu dari awal sudah WebAssembly dan C++.
- Jadi dari awal mereka memang sudah targetnya. - Oh, karena dia tergelong baru ya?
Ya, tergelong baru dan targetnya memang Web sih.
Abis itu Figma dibeli Adobe dan sekarang Adobe sudah ada versi webnya. Jangan-jangan mereka belajar dari Figma. "Eh, ajarin WebAssembly dong."
- Ya kan kalau perusahaan aksesisi itu kan buat dapetin programmer-nya? - Iya, betul.
Buat dapetin tim developer-nya.
Dari pada mereka reset lagi dari awal kan mending mereka manfaatkan.
Yang udah proven.
Betul, yang udah punya pengalaman.
Dan kenapa WebAssembly muncul di I/O Extended? Karena dengan adanya ini proposal GearBase Collector yang sudah didukung oleh WebAssembly,
bahasa-bahasa yang tadinya belum terlalu optimal di kompilasi ke WebAssembly sekarang sudah bisa.
Bisa jalan.
Iya, kalau dulu kan yang paling, mungkin udah banyak bahasa yang menargetkan WebAssembly tapi tidak optimal.
Yang paling optimal itu CC++ dan Rust karena mereka tidak menggunakan GearBase Collector.
Nah, dengan adanya proposal ini, bahasa-bahasa yang menggunakan GearBase Collector seperti Go, Kotlin, Java, Swift dan lain-lain sudah mulai bisa.
Ini yang bikin excited, salah satunya kita bisa jalanin Swift, bahasa pemrograman yang tadinya eksklusif di Apple Ecosystem.
Apa? Apple?
Iya, sekarang sudah bisa jalan di web.
Wow.
Input number, 80.
FishBus ditambah sama...
Apa nih? Alphibonacci.
By the way, gue mau demo-in sesuatu yang keren juga nih.
Boleh dong.
Pertama, gue pindahin dulu ke sini.
Terus, present.
Share.
Ya, enter sekalian aja biar lebih gampang.
Sudah. Jadi WordPress juga sudah ada WebAssembly-nya namanya WordPress Playground.
Jadi, kan kalau jalanin WordPress itu kan biasanya kan butuh local server.
XAMPP.
Web Server, jaman dulu XAMPP gitu ya.
Pertama kali lagi recoding pasti itu.
Butuh MySQL, terus butuh PHP, Runtime, ya.
Kalau sekarang kita nggak perlu, jadi contohnya ini ya, ini Playground-nya kita tinggal klik.
Maka ini sudah jalan di browser dengan PHP 8.0, preparing WordPress.
Ini sudah WebAssembly ceritanya.
Dan kenapa dia rusak saya tidak tahu.
Ada server-nya berarti?
Tetap ada server-nya.
Gak ada, nggak pakai server.
Di lokal semua ya.
Mungkin gue bisa rubah, mungkin ada masalah.
Ya, maksudnya server-nya ya di browser itu berarti kan ya.
Di browser lah, di browser.
Itu tadi yang saya jelaskan, back-end-nya itu masuk ke browser.
Jadi cocok banget ini.
Kalau misalnya kita mau ngetes atau mau demo-in, mau ngetes plugin.
Plugin, ya.
Itu nggak perlu install-install, nggak perlu ribet-ribet ya.
Nggak perlu takut rusak ya.
Kalau rusak ya tinggal refresh, ulang semua gitu ya.
Oke, teknologinya apa teman-teman?
Nah, pertama dia pakai PHP Wasm.
Jadi PHP pun sudah bisa jalan di WebAssembly.
Ini namanya PHP Wasm.
Jadi bisa pakai ini.
Gue belum ngulik banyak, tetapi...
konsepnya kita bisa membundling aplikasi kita dan menjalankan pakai PHP Wasm ini.
Untuk menjalankan kode PHP kita di atas browser.
That's it.
Itu simple-nya, ya.
Tentunya ada limitasi-limitasi karena pertama...
limitasi yang utama itu dia jalannya di virtual file system.
Jadi punya kontainer sendiri.
Jadi nggak bisa akses file system dari si...
Jadi nggak bisa meminta kita akses local file system.
Nah, itu bahasanya.
Oke.
Saya sering banget pakai namanya WordPress Playground.
Itu namanya WP Now, ya.
Jadi kalau misalnya saya mau ngetes plugin, mau ngerjain sesuatu.
Terutama menjalankan plugin di CI.
Kan kalau install server-nya sampai Nginx kan kegedean, ya.
Saya sudah pakai WP Now.
Cara pakainya simple banget.
Tinggal pakai npm install global.
Contoh saya punya WP Package.
Oh, itu bisa diinstall jadi global package, ya?
Ya, betul.
Saya punya plugin namanya WP Passkey, ya kan.
Terus kemudian saya cukup tinggal WP Start Now.
WP-Now Start.
PHP-nya kebetulan karena plugin saya harus pakai 81.
Saya pakai 81.
Kalau nggak dia by default 80.
Saya jalankan.
And...
Tadah, dia sudah langsung jalan.
Tanpa perlu install bla-bla-bla.
Tidak perlu pakai was...
XMPP.
Server?
Server-nya nggak ada.
Dia langsung di browser.
Database-nya pakai SQLite.
Mantap.
Plugin yang saya buat tadi.
Karena saya jalankan di dalam folder plugin.
Foldernya plugin saya, passkey.
Dia otomatis install passkey-nya saya sudah deactivated.
Saya nggak ngapa-ngapa ini.
Ini baru fresh install ini ceritanya.
Dan tentunya ininya jalan seperti biasa.
Saya register passkey saya.
Sorry.
Continue.
Dan install passkey.
Seperti biasa sudah terinstall.
Saya lockout.
Dan saya pakai passkey untuk login.
And...
Tadah, selesai.
Jadi...
Development WordPress-nya sekarang itu sudah canggih.
Sudah simple.
Saya nggak perlu ngapa-ngapain.
Udah, tinggal...
Localhost saya udah jalan.
Cukup install.
Jadi pakai...
Enak banget.
Dan itu teknologinya sama seperti...
Kalau yang tadi kan ini...
Jalan di dalam browser.
Kalau itu ini jalannya pakai PHP.
Di localhost.
PHP Wasm.
Dia tetap pakai PHP Wasm.
Di browser.
Jadi kalau kita mau develop WordPress plugin...
Dan terus bikin codec atau tutorial...
Atau semacamnya.
Udah, pakai itu kayak solusi banget ya.
Men-streamline setup-nya juga kan.
Soalnya kalau misalnya...
Apalah, it works on my machine gitu.
Masing-masing versi apasihnya.
Atau lain-lain ya kan.
Kalau ini kan, kalau untuk apa?
Kalau untuk sample atau demo, tutorial, code lab...
Atau developing kan bisa...
Ya itu tadi misalnya suruh jalanin pakai PHP 8.1.
Sisanya, setting-nya semua sama.
Oke, betul-betul.
Sedikit ralat, sorry tadi.
Saya mau sharing screen lagi.
Sedikit ralat yang tadi saya katakan.
Kalau yang tadi WP...
Cukup di-share screen.
Kalau yang tadi WP Playground...
Itu jalan di atas browser.
Tetap pakai PHP Wasm.
Kalau yang tadi yang localhost, dia jalan di Node.js.
Node.js.
Di Node.js dia jalan di Node.js.
Yes, di Node.js.
Tetapi Wasm.
Tetapi Wasm.
Jadi bisa jalan di browser dan juga di Node.js.
Jadi yang WP Now tadi...
WP Now yang saya pakai tadi itu jalan di Node.js.
Jadi kalau jalan di Node.js...
Bisa pakai...
Tentu bisa access file system seperti biasa.
Karena dia di atas layer Node.js.
Kalau di atas layernya browser...
Beda lagi permission-permissionnya.
Menarik.
Jadi kalau di-refresh, nggak ilang.
Yes.
- Ngomongin Node.js. - Nggak reboot baru.
Nggak reboot. Apa?
Nggak reload baru juga ya.
Yes.
StackBits juga...
Apa?
Membuat sebuah teknologi namanya Web Containers.
- Ini juga... - Nah, kita bahas ini...
Di salah satu atas itu pertama ya.
Apa kita bisa bahas?
Tapi kita bahas VidCon, kayaknya ya.
Kalau nggak salah.
Ya, betul.
Jadi mereka ngisi di VidCon.
Jadi...
Mereka announce ini.
Mereka announce ini di 2021 ya.
Kalau nggak salah.
Ya, 2021.
Jadi mereka menggunakan teknologi...
Itu juga, WebAssembly juga.
Nah, Web Containers ini apa?
Jadi kita bisa punya...
Environment Node.js...
Dalam waktu singkat...
Online...
Dengan satu klik aja.
Terus sudah ada VS Code-nya di sana.
Jadi nggak kayak...
Nggak kayak code sandbox kan.
Kita install NPM-nya kan harus lewat itu ya.
Harus lewat yang disebelah kiri itu.
Lagin-lagin gitu ya.
Kalau ini dia udah NPM install aja.
Jadi udah kayak OS.
Ada di dalam browser.
Gitu ya.
Dan itu jalannya di client ya.
Client-side.
Itu jalannya di client.
Disinformer are not running on remote servers.
Kalau...
Kalau nggak salah mereka pakai server kan.
Ada Docker di server.
Kita jalanin di browser.
Ngirim data, balik lagi.
Terus-terus kan.
Kalau ini, Fully di client.
Kita coba jalanin...
Jadi performanya lebih bagus juga ya.
Kita lihat seberapa cepat atau seberapa lambat.
Oh ya.
WebAssembly itu...
Jalannya di atas JavaScript ya.
Meskipun bahasanya Web ya.
Jadi tetap bisa jalan di Node.js.
Nah ini adalah...
Node.js environment.
Iya.
Ini kalau kita lihat slash.
Ya, seperti...
Walaupun mungkin...
Kalau kita mau upload kesana...
Mungkin nggak bisa ya.
Karena ada samebox dan lain-lain.
Tetap seperti yang saya bilang tadi.
Dia pakai virtual file system.
Kalau kita mau copy...
Make dir...
Cuma sedikit ya.
Nggak semuanya gitu.
Nggak full.
Nggak full OS.
Tapi kita bisa npm install.
Cukup representatif lah.
Maksudnya resembling...
Local environment kita kan.
Ya betul.
Express misalkan.
Ya udah dia npm install aja.
Di OS atau seperti di localhost kita.
Kayak kita di command line...
Di terminal kita sendiri kan.
Ngeteknya kayak gitu. Yang muncul yang terjadi kayak gitu.
Itu github juga pakai ini kan.
Github.dev.
Dia pakai linux apa sih ini? Coba.
Lsb_release.
Lsb_release.
Lsb_release.
Lsb_release.
Lsb_release.
Nggak ada.
Nggak ada.
Pake apa ini?
Pake ini bisa nggak ya? APT.
Sudo.
Bisa nggak ya? Nggak bisa kayaknya.
Oh nggak bisa. DSA apa ini?
JavaScript Shell.
Iya. Iya bener.
Saya penasaran sama...
WebAssembly-nya yang dipakai apa?
Kita bisa cek di sini ya.
Di inspect element ya.
Ini ada wasm.
Oh harus refresh nggak?
Refresh.
Oh nggak bisa refresh.
Kontrolnya.
Di capture kita punya key binding.
Oh iya key binding-nya.
Sama aplikasi.
Ini file wasm-nya.
Ini extensionnya dot wasm ini.
Itu adalah binary.
Kalau temen-temen download, lihat isinya ya.
Isinya binary text gitu.
C01.01 gitu.
Nggak jelas.
Bahasa wasm sendiri.
Jadi kayak assembly-lah.
Kayak assembly.
Bukan bahasa machine-nya.
Yang bisa...
Transpile itu browser ya berarti?
Browser atau implement semacamnya.
Ya itu sih...
Web...
Kalau itu yang...
Yang bisa mobile untuk bisa call
Wasm itu ya si asm.js tadi.
Yes asm.js yang sudah ditanamkan
di browser sekarang ya.
Wasm oniguruma.
Kok kedai Onig?
Itu kenapa silahkanan
kedai Onig.
Onig wasm.
Oniguruma in wasm. Apa ini Oniguruma?
Kayak bukan itu deh.
Kayaknya bukan.
Ya anyway.
Jadi sekarang kita sudah
sudah bisa punya seolah-olah
di lokal tapi di web.
Ini lokal.
Ini juga VSCode.
Ada nggak extension-extension
yang kita...
Bisa ya?
Mana?
Enggak ya.
Github juga punya
persis kayak gini.
Setara serupa pakai webpaint
pakai container juga.
Dan kita bisa punya
hampir semua yang jalan di VSCode.
Kalau Github kayaknya yang
Github itu bukan...
Client server dia.
Belum pakai wasm.
Oh nggak pakai wasm ya?
Belum kayaknya.
Kan Github ada dua soalnya
github.dev, ada yang
Codespace.
Kayaknya dia masih pakai teknologi docker
di sisi server. Kayaknya ya.
Koreksi kalau salah.
Seperti tadi
baik itu
stackbleach
ataupun tadi WordPress.
Kalau teman-teman misalkan mau jalanin workshop
itu udah enak banget.
Apa yang perlu diinstall nih?
Yaudah tinggal klik, jalan semuanya.
Buka browser.
Yang penting brosernya mendukung
wasm yang sekarang semua browser
modern sudah dukung.
Yaudah tinggal kita kasih link.
Tinggal diklik dari web.
Selama brosernya sudah dukung
dia sudah bisa ikutin
workshop kita.
Semakin gampang sekarang.
Dan semakin gampang juga
maksudnya kalau dulu kan
misalkan kita mau siapin
kayak environment seperti itu
kita harus bikin di server
mana gitu kan.
Kan ada service seperti clock9nya
AWS atau workspace
di GCP.
Itu kan browser
code editor yang ada di
IDX kan baru, yang sebelum itu ya
workspace ya kalau gak salah ya namanya.
Itu kita harus
workspace betul workspace.
Kita harus diayain server
harus bikin server kan, harus berbayar.
Kalau ini kan di lokal ya, ini gak tahu nih
stackbleach ini berbayar atau enggak.
Gue lupa matiin
gcloud workspace
terus kan ada ya biayanya.
Itu paling
bikin parno tuh sama GitHub
juga gitu kan.
Ada free tiernya sih.
Kalau kita code spaces gak aktif
20 menit dia sat down.
Oh ya bagus ya.
Nah ini ada yang menarik
juga tadi ngomongin soal
Adobe dan ternyata Adobe juga
memanfaatkan machine learning ya.
TensorFlow.js
Sebenernya mirip kayak yang dibahas
Ivan di awal banget tadi.
Sebenernya itu mirip
cuma mereka pakainya Adobe
Photoshop untuk object detection.
Nah jadi apa
membantu
itu mereka di dalam browser
untuk object selection sorry
object selection tool.
Pakainya TensorFlow.js
Nah cuma intinya sih
tadi udah baca nih
artikel ini sekilas kayaknya
si TensorFlow.js
juga kan jalannya di browser. Sedangkan
si Photoshopnya ada
Wasm juga. Jadi sebelumnya
kayak gak play nice
with each other gitu loh kayak gak bisa.
Kayak gak compatible. Buat jalan barengnya
tuh sulit. Nah terus
mereka bisa cari cara
biar Wasmnya
kode core
Photoshop yang
dari Wasm bisa
berkomunikasi dengan TensorFlow.js
yang jalan di browser.
Cuma detailnya sebetulnya
apa tadi karena baca sekilas
yang belum terlalu
paham. Coba ayo kita baca sama-sama.
Ini ini. To tackle this
challenge, first Google and Adobe
collaborated to bring proxying API
to MScripten.
Then they use toolchain to compile
with assembly that is LLVM.
Berarti ada
compiler lagi.
Ada proxying.
Bukan, bukan ada
proxy. Middleman.
Ada middleman, proxy.
Ya, jadi
karena TensorFlow.jsnya tidak jalan
di Wasm kan?
Sementara si
Photoshopnya jalan di Wasm.
Jadi dari
JavaScript, contact ke
TensorFlow.js, balik ke
JavaScript baru dilempar ke
Photoshop, Wasm.
Jadi jalannya dua kali.
Tapi jadi ide yang menarik
juga ya, kalau yang
si TensorFlow
sudah bisa dikompilasi ke Wasm
seperti yang tadi saya juga contohkan.
Misalkan
LLM model seperti
lama, bisa
jalan di browser.
Yang menarik adalah
kalau misalkan teman-teman pakai
chat-gpt, chat-gpt kalau nggak ada internet nggak jalan kan?
Karena dia di server kan?
Kalau ini bisa gitu.
Karena jalannya di browser selama udah
download, samalah kayak jaman
dulu kita
mau buka file Flash.
Download dulu ya.
loading dulu.
Setelah selesai udah nggak perlu koneksi
internet pun bisa.
Kecuali di file
atau di aplikasi kita membutuhkan
koneksi internet. Misalkan kita save dalam
tiap 5 detik kita save file.
Kita save data lah.
Dia save data ke server.
Kita bisa-bisa
lebih bikin rich application kayak
PWA gitu ya.
Ada web assembly-nya juga.
Kayak Vigma lah ya.
PWA juga kan.
Betul.
Web assembly ini bisa
next step lagi.
Kalau PWA kita udah pakai service worker,
udah di caching, udah bisa
offline.
Apa lagi yang belum? Mungkin ada
proses. Kalau misalkan offline mode nih.
Tapi ada sesuatu yang diproses di server.
Ya nggak bisa. Kan harus koneksi.
Walaupun tidak
404 atau tidak 500.
Karena servernya
mati atau koneksi
mati.
Bikin CapCut
tapi pakai PWA
contohnya.
CapCutnya ada di browser?
Ada ya. Tapi PWA
nggak.
Lagi di jalan
pakai CapCut tapi
browser.
Contohnya.
CapCut itu ada.
Versi webnya. Cuman saya belum pernah login.
Karena nggak punya account.
Biasanya pakainya di Windows.
Edit video online.
Oh bisa.
Udah duluan deh.
Tapi kalau belum. Maksudnya kalau dia
belum pakai kayak Wasm atau
semacamnya lah. Misalnya service worker
buat handle pas offline.
Ini semua langsung ke server ya.
Kalau misalnya kita edit video
koneksinya jelek ya putus.
Udah kan ilang kan.
Kita bisa set on offline kan di sini.
Gimana caranya? Ah gue lupa.
Ada di deftol untuk buat offline.
Di sini.
Ini.
Click aja.
Coba.
Ini udah offline.
Terus kita buat text ya.
Kalau refresh mati kali ya.
Ininya mati.
Oh iya kan. Nah kalau itu kan
harus nge-fetch templatenya kan.
Mungkin ininya tetap aman. Nggak mati kan.
Yang di sini nggak masalah kan.
Gitu.
Mayan.
Oke.
Nah.
Buat teman-teman yang
penasaran mau lihat
contoh lain. Saya sempat buat
contoh kode juga.
Contohnya yang tadi saya ceritakan.
Di media kalau di server.
Ini dia bisa konversi ke server.
Prosesnya berada di server.
FFmpegnya ya.
Contohnya disini misalkan.
Loh kok ada foto Ivan.
Loh.
Oh nggak kelihatan. Ya. Ini saya
upload file mp4. Nanti dia
di konversi menjadi file
webm.
Itu server biasa ya?
Ini server. Ini server.
Ya.
Ya. Pakai express.
Terus FFmpegnya jalan di server.
Tapi kalau yang
klien. Nah ini
murni jalan di klien.
Jadi saya
dengan file yang sama.
Memang mungkin jalannya agak lebih lambat.
Tergantung si apa?
Tergantung kecepatan dari
mesin kita.
Tapi di konsol ini kelihatan.
Tidak hanya jalan di sisi
klien. Lokal.
Lokal. Dan ini ketika dia
lagi jalan tiba-tiba internet mati.
Ya udah mati aja. Gak apa-apa. Ini
offline.
Nah itu emang lagi mati.
Iya. Udah ada cache-nya ternyata ya.
Tapi tetap jalan.
Ya. Hasilnya memang agak lebih
lama.
Nah. 31 detik. Tadi 5 detik
jauh ya. Karena kan memang
server diperuntukan untuk melakukan
proses-proses yang berat itu ya.
Tapi ini
murni jalan di sisi
klien.
Kalau mau lihat kodenya bisa ke github.
Bisa dilihat-lihat.
Contohnya.
Nah. Si FFmpeg-nya itu
programnya itu sebetulnya
dari apa? Program
binary ya. Kayak download dari
itu. Binary. Download dari
ini.
Saya download ini. FFmpeg
core.wasm.
Jadi. Dikodenya
sendiri.
Bukan.
Ini yang server. Yang klien
ada di sini.
Djs.
Kemudian klien.js. Nah ini.
Pertama.
Kita import dari
FFmpeg Global.
Apa namanya?
Fungsi create FFmpeg sama
fetch file.
FFmpeg gue bilang itu dari mana
datangnya? Datangnya dari
index.html.
Klien.html.
File wasm ya?
Belum.
Ini. Dari sini.
Ada sebuah
file namanya. Jadi ada javascriptnya ya?
Ada yang udah bikin porting
javascriptnya. Iya. Ambil
dari ini.
FFmpeg.wasm.
Ada satu project namanya
FFmpeg.wasm.
Download disini.
Ini yang udah dikompilasi.
Jadi udah saya.
Seperti yang tadi kita
bicara kan di awal. Saya cuman menggunakan.
Tidak melakukan kompilasi.
Ini udah dikompilasi. Karena FFmpeg
awalnya kan bahasanya. Bahasa low level ya.
Si objektif si.
Nah. Iya. Berarti itu kan
FFmpeg yang versisi
sampai jadi wasm gitu.
Itu berarti ada yang harus bikin dulu. Yang bikin.
Iya. Si project ini yang bikinin.
Kayak si engineer yang
apa? Si Illustrator tadi.
Betul. Iya.
Jadi ini udah jadi. Maksudnya importnya tetep
gak seberat kalau harus
tulis tulang dari awal. Kayak cuman dia
meng-adjust aja.
Ya. Gak aja sih. Cuman maksudnya
apa? Gak dari 0 lah. Minimalnya.
Sudah ada NPM nya juga. Kalau mau pakai
NPM. Karena saya pakai manual.
Pakai vanilla. Jadi saya pakai gini aja.
Ya.
Gak di import gitu. Terus nanti
di client JS nya udah ada
global variable namanya
FFmpeg.
Itu kan. Terus kita ambil
dua fungsi. Yaitu
create FFmpeg sama face file.
Terus kita bikin instance nya.
Saya taro
FFmpeg core nya disini karena cukup besar.
Jadi biar di satu server aja.
Terus ini karena vanilla
ya harus di displeinan.
Di main-mainin lah ya.
Intinya
ada disini. Pada saat kita
klik convert. Nah ini
yang kita lakukan adalah
ambil file nya.
Terus dirite file dengan
FFmpeg.fs.
Terus ini dirun dengan
berbagai flag.
Itulah yang akan FFmpeg.
Inilah yang sebenarnya
dia sebenarnya manggil JavaScript.
Tapi itu bridge ke Wasm.
Betul. Dia manggil
binary file.
Ini adalah instance dari
yang kita buat di atas. Nah ini yang dia
interface untuk ke
FFmpeg yang di sisi server.
Yang kita sudah taro di browser juga.
Terus kita bisa
run seperti biasa dengan
berbagai flag nya. Sampai akhirnya
jadi output nya adalah
download.webm.
Terus dari download.webm
ini kita read
untuk dapatkan datanya.
Kita taro di video
tag dengan
url create object yang
sudah kita bahas di beberapa episode yang lalu.
Data buffer
isinya adalah si video
tadi, tipenya webm.
Stream ya.
Akhirnya
jadilah ini.
Nah ini menarikkan
kalau dilihat kode ini.
Ini kan semua JavaScript ya.
Web developer biasa
yang gak usah ngerti
itu semua tadi gak usah ngerti C++
atau apapun. Ini kan
nulisnya kayak JavaScript biasa aja.
Kalau kita sehari-hari
kita sehari-hari kerja
pakai bahasa-bahasa web
ini kan udah pasti bisa
langsung, pasti langsung bisa
tanpa harus mempelajari
hal-hal tambahan. Nah tapi
ini dengan syarat udah
ada orang lain kayak
di kasus ini kan pakai readymade
ffmpeg wasm tadi
berarti tetep perlu
pihak lain atau orang lain
atau mungkin teman kerja
yang mengkontet
yang ngerjain ini dulu kan
yang bikin ini dulu.
Kerja beratnya sebenarnya disini.
Itu tadi kan tinggal konsum
udah tinggal nulis-nulis.
Nah terus
berarti pertanyaan selanjutnya, kalau kita
pengen kita sebagai web developer
pengen bikin ini nih
si apa, kayak
ffmpeg wasm atau kayak si
itu Adobe engineer tadi, berarti
kita wajib harus
bisa bahasa low-level yang mau
di interface ini kan.
Ya, nggak low-level sih
tapi cukup ngerti
kayak si RAS
terus pakai M scripten
untuk ngumpile.
Ya betul. Jadi nggak
terlalu low-level juga. Contohnya
misalkan goleng, goleng itu udah bisa
secara netif dikompilasi ke wasm.
Jadi dengan
flagter tentu langsung bisa.
Kita masih harus pakai M scripten kali ya?
Enggak, goleng udah
nggak perlu.
Udah punya sendiri.
Nah, nih, pakai ini nih.
Go architecture sama dengan wasm.
Iya.
Tapi sebenarnya didalamnya itu
sudah pakai M scripten kali?
Mungkin juga, kalau itu saya nggak tahu.
Yang dia wasm begitu dikompilasi.
Kita kayaknya harus bikin kayak sepuluh ini.
Wasm ini penyakit banget ya.
Arkitekturnya langsung wasm ya.
Oh iya, iya.
Gue pernah inget tuh apa kemarin ya.
Bisa pakai.
Kenapa nggak kelihatan ya?
Saya lihat disini.
Apa ya kemarin?
Ini bisa
flagnya wasm gitu tinggal.
Jadi udah langsung jadi dot wasm.
Kayak Python juga bisa.
Nah ini nih, kayak gini nih.
Go os.js
Go architecture wasm.
Go build min.o. Apa file-nya wasm?
That's it.
Kita define entry point.
Kita menggunakan go.
Maksudnya ada wasm nggak sih?
Sudah ada goleng nggak?
Oh nggak ada.
Sudah install goleng?
Nggak.
Gue pengen juga hasil akhirnya
json.wasm plus
csfile-nya atau nggak?
Enggak, wasm aja.
Just csfile-nya siapa yang buat?
Ya kita bikin
sendiri, terakhir mose.
Tadi kan ada ffmpeg.min.js
Oh itu udah dibikinin.
Kalau itu
ini kita harus bikin sendiri.
Bikin sendiri, kita load.
Kayak yang contoh
2018 dulu.
Yang di Google
Chrome Dev Summit
Extended di Tokopedia
yang saya contohin ada
cara ngelod file wasm
di JavaScript.
Ini kayaknya ada di sini.
Jadi ada file itu.
Tapi itu nggak banyak.
Itu programatik aja.
Kayak semacam import
dan define output.
Import export.
Ini kan ada ffmpeg.cor.js
ffmpeg.cor.wasm kan.
Ini tujuannya adalah untuk
ini dia, ini dia.
Nggak kelihatan.
Ada nggak ininya?
Load.
Eh, salah kan?
Eh, nggak kelihatan.
Kok nggak bisa kelihatan ya?
Gak bisa kelihatan.
Berat nih, berat.
Kok nggak ada?
Nah ini ada build tool-nya
nggak buat bikin si
cor.js, ffmpeg.cor.js
dari wasm sampai jadi ffmpeg.cor.js.
Itu yang Ivan pengen tahu.
Itu yang Ivan pengen tahu.
Kalau sudah punya wasm,
mau panggil gimana caranya?
Iya, bener.
Kayaknya gua pernah buat deh.
Gua lupa sendiri.
Selain golenc,
zik juga ada.
Wasm itu juga udah secara native
di support.
Seperti tadi, tinggal pake flag aja.
Ini juga basal low level ya.
Wah, dia harus pake ini ya.
Nah, ini kayak gini sebenarnya.
Eh, nggak ya?
Run it through JS. Nah, ini.
Iya, itu ada interface WebAssembly.
Jadi kayak ada
constructor-nya gitu kan?
Iya, jadi harus
dilod dulu.
Modul WebAssembly.
Dulu contohin juga kayak gini.
Pake C++. Saya contohin
jalanin Fibonacci, bikin
Fibonacci-nya DC.
Terus abis itu dikompilasi,
di JavaScript-nya pakai
file system, fs.something.
Read file.
Ini kan
nama file-nya xyz nih.
Jadi dia read file dulu, abis itu
dijadikan instance. Instance-nya udah bisa
dipakai, diexport aja.
Eksport jadi JavaScript
yang kayak tadi tuh? Jadi JavaScript.
Iya, jadi ini adalah interface-nya.
Atau API-nya ya.
Bridge-ing, jembatan.
Nah, untuk zig-nya sendiri
pada saat build-nya tinggal
di target arsitektur-nya aja sama seperti
goleng tadi.
Begitu.
Berarti flow-nya misalnya
kita punya program
atau binary yang masih pakai
bahasa flow atau
mid-level kayak C++.
Misalnya anggap aja lah kita
semacam Photoshop atau Lego.
Perusahaan kita
atau tempat kerja kita punya
produk, punya software kayak gitu.
Terus pengen deporting ke web.
Terus kita ngusulin, pakai wasm aja.
Nah, berarti kan langkah pertama
itu harus diadaptasi
ke wasm dulu ya.
Si program original itu
C++-nya harus
dibikin jadi wasm.
Harus bisa dikompilasi jadi wasm.
Itu tugasnya
developer yang paham
ini malah paham C++
atau Rust atau
bahasa yang, bahasa original-nya
kan, web bisa ngeporting
ke wasm. Kalau web developer biasa
tiba-tiba suruh ngeporting si
software C++ ke
wasm, ya
bisa tapi harus belajar
bahasa awalnya dulu kan.
Berarti langkah pertama itu satu.
Habis itu,
di situ baru web developer bisa
proses selanjutnya itu tadi kan tinggal
instantiate apa?
Tinggal bikin new web assembly
blablabla aja. Jadi
script.js. Nah
dari script.js ya udah. Tadi kan berarti
udah tinggal di nulis apa?
Nulis kode buat execute
kayak yang di contoh ff
mpeg yang JS tadi itu kan.
Betul. Dan
ada beberapa library lain selain
ff mpeg yang sudah
tersedia di
format web assembly.
Yang pertama adalah
skelight. Jadi kita
udah bisa punya database
di browser yang database
nya beneran bukan index db bukan
local storage.
yang tadi pakai
wordpress wasm
pakai skelight juga.
Pakai skelight juga.
Jadi skelight bisa
langsung dari JavaScript bisa langsung kita
tembak ke skelight yang ada di browser.
Ff mpeg tadi udah dibahas
kemudian usb ini apa?
Framework 3d computer graphic.
3d graphic.
Oh si ini Autodesk itu
berarti Autocad ya. Autocad pakai ini
kayaknya.
Autocad pakai ini.
Ada kan fastkit, skia
engine chrome and android.
Ini untuk apa sih gaming ya?
Bukan kompleks. Iya kan
kayaknya dipakai buat game ya.
Kompleks rendering, text shipping,
fastkit. Ini apa?
Kita liat aja.
Skia. Skia itu apa?
Canvas lah ya. Canvas ya. Buat
2d atau 3d ya.
Ada tensorflow.js juga yang
ternyata sudah
menyediakan.
Yang tadi ya.
Ff wasm.
Ada open cv. Ini
library yang cukup
keren di python. Bukan buat bikin cv ya.
Bukan buat bikin cv ngelamar perjalanan.
Cv itu computer vision.
Jadi bisa mendeteksi objek.
Wajah manusia, objek.
Biasanya jalan
by default. Kayaknya native-nya
jalannya di python deh.
Ini library yang cukup terkenal
di python. Betul.
Dan mereka sekarang sudah ada
versi wasmnya. Jadi bisa langsung dipakai.
Dan terakhir yang cukup
menarik juga adalah ini.
Game engine yang namanya kokos.
Ini mereka sudah
mulai mendukung, membuka
dukungan ke
teknologi web.
Kalau unity bikin wasm
juga bisa dong? Bisa.
Jadi ya seperti tadi ya. Contohnya si
Adopt tadi. Katakanlah kita
punya game
house. Kayak software house
tapi buat game gitu ya.
Terus tiba-tiba kita bilang, bisnisnya
mengharuskan kita untuk menyasar
platform web. Karena
wah ini kayaknya kurang nih di android sama ios.
Kita harus punya game yang
berbasis web gitu.
Ya udah. Konversi aja.
Atau mereka bahkan sudah menyediakan frameworknya.
Dan sudah connect juga
ke web GPU.
Yang belum kita sempet kita bahas.
Jadi
Singkatnya web GPU itu adalah
Terpisah itu kudu web GPU.
Iya. Jadi si
browser sekarang sudah bisa mengakses
secara langsung hardware
GPU atau vega card ya.
Nah istilah kerennya ya.
Jadi 3G engine pun sudah
bisa jalan di web. Dengan kecepatan
yang menyetari
native
desktop.
Dan karena dia
tandem sama wasm
jadi nggak terbatas ke
rendering thread dari browser ya.
Yang 60 frames per second.
60 frames per second ya.
Jadi
game-game yang bahkan
web GPU pun game-game seperti
Doom
Quake
Counter Strike. Kita pernah
lihatin ya. Itu juga sudah bisa
jalan di browser. Dengan mungkin
fps-nya tidak terlalu tinggi. Tapi ya bisa
lah gitu. Nah dengan adanya web GPU ya
lebih mantap lagi.
Gitu.
Oke.
Dengan adanya wasm ini
jadi pengen bahas nanti ke depan-depannya
itu kayak
bagaimana bisa mengurangi polusi
dengan teknologi web.
Iya.
Gak perlu pakai server ya.
Biar kerja processing-nya lebih
sedikit.
Gak perlu dimana-mana ada
PC atau
yang gede di belakang sebuah layar
atau restoran.
Semuanya via web saja.
Yes.
Oke.
Ini yang tadi ya? Yang kita bahas tadi ya?
Ya.
Kita bahas. Tapi ini kalau
teman-teman ingin belajar lebih dalam
web assembly API
yang sudah ada di browser. Apa aja
gak cuma manggil doang loh.
Ternyata ada
macem-macem ya.
Terus gue baru buka ini terus bingung ini
apalagi low-level.
Dia bisa access low-level memory.
Dia bisa
ini streaming kan. Kalau kita mau
streaming. Jadi gak perlu
file wasm-nya itu
gak perlu. Perlu dikonsumsi
wasm-nya.
Terus bisa
bisa fetch juga
pakai fetch ya.
Nah kalau itu kan kayak nge-download
nyambil file-nya semua. Baru di
process.
Di export.
Terus bisa
buat teman-teman yang penasaran bentuk wasm
gimana ini dia.
Bisa aja kita tulis sendiri. Sama aja kayak
assembly dulu ya. Bisa aja kita tulis sendiri.
Tapi ribet.
Kayak assembly tadi kan.
Move to mana.
Nah ini bisa dilihat juga ya
di debugger ya.
Bentuknya. DevTool yang baru
sudah mulai lebih
lebih apa namanya?
Bisa nge-debug wasm loh.
Ntar kita bahas lah kapan.
DevTool-DevTool yang
akhir-akhir ini.
Ya lihat aja videonya Jessalinda.
Masalahnya kita belum
nge-operate sampai sejauh itu harus butuh
debug
sampai assembly sih ya.
Belum ada codenya.
Belum ada codenya.
Tapi kan tadi
ada starting code yang bagus sih. Tadi
yang contoh-contoh library yang udah
ada wasmnya.
Ya udah kan kita coba consume itu aja dulu.
Betul.
Ya itu kan buat test aja.
Jadi kita dari perspektif
developer nggak usah belajar
bahasa lain yang sulit-sulit tamat
dulu lah. Coba
ngejalanin ini pakai
API JavaScript yang ada di halaman
MDN. Itu tadi di
test satu persatu coba sambil
di-
sambil di-check di DevTools.
Ya potenya starting point yang bagus
buat belajar dari nol ya.
Ya jadi kita sebagai
developer front-end
atau JavaScript itu
yang bisa kita lakukan adalah belajar
cara mengkonsumsi si WebAssembly.
Karena kalau kita harus belajar
bahasa levelnya ya silahkan aja
tapi itu jalannya cukup panjang ya.
Harus mengetahui bahasanya dulu.
Belajar misalkan temen-temen
mau belajar RAS ya. Belajar RAS-nya dulu.
Belajar semuanya udah bisa bikin aplikasinya
baru-baru dibuat versi WebAssemblynya.
Jadi lumayan ribet ya.
Cuman kalau mau kompilasi
misalkan temen-temen tahu ada satu
atau diminta
klien untuk konversi
aplikasi jadul yang
sudah legacy ke
WebAssembly mungkin bisa coba
beberapa tools. Kalau misalkan C namanya
ada M-scripten.
M-scripten.
Nah ini
bisa melakukan kompilasi
dari C atau C++
ke WebAssembly.
Ke Wasm. Kecuali
kalau tadi kayak cerita Ivan
dari cerita Adobe
Engineer tadi, kalau ada yang nggak
kompatibel ya kita harus belajar
C++-nya buat
ke cek bagian-bagian mana
yang nggak kompatibel. Tapi itu kan
tergantung kompleksitas aplikasinya ya.
Kalau Adobe ya rumit
banget kan. Tapi kalau cuma apalah
FizzBuzz atau
FizzBuzz kali ya.
Nggak bakal serumit. Kalau misalkan
POS, tadinya jalan
di DOS
gitu kan.
Mau di konversi ya mungkin butuh
beberapa
tapi kan setidaknya engine utamanya
mungkin form-nya harus di konversi ya
pakai web kan. Tapi pada saat
di-save mungkin di-save-nya ke mana
misalkan ke VoxPro gitu kan.
Ya itu bisa, mungkin bisa
masih bisa di-conversi ke
web assembly gitu.
Tapi kalau misalkan temen-temen udah pakai yang bahasa
yang udah modern seperti Zic atau
Golang ya bisa langsung aja nggak perlu
pakai MScripten ini.
Gitu. Udah langsung pakai
arsitektur Fleck aja.
Pada sudah mulai bikin ini deh
membuat Wasm itu sebagai
arsitektur gitu.
Nambahin gitu. Betul.
Jadi saya sempat mention
juga pada saat... Jadi nggak cuma 64 bit
lagi, 32 bit atau
ARM
tapi juga ada WebAssembly.
Jadi standar
arsitektur yang baru.
Jadi WebAssembly ini
adalah target kompilasi yang baru
buat bahasa
atau platform.
Kalau dulu kan kita target kompilasinya
64 bit, 32 bit.
Ada
target kompilasi lain.
Nah target kompilasi yang
baru adalah Wasm.
Kurang lebih
sederhananya seperti itu.
Jadi ada tools yang udah
by default ada atau bahasa-bahasa
yang mungkin yang jadul seperti CC++
itu dia...
Ada yang bikinin tools seperti MScripten
ini untuk mengkompilasi
bahasa dia menjadi
Wasm. Gitu.
Oke.
Ada lagi yang mau disampaikan sebelum mudahan?
Mungkin kalau
mau belajar
resource yang paling oke sih
WebDev tadi, WebDev
/WebAssembly ya.
Walaupun terlalu banyak
cukup lengkap ya capupannya.
Di sini kita belajar MScripten juga
ternyata ya.
Introduction.
Ada link-link ke resource yang bisa dicek sendiri.
Jadi
starting pointnya dari situ.
Jadi ini belajar gimana
cara compare CC++ ke...
Dan itu sebenarnya banyak banget sih
MScripten sendiri kan sebetulnya
kalau mau deep dive, wah udah
panjang banget. Terus itu kayak
coding with WebAssembly
ya ini pointer-pointer doang
hal-hal pentingnya lah, kisi-kisinya.
Nah ini tadi yang
dibasivan juga ya.
Dibaging.
Dan masih banyak lagi.
Sampai ke WebAssembly
dan practice.
Nah kapan-kapan
kalau udah belajar kita kayaknya
sekian bulan lagi
perlu bikin revisiting
Wasm atau semacamnya deh.
Betul. Harus ada project nih.
Kita bikin project apa ya pake Wasm ya?
Teman-teman mungkin ada ide?
Jpt custom.
Jadi kayak chat jpt
tapi untuk internal, misalnya internal
tim kita atau apalah perusahaan kita.
Tapi jalannya di lokal semua.
Gak tahu apa.
Itu terlalu optimis, yang simple-simple
dulu aja.
Konversi.
Ya pake yang udah ada aja kayak cuma ditambahin
training data. Gak tahu ya itu
kan use case yang cukup umum ya. Mungkin
udah ada yang bikin.
Jadi kita harus undang dulu
yang
GDE machine learning sudah apa ya?
Ester.
Ester. Nah.
Boleh, boleh, boleh.
Oh ini aja
apa?
Episod-episod
ngobrolin web yang ada
di YouTube kan formatnya video.
Kita konversi jadi formatnya
audio. Jadi bisa
dinikmati di Spotify,
Apple Podcast,
terus bikinin transcriptnya.
Tapi transcriptnya udah rapih gitu
pake tanda baca.
Nah itu susah. Gak mungkin.
Itu pake tensile flash JS
bisa. Kalo pake
OpenAI bisa.
OpenAI bisa.
Pake OpenAI bisa.
Ininya kita kan intonasi
dan kita kan banyak pake slang-language
juga ya.
Kita kalimatnya belum, ya namanya
orang ngobrol informal ya. Kan
gak kayak pindah.
Kalo pindah tuh kan satu kalimat,
maksudnya jelas titik komonnya jelas,
kalimatnya juga jelas, struktur
kalimatnya. Nah kalo ini kan
ragam bahasa
informal dan orang ngobrol.
Ya pasti suatu hari
bisa sih. Pasti bakal ada AI-nya.
Cuma sekarang belum.
Di OpenAI ada namanya Whisper.
Itu open source.
Jadi kalo mau ngulik bisa. Tapi itu ya
masih client server belum Wasm ya.
Itu cukup akurat katanya.
Nah berarti harus ada yang nge-porting.
Harus ada yang nge-porting ke Wasm.
Ya intinya sebenernya
kalo pengen belajar,
ya harus ngulik, harus bikin
sesuatu. Kalo cuman belajar kayak gini-gini aja
ya kurang ya.
Kurang gimana gitu.
Pasti kayak hal-hal yang
edge case-nya gak ketemu.
Kita harus bikin
sesuatu yang belajar, tapi
bisa jadi topik selanjutnya untuk IOX
atau DevFace selanjutnya.
Projek kecil.
Oke kalo gitu.
Untuk malam hari ini,
topik tentang Wasm-nya kita tutup dulu.
Mudah-mudahan kedepannya kalo
ada temen-temen yang udah nyoba.
Atau ada narasumber yang udah nyoba juga.
Bisa lapor-lapor di kita.
Jadi kita bisa menambah
ini juga. Karena kita sendiri jujur
ya hanya pakai aja.
Belum umpilasi dari awal.
Jadi kalo misalkan temen-temen ada yang pengalaman
"Oh saya pernah nih bikin ini disini,
buat client ini." Boleh. Nanti kita undang,
kita tanya lebih lanjut ya.
Untuk episode teori Wasm-nya
udah selesai. Terima kasih banyak.
Introduction to Wasm.
Kita ketemu lagi selasa depan
dengan topik yang berbeda.
Jangan lupa kalo temen-temen punya topik,
boleh silahkan langsung ke bit.ly/ngobrolinweb.
Kita tunggu topik-topiknya disana.
Sampai ketemu selasa depan.
Selamat malam. Bye-bye.
Bye.
Deskripsi asli dari YouTube
Yuk mari kita diskusi dan ngobrol ngalor-ngidul tentang dunia web. Agar tetap up-to-date dengan teknologi web terkini. Topik, tautan dan pertanyaan menarik bisa dilayangkan ke https://bit.ly/ngobrolinweb Topik: - 00:00 intro - 03:00 pengenalan wasm (web assembly) - 10:00 assembly language - 16:00 lanjut wasm - 29:00 side story with ivan - 37:00 demo wordpress playground - 45:00 pengenalan webcontainer - 59:00 demo wasm - 1:10:00 langkah-langkah buat wasm - 1:20:00 start belajar wasm Terimaka Kunjungi https://ngobrol.in untuk catatan, tautan dan informasi topik lainnya.
Episode Terkait
13 Apr 2023
Ngobrolin Format Warna
Topik malam itu terdengar sepele tapi tak terhindarkan: menentukan warna di CSS. Sesedikit apa pun kita berurusan dengan...
7 Des 2022
Ngobrolin Font
Font dipilih sebagai topik justru karena jarang dibahas orang, padahal separuh isi web adalah teks. Ia bisa membuat hala...
8 Mar 2023
Ngobrolin Proyek Fugu
Proyek Fugu adalah nama panggilan yang lebih catchy untuk web capabilities project — upaya menutup jarak antara apa yang...
Suka episode ini?
Episode baru setiap Selasa malam. Dengarkan lewat YouTube, Spotify, atau feed podcast favoritmu.
Memuat komentar dari GitHub Discussions...
Jika komentar tidak muncul karena ekstensi privasi / adblocker, kamu bisa berdiskusi langsung di GitHub Discussions .