Ketertarikan pada WebAssembly sangat bagus, tetapi sejauh ini Anda jarang bertemu orang yang menggunakan teknologi ini dalam proyek yang sedang berjalan. Pengembangan aplikasi untuk Smart TV juga “JavaScript tidak lazim”, ketika semua orang mendengar sesuatu, tetapi hanya sedikit yang mencobanya secara pribadi.
Dan
Andrei andreynagih Nagih memiliki pengalaman di kedua bidang: dia sebelumnya bekerja pada aplikasi Smart TV dari proyek Peers.TV, dan dalam beberapa bulan terakhir telah menjadi begitu akrab dengan WebAssembly sehingga dia akhirnya membuat laporan tentang hal ini di konferensi HolyJS kami. Dan dalam siaran online HolyJS, kami bertanya kepadanya tentang keduanya.
Dan sekarang mereka memutuskan bahwa itu juga menarik bagi pembaca Habr, dan mereka membuat versi teks wawancara yang diedit.
(Jika seseorang lebih nyaman dengan format video, alih-alih membaca posting, Anda dapat menonton video aslinya .)Evgeny phillenium Trifonov: Anda membuat presentasi di sini tentang WebAssembly - apakah ada banyak pertanyaan pemirsa, dan apakah mereka dari "tertarik secara teoritis", atau apakah Anda sudah ditemukan secara praktis menggunakan?Andrei Nagikh: Setelah laporan, saya menjawab pertanyaan yang sangat berbeda di area diskusi selama satu jam, saya terkejut bahwa ada begitu banyak dari mereka di seluruh spektrum. Pada dasarnya, pertanyaan-pertanyaan itu dari mereka yang “hanya ingin tahu,” tetapi ada orang yang sudah menggunakannya. Yang mengejutkan, karena orang seperti itu sedikit. Ada beberapa pertanyaan praktis.
Eugene: Sebelumnya, mereka sering berkata tentang WebAssembly "segera setelah itu telah matang dan menjadi berlaku." Dan sekarang teknologinya sudah seberapa "matang"?Andrey: Teknologi itu sendiri sudah cukup berfungsi, dapat digunakan dalam produksi. Kami menggunakannya. Tapi masalahnya ada pada alat. Kompiler itu sendiri cukup bagus, karena ternyata lebih tua dari teknologi itu sendiri - tersedia dari versi sebelumnya, dengan asm.js. Tetapi alat debugging, peta sumber, debugger - ini masih sulit. Saya pikir pada tahun depan atau dua browser akan menarik poin ini.
Eugene: Dan karena apa yang awalnya Anda butuhkan WebAssembly - proyek apa, dan apa manfaatnya?Andrew: Salah satu proyek kami, ByteFog adalah teknologi untuk pengiriman konten video P2P. Kami mungkin memiliki case pengguna paling ideal yang dapat Anda pikirkan untuk WebAssembly. Kami sudah memiliki basis kode besar di C ++, kami tidak ingin menulis ulang ke bahasa lain, dan kami membutuhkannya di browser. Oleh karena itu, teknologi ini tampaknya sesuai seratus persen di sini.
Pada awalnya kami berpikir bahwa kami akan mengambilnya, hanya kompilasi dan itu akan berhasil. Tapi, tentu saja, ini tidak terjadi dalam hidup, itu sebabnya laporan tentang menyapu dan, pada kenyataannya, tentang cara menyeret semuanya ke dalam produksi lahir.
Oleg olegchir Chirukhin: Dan apa masalah utama yang muncul?Andrew: Masalah utamanya adalah kita tidak memiliki akses ke sistem. Kami punya aplikasi asli, bisa melakukan apa saja. Saat kami porting ke browser, kami tidak dapat melakukan apa pun di luar JavaScript. Dan Anda harus hidup dengannya, Anda harus menggunakan API browser.
Proses porting aplikasi kami memakan waktu delapan bulan. Benar, selama periode ini kami melakukan refactoring yang baik terhadap basis kode kami, yang, secara umum, baik. Dan sekarang kita bisa porting di tempat lain.
Oleg: Tulling telah disebutkan, tetapi apakah mungkin secara lebih rinci? Debugging, tracing, profiling, itu saja.Andrew: Singkatnya, semuanya buruk. Tetapi ada kilasan kecil hal-hal baik.
Nah, kompiler memiliki lebih atau kurang tenang: itu Emscripten (saya berbicara tentang C ++, di runtimes lain - Rust, Go, Kotlin / Native - dengan cara yang berbeda).
Debugging: Firefox mendukung peta sumber, yang dengan sendirinya tidak buruk. Google Chrome hanya memungkinkan Anda untuk melihat kode assembler, Anda dapat meletakkan breakpoints di sana, tetapi ini adalah begitu-begitu.
Profiler berfungsi lebih baik di Firefox, di Chrome sedikit lebih buruk. Perbedaannya adalah bahwa Firefox melepaskan nama-nama, yaitu, membuat mereka apa yang ada di kode sumber. Chrome menunjukkan nama yang rusak, dan Anda perlu menyipit untuk memahami apa itu.
Oleg: Bagaimana orang beradaptasi dari JavaScript ke C ++ dan sebaliknya?Andrey: Mungkin, Anda bisa melihat saya di sini - awalnya front-end, yang sekarang menyentuh kode asli. Tapi, jujur saja, bahkan sebelum proyek saya memiliki keinginan untuk mencoba kencing sesuatu secara asli. Jadi saya mungkin tidak terlalu representatif.
Kami banyak berbicara dengan kolega saya Yura, yang berbicara dalam proyek di sisi C ++: dia memberi tahu saya tentang "plus", saya katakan kepadanya tentang JavaScript. Dan dia tertarik dengan JavaScript. Kebetulan - sepuluh dari sepuluh: asli ingin mengetahui JavaScript saat itu? Dan kami memiliki tim yang baik.
Masih ada orang ketiga - ini adalah Kolya, seorang arsitek yang umumnya melihat kode assembler dan berkata: “Teman-teman, toh itu bisa dibantah. Baiklah, lihat, semuanya jelas: ini adalah mesin bertumpuk, di sini kita bekerja dengan memori, di sini berhitung ... teman-teman, mengapa kita membutuhkan peta sumber? ” Yah, dia tahu bagaimana menulis untuk embedded system, di waktu senggang dia melakukannya.
Oleg: Dan apakah Anda punya kejutan khusus dari C ++: dari bahasa, dari kegunaan, bekerja dengannya?Andrei: Ya, tentu saja, saya sudah siap untuk ini. Kejutan paling penting adalah bahwa setelah berbicara dengan nilai tambah selama proyek, kami menyadari bahwa JS dan C ++ memiliki banyak kesamaan. Tampaknya bahasa yang sama sekali berbeda, tetapi Anda dapat menemukan titik persimpangan. Anda bahkan dapat membuat laporan terpisah tentang topik ini, Anda harus memikirkannya.
Eugene: Dan sekarang, setelah satu dan yang lain, apa yang ingin Anda tulis?Andrew: Sebenarnya, saya belum siap untuk menulis dalam produksi C ++. Saya akan melakukan sesuatu untuknya sendiri. Tapi JavaScript - kemana perginya?
Oleg: Dan bagaimana dengan fakta bahwa C ++ cepat, dan dengan banyak fitur keren seperti templat? Bisakah templat membantu ujung depan saat menulis beberapa kode super-standar?Andrei: Ada lelucon seperti itu: "jika Anda memiliki masalah dan Anda ingin menyelesaikannya menggunakan ekspresi reguler, maka selamat, Anda sekarang memiliki dua masalah." Saya merasa ada yang mirip dengan templat. Dalam proyek kami, kami mencoba untuk tidak menggunakan template, arsitek sangat tahan ketika pengembang C ++ mencoba untuk mengimplementasikan sesuatu di sana. Masalah muncul dengan debugging: tidak pernah jelas di mana tepatnya itu salah.
Oleg: Artinya, tidak jelas apa yang terjadi pada kode yang dihasilkan? Dia tidak bisa membangun peta sumber ke sumber?Andrew: Sejauh yang saya tahu, bahkan di C ++ asli dengan templat, debugging sulit. Saat kami seret di bawah WebAssembly, kami akan mengalami masalah dengan debugging di bawah WebAssembly. Karena itu, saya pikir itu akan menjadi neraka sama sekali.
(perhatikan kamera dengan cermat) Anak-anak, jangan gunakan templat C ++!
Oleg: Tanpa templat, ia akan berubah menjadi C. Dimungkinkan untuk menulis dalam C. murniAndrew: Tapi bagaimana dengan benda-benda itu?
Oleg: Ya ... "C dengan kelas", ya. Saya hanya berpikir bahwa menulis kode dalam C dengan kelas dan dalam C ++ idiomatik dengan templat adalah dua metode yang sama sekali berbeda.Andrew: Ya, itu mungkin.
Oleg: Pertanyaan filosofis: tidakkah Anda berpikir bahwa ketika WebAssembly ditambahkan ke browser, portal ke neraka terbuka?Andrew: Sepertinya begitu. Karena sekarang, mungkin, akan modis untuk mengambil salah satu perpustakaan atau program C ++ yang telah ditulis untuk seluruh keberadaan C ++, coba kompilasi di browser dan lihat apa yang terjadi. Hari ini saya menunjukkan demo Windows 2000 di browser.
Oleg: Maksud saya, apakah ini hanya Windows 2000 yang lengkap?Andrew: Ya, ini adalah Windows 2000 yang sama, yang 18 tahun lalu dan yang membutuhkan seluruh komputer untuk menjalankan - dan sekarang Chrome membutuhkannya.
Oleg: Dan bagaimana dengan hal-hal yang memerlukan mode kernel, apakah hanya itu?Andrew: Dia menjalankan emulator QEMU, dan porting secara pribadi oleh WebAssembly oleh Fabrice Bellar (penulis QEMU). Di sana, tentu saja, Anda tidak dapat mengakses sistem file, jaringan. Tapi ini Windows 2000, itu dimulai, mencerai-beraikan, dan semuanya ada di sana. Anda bisa lihat.
Oleg: Mari kita beralih ke topik aplikasi untuk Smart TV. Omong-omong, bisakah Anda melakukan sesuatu yang menarik dengan WebAssembly di sana?Andrew: Mungkin saja jika didukung di sana. Apa masalah dengan Smart TV? Perkembangan ini seperti pengembangan frontend sepuluh tahun yang lalu, karena Smart TV tidak diperbarui. Seorang pria membeli TV, menggantungnya di dinding, dan dia menggantung di sana selama bertahun-tahun.
Oleg: Tapi saya terus-menerus ada "tunggu, firmware sedang memuat." Sudah membuat marah.Andrei: Firmware mungkin memuat, tetapi sejauh yang saya tahu, itu tidak secara langsung memperbarui sistem, browser. Akibatnya, kami masih mendukung TV bertahun-tahun yang lalu, di mana browser muncul sebagai Chrome 5.
Oleg: Saya bahkan tidak ingat itu.Andrew: Saya juga tidak ingat. Pengembangan untuk Smart TV, terutama yang lama, adalah ladang ranjau, mirip dengan ujung depan perang browser.
Oleg: Jadi, Anda harus membuat tata letak peramban super-silang, yang akan berfungsi pada versi lama dan baru?Andrew: Ya. Di sana, pada kenyataannya, masalahnya tidak begitu banyak dengan tata letak seperti dengan JavaScript - ketidakcocokan dengan API, sekarang saya tidak akan menyebutkan semuanya.
Oleg: Dan apa lagi yang tersedia di browser yang ingin Anda gunakan di Smart TV, tetapi tidak?Andrew: Sejuta hal, dimulai dengan flexes (bahkan bukan JavaScript) dan berakhir dengan WebRTC. ByteFog menggunakan WebRTC. Akan lebih bagus jika kita menarik kode yang sudah kita miliki di Smart TV ...
Eugene: Dan di samping masalah yang disebutkan, pengembangan untuk Smart TV - seperti apa rasanya? Apa sensasinya?Andrew: Terkadang pengembang peramban Smart TV tidak menyukai programmer yang mengembangkan aplikasi untuk Smart TV, karena alat debugging sangat buruk, praktis tidak ada. Ini tidak berlaku untuk platform Tizen dan webOS modern, mereka melakukannya lebih baik di sana. Tapi saya melakukan ini sebelumnya, lalu ada platform lama, dan semuanya buruk di sana. Alat debugging terbaik adalah
weinre , yang sebenarnya bukan debugger - Anda tidak dapat menghentikan JavaScript di sana; Ini adalah jenis porta Chrome DevTools yang berjalan di soket web. Secara umum, adalah mungkin untuk men-debug tata letak, tetapi dengan JavaScript praktis tidak mungkin untuk melakukan apa pun. Entah bagaimana kami hidup.
Oleg: Tapi mengapa men-debug di Smart TV itu sendiri, jika Anda dapat menjalankannya di browser?Andrew: Di browser, kami memiliki JavaScript dan ada API yang diberikan browser kepada kami. Ini adalah dua hal yang berbeda. Demikian pula, di TV kita memiliki JavaScript, kita memiliki API dari mesin browser ...
Oleg: Kemungkinan besar, ini adalah WebKit.Andrew: Ya, sebagai aturan. Dan ada kategori API lain - yang disediakan oleh platform TV ini. Pertama-tama, ini adalah pemain, lalu fitur lainnya - remote control dan sebagainya. API ini tidak akan ada di browser.
Ada emulator, produsen benar-benar menyediakannya, tetapi mereka tidak sepenuhnya cocok dengan perangkat kerasnya. Oleh karena itu, bukan fakta bahwa debug pada emulator akan berfungsi di TV. Dan sebaliknya: ini mungkin tidak bekerja pada emulator, tetapi itu akan berjalan dengan sempurna di TV. Jadi pada akhirnya, kami sampai pada kesimpulan bahwa kami tidak menggunakan emulator, tetapi mencoba melakukan debug pada perangkat keras nyata. Ternyata lebih cepat: Anda tidak membuang waktu untuk bug yang tidak ada.
Oleg: Dan berapa banyak platform yang harus Anda tangani, dan seiring berjalannya waktu mereka menjadi lebih kecil atau lebih besar?Andrei: Ketika saya terlibat dalam Smart TV, ada transisi dari produsen dari sistem operasi lama, yang secara kondisional disebut Linux dan masing-masing memiliki saus sendiri, ke beberapa yang baru. Kemudian kami harus menulis tiga aplikasi yang berbeda - untuk Samsung, LG dan Panasonic. Aplikasi-aplikasi ini, secara relatif, menyalin kode. Dan kemudian beritanya muncul hampir bersamaan bahwa Samsung beralih ke Tizen, LG beralih ke webOS, dan Panasonic pindah ke Firefox OS (setelah itu tidak bertahan, dan Panasonic sekarang bercabang).
Secara umum, akan terlihat bahwa semua orang mengubah platform - mengapa tidak menyatu pada satu? Akan jauh lebih baik untuk semua orang, terutama untuk pengembang: akan ada lebih banyak perangkat lunak, pengguna akan menerima lebih banyak program yang bermanfaat. Tapi tidak, kami masih menulis aplikasi yang berbeda.
Oleg: Apakah mungkin mengisi semua platform di suatu tempat?Andrew: Ya, pada akhirnya kami sampai pada satu kerangka kerja tunggal, kami mengganti hal-hal platform spesifik dan mencoba menulis logika bisnis lintas platform. Tapi sepertinya ini bisa dihindari.
Oleg: Dan ada TV Android?Andrew: Ada, dan dua jenis. Bagaimana Anda melakukannya sebelumnya? Kami memasukkan Android biasa ke TV, dan melepaskannya. Dan kemudian Google membuat cabang khusus TV Android, lebih baik dioptimalkan untuk D-Pad, yaitu, remote control. Ada juga TV semacam itu. Tapi ini adalah cerita yang terpisah dan toko yang terpisah.
Dan jika di perangkat seluler Android setiap orang menang dan berbagai produsen memilih OS ini, maka Google tidak dapat melakukan ini dengan TV. Alih-alih semuanya terbatas pada satu platform, ada satu lagi, seperti pada gambar xkcd.
Eugene: Saya punya TV di bawah TV Android saya dengan layar 4K, tetapi TV itu benar-benar menerima 4K dari input HDMI, tetapi Android bawaannya ada di 720p. Mengapa ini terjadi? Karena TV ramah anggaran dengan standar 4K, apakah produsen mungkin menghemat perangkat keras?Andrei: Ya, saya pikir, di sini mereka bersandar pada kenyataan bahwa sistem operasi tidak dapat membuat gambar 4K pada perangkat keras ini. Bahkan, ini adalah situasi yang umum ketika Smart TV (yaitu, bagian pada TV yang berasal dari aplikasi) tidak menggunakan resolusi layar penuh. FullHD bocor ke HD Ready, 4K ke FullHD atau bahkan 720p. Ini adalah momen yang menarik ketika kami tidak dapat menampilkan konten 4K di TV 4K, meskipun kami memiliki TV dan konten.
Televisi umumnya sering memiliki antarmuka - sayangnya, ini adalah momok dari platform-Smart TV. Selain itu, di Yandex.Market, jangan mencentang "TV yang tidak akan melambat" dan memfilternya. Tampaknya, masih harus datang ke toko dan memilih di sana.
Oleg: Dan bagaimana hal ini memengaruhi pengembangan aplikasi? Jika Anda menambahkan banyak div, apakah aplikasi semakin lambat?Andrew: Tentu saja. Jika Anda perlu membuat daftar besar, Anda harus memutarbalikkan dan membuat tidak semua, tetapi sebagian. Kami dapat memiliki dua ratus dari mereka dalam daftar saluran, dan kami tidak dapat membuat seluruh daftar - ia kemudian memiliki rem ketika menggulir.
Saya berbicara tentang situasi beberapa tahun yang lalu. Di TV yang sedang dirilis sekarang, segalanya bisa jauh lebih baik. Tetapi, sekali lagi, orang jarang mengganti TV.
Oleg: Bagaimana menurut Anda, seperti apa masa depan semua yang sekarang kita lihat di Smart TV?Andrew: Saya pesimis. Saya berharap perkiraan saya tidak menjadi kenyataan, tetapi kami melihat penurunan teknologi 3D di TV, ketika semua produsen mengatakan: "Oke, tidak ada yang membeli ini, ini bukan faktor kunci ketika memilih perangkat." Sepertinya Smart TV dapat mengalami nasib ini, walaupun saya tidak mau.
Oleg: Lalu apa pola utama untuk menggunakan benda ini jika Anda tidak memiliki Smart TV? Ambil PC besar dan letakkan di TV?Andrew: Komputer besar, saya pikir tidak ada yang mau menempel. Konsol mungkin merupakan pilihan terbaik, tetapi Smart TV dan konsol memiliki satu kesamaan: remote control. Dan untuk membuat remote control yang baik sangat sulit. Kadang-kadang mereka membuat joystick dengan accelerometer, yaitu, mereka menerapkan kontrol gerakan, atau meniru mouse, tetapi ini juga jauh dari ideal. Secara umum, masalah dengan Smart TV lebih terletak di area UI / UX. Sebagian, kontrol suara dapat membantu televisi UX - di Peers.TV, didukung oleh smartphone pengguna, dan sekarang kami sedang mengerjakan remote control khusus dengan mikrofon.
Eugene: Ya, saya melihat bahwa Google dengan tekun memimpin TV ke arah kontrol suara. Sementara ini terjadi dengan berbagai keberhasilan. Tapi kemudian kita mengakhiri pembicaraan seperti ini: mari kita berharap bahwa di masa depan itu akan cukup bagi pemirsa kita untuk mengatakan "mulailah menyiarkan HolyJS untukku"!Jika Anda memiliki pertanyaan saat membaca tentang WebAssembly atau Smart TV, tanyakan pada Andrey di komentar.
Dan perhatikan juga bahwa pada 24-25 Mei HolyJS berikutnya akan diadakan di St. Petersburg. Programnya belum diumumkan, tetapi mungkin juga akan ada tempat untuk “javascript atipikal” yang melampaui front-end biasa - dan tiket secara bertahap menjadi lebih mahal.