Gsxui: Komponen UI Shadcn-style untuk Go Web Apps — Tanpa JavaScript Bundle 2026

Pernah gak mikir gini: "komponen UI di ekosistem React kayak shadcn/ui itu enak banget — tinggal copy file-nya, langsung jalan, gak ada dependency yang nyeret. Kok di Go gak ada yang kayak gitu sih?" Pertanyaan itu akhirnya punya jawaban. Namanya Gsxui — project open source yang baru muncul pertengahan 2026, bawa filosofi copy-in khas shadcn ke dunia Go. Artikel ini bahas tuntas: apa itu gsxui, gimana cara pakainya, di mana letak kelebihannya dibanding alternatif yang udah ada, dan — penting banget — di mana harus hati-hati karena project ini masih pre-release. Bakal dapet gambaran lengkap buat mutusin apakah ini layak dipake di project berikutnya atau ditunggu dulu sampe mature.

Baru Dengar Gsxui? Ini Dulu Konteksnya

Gsxui itu singkatan praktis dari "GSX UI". Di GitHub, project-nya hidup di github.com/gsxhq/gsxui dan mendeskripsikan dirinya sebagai "shadcn-style components for gsx — copy-in, type-checked, server-rendered". Artinya: kumpulan komponen UI yang gayanya ngikutin pendekatan shadcn/ui (yang terkenal di React), tapi dibangun di atas gsx — sebuah library Go yang nambahin sintaks ala JSX ke bahasa Go lewat file berekstensi .gsx.

Statusnya sekarang pre-release dengan 53 komponen plus satu paket icon, dan katanya udah nutupin sebagian besar set yang ada di shadcn/ui. Project ini mulai ada tanggal 22 Juli 2026 dan udah dikoleksi sekitar 38 bintang di GitHub — kecil, tapi gercep. Yang paling seru: semua komponennya bisa diliat hidup-hidup di homepage ui.gsxhq.dev, lengkap dengan theme editor, jadi gak perlu nebak-nebak hasilnya kayak gimana sebelum nyobain sendiri.

Kenapa Pendekatan Shadcn Bisa Meledak di React

Sebelum nyemplung ke teknisnya, worth it buat ngerti dulu kenapa pendekatan shadcn bisa sepopuler itu di React. Intinya satu: komponen bukan library yang di-install, tapi kode yang di-copy. Gak nambah dependency baru ke package manager — file komponen (JSX + Tailwind CSS) dimasukin langsung ke codebase, lalu diedit sesuai kebutuhan. Hasilnya:

• Zero lock-in. Gak ada maintainer library yang bisa ngerubah API di bawah kaki. Kodenya udah jadi milik sendiri.
• Bundle kecil. Cuma bawa komponen yang dipake, bukan seluruh library.
• Mudah di-custom. Mau ngubah style, tambahin behavior, atau nge-remix dua komponen — semua tinggal edit file.
• Transparan. Bisa baca seluruh kode yang jalan di production. Gak ada kotak hitam.

Pendekatan ini sukses banget di React. Pertanyaannya: kenapa baru sekarang ada yang nyoba di Go? Karena Go selama ini gak punya sintaks yang bikin komponen UI terasa natural. Sampai gsx datang.

Yang Beda dari Gsxui: Copy-In + Type-Checked

Gsxui ngadopsi filosofi copy-in yang sama, tapi ada dua kata kunci yang bikin dia beda dari sekadar "port shadcn": type-checked dan server-rendered.

Type-checked artinya komponen-nya ditulis sebagai kode Go yang di-type check oleh compiler. Salah nama prop, salah tipe data, atau salah struktur — ketahuan di go build, bukan pas browser udah render setengah halaman. Ini kontras sama pendekatan string-based di beberapa library Go lain yang baru ketahuan errornya pas runtime.

Server-rendered artinya HTML-nya dihasilkan di server oleh Go. Gak ada client-side rendering, gak ada hydration — browser tinggal nerima HTML jadi. Buat aplikasi yang butuh SEO, first paint cepat, atau kerja di device lemah, ini nilai jual yang gede banget.

Terus, JavaScript-nya gimana? Nah, ini bagian yang menarik: komponen gsxui yang butuh interaktivitas (dialog, dropdown, toast) punya file .js pendamping yang di-vendor bareng komponennya. Behavior-nya didapet tanpa nulis framework JavaScript sendiri — gak ada React, gak ada Vue, gak ada Svelte yang nyeret bundle. Konsepnya simpel: server render HTML-nya, JS kecil cuma buat bagian yang emang butuh interaksi.

