เว็บแอป HTML ล้วนแบบไฟล์เดียว พกพาได้ และอัปเดตอัตโนมัติ

 (hyperclay.com)
26 คะแนน โดย GN⁺ 2025-08-19 | 7 ความคิดเห็น | แชร์ทาง WhatsApp
  • Hyperclay รองรับการสร้างเว็บแอปในรูปแบบที่รวม UI, ลอจิก และข้อมูลทั้งหมดไว้ใน ไฟล์ HTML เดียว
  • สามารถ แก้ไขได้ทันทีและแชร์แบบเรียลไทม์ ได้จากตัวไฟล์เอง พร้อมควบคุมทั้งหน้าตา การทำงาน และวิธีแก้ไขของแอปได้โดยตรง
  • มอบโครงสร้างแบบ รันและบันทึกได้ทันที โดยไม่ต้องมี ขั้นตอน build/deploy แยกต่างหาก, ฐานข้อมูล หรือแบ็กเอนด์ที่ซับซ้อน
  • ใช้ไฟล์ HTML เพียงไฟล์เดียวเพื่อ รันแอปได้ทุกที่ ไม่ว่าจะเป็นบนเบราว์เซอร์ เซิร์ฟเวอร์ หรือออฟไลน์ และทุกการเปลี่ยนแปลงจะถูกจัดการเวอร์ชันและกู้คืนได้
  • ออกแบบมาเพื่อลด ความซับซ้อนของการพัฒนาเว็บสมัยใหม่ และทำให้ใครก็สร้างแอปอินเทอร์แอกทีฟที่มีชีวิตแบบเรียลไทม์ได้อย่างง่ายดาย

แนะนำ: Hyperclay เว็บแอปมีชีวิตที่สร้างจากไฟล์ HTML เพียงไฟล์เดียว

  • Hyperclay มอบประสบการณ์ให้โปรแกรมเมอร์สร้างเว็บแอปราวกับการปั้นผลิตภัณฑ์ ด้วย ไฟล์ HTML แบบพกพา เพียงไฟล์เดียว โดยไม่ต้อง จัดการอินฟราสตรักเจอร์ที่ซับซ้อน
  • ตั้งเป้าตัดทอนองค์ประกอบที่เคยเป็นสิ่งจำเป็นในการพัฒนาเว็บแบบเดิม เช่น ไฟล์ตั้งค่า, build, framework, deployment pipeline ให้เหลือโครงสร้างที่สมบูรณ์ได้ด้วยไฟล์เพียงไฟล์เดียว

แนวคิดหลักและข้อดี

  • แอปประกอบด้วย ไฟล์ HTML ไฟล์เดียว
  • สามารถแก้ไขตัวไฟล์เองแบบเรียลไทม์ผ่าน visual UI และสิ่งที่แก้ไขจะถูก บันทึกถาวรเป็นสถานะของแอป ทันที
  • ทั้ง UI, ลอจิก และข้อมูลถูกรวมไว้แบบไดนามิกภายในไฟล์เดียว
  • ผู้ใช้สามารถ แก้ไขแอปได้ทันทีเหมือนเอกสาร และแชร์/ดาวน์โหลดการเปลี่ยนแปลงเพื่อนำไปใช้งานแบบออฟไลน์ได้ทันที
  • เปรียบได้กับ "Google Docs for interactive code" ที่ให้ทั้งการแชร์ การแก้ไข และการควบคุมความเป็นเจ้าของได้อย่างอิสระ

สรุปฟีเจอร์หลัก

  • Direct manipulation: แก้ไขได้ทันทีระหว่างที่แอปกำลังทำงาน การเปลี่ยนแปลงมีผลในทันทีโดยไม่ต้องคอมไพล์หรือรีเฟรช
  • What you see is what you build: ไม่ว่าจะปรับ UI หรือแก้ซอร์สโค้ดโดยตรง แอปจะเปลี่ยนตามทันทีโดยไม่มีชั้นกลาง
  • การพกพาอย่างแท้จริง: ส่งออกแอปเป็นไฟล์ HTML เพื่อรันแบบเดียวกันได้ทุกที่ (ทั้งบนเซิร์ฟเวอร์และออฟไลน์) และทุกครั้งที่บันทึกจะมีการจัดการเวอร์ชันเพื่อให้กู้คืนได้
  • ทั้งหมดนี้เกิดขึ้นได้ โดยไม่ต้องใช้เทคโนโลยีพิเศษใด ๆ ใช้เพียงไฟล์ HTML มาตรฐานแค่ไฟล์เดียว
