Scrappy - สร้างแอปเล็กๆ สำหรับคุณและเพื่อนๆ

• Scrappy คือ เครื่องมือสร้างซอฟต์แวร์แบบโฮมเมด ที่ช่วยให้แม้แต่คนที่ไม่ใช่มืออาชีพก็สร้างแอปเล็กๆ ได้ด้วยตัวเองอย่างง่ายดาย
• ต่างจากแอปเชิงพาณิชย์ขนาดใหญ่หรือแอประดับองค์กร ตรงที่สามารถแก้ปัญหา ขนาดเล็กที่เป็นเรื่องส่วนตัวและสร้างสรรค์ ได้อย่างอิสระ
• มี UI แบบแคนวาส การแก้ไขโค้ดที่เรียบง่าย รวมถึงฟีเจอร์ทำงานร่วมกันและแชร์แบบเรียลไทม์ ทำให้ผู้ที่ไม่ใช่นักเขียนโปรแกรมก็ใช้งานได้
• ทุกแอป (Scrapp) เป็นสภาพแวดล้อมแบบหลายผู้ใช้โดยพื้นฐาน และสามารถเริ่มใช้งานกับทำงานร่วมกันได้ทันทีโดยไม่ต้องสร้างบัญชี
• ต่างจาก การสร้างโค้ดด้วย AI หรือเครื่องมือเดิมๆ Scrappy เน้น การควบคุมและความเป็นเจ้าของโดยผู้ใช้โดยตรง

---

บทนำและที่มา

• ซอฟต์แวร์ส่วนใหญ่ถูกสร้างมาเพื่อขายในตลาดมวลชน หรือเป็นแอปสั่งทำขนาดใหญ่เป็นหลัก
• แต่แอปขนาดเล็กที่ปรับให้ตรงกับความต้องการของแต่ละคนจริงๆ กลับมีอยู่น้อยมาก
• Scrappy คือโปรโตไทป์งานวิจัยที่ช่วยให้ใครก็ตามสามารถสร้าง แอปที่เรียบง่ายและสร้างสรรค์ สำหรับเพื่อนและครอบครัวได้ด้วยตัวเอง
• เป้าหมายของ Scrappy คือทำให้วิสัยทัศน์ที่ว่า ผู้คนจำนวนมากขึ้นสามารถสร้างซอฟต์แวร์ที่สร้างสรรค์และปรับให้เป็นส่วนตัวได้ เป็นรูปธรรม แม้จะไม่มีความเชี่ยวชาญด้านการเขียนโปรแกรม

Scrappy คืออะไร

• แอปที่สร้างใน Scrappy เรียกว่า Scrapp
• ตัวอย่างเด่นๆ:
  • แอปฝึกคณิตศาสตร์สำหรับเด็กประถม: ปรับระดับความยากได้
  • ตัวนับผู้เข้าร่วมงานในชุมชน: จัดการการเข้าออกของผู้ร่วมงานจากหลายทางเข้า
  • นาฬิกาคำนวณค่าใช้จ่ายการประชุม: คำนวณค่าใช้จ่ายของการประชุมแบบเรียลไทม์
  • ระบบจัดการงานบ้านรายสัปดาห์: จัดตารางอย่างยืดหยุ่นให้สมาชิกแต่ละคนได้

ประสบการณ์การสร้างแอปใน Scrappy

• Scrappy ใช้ แคนวาสแบบไม่สิ้นสุดที่คล้าย Figma, Miro, Google Slides สำหรับวางอ็อบเจ็กต์อย่างปุ่มและช่องข้อความ
• สามารถแก้ไขคุณสมบัติได้โดยตรงในแผง Inspector และยังผูก โค้ด JavaScript เข้ากับปุ่มหรือองค์ประกอบอื่นๆ ได้
• การสร้างแอปจะค่อยๆ เสร็จสมบูรณ์ผ่านการทำซ้ำเป็นขั้นตอน เช่น ลากและวาง แก้ไขคุณสมบัติ และแทรกโค้ด

คุณสมบัติหลัก:

• กำหนดพฤติกรรมพื้นฐาน: วางฟิลด์และปุ่มแล้วเชื่อมการทำงานได้ทันที
• สูตรแบบตอบสนอง: ทำให้คุณสมบัติเปลี่ยนแบบเรียลไทม์ตามเงื่อนไขที่กำหนด
• การซิงก์หลายผู้ใช้: สถานะจะถูกบันทึกและซิงก์แบบเรียลไทม์ตลอดเวลา
• การแก้ไขสด: ปรับแก้ได้แบบเรียลไทม์เสมอโดยไม่ต้องแยกระหว่างโหมดรันกับโหมดแก้ไข
• การแชร์แบบเลือกส่วนได้: แชร์และเชื่อมโยงเฉพาะบางส่วนของแอปแยกกันได้
• การจัดการข้อมูลแบบมองเห็นได้: ดีบักและแก้ไขข้อมูลได้ขณะมองเห็นข้อมูลเหมือนสเปรดชีต

เหตุผลที่พัฒนา Scrappy

• Scrappy เกี่ยวข้องกับแนวโน้มอย่าง user-driven programming, “small computing”, “casual programming”, “home-cooked software” ซึ่งมุ่งทำให้การเขียนโปรแกรมขับเคลื่อนโดยผู้ใช้
• แตกต่างจากการเขียนโปรแกรมแบบภาพเดิมๆ (บล็อก, โหนด-สาย) โดยเลือกผสาน การจัดการที่เป็นธรรมชาติกับการเขียนสคริปต์
• ได้แรงบันดาลใจจาก HyperCard, Visual Basic, สื่อออนไลน์แบบพร้อมกัน รวมถึงให้ความสำคัญกับประสบการณ์จาก เครื่องมือเพิ่มประสิทธิภาพบนแคนวาส และการทำงานร่วมกันแบบเรียลไทม์ (เช่น Google Docs, Figma)

• Scrappy ต่างจากแอปเชิงพาณิชย์ขนาดใหญ่หรือแนวทางสร้างอัตโนมัติด้วย AI ตรงที่ให้ผู้ใช้ควบคุมได้เอง และขยาย ความเป็นส่วนตัว ความสนุก และความคิดสร้างสรรค์ ได้สูงสุด
• แม้ไม่ต้องสร้างโค้ดโดยตรง ก็ยังมอบประสบการณ์สร้างแอปที่ง่ายกว่าและเป็นมิตรกับมนุษย์มากกว่า

ผู้ใช้เป้าหมายของ Scrappy

• ผู้ปรับกระบวนการทำงานให้มีประสิทธิภาพ: คนที่อยากปรับปรุงเวิร์กโฟลว์ซับซ้อนโดยไม่ต้องพึ่งผู้เชี่ยวชาญ
• ครูและนักเรียน: โฟกัสกับแก่นของการเขียนโปรแกรมได้โดยไม่ต้องติดกับทักษะประกอบอื่นๆ (เช่น command line หรือการตั้งค่าสภาพแวดล้อม)
• นักพัฒนาสายงานอดิเรก: คนที่อยากสำรวจหลายโปรเจกต์อย่างรวดเร็วโดยหลุดพ้นจากความซับซ้อนของแอปตลาดมวลชน
• สาย DIY: ผู้ใช้ที่อยากสร้างแอปของตัวเองโดยตรงเหมือนกับการทำของใช้ในบ้านหรือทำงานอดิเรก

ปัจจุบัน การให้มือใหม่แบบสมบูรณ์สร้างแอปด้วย Scrappy ยังทำได้ยากอยู่บ้าง (ยังต้องมีความรู้ JavaScript บางส่วน) แต่ การแชร์และรีมิกซ์นั้นแม้แต่คนที่ไม่เขียนโปรแกรมก็ทำได้

แอปแบบไหนที่เหมาะจะสร้างด้วย Scrappy?

• แชร์กับเพื่อนหรือคนรู้จัก: Scrapp ส่วนใหญ่เหมาะกับการทำงานร่วมกันแบบเรียลไทม์ระหว่างหลายผู้ใช้
• แก้ไขและปรับปรุงอย่างต่อเนื่อง: แก้ไขได้ทันทีแม้ระหว่างใช้งานแอป โดยไม่มีขั้นตอน deploy/build
• การคำนวณหรือการจัดการขนาดเล็ก: เหมาะกับงานแนวเอกสารที่แชร์ร่วมกันบวกความสามารถด้านคอมพิวติ้งเล็กน้อย มากกว่าระบบซับซ้อน
• ลดแรงเสียดทานของผู้ใช้ให้น้อยที่สุด: เข้าถึงและใช้งานได้ผ่านลิงก์อย่างเดียวโดยไม่ต้องมีขั้นตอนเกินจำเป็น เช่น การสมัครบัญชี
• ผู้ใช้จำนวนน้อยที่เชื่อถือกันได้: หากจำเป็นต้องมีการควบคุมสิทธิ์หรือรองรับงาน mission-critical ก็อาจไม่เหมาะ

