Scrappy - Membuat aplikasi kecil untuk diri sendiri dan teman-teman

• Scrappy adalah alat pembuat software rumahan yang membantu bahkan orang nonprofesional membuat sendiri aplikasi kecil dengan mudah
• Berbeda dari aplikasi komersial besar atau aplikasi enterprise, alat ini memungkinkan pengguna menyelesaikan masalah kecil yang personal dan kreatif dengan bebas
• Menyediakan UI berbasis kanvas, pengeditan kode yang sederhana, serta fitur kolaborasi dan berbagi real-time sehingga dapat dimanfaatkan juga oleh non-programmer
• Semua aplikasi (Scrapp) pada dasarnya bersifat multiplayer, dan bisa langsung digunakan serta dikolaborasikan tanpa perlu membuat akun
• Tidak seperti pembuatan kode dengan AI atau alat yang sudah ada, Scrappy menekankan kendali langsung dan kepemilikan oleh pengguna

---

Pengenalan dan latar belakang

• Sebagian besar software berfokus pada penjualan ke pasar massal atau aplikasi kustom berskala besar
• Namun, aplikasi kecil yang disesuaikan secara personal untuk memenuhi kebutuhan nyata tiap individu sangat jarang ditemukan
• Scrappy adalah prototipe riset yang membantu siapa pun membuat sendiri aplikasi sederhana dan kreatif untuk teman serta keluarga
• Tujuan Scrappy adalah menghadirkan visi yang konkret agar lebih banyak orang dapat membuat software yang kreatif dan personal meski tanpa keahlian pemrograman

Apa itu Scrappy

• Aplikasi yang dibuat di Scrappy disebut Scrapp
• Contoh yang representatif:
  • Aplikasi latihan aritmetika untuk siswa sekolah dasar: tingkat kesulitan dapat diatur
  • Penghitung peserta acara lokal: mengelola keluar-masuk peserta dari beberapa pintu masuk
  • Jam penghitung biaya rapat: menghitung biaya rapat secara real-time
  • Pengelolaan pekerjaan rumah mingguan: pengaturan jadwal yang fleksibel untuk tiap anggota

Pengalaman membuat aplikasi di Scrappy

• Di Scrappy, objek seperti tombol dan kolom teks ditempatkan pada kanvas tak terbatas yang mirip Figma, Miro, dan Google Slides
• Properti dapat diubah langsung di panel Inspector, dan objek seperti tombol juga bisa dihubungkan dengan kode JavaScript
• Pembuatan aplikasi diselesaikan melalui pengulangan bertahap berupa drag/drop, pengubahan properti, dan penyisipan kode

Fitur utama:

• Menyusun perilaku dasar: letakkan field dan tombol lalu langsung hubungkan ke perilaku yang diinginkan
• Rumus reaktif: mewujudkan perubahan properti secara real-time sebagai respons terhadap kondisi tertentu
• Sinkronisasi multiplayer: status selalu disimpan dan disinkronkan secara real-time
• Pengeditan live: bisa selalu diedit secara real-time tanpa pemisahan antara menjalankan dan mengedit
• Berbagi selektif: hanya bagian tertentu dari aplikasi yang bisa dibagikan dan ditautkan secara terpisah
• Manipulasi data yang terlihat: debugging dan pengeditan bisa dilakukan sambil melihat data seperti pada spreadsheet

Alasan pengembangan Scrappy

• Scrappy berkaitan dengan tren seperti user-driven programming, “small computing”, “casual programming”, dan “home-cooked software” yang mewujudkan pemrograman yang dipimpin pengguna
• Berbeda dari pemrograman visual yang ada selama ini (berbasis blok, node-wire), Scrappy mengambil jalur berbeda dengan menggabungkan manipulasi intuitif dan scripting
• Scrappy terinspirasi oleh HyperCard, Visual Basic, dan media online kolaboratif, serta sangat menekankan pengalaman dari alat kampus produktivitas dan kolaborasi real-time (Google Docs, Figma, dll.)

• Berbeda dari aplikasi komersial skala besar atau pendekatan pembuatan otomatis berbasis AI, Scrappy memaksimalkan personalisasi, kesenangan, dan kreativitas dengan memberi kendali langsung kepada pengguna
• Tanpa harus menghasilkan kode secara langsung, Scrappy memberikan pengalaman membuat aplikasi yang lebih mudah dan lebih ramah bagi manusia

Pengguna sasaran Scrappy