โฆษณา

โครงสร้างทางเทคนิค

  • Hyperclay ประกอบด้วย NodeJS server และ ไลบรารี JS ฝั่งไคลเอนต์
  • เมื่อหน้า HTML แก้ไข DOM ของตัวเอง ระบบจะส่ง document.body.outerHTML ที่เปลี่ยนแล้วกลับไปยังเซิร์ฟเวอร์ และไฟล์ HTML นั้นเองจะถูกอัปเดต
  • การเปลี่ยนแปลงภายในแอป เช่น คุณสมบัติ checked ของ checkbox จะถูกบันทึกถาวรลงในโค้ด HTML ทำให้เมื่อเข้าถึงครั้งถัดไปก็สามารถจำลองสถานะเดิมได้
  • รองรับ การจัดการเวอร์ชัน และ การจัดการสิทธิ์อ่าน/เขียน

ตัวอย่างการใช้งานจริง

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

ที่มาและปัญหาที่ต้องการแก้

  • จากการสร้างเว็บไซต์หลายสิบแห่งในแต่ละปี จึงเกิดความต้องการว่า ถ้าการเขียนเว็บแอปเป็นธรรมชาติเหมือนการเขียนข้อความก็คงดี
  • เว็บไซต์แบบสแตติกดั้งเดิมมีข้อจำกัดตรงที่การเปลี่ยนแปลงเป็นสิ่งชั่วคราว (การกระทำของผู้ใช้ไม่ถูกบันทึก)
  • หากต้องการทำ data persistence บนเว็บ มักต้องใช้ความพยายามมากเกินไป เช่น การสร้างฐานข้อมูล, API, template และระบบบัญชีผู้ใช้
  • จึงไม่มีประสิทธิภาพสำหรับความต้องการแบบ อยากสร้างเร็ว แก้ไขแบบเรียลไทม์ และแชร์ได้ทันที เช่น prototype, เครื่องมือง่าย ๆ, บันทึกการพัฒนาส่วนตัว หรือบล็อก

วิธีที่ Hyperclay ใช้แก้ปัญหา

  • รวม UI, สถานะ และพฤติกรรมไว้ในไฟล์ HTML ไฟล์เดียว
  • เปิดใช้งานและแก้ไขได้อย่างง่ายดายเหมือนเปิดแอปเดสก์ท็อป พร้อมสะท้อนผลลัพธ์ขึ้นออนไลน์ได้ทันที
  • นำเสนอแนวคิดของวัตถุดิจิทัลแบบคงอยู่ (shared, cloneable, persistent)
  • สามารถประยุกต์ใช้กับเครื่องมือหลากหลาย เช่น website builder, เครื่องมือเอกสาร/ไดอะแกรม/พรีเซนเทชัน, dashboard, blog, การสร้างแบบสอบถาม/ควิซ และ data visualization
โฆษณา

สรุปแนวคิดทั้งหมด

  • เว็บแอปส่วนใหญ่ใช้ HTML อยู่แล้ว
  • หากตัดขั้นตอนกลางออกไป ไฟล์ HTML จะทำหน้าที่เป็น ฐานข้อมูล / API / UI ทั้งหมด ทำให้สแตกเรียบง่ายเหลือเพียงไม่กี่บรรทัด
  • นักพัฒนาสามารถลดความซับซ้อน และสร้างแอปที่ใช้งานง่ายและดูแลรักษาได้ดีด้วย โค้ดเพียงเล็กน้อย

ตัวอย่างการใช้ Hyperclay

  • ไม่ว่าจะเป็นบล็อก เช็กลิสต์ หรือแอปประเภทใด ก็สามารถเขียน เผยแพร่ แชร์ และแก้ไขได้ด้วย HTML เพียงไฟล์เดียว
  • ใช้งานได้ทันทีในรูปแบบ `내 블로그!

` และใช้ `` เพื่อบันทึกแต่ละสถานะลงในเอกสารถาวร