ตัวอย่างไอเดียแอป: แฟลชการ์ดแบบกำหนดเอง, วาระการประชุม, การจัดการเวิร์กช็อปออนไลน์, กระดานข้อความสำหรับครอบครัว, ตารางวางแผนท่องเที่ยว เป็นต้น

Scrappy vs แอปตลาดมวลชน

หากหาแอปยอดนิยมที่ตรงความต้องการไม่ได้ หรือมีแต่ไม่เหมาะ ก็สามารถสร้างเองด้วย Scrappy แล้วแชร์ได้ ข้อดีของ Scrappy คือ:

• มีเฉพาะฟังก์ชันที่ต้องการ: ไม่มีส่วนเกินที่ไม่จำเป็น
• มีความใส่ใจแบบส่วนตัว: แอปที่สร้างเองมีความหมายและความผูกพันมากกว่า
• ปรับแต่งได้อย่างสนุก: ตกแต่งสี เลย์เอาต์ และเพิ่มมุกตลกได้อย่างอิสระ
• รีมิกซ์/แชร์ได้ง่าย: ผู้ใช้อื่นแก้ไขและนำกลับไปใช้ต่อได้ง่าย
• ออกแบบมาเพื่อการทำงานร่วมกัน: หลายคนสามารถจัดการและแก้ไขพร้อมกันได้
• ใช้งานได้ทันที: แค่คลิกลิงก์ก็เริ่มใช้ได้เลยโดยไม่ต้องสมัครบัญชี
• ความเป็นเจ้าของข้อมูลชัดเจน: ข้อมูลถูกเก็บไว้ในเครื่อง ทำให้ผู้ใช้ควบคุมได้อย่างสมบูรณ์

Scrappy vs การสร้างแอปด้วย AI

แม้ AI จะสร้างแอปได้อัตโนมัติ แต่ จุดแข็งของ Scrappy อยู่ที่ความเข้าใจง่าย การทำงานร่วมกันแบบเรียลไทม์ และความรู้สึกเป็นเจ้าของเชิงสร้างสรรค์

• โครงสร้างที่เข้าใจง่าย: ใช้อ็อบเจ็กต์เชิงภาพแทนโค้ดที่ซับซ้อน
• รองรับการทำงานร่วมกันแบบเรียลไทม์: หลายผู้ใช้สามารถร่วมมือและแก้ไขพร้อมกันได้
• สนุกและสร้างสรรค์ได้มากกว่า: ให้ฟีดแบ็กทันทีและความสนุกจากการปรับแก้อย่างกระตือรือร้น

Scrappy vs HyperCard และเครื่องมือรุ่นถัดมา

• แชร์แบบเป็นมิตรกับอินเทอร์เน็ต: แอป Scrappy แชร์ออนไลน์ได้ผ่านลิงก์เพียงอย่างเดียว
• สภาพแวดล้อมการทำงานร่วมกันแบบเรียลไทม์: รองรับการแก้ไข/รันพร้อมกัน
• UI และอินเทอร์แอ็กชันสมัยใหม่: รองรับแคนวาสไม่สิ้นสุดและอ็อบเจ็กต์หลากหลาย
• การเขียนสคริปต์ด้วย JavaScript: ใช้ภาษาสมัยใหม่ที่แพร่หลาย
• อ็อบเจ็กต์อินเทอร์แอ็กทีฟที่หลากหลายยิ่งขึ้น: รองรับสตริง ตัวเลข วันที่ JSON เป็นต้น
• สูตรแบบตอบสนองและการเชื่อมสถานะ: ตั้งค่าความสัมพันธ์แบบไดนามิกคล้ายสเปรดชีตได้

แผนในอนาคต