• Pengoptimal proses kerja: orang yang ingin memperbaiki alur kerja yang rumit tanpa bantuan ahli
• Guru dan siswa: dapat fokus pada esensi pemrograman tanpa keterampilan tambahan (command line, pengaturan environment)
• Pengembang hobi: mereka yang ingin cepat mengeksplorasi banyak proyek tanpa kerumitan aplikasi massal
• Penganut DIY: pengguna yang ingin membuat sendiri aplikasi khusus seperti untuk rumah dan hobi

Saat ini, masih sulit bagi pemula total untuk membuat aplikasi dengan Scrappy (karena tetap memerlukan sebagian pengetahuan JavaScript), tetapi berbagi dan remix tetap bisa dilakukan oleh non-programmer.

Aplikasi seperti apa yang cocok dibuat di Scrappy?

• Dibagikan dengan teman/kenalan: sebagian besar Scrapp cocok untuk kolaborasi multi-pengguna secara real-time
• Terus diperbaiki dan disempurnakan: bisa langsung diubah saat aplikasi berjalan, tanpa proses deployment/build
• Perhitungan atau manipulasi skala kecil: lebih efektif untuk dokumen bersama + sedikit komputasi daripada sistem yang kompleks
• Meminimalkan friksi pengguna: dapat diakses dan digunakan hanya lewat tautan tanpa proses yang tidak perlu seperti membuat akun
• Sejumlah kecil pengguna yang saling percaya: tidak cocok bila kontrol izin atau sifat mission-critical adalah keharusan

Contoh ide aplikasi: flashcard kustom, agenda rapat, pengelolaan workshop online, papan keluarga, tabel rencana perjalanan, dll.

Scrappy vs aplikasi massal

Jika tidak ada aplikasi populer yang bisa ditemukan atau tidak ada yang benar-benar cocok, Anda bisa membuatnya sendiri dengan Scrappy lalu membagikannya. Keunggulan Scrappy:

• Hanya memiliki fitur yang dibutuhkan: tanpa elemen yang tidak perlu
• Sentuhan personal: aplikasi buatan sendiri punya makna dan keterikatan yang lebih tinggi
• Mudah dimodifikasi dengan menyenangkan: warna, layout, dan bahkan humor bisa ditambahkan dengan bebas
• Mudah di-remix/dibagikan: pengguna lain bisa dengan mudah memodifikasi dan memanfaatkannya kembali
• Dirancang berpusat pada kolaborasi: banyak pengguna dapat mengoperasikan dan mengedit secara bersamaan
• Langsung dipakai: cukup klik tautan tanpa perlu mendaftar akun
• Kepemilikan data yang jelas: data disimpan secara lokal sehingga sepenuhnya berada dalam kendali pengguna

Scrappy vs pembuatan aplikasi berbasis AI

AI memang dapat membuat aplikasi secara otomatis, tetapi keunggulan Scrappy terletak pada kemudahan dipahami, kolaborasi real-time, dan rasa kepemilikan kreatif

• Struktur yang mudah dipahami: berbasis objek visual tanpa kode yang rumit
• Mendukung kerja sama real-time: banyak pengguna dapat berkolaborasi dan mengedit secara bersamaan
• Lebih seru dan kreatif: memberikan umpan balik instan dan kesenangan dari modifikasi yang aktif

Scrappy vs HyperCard dan alat penerusnya

• Ramah berbagi di internet: aplikasi Scrappy bisa dibagikan online hanya lewat tautan
• Lingkungan kolaborasi real-time: mendukung pengeditan/eksekusi serentak
• UI dan interaksi modern: mendukung kanvas tak terbatas dan beragam objek
• Scripting JavaScript: menggunakan bahasa yang modern dan umum digunakan
• Objek interaktif yang lebih beragam: mendukung string, angka, tanggal, JSON, dll.
• Rumus reaktif dan koneksi state: dapat menetapkan hubungan dinamis mirip spreadsheet

Rencana ke depan

• Menurunkan hambatan masuk bagi pengguna non-programmer
  • autocomplete kode, debugging yang lebih mudah, visualisasi relasi, pesan error yang mudah dipahami, asisten berbasis AI
  • berbagi yang mudah dan cepat, galeri publik, penguatan dukungan mobile
• Penguatan dan perluasan fitur
  • memperkuat fitur koleksi dan pemrosesan data, pengelolaan objek berulang, memperkenalkan komponen reusable
  • memperluas extensibility Scrappy (dukungan objek baru), meningkatkan konsistensi konseptual, dll.

• Coba langsung Scrappy (khusus desktop)

[GN⁺]

Komentar Hacker News

