• 

  PWA di 2026: Masih Relevan atau Sudah Digantikan?

  Tahun 2018-2019, semua orang ngomong PWA. “Web yang bisa jadi native app!” katanya. Google push habis-habisan, Twitter Lite jadi studi kasus andalan, dan banyak yang prediksi PWA akan gantiin native apps.

  Lalu apa yang terjadi? iOS support-nya setengah-setengah, Apple tidak mau beri akses ke fitur native dengan alasan yang kadang tidak masuk akal, dan adopsi yang terjadi kurang dari yang diharapkan.

  Tapi sekarang 2026. Banyak yang berubah. Mari kita lihat kondisi PWA sekarang dengan jujur.

  Apa yang Sudah Membaik

  Apple Akhirnya Lebih Serius

  Ini yang paling significant. Selama bertahun-tahun, iOS menjadi bottleneck terbesar adopsi PWA. Safari tidak support Push Notifications, tidak support Background Sync, dan banyak Web API yang sudah ada di Chrome tapi tidak ada di Safari.

  Di iOS 16.4 ke atas, Apple akhirnya enable Web Push untuk PWA yang diinstall dari home screen. Di versi-versi berikutnya, dukungan terus diperluas. Ini bukan perfect, tapi jauh lebih baik dari sebelumnya.

  Web APIs Makin Lengkap

  Fitur yang dulu cuma native app yang bisa:

  • Web Bluetooth — connect ke perangkat Bluetooth
  • Web NFC — baca/tulis NFC tags
  • File System Access API — akses file system user
  • Web Share API — share native di berbagai platform
  • Badging API — set badge di icon app
  • Screen Wake Lock — prevent screen dari sleep

  Semua ini sekarang ada di web. Masih ada gap dengan native, tapi gap-nya semakin kecil.

  Performance yang Makin Baik

  V8 engine terus dapat optimasi. WebAssembly makin mature. Kalau dulu PWA terasa laggy dibanding native, sekarang untuk sebagian besar use case perbedaannya sudah tidak terlalu terasa.

  Apa yang Masih Jadi Tantangan

  App Store Discovery

  Kalau kamu build PWA, user harus menemukan website kamu terlebih dahulu. Kamu tidak bisa “listing di App Store” seperti native app.

  Ada workaround — Google Play Store menerima TWA (Trusted Web Activity) yang essentially adalah PWA yang di-wrap. Microsoft Store juga terima PWA. App Store Apple? Belum, dan kemungkinan kecil akan berubah.

  Push Notification di iOS Masih Terbatas

  Walaupun sudah support, push notification di iOS untuk PWA masih ada batasan. User harus install dulu ke home screen, dan ada permission flow yang berbeda dari native.

  Akses ke Hardware Spesifik

  Kamera, mikrofon, GPS sudah bisa. Tapi untuk hardware yang lebih spesifik — sensor khusus, akselerometer dengan presisi tinggi untuk gaming, Bluetooth Low Energy dengan control penuh — native masih unggul.

  Gap di Ekosistem Enterprise

  Banyak enterprise tools dan MDM (Mobile Device Management) lebih mudah manage native apps. Kalau kamu target B2B dengan keamanan tinggi, ini bisa jadi blocker.

  Kapan PWA Masih Sangat Worth-it di 2026?

  1. Konten dan Data-Heavy Apps

  News apps, e-commerce, dashboard, social media — ini adalah sweet spot PWA. Fitur offline dengan service worker, performance caching, dan install ke home screen bisa beri pengalaman yang sangat baik tanpa harus maintain dua codebase.

  2. Audience yang Tersebar Luas

  Kalau kamu target user di negara berkembang dengan device yang beragam dan koneksi yang tidak stabil — PWA adalah pilihan terbaik. Satu URL, bisa diakses dari device apapun, dengan offline capability.

  3. Budget Terbatas

  PWA = satu codebase untuk semua platform. Dibanding maintain native iOS + native Android + web, PWA bisa memangkas biaya development secara significant. Untuk startup atau project indie, ini huge.

  4. B2C App dengan Fungsi yang Tidak Perlu Deep Native Access

  Kalau user kamu tidak butuh akses kamera intens, augmented reality, payment NFC, atau hardware yang sangat spesifik — PWA sudah lebih dari cukup.

  Kapan Tetap Pilih Native?

  Ada kondisi di mana native masih pilihan yang lebih masuk akal:

  Game mobile — performa rendering, akses GPU, dan kontrol hardware yang dibutuhkan game masih lebih baik di native.

  App yang sangat hardware-intensive — kamera AI, AR/VR experience, fitness tracker dengan sensor presisi.

  App yang butuh deep OS integration — widget, shortcut di home screen yang kompleks, system-level integration.

  Regulated industries — banking, healthcare, dengan compliance ketat yang mungkin mewajibkan native.

  Framework untuk Membuat PWA di 2026

  Kalau kamu mau mulai, beberapa pilihan populer:

  Next.js + PWA plugin — Paling populer untuk React developer. next-pwa atau @ducanh2912/next-pwa handle service worker secara otomatis.

  Nuxt.js + @vite-pwa — Equivalent untuk Vue developer.

  SvelteKit — Lightweight dan PWA-friendly secara default.

  Vite PWA Plugin — Agnostik framework, bisa dipakai dengan Vite-based setup apapun.

  Checklist PWA minimal:

  • [ ] Web App Manifest (icons, name, theme color)
  • [ ] Service Worker (caching strategy)
  • [ ] HTTPS
  • [ ] Responsive design
  • [ ] Offline fallback page

  Cara Cek “PWA Score” App Kamu

  Chrome DevTools punya Lighthouse yang bisa audit PWA score. Buka DevTools → tab “Lighthouse” → run audit. Kamu akan dapat skor dan rekomendasi spesifik apa yang perlu diperbaiki.

  Realita di Lapangan

  Saya sudah bangun beberapa PWA untuk klien, dan kondisinya begini:

  • User yang install ke home screen itu retention-nya jauh lebih tinggi dari yang akses via browser biasa
  • Install rate dari browser ke home screen masih rendah — user perlu diedukasi atau di-nudge
  • Untuk proyek dengan target Android-heavy, PWA bekerja sangat baik
  • Untuk proyek yang sangat iOS-centric, native masih lebih smooth experience-nya

  Kesimpulan

  PWA di 2026 tidak “menggantikan” native apps, tapi juga tidak mati. Yang lebih tepat: PWA sekarang adalah pilihan yang legitimate untuk banyak use case, bukan compromise yang dipaksakan.

  Kalau proyek kamu adalah app content/data-heavy, budget terbatas, atau audience yang tersebar luas — PWA adalah pilihan yang solid. Kalau butuh deep hardware access atau game mobile — native masih lebih tepat.

  Kuncinya: pilih berdasarkan use case, bukan hype atau counter-hype.

  ---

  Lagi planning project mobile dan bingung pilih PWA atau native? Mau diskusi tradeoff yang sesuai situasi spesifik kamu? Yuk ngobrol — hubungi mafadev.

  August 22, 2026