• ลดอุปสรรคในการเริ่มต้นสำหรับผู้ใช้ที่ไม่ใช่นักเขียนโปรแกรม
  • เติมโค้ดอัตโนมัติ, การดีบักที่ง่ายขึ้น, การมองเห็นความสัมพันธ์, ข้อความแสดงข้อผิดพลาดที่เข้าใจง่าย, ผู้ช่วยที่ขับเคลื่อนด้วย AI
  • แชร์ได้ง่ายและรวดเร็วขึ้น, แกลเลอรีสาธารณะ, เสริมการรองรับมือถือ
• เสริมและขยายความสามารถ
  • เพิ่มความสามารถด้านคอลเลกชันและการประมวลผลข้อมูล, การจัดการอ็อบเจ็กต์แบบทำซ้ำ, เพิ่มคอมโพเนนต์ที่นำกลับมาใช้ซ้ำได้
  • ขยายความสามารถของ Scrappy (รองรับอ็อบเจ็กต์ใหม่), ปรับปรุงความสอดคล้องเชิงแนวคิด เป็นต้น

• ลองใช้ Scrappy ด้วยตัวเอง (เดสก์ท็อปเท่านั้น)

[GN⁺]

ความคิดเห็นจาก Hacker News

• ฉันชอบทิศทางของโปรเจกต์นี้ แต่ขอแชร์ประสบการณ์ว่ารูปแบบ SaaS ที่โฮสต์ไว้ไม่ใช่สิ่งที่ฉันต้องการ สำหรับโปรเจกต์หนึ่งวันที่เป็นอะไรเล็ก ๆ อย่างเคาน์เตอร์ก็ไม่เป็นไร แต่ถ้าเป็นแอปเล็ก ๆ ที่จะใช้ไปอีกหลายปี การพึ่งพาระบบภายนอกกลายเป็นปัญหา ไม่ว่าเส้นโค้งการเรียนรู้จะต่ำแค่ไหน สุดท้ายมันก็ยังมีอยู่ และสิ่งที่ฉันอยากได้มากกว่าคือแนวทางที่เข้าถึงได้นาน ๆ ใช้ภาษาที่ง่าย และมีเครื่องมือที่ใส่ GUI เองได้ง่าย ๆ ฉันคิดว่าไม่จำเป็นต้องซ่อนโค้ดทั้งหมด แต่อยู่ที่ทำให้คนทำได้จริงอย่างง่ายมากกว่า พอนึกถึงว่าในยุค MySpace มีคนมากแค่ไหนที่ได้เรียน CSS ก็จะเห็นว่าแม้จะเริ่มจากการคัดลอกวาง แต่สุดท้ายคนก็ค่อย ๆ ปรับแต่งจนกลายเป็นของตัวเอง ทุกวันนี้ส่วนตัวฉันใช้ HTML/CSS/JS เป็นหลัก และถ้าจำเป็นต้องมีแบ็กเอนด์จริง ๆ ก็ใช้ PHP ล้วน ๆ (ไม่ใช้เฟรมเวิร์ก) แต่วิธีนี้มีข้อเสียคือผูกติดกับเบราว์เซอร์ ถึงอย่างนั้น ในบริษัทก็มีโปรเจกต์ขนาดเล็กที่ทำด้วยแนวทางนี้ (รวมถึง AutoHotKey) ซึ่งรันมานานกว่า 10 ปีแบบแทบไม่ต้องดูแล โดยเฉพาะสคริปต์ AutoHotKey ที่ฉันเลิกยุ่งไปตั้งแต่ย้ายไป macOS เมื่อ 8 ปีก่อน แต่เพื่อนร่วมงานก็ยังใช้กันวันละหลายครั้งอยู่ดี ต่อให้วันหนึ่ง AutoHotKey ใช้งานไม่ได้ โค้ดที่สร้างไว้ก็ยังใช้ต่อได้ แต่โซลูชันแบบ SaaS มีความเสี่ยงว่าถ้าผู้ก่อตั้งหันไปสนใจอย่างอื่น เราก็ต้องมาสร้างใหม่ ประเด็นสำคัญคือ คนที่มองหาโซลูชันแบบ “scrappy” นี้ ไม่ได้อยากสร้างมันใหม่ทุกครั้ง

  • ถ้าเป็นโซลูชันแนวนี้ ฉันคิดว่าวิธีแบบ TiddlyWiki น่าจะเหมาะกว่า TiddlyWiki ใส่เว็บแอปทั้งก้อนไว้ในไฟล์ HTML ไฟล์เดียว และเมื่อก่อนเวลามีการเปลี่ยนแปลงก็จะบันทึกกลับลงในไฟล์ HTML นั้นเอง ทำให้มัน self-replicating ได้ ช่วงหลัง ๆ ก็มีวิธีอื่นเพิ่มขึ้น เช่น รองรับการจัดเก็บผ่านแบ็กเอนด์ ด้วยแนวทางไฟล์ HTML ที่คัดลอกตัวเองได้และการเข้าถึงแบ็กเอนด์แบบเลือกใช้ ฉันมองว่านี่เป็นตัวเลือกที่เชื่อถือได้กว่ามากสำหรับโปรเจกต์ส่วนตัวขนาดเล็กที่ปรับตามใจ อย่างน้อยจุดแข็งคือความทนทานสูงมาก
  • ขอแนะนำ codeboot.org เป็น Python IDE แบบทำงานฝั่งไคลเอนต์ทั้งหมด รองรับ single-stepping, virtual file system แบบไม่เป็นลำดับชั้น, FFI กับโค้ด JS และฟีเจอร์อื่น ๆ อีกหลายอย่าง (ดูในเอกสารได้) การแชร์แอปก็ง่ายมาก แค่คลิกขวาที่ปุ่มเล่นแล้วคัดลอก URL ก็แชร์ได้เลย ฉันเคยใช้มันแก้ปัญหาหลายอย่าง เช่น data wrangling และบ่อยครั้งก็ทำแอปด้วยวิธีนี้แล้วบุ๊กมาร์กไว้ใช้ต่อ ใช้งานได้ดีจริง ๆ ถ้าอยากรู้อะไรเพิ่มก็ถามมาได้เลย กำลังพัฒนาอย่างต่อเนื่องและมีฟีเจอร์ใหม่เจ๋ง ๆ กำลังมา
  • อีกวิธีหนึ่งอาจเป็นการเปิดซอร์สโค้ดทั้งหมดของ SaaS เพื่อรับประกันการใช้งานระยะยาว Penpot ใช้วิธีนี้ได้ดีมาก คนส่วนใหญ่ใช้แบบ SaaS แต่ก็ self-host ได้เหมือนกัน แน่นอนว่าเรื่องอย่างการรับรองดิสทริบิวชันหรือการเซ็นแอปยังเป็นเรื่องยากอยู่ดี แต่บางทีแนวทางแบบ Web3 ก็น่าจะช่วยได้ หรืออาจใช้วิธีแบบ PICO-8 หรือ Flash สมัยก่อน โดยเปิดเผย runtime แล้วกระจาย “คาร์ทริดจ์” หรือแอปแทน การสร้างช่องทางกระจายที่เชื่อถือได้โดยไม่ต้องพึ่ง SaaS นั้นซับซ้อนพอสมควร แต่ก็มีประวัติให้เห็นว่าเคยทำได้จริง จึงน่าลองอยู่ Penpot / PICO-8
  • ในฐานะผู้ร่วมสร้าง Scrappy ฉันเห็นด้วยเต็มที่ว่าความสามารถในการใช้งานซอฟต์แวร์ในระยะยาวสำคัญมาก Scrappy ถูกออกแบบด้วยสถาปัตยกรรม local-first ไม่มีแบ็กเอนด์แบบดั้งเดิม ดังนั้นการพึ่งพาคลาวด์มีแค่เซิร์ฟเวอร์ซิงก์เท่านั้น (หลังจากประเด็นนี้เริ่มถกกันมากบน HN เราก็รีบเพิ่มรายละเอียดทางเทคนิคลงใน FAQ) ฉันคิดว่านี่เป็นจุดต่างทั้งในเชิงเทคนิคและการเงินเมื่อเทียบกับเครื่องมือ low-code/no-code แบบ SaaS ตั้งแต่ช่วงแรกเราก็เคยทดลองฟีเจอร์บันทึก scrap เป็นไฟล์ HTML แบบหน้าเดียวและมีทุกอย่างในตัวเองแล้ว แต่ตอนนี้ยังไม่ได้เปิดให้ใช้งาน
  • ฉันกำลังทำของแนวนี้ด้วย Cursor และแนวทาง vibe coding และพอใจมาก ๆ เมื่อไม่นานนี้ฉันทำตัวติดตามเครื่องบินที่รับข้อมูลเส้นทางใกล้บ้านผ่าน SDR จากนั้นดึงข้อมูลเที่ยวบินจากสนามบินมาเพิ่ม แล้วแสดงบน magic mirror ในสไตล์ flip board ของสถานีรถไฟ ฝั่งฟรอนต์เอนด์ฉันแทบไม่รู้ JS เลย แต่ใช้เวลาเขียนโค้ดราว 10 ชั่วโมงก็ได้แอปที่ออกมาค่อนข้างดี ถ้าเป็นเมื่อก่อนคงใช้เวลาเกิน 2 เดือนแล้วสุดท้ายก็ยอมแพ้ไป แต่พอทำแบบ vibe coding แล้วทั้งสนุกและเป็นประสบการณ์ที่ดีมาก โค้ดมีประมาณ 1200 sLOC และฉันกล้าพูดว่าเป็นโค้ดกึ่งมืออาชีพทั้งด้าน logging, performance และคุณภาพ (คิดว่าดีกว่าโค้ดเชิงพาณิชย์ทั่วไปด้วยซ้ำ)