• Saya suka arah proyek ini, tetapi pernah merasa model SaaS terhosting berbeda dari yang saya inginkan. Untuk proyek satu hari seperti penghitung kecil mungkin tidak masalah, tetapi untuk aplikasi kecil yang akan dipakai bertahun-tahun, ketergantungan menjadi masalah. Seberapa rendah pun kurva belajarnya, itu tetap ada; justru saya lebih menginginkan pilihan dengan aksesibilitas jangka panjang, bahasa yang mudah, dan alat yang memungkinkan saya memasang GUI sendiri. Kodenya tidak harus sepenuhnya disembunyikan; menurut saya, itu harus dibuat mudah ke arah yang benar-benar bisa dilakukan orang. Kalau mengingat berapa banyak orang belajar CSS dari MySpace, awalnya memang salin-tempel, tetapi akhirnya mereka menyesuaikannya menjadi milik mereka sendiri. Secara pribadi akhir-akhir ini saya terutama memakai HTML/CSS/JS, dan kalau benar-benar butuh backend saya memakai PHP murni tanpa framework. Namun pendekatan ini punya kelemahan karena terikat ke browser, meski di kantor proyek-proyek kecil yang dibuat dengan cara seperti ini (termasuk AutoHotKey) sudah berjalan lebih dari 10 tahun nyaris tanpa perawatan. Khusus skrip AutoHotKey, saya sudah melepasnya 8 tahun lalu saat pindah ke macOS, tetapi rekan kerja saya masih memakainya berkali-kali setiap hari. Bahkan jika AutoHotKey berhenti bekerja, kode yang sudah dibuat tetap bisa dipakai. Sebaliknya, solusi bergaya SaaS punya risiko harus dibuat ulang jika pendirinya beralih minat ke hal lain. Intinya, orang yang mencari solusi “scrappy” seperti ini biasanya tidak ingin membuat ulang semuanya setiap kali itu terjadi.

  • Untuk solusi seperti ini, saya rasa pendekatan seperti TiddlyWiki lebih cocok. TiddlyWiki memuat seluruh web app dalam satu file HTML, dan dulu ketika sesuatu diubah, perubahan disimpan ke file HTML itu sendiri sehingga bisa mereplikasi diri. Belakangan ini ada berbagai pendekatan lain, termasuk dukungan penyimpanan backend. Dengan file HTML yang mereplikasi diri dan akses backend opsional, ini bisa menjadi pilihan yang jauh lebih andal untuk proyek kecil personal yang disesuaikan. Setidaknya, daya pulihnya yang kuat adalah kelebihannya.
  • Saya merekomendasikan codeboot.org. Ini adalah IDE Python sepenuhnya client-side dengan dukungan single-stepping, sistem file virtual non-hierarkis, FFI ke kode JS, dan berbagai fitur lain (lihat dokumentasi). Berbagi aplikasi juga sangat mudah: klik kanan tombol play lalu salin URL, selesai. Saya pernah memakainya untuk menyelesaikan berbagai masalah seperti pembersihan data, dan aplikasi yang dibuat seperti ini sering langsung saya bookmark dan pakai. Ini benar-benar bekerja dengan baik, dan kalau ada yang penasaran AMA. Pengembangannya aktif dan ada fitur-fitur keren baru yang sedang disiapkan.
  • Saya juga berpikir ada cara untuk menjamin keberlangsungan jangka panjang dengan membuka seluruh kode SaaS sebagai open source. Penpot memakai pendekatan ini dengan baik. Kebanyakan orang menggunakannya sebagai SaaS, tetapi self-hosting juga memungkinkan. Tentu saja ada bagian yang sulit dihindari seperti sertifikasi distribusi atau penandatanganan aplikasi, tetapi mungkin pendekatan Web3 juga bisa membantu. Atau seperti PICO-8 atau Flash dulu: runtime dibuka, lalu “cartridge” atau aplikasi didistribusikan di atasnya. Membangun jalur distribusi tepercaya di luar SaaS memang cukup rumit, tetapi karena ada preseden sejarah, menurut saya layak dicoba. Lihat Penpot / PICO-8
  • Sebagai salah satu pembuat Scrappy, saya sepenuhnya setuju bahwa keberlangsungan jangka panjang perangkat lunak itu penting. Scrappy dirancang dengan arsitektur local-first, tanpa backend tradisional, jadi ketergantungan cloud-nya hanya pada server sinkronisasi yang sederhana. (Setelah diskusi ini membesar di HN, kami buru-buru menambahkan detail teknis ke FAQ.) Menurut saya ini menjadi pembeda secara teknis dan finansial dibanding alat low-code/no-code berbasis SaaS. Sejak awal kami bereksperimen dengan fitur menyimpan scrap sebagai file HTML tunggal yang self-contained, tetapi fitur itu saat ini tidak diekspos.
  • Saya membuat hal-hal seperti ini dengan Cursor dan gaya vibe coding, dan saya sangat puas memakainya. Baru-baru ini saya membuat pelacak pesawat yang menerima informasi jalur terbang ke rumah saya lewat SDR, menambahkan informasi penerbangan dari bandara, lalu menampilkannya di magic mirror dengan gaya flip board stasiun kereta. Untuk frontend saya nyaris tidak tahu JS, tetapi setelah sekitar 10 jam coding saya berhasil menyelesaikan aplikasi yang lumayan bagus. Dulu mungkin butuh lebih dari 2 bulan dan pada akhirnya saya menyerah, tetapi dengan vibe coding ini sangat menyenangkan dan menjadi pengalaman yang positif. Kodenya sekitar 1200 sLOC, dan saya berani bilang kualitas logging/performa/quality-nya sudah cukup semi-profesional, bahkan menurut saya lebih baik dari rata-rata kode komersial.