• 

  WebSocket vs SSE: Pilih Mana untuk Real-time App?

  Waktu pertama kali membuat fitur notifikasi real-time, saya langsung buka tutorial WebSocket. Kelihatannya WebSocket itu “jawaban” untuk semua hal real-time. Ternyata tidak selalu begitu.

  Setelah membuat beberapa project yang melibatkan real-time data — live dashboard, chat sederhana, streaming AI response — saya jadi lebih paham kapan harus pilih WebSocket dan kapan SSE (Server-Sent Events) adalah pilihan yang lebih tepat.

  Bedanya dari Konsep Dasar

  WebSocket adalah protokol komunikasi dua arah (bidirectional). Setelah koneksi terbentuk, client dan server bisa saling kirim data kapan saja, tanpa perlu request baru.

  SSE (Server-Sent Events) adalah mekanisme komunikasi satu arah — dari server ke client. Client cukup buka koneksi HTTP biasa, dan server bisa push update kapanpun.

  Analogi simpelnya:

  • WebSocket = telepon. Dua orang bisa ngomong bergantian kapan saja.
  • SSE = radio. Stasiun broadcast, pendengar terima. Pendengar tidak bisa reply lewat channel yang sama.

  Cara Kerja WebSocket

  1. Client kirim HTTP request dengan header Upgrade: websocket
  2. Server setuju, koneksi “upgrade” jadi protokol WebSocket
  3. Sekarang ada koneksi persistent yang bisa dipakai dua arah
  4. Baik client maupun server bisa kirim “frame” data kapanpun
  5. Koneksi tutup kalau salah satu pihak menutupnya

  // Client side
  const ws = new WebSocket('wss://example.com/ws');
  
  ws.onopen = () => {
  ws.send(JSON.stringify({ type: 'subscribe', channel: 'updates' }));
  };
  
  ws.onmessage = (event) => {
  const data = JSON.parse(event.data);
  console.log('Received:', data);
  };
  
  // Bisa juga kirim dari client ke server kapanpun
  ws.send(JSON.stringify({ type: 'ping' }));

  Cara Kerja SSE

  1. Client buka HTTP GET request ke endpoint SSE
  2. Server balas dengan header Content-Type: text/event-stream
  3. Koneksi tetap buka, server bisa kirim event kapanpun
  4. Kalau koneksi putus, browser otomatis reconnect (built-in!)

  // Client side — sesimpel ini
  const eventSource = new EventSource('/api/updates');
  
  eventSource.onmessage = (event) => {
  const data = JSON.parse(event.data);
  console.log('Received:', data);
  };
  
  eventSource.onerror = (error) => {
  console.error('SSE error:', error);
  // Browser otomatis reconnect, kamu tidak perlu handle manual
  };

  // Server side (Node.js/Express)
  app.get('/api/updates', (req, res) => {
  res.setHeader('Content-Type', 'text/event-stream');
  res.setHeader('Cache-Control', 'no-cache');
  res.setHeader('Connection', 'keep-alive');
  
  const sendUpdate = (data) => {
  res.write(data: ${JSON.stringify(data)}\n\n);
  };
  
  // Kirim data setiap 5 detik sebagai contoh
  const interval = setInterval(() => {
  sendUpdate({ time: new Date(), value: Math.random() });
  }, 5000);
  
  req.on('close', () => {
  clearInterval(interval);
  });
  });

  Perbandingan Head-to-Head

  | Aspek | WebSocket | SSE |

  |—|—|—|

  | Arah komunikasi | Bidirectional | Server → Client only |

  | Protokol | ws:// atau wss:// | HTTP biasa |

  | Browser support | Semua modern browser | Semua kecuali IE |

  | Auto reconnect | Harus implementasi sendiri | Built-in |

  | Multiplexing (banyak channel) | Ya, tapi manual | Pakai event types |

  | Load balancer friendly | Perlu sticky session | Yes (stateless HTTP) |

  | Overhead | Lebih rendah setelah handshake | Header HTTP tiap batch |

  | Kompleksitas setup | Lebih tinggi | Lebih rendah |

  Kapan Pakai WebSocket?

  Pilih WebSocket kalau:

  Butuh komunikasi dua arah yang sering. Contoh paling klasik: aplikasi chat. User kirim pesan, server forward ke user lain. Kalau pakai SSE, kamu masih butuh endpoint POST terpisah untuk kirim pesan dari client — jadi awkward.

  Online game atau collaborative editing. Google Docs-style editing, whiteboard kolaboratif, game multiplayer — semua butuh latensi rendah dan dua arah.

  Banyak aksi dari client yang perlu real-time feedback. Kalau user sering trigger action dan butuh response cepat, WebSocket lebih natural.

  Use case bagus untuk WebSocket:
  
  Chat app
  Multiplayer game
  Collaborative editor (Figma, Google Docs)
  Live trading/bidding platform
  Video call signaling