• แม้ CardStock จะไม่ได้ถูกพูดถึงในบทความหลัก แต่ดูเหมือนมีเป้าหมายและแนวทางคล้ายกับ Scrappy ต่างกันตรงที่ CardStock เป็นโอเพนซอร์สและรันแบบโลคัลได้ CardStock / GitHub repository และ Decker ก็เป็นโอเพนซอร์สเช่นกัน โดยมันทำหลายอย่างตามที่อยู่ในโรดแมปของ Scrappy ไว้แล้ว เช่น table data query language, grid widget และการทำ abstraction ของชิ้นส่วนให้เป็น “Contraption” ดูได้ที่ Decker

  • ฉันตามหาเครื่องมือแบบนี้มานานมาก และการที่ CardStock มีเดสก์ท็อปแอปนี่มีความหมายมากจริง ๆ

• ในโรดแมปมีเรื่องทำให้แอปที่สร้างบนมือถือทำงานได้ดี แต่ดูเหมือนจะไม่ได้พิจารณาการแก้ไขบนมือถือเองเลย (มีการพูดว่า “หน้าจอสัมผัสขนาดฝ่ามือไม่เหมาะกับการแก้ไข Scrapps”) แต่ตอนนี้เราอยู่ในยุคที่หลายคนใช้มือถือเป็นอุปกรณ์คอมพิวติ้งเพียงอย่างเดียว และหลายคนก็เขียนทั้งโค้ดหรือแม้แต่นวนิยายบนมือถือ ดังนั้นต่อให้จะใช้งานไม่สะดวกนัก หากคิดถึงอินเทอร์เฟซสำหรับแก้ไขบนมือถือด้วย เครื่องมือนี้จะมีอิทธิพลมากขึ้นอีกมาก