• CardStock tidak disebut di artikel utama, tetapi tampaknya punya tujuan dan pendekatan yang mirip dengan Scrappy. Tidak seperti Scrappy, CardStock adalah open source dan juga berjalan secara lokal. Lihat CardStock / repositori GitHub. Decker juga open source, dan sudah mengimplementasikan banyak kebutuhan di roadmap Scrappy (bahasa kueri data tabel, widget grid, abstraksi komponen menjadi “Contraption”, dll.). Lihat Decker.

  • Saya sudah lama mencari alat seperti ini, dan bagi saya fakta bahwa CardStock punya aplikasi desktop benar-benar sangat berarti.

• Membuat aplikasi yang dibuat di mobile bisa berjalan baik memang ada di roadmap, tetapi penyuntingan langsung di mobile tampaknya tidak dipertimbangkan (“layar sentuh sebesar telapak tangan tidak nyaman untuk mengedit Scrapps”). Namun sekarang ini banyak orang memakai mobile sebagai satu-satunya perangkat komputasi mereka, dan ada juga yang menulis kode atau novel di mobile. Jadi saya ingin menekankan bahwa meski sedikit tidak nyaman, kalau mereka juga memikirkan antarmuka penyuntingan mobile, dampak alat ini akan jauh lebih besar.

• Salah satu hal terbaik yang pernah saya lakukan adalah membuat aplikasi sederhana selama seminggu yang menaruh catatan jalan kaki Apple Watch di atas satu peta besar, lalu mengunggahnya ke AppStore dan membagikannya ke orang-orang dekat. Setahun kemudian, teman-teman dan orang yang kebetulan menemukan aplikasinya masih berjalan keliling seluruh kota dan mengirim pesan pembuktian, dan itu membuat saya bangga. Walau tidak menghasilkan uang, ini benar-benar pengalaman yang memuaskan. Seperti kata OP, membuat aplikasi sederhana untuk teman demi kesenangan adalah kebahagiaan terbaik.

  • Jadi penasaran dengan tautan aplikasinya.
  • Jika dibayangkan berapa banyak tembok dan rintangan yang harus dilewati untuk membuatnya, pasti banyak orang menyerah di salah satunya. Akibatnya, pengguna tetap tidak bisa mengendalikan apa pun dan akhirnya terjebak vendor lock-in. Kalau saja kita bisa langsung memerintah AI dan bebas mem-porting-nya ke watch open source, alangkah bagusnya dunia itu.

• Saya belum pernah melihat lingkungan pemrograman yang benar-benar berguna bagi end-user selain spreadsheet.

  • Sebagai contoh yang mendorong ini sampai ekstrem, saya merekomendasikan pyspread.
  • Saya pribadi melewatkannya karena tidak ada testing, version control, dan dukungan library.
  • Pada akhirnya lebih baik belajar coding langsung. Saya tidak paham alasan belajar alat-alat seperti ini. Dari sudut pandang developer, ya tinggal dibuat saja, dan dengan LLM hal yang sangat sederhana bisa cepat dirakit lewat vibe coding tanpa banyak risiko. Bahkan untuk non-developer, saya penasaran sebenarnya ada berapa banyak orang yang mau belajar alat seperti ini (saya penasaran dengan TAM-nya). Siapa yang benar-benar mau repot menyusun aplikasi dengan drag-and-drop seperti itu?