Foundation-nya: GSX, Bukan html/template

Ini bagian yang sering bikin orang salah paham — dan jujur, ada artikel yang nulis gsxui pakai html/template standar Go dengan sintaks {{define "button"}} dan helper dict. Itu keliru. Gsxui dibangun di atas gsx (github.com/gsxhq/gsx), sebuah library yang nambahin sintaks ala JSX ke Go.

Dengan gsx, file .gsx diisi campuran sintaks Go dan markup, mirip gimana JSX nyampur JavaScript sama HTML di React. Komponen ditulis sebagai component dengan named parameters, dan atribut HTML-nya di-fallthrough secara otomatis. Hasilnya kode yang jauh lebih deket ke markup daripada menumpuk string HTML di dalam Go — dan karena ini kompiler Go yang ngolahnya, semua tetap di-type check.

Jadi kalau kebetulan baca artikel lain yang bilang gsxui itu "template string di dalam Go" atau "html/template dengan helper dict", anggap aja itu versi yang salah tangkap. Fondasi aslinya: JSX-style, type-checked, dan di-render penuh di server.

Install & Init: Dari Nol ke Komponen Pertama

Setup-nya singkat banget. Pertama butuh gsx — bikin project baru dengan gsx init, terus pasang binary gsxui:

go install github.com/gsxhq/gsxui/cmd/gsxui@latest
gsx init app --yes
cd app
gsxui init          # Tailwind/Vite + tokens, JS runtime, class merger
gsxui add dialog    # vendors dialog + dependency-nya (button)
gsxui list          # liat apa aja yang tersedia

Di project baru yang masih bersih, gsxui init ngurus semuanya: install Tailwind CSS, plugin @tailwindcss/vite, sama tw-animate-css; configure plugin Vite; nyambungin web/gsxui/index.js dan web/gsxui/index.css ke web/main.js; plus nambahin GSX toolchain dan class merger ke go.mod. Setelah itu, tinggal gsxui add nama komponen yang dibutuh, dan komponennya ke-vendor ke project.

Nah, kalau mau coba-coba di lingkungan yang gak ganggu project utama — misalnya bikin sandbox buat eksplorasi — VPS murah udah lebih dari cukup. RackNerd sering dipake buat keperluan kayak gini karena harga tahunannya bersahabat, jadi bisa bebas install Go toolchain dan main-main tanpa takut tagihan.

Copy-In: Komponen Jadi Milik Sendiri Sepenuhnya

Mekanisme copy-in-nya gini: setiap komponen terdiri dari file <nama>.gsx — source komponennya — plus file <nama>.js buat behavior interaktif kalau komponennya butuh. Pas menjalankan gsxui add dialog, tool-nya nyalin file komponen beserta semua dependency-nya (misal dialog butuh button) langsung ke folder ui/ di project.

Setelah itu, file-file tersebut udah jadi bagian codebase sendiri. Bebas edit, pindahin, atau hapus. Gak ada runtime yang mengharuskan komponen "terdaftar" di suatu tempat — yang jalan ya persis apa yang ada di folder ui/.

Satu pengecualian: komponen icon. Ini di-vendor sebagai paket ui/icon sendiri, isinya data icon yang di-generate dari Lucide. Jadi kalau butuh icon, tambahin satu paket itu sekali, terus semua komponen bisa make.

Contoh Komponen: Button & Actions

Biar kebayang, ini contoh pemakaian komponen di dalam sebuah komponen gsx. Import paket ui dari project, terus panggil komponennya kayak elemen HTML biasa:

import "yourmodule/ui"

component Actions() {
    <div class="flex gap-3">
        <ui.Button>Save</ui.Button>
        <ui.Button variant="outline">Cancel</ui.Button>
    </div>
}

Perhatiin variant="outline" — komponen gsxui ngedukung named parameters, jadi variasi visual tinggal di-set lewat prop, persis kayak shadcn/ui di React. Atribut lain yang gak dikenal komponen bakal di-fallthrough ke elemen HTML yang paling dalam, jadi tetep bisa nambahin id, data-*, atau event handler standar tanpa ribet.

Karena semua ini kode Go yang di-type check, salah nulis nama variant atau tipe prop bakal langsung ditolak compiler. Sakitnya di go build, gak nyampe ke browser — justru itu yang bikin tim backend betah.

Theming: Recolor Cukup Sentuh Satu File

Ini salah satu klaim paling menarik dari gsxui: "recoloring a project means changing only theme.css". Struktur CSS-nya dirancang berlapis: ada foundation yang isinya CSS yang behavior-critical (jangan disentuh), ada theme.css yang isinya token semantik, dan ada style.css per komponen yang boleh diganti-ganti. Hasilnya, ganti warna, radius, atau font cukup edit satu file token:

/* theme.css — contoh struktur umum, token ngikutin Tailwind v4 */
@import "tailwindcss";

@theme {
  --color-background: oklch(0.99 0.005 100);
  --color-foreground: oklch(0.15 0.01 260);
  --color-primary: oklch(0.55 0.18 262);
  --radius-lg: 0.5rem;
}

@media (prefers-color-scheme: dark) {
  :root {
    --color-background: oklch(0.15 0.01 260);
    --color-foreground: oklch(0.99 0.005 100);
  }
}

Ini ilustrasi struktur umum — intinya: semua keputusan warna di-push ke satu file, dan komponen baca dari token itu. Mau rebranding kilat atau support dark mode, gak perlu bongkar 50 file komponen. Cukup satu.

Integrasi dengan htmx buat Interaksi

Karena gsxui gak nyediain framework JavaScript, buat interaksi yang lebih kompleks tinggal nyambungin dengan htmx — library kecil yang ngebiarin interaktivitas ditulis lewat atribut HTML. Kombinasi gsxui (komponen) + htmx (interaksi) + Go (handler) jadi trio yang rapi banget buat aplikasi server-rendered:

<form hx-get="/api/search" hx-target="#results" hx-trigger="input changed delay:300ms">
    <input type="search" name="q" class="input" placeholder="Cari produk..." />
</form>
<div id="results"></div>

Ngetik di input, htmx ngirim request ke endpoint Go, hasilnya dirender server dan disuntik ke #results — semua tanpa reload halaman dan tanpa nulis satu baris JavaScript vanilla pun. Buat yang penasaran, ada artikel soal HTMX 4.0 yang rilis eksklusif di Game Boy — gimmick paling absurd tapi berhasil bikin orang ngomongin library ini: HTMX 4.0: Library JS Pertama yang Release Eksklusif di Game Boy. Serius, worth dibaca — dan menjelaskan kenapa htmx punya tempat di hati developer yang anti-JS-bloat.

Katalog Komponen: 53 + Icon

Total ada 53 komponen plus satu paket icon, dan cakupannya ngikutin set shadcn/ui. Kategorinya kira-kira kayak gini:

Kategori	Fungsi	Contoh Komponen
Form controls	Input dan kontrol data dari user	button, input, select, checkbox, switch, slider, combobox, calendar
Display	Nampilin informasi statis atau status	card, badge, alert, avatar, table, progress, skeleton, spinner
Overlay	Elemen yang muncul di atas konten utama	dialog, dropdown, popover, tooltip, toast, drawer, sheet, context-menu
Navigation	Struktur pindah antar halaman atau section	tabs, accordion, breadcrumb, sidebar, pagination, command
Layout	Susunan ruang dan resizing	aspect-ratio, collapsible, resizable, scroll-area, carousel

Lengkap buat kategori aplikasi umum: dashboard, admin panel, form CRUD, sampai halaman landing. Dan karena semua copy-in, kalau ada komponen yang belum ada, bisa bikin sendiri dengan pola yang sama dan naruh di folder ui/ — ekosistemnya ngikutin, bukan sebaliknya.

Manual Setup buat Custom Vite Config

gsxui init di project yang masih polos otomatis ngatur semuanya. Tapi kalau project udah punya Vite config custom yang gak mau diutak-atik tool, init-nya menolak auto-rewrite dan dijalanin manual:

npm install --save-dev tailwindcss@^4.3.3 @tailwindcss/vite@^4.3.3 tw-animate-css@^1.4.0

# vite.config.ts: import tailwindcss, tambahin tailwindcss() ke plugins
# web/main.js: import "./gsxui/index.js" dan "./gsxui/index.css"

Dua file yang disentuh: vite.config.ts (nambahin plugin Tailwind) dan web/main.js (import entry CSS/JS gsxui). Setelah itu semua jalan — komponen gsxui yang interaktif nyari behavior JS-nya dari import index.js itu, dan style-nya dari index.css.

Perbandingan: Gsxui vs Templ+DaisyUI vs Bootstrap

Biar gak bias, ini perbandingan jujur sama jalur lain yang umum dipake di Go:

• Gsxui (gsx): komponen copy-in, type-checked, JSX-style. Cocok buat yang mau kekuatan shadcn di Go dengan kontrol penuh. Trade-off: masih pre-release, dan harus mau belajar sintaks gsx.
• Templ + DaisyUI: Templ punya sintaks templating yang mature dan komunitas gede; DaisyUI nyediain komponen class-based. Trade-off: komponennya "class saja", jadi behavior interaktif tetep tanggung jawab sendiri, dan gaya "copy class" kadang bikin HTML kotor.
• Bootstrap CDN: paling gampang — satu tag <link>, langsung jadi, sekitar 200KB CSS+JS ikut kebawa. Trade-off: semua halaman kebawa semua CSS meski gak dipake, dan tampilannya gampang ketauan "Bootstrap banget" kalau gak di-custom habis-habisan.

Intinya: kalau prioritas-nya kecepatan eksekusi dan nol dependency, Bootstrap atau DaisyUI menang. Kalau prioritas-nya kontrol penuh, tipe aman, dan bundle minimal — gsxui (atau Templ) yang lebih masuk akal.

Kapan Gsxui Pas, Kapan Gak

Pas banget dipake buat: aplikasi Go server-rendered dengan UI form-heavy — dashboard admin, panel manajemen, internal tools, app CRUD. Tim yang mayoritas backend Go dan gak mau megang ekosistem frontend JavaScript. Project yang butuh first paint cepat dan SEO (karena semua HTML dirender server). Dan yang suka ngoprek: karena copy-in, bebas bongkar komponennya sesuka hati.

Kurang pas buat: aplikasi yang butuh interaktivitas real-time kompleks — kolaborasi live, drag-and-drop board yang berat, atau SPA dengan state client-side yang rumit. Di situ React/Vue/Svelte dengan hydration masih unggul. Juga kurang pas kalau butuh dukungan ekosistem yang mature dan stabil sekarang juga — pre-release artinya API bisa berubah, dan dokumentasi masih ngikutin irama development.

Buat konteks yang lebih lengkap soal sisi backend-nya, ada juga panduan dari nol soal REST API Go + PostgreSQL — fondasi yang biasanya nyatu sama dashboard kayak gini: Panduan Lengkap Membuat REST API dengan Go.

Catatan Pre-Release: Owning the Code, --overwrite

Karena gsxui masih pre-release, ada beberapa hal yang wajib tau sebelum serius make:

• Kode dipegang sendiri. Setelah gsxui add, komponen udah jadi milik sendiri dan gak akan disentuh tool lagi selama gak diminta. Kalau udah edit file-nya, gsxui add berikutnya buat komponen yang sama gak bakal nimpa — kecuali dipaksa.
• Refresh lewat --overwrite. Abis upgrade binary gsxui, komponen bisa di-refresh dengan gsxui add <nama> --overwrite. Tapi inget: ini buang semua edit lokal di file itu. Jadi backup dulu atau simpen perubahan di tempat lain sebelum refresh.
• Versi belum 1.0. API, struktur file, dan cara setup bisa berubah antar versi. Buat project production yang serius, pin versi binary gsxui dan baca changelog tiap mau upgrade.

Filosofinya konsisten sama shadcn: tool cuma nyalin, sisanya diatur sendiri. Kebebasan itu enak, tapi datang dengan tanggung jawab buat maintain sendiri.

Kesimpulan

Gsxui dateng dengan proposisi yang jarang banget ada di ekosistem Go: komponen UI bergaya shadcn yang copy-in, type-checked, dan server-rendered — tanpa framework JavaScript yang nyeret bundle. Buat tim backend Go yang selama ini gigit jari liat shadcn di React, ini angin segar. 53 komponen, theming satu file, dan integrasi htmx yang mulus bikin dia layak buat dipantau serius.

Tapi jujur aja: masih pre-release. Buat project kecil, eksperimen, atau internal tools, gak ada salahnya nyobain sekarang — kodenya udah jadi milik sendiri begitu di-copy, jadi risiko lock-in-nya kecil. Buat production skala gede yang gak bisa nerima API berubah-ubah, tunggu sampe versi stabil atau siapin buffer buat migrasi. Either way, ini salah satu project Go paling menarik di 2026 — dan layak buat diisengin.

Kalau mau nyoba gsxui di lingkungan sendiri tanpa ganggu mesin utama, VPS murah kayak RackNerd bisa jadi tempat eksperimen yang pas — install Go toolchain, bikin sandbox, dan berantem sama komponen sesuka hati tanpa takut bikin project production rusak.

Sumber

Buat yang mau dalemin: Repo gsxui di GitHub, ui.gsxhq.dev (browse semua komponen live + theme editor), GSX — library JSX untuk Go, shadcn/ui (inspirasi pendekatan), htmx, dan Templ (kompetitor utama di segmen template Go).