• หนึ่งในสิ่งที่ดีที่สุดที่ฉันเคยทำ คือการใช้เวลาหนึ่งสัปดาห์สร้างแอปเรียบง่ายที่เอาสถิติการเดินจาก Apple Watch ไปวางบนแผนที่ขนาดใหญ่ใบเดียว แล้วเอาขึ้น AppStore เพื่อแชร์กับคนรู้จัก ผ่านมา 1 ปีแล้วก็ยังมีทั้งเพื่อนและคนที่บังเอิญเจอแอป ส่งข้อความมายืนยันว่าพวกเขาเดินครบทั้งเมืองแล้ว มันทำให้รู้สึกดีมาก ถึงจะไม่ได้เงินแต่ก็เป็นประสบการณ์ที่คุ้มค่ามาก อย่างที่ OP ว่าไว้ การทำแอปง่าย ๆ สนุก ๆ ให้เพื่อนนี่แหละคือความสุขที่สุด

  • ชักอยากรู้ลิงก์แอปแล้ว
  • ถ้าลองนึกว่าต้องผ่านกำแพงและอุปสรรคมากแค่ไหนกว่าจะสร้างมันออกมาได้ ก็จะเห็นว่าคนจำนวนมากคงยอมแพ้ไปตั้งแต่ขั้นใดขั้นหนึ่ง สุดท้ายผู้ใช้ก็ยังคุมอะไรไม่ได้เลย และยังติดกับผู้ขายเหมือนเดิม ถ้าสามารถสั่ง AI ได้ตรง ๆ แล้วพอร์ตไปสู่นาฬิกาโอเพนซอร์สได้อย่างอิสระ โลกคงจะดีขึ้นมาก

