YouTube Music: Aplikasi ‘Malas’ atau Jenius?

Dikala mood sedang suntuk, atau pengen dengerin rilis dangdut pantura terbaru. Wkwkwk. YouTube Music adalah pilihan saya untuk mendengarkan musik di desktop dibanding lainnya.

Alasannya adalah algoritma Google selalu pas di hati 😂.

Namun, ada satu hal yang selalu menggelitik rasa penasaran saya: Kenapa Youtube Music tidak memiliki aplikasi native di desktop?

Jika kalian menginstal YouTube Music di PC atau Mac, yang kalian dapatkan sejatinya hanyalah sebuah PWA (Progressive Web App). Itu hanyalah website yang “dibungkus” agar terlihat seperti aplikasi.

Awalnya saya kira ini hanya bentuk “kemalasan” Google untuk menekan biaya development agar satu kode bisa jalan di semua OS. 😬

Tapi, setelah iseng “ngulik” dan membedah source code-nya via Inspect Element, saya menemukan bahwa alasannya jauh lebih kompleks daripada sekadar efisiensi biaya. Ada arsitektur video player yang unik di sana.

Keunikan Hybrid: Audio vs Video

Berbeda dengan Spotify atau Apple Music yang murni audio-first player, YouTube Music memiliki beban teknis ganda. Ia harus bisa menjadi pemutar musik, tapi di detik berikutnya harus bisa berubah menjadi video player jika pengguna menekan tombol “Video” (karena backend-nya terintegrasi dengan YouTube Main).

Tantangannya adalah: Bagaimana cara membuat transisi audio-ke-video ini secara instan, tanpa buffering ulang, dan tetap sinkron?

Disinilah saya menemukan implementasi teknis yang menarik pada struktur DOM mereka.

Adanya Decoupling UI dan Player

Jika kita melihat aplikasi web pemutar media sederhana, biasanya tag <video> atau <audio> diletakkan satu paket dengan tombol play/pause-nya. Namun, YouTube Music memecah logika ini demi mempertahankan prinsip SPA (Single Page Application).

Saat melakukan inspeksi elemen (Inspect Element), hal pertama yang mungkin membuat kalian mengernyitkan dahi adalah keberadaan tag-tag asing seperti <ytmusic-player-bar> atau <ytmusic-app>.

YouTube Music (dan banyak layanan Google lainnya seperti YouTube Main dan Google Earth) dibangun menggunakan library front-end buatan Google sendiri bernama Polymer.

Adanya dua giant component ini yang seakan-akan bekerja secara terpisah namun sinkron, tapi (sepertinya) seperti ini menurut pengamatan saya:

1. ytmusic-player-bar: Komponen yang selalu menempel di bawah layar (footer). Karena ini adalah custom element, ia memiliki manajemen state sendiri untuk mengurus kontrol navigasi, judul lagu, dan progress bar.
2. ytmusic-player-page: Area kanvas utama yang menampilkan lirik atau me-render video klip.

Secara hierarki yang telah saya sederhanakan, strukturnya terlihat seperti ini:

<ytmusic-app>
  <ytmusic-app-layout>
  
    <div id="nav-bar-background">...</div>
    
    <ytmusic-player-page class="style-scope">
       <div id="player-container">
          <video class="html5-main-video"></video>
       </div>
    </ytmusic-player-page>
    
  </ytmusic-app-layout>

  <ytmusic-player-bar class="style-scope">
  </ytmusic-player-bar>
</ytmusic-app>

Masalah “State” dan Persistensi

Pemisahan antara ytmusic-player-bar (kontrol) dan ytmusic-player-page (tampilan) ini adalah hal yang krusial, jika kalian biasa membuat web app berbasis PWA.

Jika Google membuat aplikasi ini sebagai aplikasi native biasa atau struktur web tradisional, perpindahan halaman (misalnya dari menu “Home” ke menu “Library”) akan mereset state aplikasi. Musik akan berhenti. (Maksudnya: mereka mungkin harus re-implement hal-hal yang sebenarnya sudah berjalan mulus di web)

Dengan arsitektur PWA berbasis Web Components (Polymer/Lit) ini, ytmusic-player-bar berada di luar router konten utama. Artinya, ketika kita berpindah-pindah halaman mencari lagu lain, player bar tidak pernah di-reload.

Namun, kerumitan muncul saat mode Video. Video harus tampil di area konten (player-page), bukan di bar bawah. Tetapi kontrolnya tetap di bawah.

YouTube Music mengakalinya dengan State Management yang ketat. Saat kita menekan tombol “Video”:

• ytmusic-player-bar tetap menjadi “remote control”, mengirim perintah ke elemen video yang secara visual berada jauh di atasnya dalam struktur layar, namun secara DOM mungkin saja di-reparenting atau dimanipulasi posisinya.

• ytmusic-player-page diperintahkan untuk naik ke lapisan atas (z-index tinggi).

Stream audio yang sedang berjalan di-handover ke elemen video tanpa memutus koneksi buffer.

Apa yang bisa kita pelajari?

YouTube Music membuktikan bahwa dengan arsitektur DOM dan pemanfaatan PWA yang ciamik, tepat dan cerdas, bisa mengaburkan batasan antara “Aplikasi Web” dan “Aplikasi Native”.

Sebagai engineer atau web developer, tugas kita bukan lagi sekedar menempelkan video player di halaman web, tapi merancang orkestrasi elemen agar pengalaman pengguna terasa seamless, sekompleks apapun logika di belakangnya.

Implementasi PWA yang dilakukan oleh Youtube Music menurut saya adalah hal yang sangat masuk akal, dimana teknologi PWA, web hingga browser saat ini sebenarnya sudah cukup mumpuni untuk menangani native-like app seperti Youtube Music. Terima kasih.