Kapan Pakai SSE?

Pilih SSE kalau:

Server yang push, client yang dengarkan. Live dashboard dengan chart yang update otomatis, feed berita real-time, notifikasi, status monitoring — ini semua SSE territory.

Streaming AI response. Ini yang paling relevan sekarang. ChatGPT, Claude — mereka streaming response karakter per karakter. Itu SSE! Server push token satu-satu, browser tampilin seiring datang.

Mau simpel dan HTTP-native. SSE bekerja di atas HTTP biasa. Tidak perlu library khusus di server, tidak perlu handle upgrade protocol, lebih mudah di-debug.

Load balancer standar. WebSocket perlu sticky session atau konfigurasi khusus di load balancer. SSE cukup HTTP standar — lebih friendly di infrastructure yang sudah ada.

Use case bagus untuk SSE:

Live dashboard / analytics
Streaming AI output
Notifikasi real-time
Live score/update olahraga
Log streaming
Progress bar untuk long-running task

SSE untuk Streaming AI Response: Contoh Nyata

Ini pattern yang sekarang banyak dipakai:

// Endpoint streaming AI response
app.post('/api/chat', async (req, res) => {
const { message } = req.body;

res.setHeader('Content-Type', 'text/event-stream');
res.setHeader('Cache-Control', 'no-cache');

const stream = await openai.chat.completions.create({
model: 'gpt-4',
messages: [{ role: 'user', content: message }],
stream: true,
});

for await (const chunk of stream) {
const token = chunk.choices[0]?.delta?.content || '';
if (token) {
res.write(data: ${JSON.stringify({ token })}\n\n);
}
}

res.write('data: [DONE]\n\n');
res.end();
});

Clean, straightforward, dan tidak perlu maintain koneksi WebSocket yang stateful.

Mitos: “WebSocket Selalu Lebih Baik karena Lebih Powerful”

Powerful bukan berarti lebih cocok. Kalau kamu pakai WebSocket untuk use case yang sebetulnya cukup SSE, kamu nambah kompleksitas tanpa benefit:

• Harus handle reconnection logic sendiri
• Perlu manage WebSocket state di server
• Load balancer jadi lebih ribet
• Library/dependency tambahan

SSE itu “cukup” untuk banyak kasus, dan “cukup” sambil lebih simpel adalah pilihan yang bagus.

Hybrid Approach

Kamu juga bisa kombinasikan keduanya:

• SSE untuk push dari server (update, notifikasi)
• Regular HTTP POST/fetch untuk aksi dari client

Ini bahkan lebih sederhana dari WebSocket dalam beberapa kasus, karena request-response tetap familiar dan mudah di-debug.

Kesimpulan

• WebSocket untuk komunikasi dua arah yang intens dan real-time (chat, game, collaborative tools)
• SSE untuk server push yang satu arah (dashboard, notifikasi, AI streaming)

Mulai dari SSE kalau kamu belum yakin — lebih mudah diimplementasikan, lebih friendly di infrastructure, dan auto reconnect sudah built-in. Upgrade ke WebSocket hanya kalau kamu benar-benar butuh bidirectionality.

Lagi bangun fitur real-time dan bingung pilih mana? Atau ada arsitektur yang mau didiskusikan? Yuk ngobrol — hubungi mafadev.