• ฉันยังไม่เคยเห็นสภาพแวดล้อมการเขียนโปรแกรมสำหรับผู้ใช้ปลายทางที่ใช้งานได้จริงเท่าสเปรดชีตเลย

  • ถ้าจะไปให้สุดทางด้านนี้ ขอแนะนำ pyspread
  • ส่วนตัวฉันขอผ่าน เพราะไม่มีการทดสอบ, version control และการรองรับไลบรารี
  • สุดท้ายแล้วไปเรียนเขียนโค้ดเองดีกว่า ฉันไม่เข้าใจว่าทำไมต้องมาเรียนเครื่องมือแบบนี้ ถ้าเป็นนักพัฒนาก็แค่ลงมือทำ และถ้าใช้ LLM งานง่าย ๆ ก็ vibe coding ได้สบายแทบไม่มีอะไรให้เสีย ต่อให้ไม่ใช่นักพัฒนา ฉันก็สงสัยว่าจะมีคนยอมเรียนเครื่องมือแบบนี้มากแค่ไหน (อยากรู้ TAM) ใครจะยอมเสียเวลาลากวางมาสร้างแอปกันนะ

• vibe coding อาจยังไม่แทนที่นักพัฒนาในทันที แต่สำหรับระบบง่าย ๆ แบบนี้มันจะเป็นคู่แข่งที่แข็งแกร่งที่สุด ถ้าสั่ง LLM ให้สร้างแอปง่าย ๆ (HTML+JS ฝังในตัว) แล้วเอามาปรับนิดหน่อย ก็ได้งานที่สมบูรณ์มาก และยังดูดีกว่าด้วยซ้ำ ดู ตัวอย่าง

  • ฉันก็ทำ side project ด้วย vibe coding เหมือนกัน แต่ทุก ๆ ไม่กี่ชั่วโมงก็มักชนกับปัญหาที่ LLM แก้ไม่ได้ เลยคิดว่าถ้าผู้ใช้ไม่มีประสบการณ์เขียนโค้ดก็อาจแก้ไม่ออกเลยและไปต่อไม่ได้ คงขึ้นกับเทคโนโลยีที่ใช้และขอบเขตของโปรเจกต์ด้วย
  • รายงานบั๊ก: ถ้าใส่อะไรอย่าง 3 + 2 = 5.1 ก็ยังถูกนับว่าตอบถูก
  • vibe coding ก็เป็นเป้าหมายดั้งเดิมอยู่แล้ว และคนกลุ่มนี้ก็เป็นคู่เปรียบตามธรรมชาติ
  • อยากรู้ stack ระบบง่าย ๆ ที่ self-host ได้ ตอนนี้ส่วนตัวต้องการ Vue พร้อมระบบ auth, multiplayer offline DB, static hosting, file hosting และฟิลเตอร์ที่ทำให้ผู้ใช้มองไม่เห็นข้อมูลของคนอื่น
  • ฉันอยากเปลี่ยนเครื่องหมายคำถามเป็นช่องว่างหรือขีดเส้นใต้แทน

• เรากำลังเข้าหาหัวข้อนี้จากมุมมองของโปรแกรมเมอร์ แต่ฉันคิดว่าโอกาสจริง ๆ อยู่ที่ชุมชน เช่น อาจเริ่มจากอะไรอย่าง app store ส่วนตัวระดับครอบครัวก็ได้ (สไตล์ Masterson) ไม่ต้องมีความปลอดภัยอะไรมากเพราะทุกคนรู้จักกัน และถ้าไม่ได้รับเชิญก็ร่วมแก้ไขไม่ได้ แค่เสนอเป็นไอเดียเฉย ๆ