บทสรุป

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

บทความที่เกี่ยวข้อง

7 ความคิดเห็น

 
bobross0 2025-09-03

น่าสนใจดีนะ
 
aobamisaki 2025-08-21

ดูคล้ายกับหลักการทำงานของเว็บเอดิเตอร์ที่เคยมีอยู่ดาษดื่นเมื่อก่อน แต่สิ่งที่น่าสนใจคือมันทำงานได้ด้วยไฟล์ HTML เพียงไฟล์เดียว สำหรับผมแล้วมันก็ดูเหมือนจะเป็น Proof-of-Concept แบบหนึ่งเหมือนกัน แต่พูดตามตรงก็อดสงสัยไม่ได้ว่าถ้านำสิ่งนี้ไปประยุกต์ใช้ได้ดีแล้วจะออกมาเป็นอย่างไร
 
ifmkl 2025-08-20

วิธีการทำงานของอันนี้ก็เหมือนกับวิธีทำงานของตัวแก้ไขที่เคยโพสต์ไว้ก่อนหน้านี้ที่ https://th.news.hada.io/topic?id=19611 เลยไม่ใช่เหรอครับ? ฝั่งผมก็เอาอันนี้ไปติดแบ็กเอนด์ง่าย ๆ ด้วย nodejs บนเซิร์ฟเวอร์เพื่อทำ self-hosting ให้บันทึกโพสต์ที่เขียนจากตัวแก้ไขได้ แล้วก็เพิ่มฟังก์ชันอีก 2 อย่างคือโหลดรายการมาแสดงใน index.html เลยใช้เป็นบอร์ดบล็อกแบบง่าย ๆ อยู่ พอลองดูแล้วก็ให้ความรู้สึกว่าเหมือนกันเลยครับ
 
reagea0 2025-08-19

น่าสนใจดีนะ!
อยากรู้จริง ๆ ว่าความปลอดภัยจะเป็นยังไง
 
m00nlygreat 2025-08-19

ไอเดียน่าสนใจดีนะ tiddlyWIki ก็สนุกดีเหมือนกัน
 
developerjhp 2025-08-19

น่าสนใจนะ..
 