• vibe coding mungkin tidak akan menggantikan developer sekarang juga, tetapi untuk sistem sesederhana ini, itu akan menjadi pesaing terkuat. Bahkan ketika menyuruh LLM membuat aplikasi sederhana (HTML+JS tertanam), setelah sedikit perbaikan hasilnya sudah sangat matang, dan bahkan tampilannya juga lebih bagus. Lihat contoh ini.

  • Saya juga sedang mengerjakan side project dengan vibe coding. Setiap beberapa jam saya selalu mentok pada masalah yang tidak bisa diselesaikan LLM, dan saya jadi berpikir pengguna tanpa pengalaman coding mungkin sama sekali tidak akan bisa melewatinya. Mungkin tergantung teknologi yang dipakai atau cakupan proyeknya.
  • Laporan bug: jika memasukkan kesalahan seperti 3 + 2 = 5.1, itu tetap dianggap jawaban benar.
  • vibe coding memang tujuan awalnya, dan mereka adalah lawan alami.
  • Saya jadi penasaran dengan stack sistem sederhana yang bisa di-self-host. Secara pribadi saya butuh Vue dengan autentikasi, database offline multiplayer, static hosting, file hosting, dan fitur filter agar pengguna tidak bisa melihat data orang lain.
  • Saya ingin mengganti tanda tanya dengan spasi kosong atau garis bawah.

• Kita mendekati topik ini dari sudut pandang programmer, tetapi saya rasa peluang sesungguhnya ada di komunitas. Misalnya bisa dimulai seperti app store pribadi tingkat keluarga (gaya Masterson). Tanpa keamanan juga tidak masalah karena semuanya orang yang dikenal, dan kontribusi pun tidak bisa dilakukan tanpa undangan. Hanya sekadar melempar ide.

• Jika pada akhirnya semua yang bisa dilakukan adalah drag-and-drop elemen UI ke lembar kosong, lalu terus bertarung karena grid snap tidak cocok dengan ukuran elemen UI, dan akhirnya tetap harus mengetik JavaScript mentah tanpa autocomplete kode, visual programming, bantuan API, atau dukungan AI, saya jadi bertanya apakah memang hanya segini akhirnya.

• Saya juga 100% setuju dengan pendekatan “komponen yang bisa discrpt” dibanding pendekatan berbasis blok untuk pemula. Sekarang saya sedang di mobile, tetapi berencana mencobanya di desktop nanti. Hal yang terlewat dalam analisis adalah bahwa orang-orang menginginkan “berbagi yang mudah” dan “biaya nol”. Bahkan di lingkungan minimal pun, membuat aplikasinya sendiri itu mudah, tetapi distribusi (hambatan app store)/hosting adalah masalah, jadi bahkan keluarga atau kenalan pun ragu membayar US$5 per bulan. Sebenarnya developer profesional pun sama.

  • Tinggal self-host saja dengan web server di rumah + dynamic DNS.
  • Berbagi ide itu bagus, tetapi hosting/distribusi gratis berisiko disalahgunakan oleh pengguna jahat.

• Saat melihat ungkapan seperti “komputer harus bekerja untuk manusia, dan seharusnya menjadi aktivitas semua orang seperti memasak atau pengolah kata”, saya merasa arahnya terlalu umum. Frasa seperti “dengan live update, semuanya gratis. LLM...” juga terasa penuh em-dash (-) sampai terkesan seperti tulisan AI. Secara pribadi, kalau terlihat sebagai konten yang ditulis AI, minat saya langsung turun tajam. Bukan salah pembuatnya, tetapi saya juga memang tidak terlalu tertarik pada copy seperti ini.

  • Gaya em-dash seperti ini sudah saya pakai 10–15 tahun dalam gaya menulis saya sehari-hari. Saya juga tidak terlalu suka mengonsumsi konten buatan AI, dan kalau seseorang hanya memasukkan prompt, saya merasa lebih baik saya tanya langsung ke LLM sendiri.
  • Kalau mengikuti pemakaian hyphen/en dash/em dash, memakai em dash sebagai pemisah itu justru benar sesuai kaidah. Saya tidak setuju kalau itu dianggap penanda AI.
  • Dari sudut pandang salah satu pembuat Scrappy, saya pengguna Macintosh lama jadi saya sangat membedakan hyphen, en dash, dan em dash :) Saya kadang memakai AI hanya untuk polishing, bukan untuk menghasilkan teks. Saya menulisnya sendiri, jadi pekerjaan yang dikerjakan secara nyata memang sangat banyak (sebenarnya sebagian besar pekerjaan dilakukan oleh Pontus).
  • Kalau mau mengetik em dash, pakai compose key lalu tiga kali hyphen. — seperti ini. Di Mac, itu shift-option-hyphen.