• ถ้าสุดท้ายต้องลากวางองค์ประกอบ UI ลงบนแผ่นว่าง ๆ แล้วมานั่งสู้กับการ snap grid ที่ขนาดไม่ตรงกับองค์ประกอบ UI และสุดท้ายก็ยังต้องพิมพ์ JavaScript ดิบ ๆ โดยไม่มี code autocomplete, visual programming, ความช่วยเหลือด้าน API หรือ AI ช่วยเลย แบบนี้มันคือที่สุดแล้วจริงหรือ

• ฉันเองก็เห็นด้วย 100% กับแนวทาง “คอมโพเนนต์ที่สคริปต์ได้” แทนระบบบล็อกสำหรับผู้เริ่มต้น ตอนนี้อยู่บนมือถือ เลยตั้งใจว่าจะลองบนเดสก์ท็อปเร็ว ๆ นี้ สิ่งที่การวิเคราะห์ตกหล่นไปคือ ผู้คนต้องการ “แชร์ง่าย” และ “ไม่มีค่าใช้จ่าย” การสร้างตัวแอปเองนั้นง่ายแม้ในสภาพแวดล้อมขั้นต่ำ แต่ปัญหาคือการแจกจ่าย (ด่าน App Store) และการโฮสต์ จนแม้แต่ครอบครัวหรือคนรู้จักก็ยังลังเลจะจ่ายเดือนละ 5 ดอลลาร์ ที่จริงนักพัฒนามืออาชีพก็เป็นแบบเดียวกัน

  • self-host ที่บ้านด้วยเว็บเซิร์ฟเวอร์ + dynamic DNS ก็ได้
  • ฉันชอบแนวคิดเรื่องการแชร์ไอเดีย แต่โฮสต์หรือแจกจ่ายฟรีก็มีความเสี่ยงจะถูกผู้ใช้ไม่หวังดีนำไปใช้ในทางที่ผิด

• เห็นการพูดถึงแนวคิดทำนองว่า “คอมพิวเตอร์ควรทำงานเพื่อผู้คน และควรเป็นกิจกรรมของทุกคนเหมือนการทำอาหารหรือการใช้เวิร์ดโปรเซสเซอร์” แล้วรู้สึกว่ามันกว้างเกินไป อีกอย่างประโยคแบบ “อัปเดตสดทั้งหมด ฟรีทั้งหมด LLM...” ที่ใส่ em-dash (-) เยอะเกิน ทำให้ฉันรู้สึกว่าเป็นข้อความที่ AI เขียน ส่วนตัวถ้าดูออกว่าเป็นคอนเทนต์จาก AI ความสนใจก็จะลดลงทันที ไม่ได้โทษคนทำหรอก แต่ฉันก็ไม่ค่อยสนใจถ้อยคำโฆษณาแบบนี้เหมือนกัน

  • สไตล์ใช้ em-dash แบบนี้เป็นวิธีเขียนในชีวิตจริงของฉันมา 10–15 ปีแล้ว ฉันเองก็ไม่ค่อยชอบเสพคอนเทนต์ที่ AI สร้าง และถ้าใครแค่พิมพ์พรอมป์ต์ให้มันทำ ฉันก็รู้สึกว่าสู้ไปถาม LLM เองตรง ๆ ไม่ได้
  • ถ้าว่ากันตามหลักการใช้ hyphen/en-dash/em-dash การใช้ em-dash เป็นตัวคั่นนั้นถูกต้องตามหลักเลย ฉันไม่เห็นด้วยที่จะมองว่านี่เป็นสัญญาณของ AI
  • ในฐานะผู้ร่วมสร้าง Scrappy ฉันเป็นผู้ใช้ Macintosh มานาน จึงแยก hyphen, en-dash และ em-dash ชัดเจน :) มีใช้ AI บ้างเป็นครั้งคราวเพื่อช่วยขัดเกลาข้อความเท่านั้น ไม่เคยใช้ให้มันสร้างข้อความเลย เพราะฉะนั้นฉันเขียนเองจริง ๆ และใช้แรงไปมาก (งานส่วนใหญ่จริง ๆ เป็นฝีมือ Pontus)
  • ถ้าจะพิมพ์ em dash ให้กด compose key แล้วตามด้วย hyphen สามครั้ง แบบนี้ — บน Mac คือ shift-option-hyphen