GN⁺ 2025-08-19
ความคิดเห็นบน Hacker News
  • Hyperclay สามารถทำให้หน้า HTML อัปเดต DOM และคงความทันสมัยของหน้าไว้อย่างต่อเนื่องได้ผ่านเซิร์ฟเวอร์ NodeJS และไลบรารี JS ฝั่งฟรอนต์เอนด์ โดยแทนที่ซอร์ส .html ที่เปลี่ยนไป
    ตัวอย่างเช่น เมื่อคลิก checkbox ก็จะมีการเพิ่มแอตทริบิวต์ checked แล้วนำ document.body.outerHTML ในสถานะนั้นไปเก็บแบบโกลบอลด้วย Hyperclay เพื่อให้ครั้งหน้าที่เข้ามายังสะท้อนสถานะเดิม
    ยังรองรับการจัดการเวอร์ชันอัตโนมัติและการจัดการสิทธิ์อ่าน/เขียนด้วย
    คิดว่าน่าจะมีประโยชน์ที่สุดเมื่อบทบาทนักพัฒนากับผู้แก้ไขคอนเทนต์เป็นคนเดียวกัน เพราะถ้ามีผู้แก้ไขหลายคนใช้งานพร้อมกันก็อาจเขียนทับการเปลี่ยนแปลงกันได้
  • ถ้าจำเป็นต้องมีเซิร์ฟเวอร์ NodeJS ก็รู้สึกสับสนว่าแบบนี้คงไม่ใช่ไฟล์ HTML แบบ self-contained ล้วน ๆ อย่างสมบูรณ์
  • เพิ่มเนื้อหานี้เข้าไปในหน้าแรกของเว็บไซต์ตามเดิมแล้ว
    อ้างอิงด้วยว่าตอนนี้กำลังทำวิธีสำหรับ push "DOM-based schema migration" ไปยังทุกแอปที่นักพัฒนา fork ออกไป
  • ได้ยินมาว่าได้แรงบันดาลใจจาก TiddlyWiki เลยสงสัยว่าแก่นของ TiddlyWiki เดิมทีไม่ใช่โครงสร้างที่ไม่ต้องมีเซิร์ฟเวอร์หรือ
    เอาเข้าจริงพอทำเว็บแอปง่าย ๆ ไปสักพักก็มักจะถึงจุดที่ต้องมีเซิร์ฟเวอร์อยู่ดี แต่แนวทางแบบไร้เซิร์ฟเวอร์กับการผูกกับเซิร์ฟเวอร์ก็ดูขัดกันนิด ๆ
    ถึงอย่างนั้นข้อดีก็คือการเข้าถึงข้ามอุปกรณ์ดีขึ้น และน่าจะทำให้แก้ไขออนไลน์ง่ายขึ้น
    สำหรับฉันจะใช้ text editor บนมือถือแล้วซิงก์ไปแล็ปท็อปผ่านแอปซิงก์
  • อยากให้เว็บสแตนดาร์ดรองรับหน้าไฟล์โลคัลที่รันผ่านโปรโตคอล file:// ได้ดีกว่านี้
    ทุกครั้งที่ทำมินิแอป HTML/Vue แบบง่าย ๆ ก็จะเจอปัญหาหลายอย่างจนต้องหาทางเลี่ยงตลอด
    เช่น ไฟล์ HTML โลคัล import JS module โลคัลไม่ได้ หรือเปิดไฟล์โลคัลอื่น ๆ (เช่นเสียง) ไม่ได้
    เข้าใจว่าต้องมีข้อจำกัดเพื่อกันการเข้าถึงแบบสะเปะสะปะ แต่ถ้ามีวิธีอนุญาตผ่านการระบุนามสกุลหรือไดเรกทอรีก็น่าจะดี
    การต้องเปิดเว็บเซิร์ฟเวอร์ทุกครั้งทั้งยุ่งยากและดูเกินจำเป็นเกินไป แบบแค่พิมพ์ URL แล้วแอปทำงานได้เลยน่าจะดีที่สุด
    • ข้อจำกัดใหญ่ของเว็บแอปประเภทตัวสร้างคือมีแค่หน้าที่โหลดผ่าน HTTPS เท่านั้นที่ใช้ Clipboard API ได้ ดังนั้นบน file:/// ฟังก์ชันคัดลอกจะไม่ทำงาน
      ต่อให้เป็นแอปออฟไลน์สมบูรณ์ที่ไม่มี build/ไม่มี dependency ก็ยังติดข้อจำกัดนี้ จนต้องใช้ text area แทนปุ่ม ทำให้ยุ่งยาก
      ถ้าจะรันโลคัลเซิร์ฟเวอร์ก็ใช้ VS Code devcontainer ให้เปิดเซิร์ฟเวอร์อัตโนมัติได้ และเพิ่มคำสั่งอีกนิดก็ทำ HTTPS ในเครื่องได้ด้วย
    • เมื่อก่อนบน Windows มีแนวทาง HTA ซึ่งเป็นไฟล์ HTML ที่ใช้นามสกุลต่างออกไป มีสิทธิ์เข้าถึงไฟล์ซิสเต็มโดยไม่มีเมนูเบราว์เซอร์
      แม้ด้านความปลอดภัยจะเปราะบาง แต่ทุกวันนี้เวอร์ชันสมัยใหม่ที่ใช้ Electron และเข้าถึงโฟลเดอร์หรือ sqlite db ได้บ้างก็น่าจะยังใช้งานได้ดี
      อีกทางเลือกคือ wasm app builder อย่าง Orca ที่ให้แค่ canvas โดยไม่มีเบราว์เซอร์หรือ DOM
    • แม้จะเข้าใจความเสี่ยงของไฟล์ HTML โลคัล แต่ก็อยากให้เบราว์เซอร์มีโหมด "ออฟไลน์เท่านั้น" ที่แยกไฟล์ซิสเต็มโลคัลออกจากหน้าเพจภายนอกได้
      ถึงจะไม่ใช่คำตอบที่สมบูรณ์ แต่ก็น่าจะมีประโยชน์มากพอ เพราะทำให้ใช้เบราว์เซอร์เป็นโลคัลเซิร์ฟเวอร์แบบจำกัดขอบเขตได้อย่างเรียบง่ายและตรงไปตรงมา
    • เคยไม่พอใจอยู่บ้างที่ HTML ถูกเริ่มล็อกให้เป็นแพลตฟอร์มโลคัลน้อยลง
      ถึงอย่างนั้นเสียง, JavaScript ฯลฯ ก็ยังทำงานได้ในระดับหนึ่ง และการเปิดเว็บเซิร์ฟเวอร์เองก็ทำได้ทันทีด้วย python/node จึงไม่ได้ยากมากนัก
      แค่เพิ่มคำสั่ง webserver_here ในเทอร์มินัลหรือเปิดค้างไว้ก็พอ
      กลับกันยิ่งรู้สึกว่า HTML โลคัลมีความเสี่ยงมากขึ้นจนอยากได้ขอบเขตที่เข้มงวดกว่าเดิม
    • ไม่นานมานี้ก็เคยคิดเรื่องคล้ายกันใน ที่นี่, ที่นี่
      ตอนนี้มีแค่ localStorage กับการ export/import ด้วยมือเท่านั้นที่เป็นทางออก
      ได้ไอเดียจาก Hyperclay เลยสนใจแนวคิดแอป Electron ที่ติดตั้งครั้งเดียวแล้วโหลดมินิแอปได้หลายตัวแบบ Electron Fiddle
  • อยากรู้วิธีทำงานเชิงเทคนิคของ Hyperclay
    ว่าเป็นแค่เรื่อง localStorage หรือว่าใช้ FileSystemAPI เขียนทับไฟล์โดยตรงกันแน่ รายละเอียดกลไกการทำงานยังอธิบายไม่พอ
    และก็สงสัยด้วยว่าตอนผู้ใช้บันทึกจะสะท้อนผลอัตโนมัติโดยไม่ต้องมีไดอะล็อก "บันทึกเป็น" หรือไม่
    • Hyperclay มีสองรูปแบบ
      1. โฮสต์เอง: แอป HTML หลายตัวเรียก /save endpoint ของตัวเองเพื่อบันทึกและเขียนทับ HTML (มี backup/การจัดการเวอร์ชันให้)
      2. โลคัล: ดาวน์โหลดโอเพนซอร์ส Hyperclay Local(ลิงก์) มารันเองส่วนตัว และก็เรียก /save endpoint เพื่อทำ backup ได้เช่นกัน รวมถึงโฮสต์บนเซิร์ฟเวอร์ที่ปรับแต่งเองได้ (แค่ต้องทำ auth เอง)
    • อืม ถ้าขยับไปอีกขั้น มันก็คล้าย PHP ที่เติมไวยากรณ์ฝั่งเซิร์ฟเวอร์ หรือ WordPress ในเชิงแก่นแท้ไม่ใช่หรือ
      รู้สึกว่าเมื่อระบบเริ่มแตกแขนงหลายชั้นก็ยิ่งซับซ้อนขึ้น และกลายเป็นวงจรที่เพิ่มภาระมากกว่าปรับปรุงอะไรจริง ๆ
    • การจัดวางข้อความว่า "ไม่สนเสียงรบกวนของการพัฒนาเว็บสมัยใหม่ แล้วสร้างประสบการณ์ที่ฉันต้องการ" ที่ปะปนอยู่ระหว่างข้อความสั้น ๆ กับภาพมีม ทำให้รู้สึกแปลกนิดหน่อย
      ประสบการณ์ที่ฉันต้องการคือคำอธิบายแกนหลัก เรื่องราวต่อเนื่องเบื้องหลัง และแผนภาพที่มีเฉพาะส่วนจำเป็นเท่านั้น
    • มี DB อยู่บนเซิร์ฟเวอร์ และเก็บ HTML
      นั่นคือไม่ได้อิง JSON แบบเก็บเฉพาะการเปลี่ยนแปลง แต่เหมือนเก็บ snapshot ของ HTML ทั้งก้อนในแต่ละช่วงเวลา
    • เท่าที่เข้าใจคือไฟล์ HTML เองถูกอัปเดต
      การเปลี่ยนแปลงของ form, แอตทริบิวต์, tag ฯลฯ ถูกสะท้อนลงในซอร์ส HTML โดยตรง
  • ให้ความรู้สึกเหมือนกลับเข้าใกล้วิสัยทัศน์ดั้งเดิมของ WWW อีกครั้ง
    เว็บเบราว์เซอร์ยุคแรก ๆ (แอปของ Tim Berners-Lee สำหรับ NeXT) ก็มีความสามารถด้านการแก้ไขรวมอยู่ด้วย
    เหตุผลที่การแก้ไข HTML บนเว็บหายไปในยุคแรกคือ
    1. ไม่มีเมธอด HTTP PUT จึงบันทึก HTML ที่แก้แล้วกลับขึ้นเว็บไม่ได้ ทำได้แค่บันทึกโลคัล
    2. เบราว์เซอร์อย่าง Mosaic ถูกเผยแพร่โดยตัดฟังก์ชันแก้ไขออกเพราะเหตุผลด้านความซับซ้อน ฯลฯ จนทิศทางการใช้งานของมหาชนเปลี่ยนไป
    • เว็บที่อ่าน/คอมเมนต์/เขียนได้ คือภาพของเว็บที่เฝ้าหวังมานานมาก
      การทำ toolkit เฉพาะของแต่ละหน้าแบบ Hyperclay ก็น่าสนใจ แต่สิ่งที่พึงปรารถนาจริง ๆ คือมีเครื่องมือมาตรฐานที่ใช้ได้ทุกที่ในระดับเบราว์เซอร์ (user agent)
    • W3C เคยดูแลเว็บเอดิเตอร์ชื่อ Amaya อยู่กว่าสิบปี
      คิดว่าเป็นไอเดียที่ดีและทำหน้าที่เป็น testbed ได้ยอดเยี่ยม
      น่าเสียดายที่หายไป แต่ก็สอดคล้องกับวิสัยทัศน์เริ่มต้นอย่างชัดเจน
    • ในบริบทช่วงแรกของ TBL (Tim Berners-Lee) การบันทึกโลคัลก็คือการบันทึกบนเว็บ
      บนเวิร์กสเตชันของมหาวิทยาลัยมีการใช้ network share อย่าง NFS ทำให้ไฟล์ถูกเก็บแบบเปิดเผยจริงและเข้าถึงได้ผ่านที่อยู่เครื่องเดิม
      บนเวิร์กสเตชัน SGI ถ้าตั้งค่าเครือข่ายเสร็จก็ใช้งานได้สมบูรณ์ทันที
      อีกทั้งจุดโฟกัสของเว็บคือการจัดโครงสร้างข้อมูล และเนื้อหาสำคัญกว่ารูปลักษณ์ภายนอก
      พอเวลาผ่านไปก็เริ่มหมกมุ่นกับโมเดล WYSIWYG และการใช้ table/div เกินจำเป็นจนค่อย ๆ ห่างจากเจตนาเดิม
      การออกแบบให้เรียบง่ายจนใครก็เข้าใจได้นั้นยากมาก แต่ตอนนี้เว็บกลายเป็นโครงสร้างที่ซับซ้อนพอสมควรซึ่งมีผู้เชี่ยวชาญเพียงกลุ่มเล็ก ๆ ที่เข้าใจ
      น่าเสียดายที่ HTML ซึ่งยังเขียนได้ง่าย กลับกลายเป็นเทคโนโลยีเฉพาะทางซับซ้อนในงานพัฒนาสมัยใหม่
      ดูเหมือนจะเหลือคนเพียงไม่กี่คนที่เข้าใจบริบทที่ TBL ตั้งใจไว้แต่แรกอย่างแท้จริง
    • สำหรับประเด็น "เว็บเบราว์เซอร์ก็เป็นเอดิเตอร์"
      ทุกวันนี้เบราว์เซอร์ล้วนแก้ HTML/JS/CSS แบบสด ๆ ได้ผ่าน developer tools จึงอดคิดไม่ได้ว่าทุกตัวก็เป็นเอดิเตอร์อยู่แล้วไม่ใช่หรือ
      เลยสงสัยว่าคนอื่นไม่ใช้ devtools กันหรือว่าใช้แต่ React หรือ TS แทน vanilla JS/HTML
      ตระกูล Chrome, Firefox และ Safari ต่างก็มีฟังก์ชันระดับ IDE ฝังมาในเบราว์เซอร์จนเขียนโค้ดตรงนั้นได้เลย
  • พอลองดู Hyperclay แล้วเหมือนเป็นโครงสร้างที่ใช้ DOM (virtual DOM)
    ถ้ามีการเพิ่มแนวนโยบายและคำชี้แจงทางกฎหมายแบบสไตล์ Shopify ก็น่าจะยิ่งดี
    ถ้าดู HN profile ของฉันจะเข้าใจว่าทำไมถึงคิดว่านี่เจ๋ง แต่ก็ยังรู้สึกว่าต้องมีส่วนด้านกฎหมายประกอบ
  • เคยลองใช้วิธีคล้ายกันกับไฟล์เซฟเกม
    บรรทัดแรกเป็นรูปแบบ <!DOCTYPE html><html><head><script>const rawData = และบรรทัดที่สองเก็บสถานะทั้งหมด
    พอกดปุ่มบันทึกก็จะเอา document.documentElement.outerHTML มา แล้วเปลี่ยนบรรทัดที่สองให้เป็นสถานะล่าสุดก่อนดาวน์โหลด
    ทำงานได้โดยไม่ต้องมีเซิร์ฟเวอร์
    โค้ดที่เกี่ยวข้อง
    • บน Chrome สามารถสร้างบุ๊กมาร์ก data: URL ด้านล่าง แล้วเปิดเอดิเตอร์สไตล์ notepad ไว้ในแท็บหนึ่งได้ ถ้าไม่ปิดแท็บ state ก็จะคงอยู่ 
      data:text/html,<html><head><title>Notepad</title><style>html,body{margin:0;padding:0;}textarea{padding:10px;font-family:Courier;font-size:16px;height:100%;width:100%;border:none;outline:none;}</style></head><body><textarea style="height:100%;width:100%;font-size:16px;padding:10px;"></textarea><script>document.getElementsByTagName('textarea')[0].focus()</script></body></html>
    • ฉันก็เคยทำคล้ายกัน เป็นเกมที่ทำงานด้วยไฟล์ HTML เดียว
      หลังแก้ข้อความแล้วสามารถบันทึกเป็นเวอร์ชันโลคัลใหม่ได้
      บน Android + Brave ใช้งานได้ดี แต่บน iOS + Safari ยังไม่รองรับ
  • TiddlyWiki ก็เป็นเครื่องมือในสายนี้ที่มีประวัติยาวนานกว่า 20 ปี
    Hyperclay ดูเหมือนจะเน้น multi-user/Multi-tenancy และ persistence ที่อิง DB มากกว่า
    TiddlyWiki ก็น่าเอาไปดูประกอบ
  • ดูเหมือนเป็นโปรเจกต์ประเภทที่มีคนไปขุด archive ของ Windows 98 HTA กลับมาพบอีกครั้ง
    HTA wiki
    • HTA ให้อารมณ์เหมือน Electron ต้นฉบับ
      เพียงแต่ในสภาพแวดล้อม IE สมัยก่อน การดีบักนั้นโหดร้ายมาก
    • HTA เป็นเทคโนโลยีที่ทั้งดีและน่ากลัวในเวลาเดียวกัน แถมมาก่อนยุคของมัน
      มันดูเหมือนหน้าเว็บธรรมดา แต่เป็นของ IE เท่านั้น และยังมีสิทธิ์รัน local process ได้อีก
      ปัญหาอยู่ที่การจัดการ persistence และความคล้ายกันก็มีอย่างจำกัดมาก
    • ก่อนหน้านั้น Outlook Web Access ก็ดูเหมือนจะทำหน้าที่คล้าย ๆ กัน
      Outlook on the web
    • ฉันก็คิดเหมือนกันเป๊ะจนเกือบจะเข้ามาคอมเมนต์แบบนี้อยู่แล้ว
  • คิดว่าเป็นไอเดียที่ไม่เหมือนใครและอยากลองทำสักครั้งในอนาคต
    พอดูเว็บไซต์แล้วก็ชอบภาพรวมอยู่มาก แต่ในทางปฏิบัติยังสงสัยว่าข้อจำกัดจะเริ่มโผล่ตรงไหน
    ด้านความปลอดภัย: ถ้าฉันแก้หน้าได้ คนอื่นก็ทำได้ด้วยไหม? จัดการสิทธิ์กันอย่างไร?
    ถ้าโค้ดหรือโลจิกเยอะขึ้น จุดไหนจะเริ่มดูแลยาก? ถ้าปริมาณข้อมูลเพิ่มขึ้นจะเป็นอย่างไร?
    เช่น ถ้าฉันทำแอปจัดการเบียร์ คนอื่นจะคัดลอกเฉพาะตัวแอปไปใช้แยกจากข้อมูลของฉันได้ไหม
    • ความปลอดภัย: ใช้ trust model เดียวกับเว็บบิลเดอร์แทบทั้งหมดอย่าง SquareSpace
      ผู้ใช้สามารถเปลี่ยนเว็บไซต์ของตัวเองได้อย่างอิสระ
      ถ้าผู้ใช้ละเมิดความไว้วางใจ ก็จะมีผลต่อสิทธิ์เข้าถึงบัญชีแบบเสียเงิน และต้องรับผิดหากสร้างความเสียหายให้ผู้อื่น
    • สิทธิ์การแก้ไข: ใครก็ตามที่สร้างแอปสามารถแก้ไขได้
      ถ้าเปิดฟังก์ชัน "signups" ผู้ใช้อื่นก็ fork แอปได้ง่าย และติดตามกลับไปยังต้นฉบับได้
      ตอนนี้กำลังทำฟังก์ชัน push อัปเดตไปยังแอปที่ fork ออกไปด้วย
    • ความยากในการบำรุงรักษา: Pieter Levels แห่ง NomadList ก็ยังรันแอปที่ทำรายได้เดือนละ $60k ด้วย index.php ไฟล์เดียว ดังนั้นสุดท้ายคงอยู่ที่การจัดระเบียบโค้ดและการรับมือกับส่วนที่ไม่จำเป็นมากกว่า
    • คนอื่นสามารถ fork แอปแล้วใช้งานโดยเก็บเฉพาะข้อมูลของตัวเองได้
      ในอนาคตมีแผนเพิ่มฟังก์ชัน collaboration แต่ตอนนี้เหมาะกับผู้ใช้คนเดียวที่สุด
  • ไอเดียนี้ให้ความรู้สึกสดใหม่
    โปรเจกต์ Webstrates ก็ทดลองเรื่องคล้ายกันอยู่
    พวกเขาใช้ DOM เป็น persistence layer เพื่อสร้างซอฟต์แวร์ทำงานร่วมกันสำหรับกลุ่มเล็ก ๆ โดย Hyperclay ต่างออกไปตรงที่นำกลไกนี้มาใช้กับหน้าเว็บแบบดั้งเดิมโดยตรง
    ระยะหลังยังมีการลองแนวทาง local-first อย่าง MyWebstrates ด้วย
    เลยสงสัยว่า Hyperclay จะรองรับการแก้ไขแบบออฟไลน์ผ่าน Webworker ได้ไหม
    • Clemens ฉันเป็นคนหนึ่งที่ประทับใจ Webstrates มาก
      เพิ่งมารู้จักตอนคิด Hyperclay เมื่อปีที่แล้ว
      อยากทำ Hyperclay เวอร์ชัน local-first มากจริง ๆ และคิดว่าการแก้ไขออฟไลน์คือเสาหลักของซอฟต์แวร์ส่วนบุคคล
      ถ้าสะดวก อยากชวนคุยแลกเปลี่ยนความเห็นผ่านวิดีโอคอลไหม