• 

  Superwhisper: Dikte Kode dengan Suara, Benar-benar Bisa?

  Saya masih ingat pertama kali coba voice dictation untuk menulis kode. Itu sekitar 2019, dan hasilnya? Bencana. “if open parenthesis” tertulis literally sebagai “if open parenthesis”, bukan if (. Saya menyerah setelah 10 menit.

  Tapi sekarang 2026, dan teknologi speech recognition sudah jauh berbeda. Whisper dari OpenAI mengubah game. Dan Superwhisper adalah salah satu aplikasi yang paling polished yang manfaatkan teknologi ini.

  Setelah beberapa minggu pakai serius — ini laporan jujurnya.

  Apa Itu Superwhisper?

  Superwhisper adalah aplikasi macOS yang menjalankan speech-to-text menggunakan model Whisper (dan varian yang lebih baru) secara lokal atau via API. Intinya: tekan shortcut, ngomong, teks muncul di mana kursor kamu berada — di email, Slack, code editor, dokumen, di mana saja.

  Yang membuat ini beda dari voice typing built-in macOS atau Windows:

  • Akurasi jauh lebih tinggi, terutama untuk bahasa dengan aksen
  • Bisa custom vocabulary — kamu bisa beri tahu model kata-kata teknis atau nama yang sering kamu sebut
  • Modes yang berbeda untuk konteks yang berbeda
  • Processing bisa local — data kamu tidak keluar ke server
  • Diksi multi-bahasa dalam satu session

  Setup Awal

  Superwhisper butuh setup awal yang sedikit lebih dari install-and-go:

  1. Download dari superwhisper.com
  2. Pilih mode: local (pakai compute lokal, lebih privat) atau cloud (lebih cepat dan akurat)
  3. Download model yang kamu mau — ada beberapa ukuran, dari kecil (cepat tapi less accurate) sampai large (lebih akurat tapi butuh lebih banyak RAM)
  4. Set global shortcut

  Saya pakai mode cloud dengan model terbesar untuk daily driver. Kalau ada concern privasi untuk content sensitif, mode local tersedia.

  Untuk Menulis Teks Biasa: Sangat Impressed

  Untuk menulis email, Slack message, dokumen, komentar di PR — Superwhisper bekerja luar biasa. Akurasinya tinggi, bahkan untuk bahasa Indonesia yang saya campur dengan istilah Inggris teknis.

  Workflow yang saya temukan efektif:

  • Draft email panjang dengan suara, edit typo kecil secara manual
  • Slack message informal — langsung ngomong, tidak perlu edit
  • Meeting notes — rekam dan dikte poin-poin sambil meeting
  • Komentar di code review — lebih cepat dari mengetik panjang-panjang

  Speedup yang saya rasakan untuk text biasa: sekitar 2-3x lebih cepat dari mengetik, terutama untuk paragraf panjang.

  Untuk Koding: Realistis

  Ini yang paling banyak orang penasaran. Bisa tidak dikte kode?

  Jawaban jujur: bisa, tapi untuk hal-hal tertentu saja.

  Yang Berhasil dengan Baik

  Komentar dan dokumentasi dalam kode. Ini yang paling natural dan paling sering saya pakai. Daripada mengetik komentar panjang, saya ngomong saja.

  // saya: "tambahkan fungsi ini menerima parameter user object yang berisi id, email, dan role, lalu return boolean apakah user memiliki permission yang diperlukan"
  // output: // Fungsi ini menerima parameter user object yang berisi id, email, dan role, lalu return boolean apakah user memiliki permission yang diperlukan

  Variable dan function names. “isUserAuthenticated”, “fetchUserProfile”, “handleFormSubmit” — ini bisa dikte dengan cukup akurat.

  String literals. Teks yang masuk ke dalam string, pesan error, label UI — ini natural untuk diucapkan.

  Prompt untuk AI coding assistant. Saya sering pakai Superwhisper untuk ngomong instruksi ke Cursor atau GitHub Copilot. Daripada mengetik panjang lebar apa yang mau saya buat, saya ngomong saja dan AI yang menulis kode-nya.

  Yang Masih Susah

  Syntax yang sangat symbolic. {}, (), =>, &&, || — ini awkward untuk diucapkan dan hasilnya seringkali salah. Kamu harus bilang “curly brace” atau pakai shorthand yang butuh customization.

  Indentation dan whitespace. Kode sensitif terhadap indentation. Voice dictation tidak handle ini dengan baik secara default.

  Long chained expressions. array.filter(x => x.active).map(x => x.name).join(', ') — ini lebih cepat diketik dari diucapkan.

  Workaround yang Saya Pakai

  Daripada dikte kode secara langsung, saya gabungkan dengan AI:

  1. Dikte instruksi ke AI coding assistant (Cursor, Copilot, Claude)
  2. AI yang generate kode
  3. Review dan edit manual kalau perlu

  Ini terasa lebih natural. Saya berbicara seperti menginstruksikan junior developer: “Buatkan fungsi yang ambil list user dari API, filter yang aktif saja, lalu return sorted by last login.” AI yang terjemahkan ke kode.

  Custom Modes — Fitur yang Underrated

  Superwhisper punya fitur “Modes” yang memungkinkan kamu setup konteks berbeda untuk situasi berbeda:

  • Mode “Email”: Otomatis format paragraf, tambahkan greeting/closing
  • Mode “Coding”: Aktifkan vocabulary teknis khusus
  • Mode “Meeting Notes”: Format output sebagai bullet points
  • Mode “Bahasa Indonesia”: Pastikan output dalam Bahasa Indonesia walau kamu sesekali sebut kata Inggris

  Saya punya mode custom untuk developer context yang include vocabulary seperti nama-nama framework yang sering saya pakai.

  Perbandingan dengan Alternatif

  Whisper.cpp (self-hosted) — Gratis, privat, tapi butuh setup teknis dan tidak se-polished Superwhisper.

  macOS built-in Dictation — Terintegrasi, tapi akurasi jauh di bawah Whisper-based apps.

  Dragon NaturallySpeaking — Veterans di kategori ini, lebih mature untuk koding dengan banyak syntax support, tapi mahal dan Windows-focused.

  Whisper Flow — Mirip Superwhisper, lebih sederhana, lebih murah. Pilihan bagus kalau kamu mau sesuatu yang less feature-rich.

  Biaya

  Superwhisper punya free tier dengan batasan waktu transkripsi per bulan. Paid plan sekitar $8-10/bulan untuk unlimited penggunaan.

  Kalau pakai mode cloud dengan model besar, ada biaya API di atasnya (biasanya sangat kecil — sen per request).

  Siapa yang Paling Benefit?

  Berdasarkan pengalaman saya, Superwhisper paling valuable untuk:

  • Developer yang banyak menulis dokumentasi dan komentar — ROI langsung terasa
  • Orang yang lebih cepat berpikir dengan ngomong daripada mengetik
  • Developer yang punya kondisi fisik yang membuat ngetik lama jadi melelahkan — RSI, misalnya
  • Orang yang sering harus multitask dan tidak bisa selalu pegang keyboard
  • User AI coding assistant — dikte prompt jauh lebih cepat

  Kesimpulan

  Superwhisper bukan magic wand yang membuat kamu bisa coding 100% tanpa keyboard. Untuk syntax-heavy coding, keyboard masih lebih efisien.

  Tapi untuk semua yang di sekitar coding — dokumentasi, komunikasi, instruksi ke AI, planning, dan note-taking — ini adalah tools yang genuinely mengubah workflow saya menjadi lebih cepat. Dan untuk developer yang pakai AI coding assistant, kombinasi voice dictation + AI adalah combo yang powerful.

  Worth dicoba, terutama dengan free tier yang tersedia.

  ---

  Punya pertanyaan tentang tools produktivitas developer yang lain? Atau mau diskusi setup workflow yang optimal? Yuk ngobrol — hubungi mafadev.

  August 25, 2026

• 

  Edge Computing untuk Developer Indie: Apa yang Perlu Diketahui?

  Waktu pertama dengar “edge computing”, saya pikir ini jargon enterprise yang tidak relevan buat developer indie seperti saya. CDN sudah ada, server sudah ada, ngapain rumit-rumingin lagi?

  Ternyata saya salah — dan deep dive ke dunia edge computing dalam 6 bulan terakhir cukup mengubah cara saya pikir tentang infrastruktur.

  Edge Computing Itu Apa Sebenarnya?

  Konsep dasarnya: daripada request user selalu pergi ke server pusat (misalnya di us-east-1 di Virginia atau server VPS kamu di Singapura), kode dan data dijalankan lebih dekat ke user — di “edge”, yaitu server yang tersebar di ratusan lokasi di seluruh dunia.

  Hasilnya: latensi lebih rendah karena data tidak harus melakukan perjalanan jauh.

  Ini berbeda dari CDN yang cuma serve static files. Edge computing menjalankan kode di edge location — logika bisnis, database queries, personalisasi, semuanya bisa terjadi di server yang fisiknya dekat dengan user.

  Platform Edge yang Relevan untuk Developer Indie

  Cloudflare Workers

  Ini yang paling saya rekomendasikan untuk mulai. Cloudflare Workers menjalankan JavaScript (dan bahasa lain via WebAssembly) di 300+ lokasi di seluruh dunia.

  Yang membuat menarik untuk indie developer:

  • Free tier yang generous: 100.000 request/hari gratis
  • Latency sangat rendah: Kode dieksekusi < 1ms dari lokasi terdekat user
  • KV Store: Key-value storage yang tersedia di semua edge location
  • D1 Database: SQLite yang tersebar di edge
  • R2: Object storage (seperti S3 tapi tanpa egress fee)

  Biaya paid plan mulai $5/bulan untuk 10 juta request — untuk banyak indie project, ini lebih dari cukup.

  Vercel Edge Functions

  Kalau kamu sudah pakai Vercel untuk deployment, Edge Functions adalah natural extension. Bisa ditulis dengan syntax Next.js middleware yang familiar.

  // app/middleware.ts
  import { NextResponse } from 'next/server';
  import type { NextRequest } from 'next/server';
  
  export function middleware(request: NextRequest) {
  // Ini dijalankan di edge, bukan di origin server
  const country = request.geo?.country || 'ID';
  
  // Redirect berdasarkan lokasi user
  if (country === 'ID') {
  return NextResponse.rewrite(new URL('/id' + request.nextUrl.pathname, request.url));
  }
  
  return NextResponse.next();
  }

  Deno Deploy

  Deno, runtime JavaScript alternatif, punya hosting service-nya sendiri dengan edge deployment. Kalau kamu suka Deno (dan banyak developer yang mulai suka), ini pilihan yang clean.

  Use Case Nyata yang Bisa Kamu Implementasikan

  1. Geolocation-based Routing

  Redirect user ke versi bahasa/region yang tepat tanpa roundtrip ke origin server. Deteksi country di edge, serve konten yang sesuai.

  2. A/B Testing di Edge

  Daripada run A/B test di client (yang lambat dan bisa di-block) atau di origin server (tambah latency), run di edge. User dapat variasi yang tepat sebelum request bahkan sampai ke origin kamu.

  // Cloudflare Worker untuk A/B test sederhana
  export default {
  async fetch(request) {
  const url = new URL(request.url);
  const userId = getCookie(request, 'user_id') || generateId();
  
  // Assign ke group berdasarkan hash dari userId
  const group = parseInt(userId.slice(-1), 16) < 8 ? 'A' : 'B';
  
  if (group === 'B') {
  url.pathname = '/variant-b' + url.pathname;
  }
  
  return fetch(url);
  }
  };

  3. Rate Limiting di Edge

  Block excessive request sebelum mereka sampai ke server kamu. Lebih efisien karena tidak buang compute di origin.

  4. Image Optimization On-the-Fly

  Cloudflare Images dan Vercel Image Optimization sudah pakai edge untuk resize/compress gambar sesuai device yang request. Kamu bisa implement logic serupa.

  5. Auth Token Validation

  Validasi JWT token di edge sebelum request diteruskan ke API kamu. Ini mengurangi load di origin server secara signifikan.

  // Validasi JWT di Cloudflare Worker
  export default {
  async fetch(request, env) {
  const token = request.headers.get('Authorization')?.replace('Bearer ', '');
  
  if (!token) {
  return new Response('Unauthorized', { status: 401 });
  }
  
  try {
  // Verify JWT di edge
  const payload = await verifyJWT(token, env.JWT_SECRET);
  
  // Forward request dengan user info di header
  const modifiedRequest = new Request(request, {
  headers: {
  ...Object.fromEntries(request.headers),
  'X-User-Id': payload.sub,
  'X-User-Role': payload.role,
  }
  });
  
  return fetch(modifiedRequest);
  } catch {
  return new Response('Invalid token', { status: 401 });
  }
  }
  };

  Batasan yang Perlu Kamu Tahu

  Edge computing bukan tanpa batasan:

  Cold start yang berbeda. Edge workers biasanya tidak punya cold start seperti serverless konvensional, tapi ada batasan CPU time yang ketat (biasanya 50ms per request di tier gratis).

  Tidak semua library bisa jalan. Beberapa npm packages yang bergantung pada Node.js APIs spesifik tidak bisa dipakai di edge runtime. Workers runtime itu subset dari browser runtime, bukan full Node.js.

  Stateful operations lebih rumit. Edge workers secara default stateless. Untuk state, kamu harus integrasikan dengan KV store atau database — ada overhead ini.

  Debugging lebih susah. Troubleshoot kode yang jalan di 300+ lokasi berbeda itu lebih complex dari debug server tunggal.

  Kapan Edge Computing Worth It untuk Project Indie?

  Worth it kalau:

  • User kamu tersebar global — ini impact-nya paling besar
  • Ada operasi yang bisa di-offload (auth, routing, rate limiting) dari origin
  • Budget infrastruktur terbatas — free tier Cloudflare Workers sangat generous
  • Kamu sudah pakai Cloudflare/Vercel — adopsi edge jadi lebih natural

  Mungkin belum worth it kalau:

  • User kamu concentrated di satu region — benefit latensi jadi minimal
  • App kamu sangat database-heavy — bottleneck tetap di database, bukan network
  • Tim kamu belum familiar dengan edge paradigm

  Langkah Pertama yang Konkret

  Kalau mau mulai eksperimen:

  1. Buat Cloudflare account (gratis)
  2. Install Wrangler CLI: npm install -g wrangler
  3. Buat worker sederhana: wrangler generate my-worker
  4. Deploy: wrangler deploy

  Untuk project yang lebih structured, Hono adalah framework yang ringan dan optimal untuk edge environment. Mirip Express, tapi dirancang untuk edge runtime.

  Kesimpulan

  Edge computing bukan lagi domain eksklusif perusahaan besar. Dengan Cloudflare Workers, Vercel Edge Functions, dan platform serupa — ini sekarang accessible untuk developer indie dengan biaya yang sangat masuk akal.

  Untuk project yang butuh performa global, atau ingin offload logika tertentu dari origin server — ini layak dieksplor. Mulai kecil: implementasikan rate limiting atau auth di edge, rasakan bedanya, baru expand dari sana.

  ---

  Tertarik eksplorasi edge computing untuk project kamu? Atau mau diskusi arsitektur infrastruktur yang tepat untuk skala project kamu? Yuk ngobrol — hubungi mafadev.

  August 24, 2026

• 

  AI dan Masa Depan Pekerjaan Developer: Jujur-jujuran

  Oke, kita ngobrol jujur.

  Pertanyaan ini ada di kepala hampir semua developer sekarang: “Seberapa aman pekerjaan saya di era AI ini?” Dan saya lihat dua ekstrem reaksinya — ada yang denial total (“AI tidak akan pernah gantiin programmer!”), ada yang panik berlebihan (“semua developer akan jadi pengangguran dalam 5 tahun!”).

  Keduanya salah. Realitanya lebih nuanced, dan saya mau share sudut pandang saya — bukan sebagai akademisi, tapi sebagai developer yang sehari-hari kerjanya bersinggungan langsung dengan AI.

  Apa yang Sudah Berubah

  Jujur: AI sudah mengubah cara saya bekerja secara signifikan.

  Hal-hal yang dulu butuh waktu lama sekarang jauh lebih cepat:

  • Menulis boilerplate code? AI yang handle.
  • Debugging error yang annoying? Paste ke Claude, dapat penjelasan dan solusi.
  • Dokumentasi? Draft pertama dari AI, saya edit.
  • Convert data dari satu format ke format lain? Selesai dalam detik.
  • Unit test untuk fungsi yang sudah ada? AI generate, saya review.

  Kalau saya jujur menghitung, mungkin 30-40% dari aktivitas coding sehari-hari saya sudah sangat terbantu — bahkan sebagian sudah bisa didelegasikan ke AI. Dan ini tren yang akan terus berlanjut.

  Apa yang Belum Bisa Digantikan

  Tapi ada hal-hal yang AI masih kesulitan, dan ini bukan karena AI “bodoh” — ini karena sifat pekerjaannya berbeda.

  Understanding Context Bisnis

  AI tidak tahu bahwa client kamu punya constraint khusus, budget yang terbatas, tim yang kecil, atau legacy system yang harus dikompatibeli. Kamu yang duduk di meeting, dengarkan pain point mereka, dan terjemahkan itu ke keputusan teknis.

  “Fitur ini secara teknis bisa dibuat, tapi apakah worth effort-nya?” — ini adalah judgment call yang butuh konteks manusiawi.

  Navigasi Ambiguitas

  Requirement yang ambigu, stakeholder yang punya expectation berbeda-beda, spec yang berubah di tengah jalan — ini adalah realita project. Developer yang berpengalaman tahu cara navigasi ini. AI belum bisa menelepon product manager untuk klarifikasi.

  Arsitektur dan Keputusan Jangka Panjang

  “Pakai microservices atau monolith untuk project ini?” bukan cuma pertanyaan teknis — ini pertanyaan tentang team size sekarang, projection growth, budget infrastruktur, expertise tim, dan banyak faktor lain. AI bisa beri opsi, tapi keputusan akhir butuh judgment manusia dengan konteks lengkap.

  Relasi dan Trust

  Klien percaya ke kamu, bukan ke AI. Dalam banyak engagement profesional, hubungan personal dan track record adalah aset terbesar. AI tidak bisa bangun trust itu.

  Yang Paling Terancam

  Kalau saya harus jujur tentang siapa yang paling terancam:

  Junior developer dengan skill yang sangat narrow. Kalau keahlian utama kamu adalah “bisa menulis CRUD API dalam framework X” — ya, AI sudah bisa melakukan itu. Ini bukan berita bagus untuk junior yang baru mau masuk industri dengan skill dasar.

  Pekerjaan yang highly repetitive. Data entry, simple script, template-based work — ini yang paling mudah di-automate.

  Outsourcing model tertentu. Banyak bisnis outsourcing yang hidup dari “cheap labor untuk task sederhana” — ini yang paling terdisrupsi.

  Yang Justru Naik Nilainya

  Di saat yang sama, beberapa hal justru makin berharga:

  Developer yang bisa “direct” AI dengan baik. Ini bukan cuma soal prompt engineering — ini soal tahu APA yang mau dicapai, bisa validasi output AI, dan tahu kapan AI salah. Skill ini butuh pengalaman dan judgment.

  Problem solving dan arsitektur tingkat tinggi. Ketika coding mekanis bisa di-delegate ke AI, skill yang tersisa adalah kemampuan berpikir sistemik.

  Komunikasi dan pemahaman domain. Developer yang bisa berbicara bahasa bisnis, memahami kebutuhan user, dan menterjemahkan itu ke solusi teknis — ini makin langka dan makin valuable.

  Spesialisasi dalam domain yang butuh akuntabilitas. Healthcare tech, fintech, sistem kritis — di sini manusia tetap dibutuhkan karena ada accountability legal dan etika yang tidak bisa didelegasikan ke AI.

  Skenario yang Paling Mungkin: Augmentation, Bukan Replacement

  Saya percaya skenario yang paling likely bukan “AI gantiin semua developer” — tapi “developer yang pakai AI dengan baik akan menggantikan developer yang tidak.”

  Analoginya: ketika kalkulator ditemukan, apakah semua akuntan kehilangan pekerjaan? Tidak. Tapi akuntan yang bisa pakai kalkulator (dan kemudian software akuntansi) jauh lebih produktif dari yang tidak, dan yang tetap manual memang terpinggirkan.

  Bedanya sekarang: AI mengambil tidak hanya pekerjaan repetitif, tapi mulai menyentuh pekerjaan kognitif. Ini lebih besar dampaknya. Tapi analoginya tetap relevan.

  Yang Perlu Kamu Lakukan Sekarang

  Bukan untuk panik, tapi untuk adaptasi:

  Belajar pakai AI tools dengan serius. Bukan cuma “ah saya sudah pernah coba ChatGPT”. Integrasikan ke daily workflow. Eksperimen dengan GitHub Copilot, Cursor, Claude. Temukan di mana AI benar-benar saving your time.

  Investasi di soft skills yang AI tidak bisa. Komunikasi, leadership, kemampuan memahami bisnis, empati ke user — ini yang makin berharga.

  Bangun domain expertise. Jangan cuma jadi “web developer generik”. Jadilah developer yang paham deep di industri tertentu — fintech, edtech, healthcare, atau lainnya. Context domain ini adalah moat yang sulit di-automate.

  Jangan berhenti belajar fundamentals. Justru ketika AI handle surface-level coding, kamu perlu lebih paham apa yang terjadi di bawah — supaya bisa evaluate, debug, dan improve output AI.

  Pendapat Jujur Saya

  Saya tidak mau jual optimisme palsu. AI memang akan menghilangkan beberapa jenis pekerjaan. Ini sudah terjadi. Beberapa posisi junior yang dulu ada, sekarang tidak lagi karena satu senior developer dengan AI tools bisa handle pekerjaan beberapa orang.

  Tapi saya juga tidak percaya developer sebagai profesi akan hilang dalam jangka yang relevan. Selama teknologi berkembang, selama ada masalah baru yang butuh solusi, selama bisnis butuh sistem yang reliable — ada kebutuhan untuk manusia yang bisa berpikir, membuat keputusan, dan bertanggung jawab.

  Yang berubah adalah apa yang diharapkan dari developer, dan bagaimana kita bekerja. Dan adaptasi terhadap perubahan itu sudah selalu jadi bagian dari being a developer.

  ---

  Mau diskusi tentang bagaimana AI bisa masuk ke project atau bisnis kamu? Atau punya pertanyaan tentang navigasi karir di era AI? Yuk ngobrol — hubungi mafadev.

  August 23, 2026

• 

  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.