3 คะแนน โดย GN⁺ 2023-11-17 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • ความรู้สึกหลังได้ลองเดโม Make Real ของ TLDraw
  • เครื่องมือที่ใช้ AI เปลี่ยนภาพวาดให้เป็นซอฟต์แวร์ที่ทำงานได้
    • ใช้ GPT-4V ของ OpenAI เพื่อแปลงภาพเวกเตอร์เป็น HTML/TailWind CSS และ Javascript

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

 
GN⁺ 2023-11-17
ความคิดเห็นจาก Hacker News
  • Steve จาก tldraw เอง ขอโทษด้วยที่นี่เป็น โปรเจกต์ของเล่นที่มีแพตเทิร์นด้านความปลอดภัยแย่มาก ถ้าอยากรันในเครื่องหรือดูซอร์ส อยู่ที่นี่: https://github.com/tldraw/draw-a-ui
    ตัวอย่างอื่น ๆ ดูได้ที่ https://twitter.com/tldraw ถ้ามีคำถามเกี่ยวกับ tldraw หรือโปรเจกต์นี้ ผมตอบได้ นี่ไม่ใช่ของที่จะไปทำให้งานใครหายไป แต่เอามาเล่นแล้วสนุกจริง ๆ และมีตัวอย่างที่ซับซ้อนกว่านี้อยู่ที่นี่: https://twitter.com/tldraw/status/1725083976392437894

    • ควรปล่อยออกมาเลย นี่เป็น ผลิตภัณฑ์ที่ปิ๊งมาก จริง ๆ เก็บเงินเดือนละ $5 แล้วให้ผู้ใช้เอา OpenAI key ของตัวเองมาใช้ก็พอ
      มี license server ที่เพิ่งเปิดเป็น MIT license ด้วย เขียนด้วย Elixir และใช้รัน https://go.robocoder.app ถ้าต้องการความช่วยเหลือในการตั้งค่า ติดต่อมาได้: https://github.com/emcmanus/robocoder-server/
    • Steve จะให้ส่งเงินไปที่ไหน? ล้อเล่นนะ แต่เป็นของที่โน้มน้าวใจได้พอสมควร อาจเป็นของเล่นก็จริง แต่ทุกคนกำลังสนุกกับมันแบบนี้
    • โปรเจกต์เจ๋งมาก และยินดีกับการเปิดตัว ลองใส่ OpenAI key ของตัวเองแล้วเจอข้อผิดพลาด "you exceeded your current quota, check billing" เลยสงสัยว่าสมัคร OpenAI Pro ราคาเดือนละ $20 แล้วใช้ได้หรือเปล่า หรือว่าต้องมีสิทธิ์เพิ่มเติม
      คำตอบเจอใน GitHub README แล้ว เนื้อหาคือ “ถ้าจะใช้ API key ของตัวเอง ต้องมีสิทธิ์เข้าถึง usage tier 1 และให้ดู tier ปัจจุบันกับวิธีอัปเกรดใน OpenAI settings”
    • ตัวอย่างผังงาน นั่นแหละคือประเด็นสำคัญจริง ๆ และดูเหมือนว่าในเครื่องมือแบบนี้ควรถูก扱เป็นแนวคิดชั้นหนึ่ง มันเริ่มให้ที่จับสำหรับสร้างสิ่งที่มีประโยชน์ ไม่ใช่แค่ของเล่น
    • ตัวอย่างสุดท้ายสนุกดี และน่าทึ่งที่ให้ฟีดแบ็กแบบนั้นได้ สงสัยว่าถ้าเลือกแอปที่สร้างขึ้นพร้อมกับข้อความ มันรับอะไรเป็นอินพุตจริง ๆ ได้โค้ดที่สร้างก่อนหน้ารวมกับข้อความใหม่ไปด้วยหรือเปล่า?
  • system prompt ใน repository เป็นแบบนี้:

    You are an expert tailwind developer. A user will provide you with a  
    low-fidelity wireframe of an application and you will return  
    a single html file that uses tailwind to create the website.  
    They may also provide you with the html of a previous design that they want you to iterate from.  
    Carry out any changes they request from you.  
    In the wireframe, the previous design's html will appear as a white rectangle.  
    Use creative license to make the application more fleshed out.  
    if you need to insert an image, use a colored fill rectangle as a placeholder. Respond only with the html file.  
    

    ไม่ค่อยแน่ใจว่าทำไมถึงพูดถึง "creative license" ตรงนี้ ส่วน user prompt ในแต่ละครั้งที่สร้างจะเป็นแบบนี้:

    [IMAGE_LINK]  
    Turn this into a single html file using tailwind.  
    

    https://github.com/tldraw/draw-a-ui/blob/8a889bf36afc06fbb0c...
    ดูเหมือนว่าถ้าถ่ายสกรีนช็อตจากแคนวาส tldraw ปกติ แล้วส่งให้ API พร้อม prompt นี้ ก็ง่ายพอที่จะรันแบบ “ส่วนตัว” ได้

    • "creative license" ในภาษาอังกฤษทั่วไปหมายถึง อย่าไปกังวลกับข้อจำกัดมากนัก ให้ทำตามที่รู้สึกว่าดีที่สุด ดูไม่น่าจะเกี่ยวกับ license ของซอฟต์แวร์
  • ลองใส่โมเดลจากคำถามสัมภาษณ์ของ Facebook เข้าไป เป็นรายการ checkbox สองรายการกับปุ่มสองปุ่มสำหรับย้ายรายการที่ถูกติ๊กไปมาระหว่างกัน ซึ่งมันทำได้ถูกต้อง: https://gist.github.com/milesrichardson/2a2f77d4bfb19c3b28dc...

    • ไม่เคยรู้เลยว่า toList.appendChild(item.closest('li')); จะ ย้าย รายการได้ ได้เรียนรู้อะไรใหม่ทุกวันจริง ๆ
    • ลองตรวจด้วย screen reader แล้ว พอกดปุ่มไม่มีการประกาศอะไรเลย นี่เป็นปัญหา ควรพูดประมาณว่า “Checkbox B moved to the left”
      ถ้าไม่มีการแจ้งใด ๆ ผู้ใช้จะไม่รู้ว่าพอกดปุ่มแล้วมีอะไรเกิดขึ้นจริงหรือไม่ หน้าทดสอบ: https://output.jsbin.com/jixoqur/quiet
  • เดโมล่าสุดเหล่านี้แสดงให้เห็นว่า ความก้าวหน้าของแมชชีนเลิร์นนิง/AI ในช่วงหลังน่าประทับใจเพียงใด ขณะเดียวกันก็แสดงให้เห็นว่านักพัฒนาหลายล้านคนทั่วโลกยังคงต้องนำงานที่ซ้ำซากและมีความคิดสร้างสรรค์ต่ำกลับมาทำใหม่ซ้ำแล้วซ้ำเล่าแค่ไหน
    หน้าจอ UI ส่วนใหญ่สามารถอธิบายได้อย่างแม่นยำด้วยย่อหน้าหนึ่งหรือสองย่อหน้า ดังนั้นจึงไม่แปลกที่มันจะถูกแทนค่าได้ค่อนข้างละเอียดในเวกเตอร์ embedding ที่มีขนาดค่อนข้างเล็ก

    • ผมเห็นด้วยกับทิศทางใหญ่ ๆ แต่สิ่งสำคัญอีกอย่างคือเดโมส่วนใหญ่แบบนี้เป็น กรณีที่คัดสรรมาอย่างระมัดระวัง ถ้าดูแต่เดโมไวรัลบนโซเชียลมีเดีย ก็จะทำให้คิดว่า AI ก้าวหน้าในงานซับซ้อนไปไกลกว่าความเป็นจริงมาก
      โดยเฉพาะสายงานที่ไม่ใช่สายเทคนิคและไม่เคยใช้ AI อย่างหนักในงานจริงจะเปราะบางต่อเรื่องนี้ คนที่เจอในภาคสนามมักมองแบบมีรายละเอียดปลีกย่อยมากกว่า มันมีประโยชน์มากก็จริง แต่ก็ผิดพลาดบ่อย และถ้าจะให้ได้ผลลัพธ์ระดับ production ก็ต้องปรับแต่งอย่างละเอียด แม้ในฐานะคนที่มอง AI ในแง่ดี ผมก็คิดว่าคุณค่านั้นเป็นของจริง และเดโมที่น่าประทับใจก็ชี้ให้เห็นทิศทางที่เรากำลังไป แต่ยังต้องใช้เวลากว่าผลลัพธ์โดยเฉลี่ยจะไล่ทันความคาดหวังที่ถูกโหมเกินจริง
    • วิธีจำนวนมากในการถ่ายทอดไอเดียซอฟต์แวร์ก็ไม่มีประสิทธิภาพเอามาก ๆ เช่นกัน ส่วนที่น่าสนใจจริง ๆ หรือ เอนโทรปี นั้นมีอยู่น้อยมาก
      ในเดโมนี้พูดตรง ๆ ก็คือมีสไลเดอร์สองตัวไว้ปรับคุณสมบัติ CSS สองค่า ดังนั้นปริมาณข้อมูลในสเปก UI จึงไม่ได้มาก ถ้ามีภาษาสเปก UI ที่เหมาะสม ก็คงเป็นโค้ดสามบรรทัดเท่านั้น ความยากมาจากการต้องจัดการ boilerplate ของเว็บ UI
    • อธิบายได้ดีว่าทำไมผมถึงอึดอัดกับกระแสโฆษณาเกินจริงของ B2C AI ที่เกาะอยู่บนเดโมแบบ “Hello World” เป็นร้อย ๆ ตัว บรรยากาศประมาณ “พระเจ้า การเขียนโปรแกรมตายแล้ว!”
      สิ่งที่แปลกคือใน HN เวลาเราพูดถึงแพลตฟอร์ม no-code แบบดั้งเดิม ผู้คนมองเห็นข้อจำกัดด้านการขยายระบบและการบำรุงรักษาได้ง่าย แต่พอมี AI เข้ามา กลับเหมือนปัญหาเหล่านี้ถูกแก้ไปทันที และไม่ต้องกังวลกับสปาเกตตีที่กล่องดำคายออกมา
    • นี่แค่เผยให้เห็นว่า สแต็กซอฟต์แวร์ของเราโง่แค่ไหน ทุกอย่างขับเคลื่อนด้วยแนวคิดว่า “ก็เราอาจอยากปรับแต่งสิ่งนี้ สิ่งนั้น และรายละเอียดไร้สาระอีก 300 อย่างนี่นา”
      สิ่งที่ต้องการจริง ๆ คือการแยกฟังก์ชันออกจากการนำเสนอ บังเอิญว่าเว็บ HTML ล้วน ๆ ในปี 1996 เป็นแบบนั้นพอดี แล้วบางอย่างก็ผิดพลาดอย่างเลวร้ายด้วยวิธีที่โง่เกินจินตนาการ และไม่มีใครทำให้มันดีขึ้นเลย สิ่งที่เหลือกลับเป็นแค่เอฟเฟกต์เงาและ flexbox ภายใน
    • การที่งานซ้ำซากและมีความคิดสร้างสรรค์ต่ำถูกนำกลับมาทำใหม่ซ้ำ ๆ ไม่ใช่ปัญหาของนักพัฒนาเท่านั้น งานออฟฟิศส่วนใหญ่ ตั้งแต่การป้อนข้อมูล การบัญชี ไปจนถึงงานสร้างสรรค์ก็เข้าข่ายนี้
      งานออฟฟิศจำนวนมากคือการทำสิ่งเดิมซ้ำ ๆ และมักมีคนในบริษัทต่าง ๆ ทำงานที่โดยเนื้อแท้แล้วเหมือนกันซ้ำ ๆ กันอยู่
  • นี่ดูเหมือนเป็นเครื่องมือที่ทำให้นักออกแบบ UI หรืออาจรวมถึง product owner ดูฉลาดและมีความสามารถ แต่สุดท้ายงานจริงก็ยังจะถูกโยนไปให้นักโปรแกรมเมอร์เหมือนเดิม
    นักออกแบบ UI อาจให้ “เดโม” ได้ แต่ฟังก์ชันพื้นฐานนี้จะเชื่อมกับส่วนที่เหลือของแอปอย่างไร? ก็คงไม่เชื่อม

    • แน่นอนว่าจะนำไปสู่ บทสนทนาที่สนุกและมีประสิทธิผล แบบ “มันทำงานอยู่ตรงนั้นแล้วนี่! ทำไมเอาใส่แอปถึงใช้เวลานานขนาดนั้น? ดาวน์โหลดมาเฉย ๆ ไม่ได้เหรอ?”
      ก่อนยุค GPT ก็มีข้อเสนออยู่แล้วว่าโปรโตไทป์หรือม็อกอัปช่วงแรก ๆ ควรถูกทำให้ดูมีความสมบูรณ์ทางภาพต่ำตามระดับฟังก์ชันภายใน โปรโตไทป์เฉพาะ UI ที่สวยและดูเหมือน “ใช้งานได้” แม้จะอธิบายชัดเจนแล้ว ก็ยังสร้างความคาดหวังที่ไม่สมจริง และเพิ่มโอกาสที่โปรโตไทป์จะกลายเป็น production ไปเลย หรือ proto-duction
    • ผมไม่ชอบเวลานักออกแบบแสดง UI ที่ดูเหมือนผลิตภัณฑ์เสร็จสมบูรณ์ ใน Figma ในสายตาผู้บริหารมันดูเหมือนผลิตภัณฑ์ที่เสร็จแล้ว ทำให้ความคาดหวังที่ไม่สมจริงเข้ามาแทรกในกระบวนการออกแบบ UI ที่ควรเป็นแบบทำซ้ำปรับปรุง
      ผมเคยเห็นหลายโปรเจกต์ที่การออกแบบระบบแย่ ๆ ถูกโยนมาให้วิศวกรเพราะข้อจำกัดจากดีไซน์ Figma ที่ผู้บริหารบางคนอนุมัติ แน่นอนว่าองค์กรแบบนั้นก็มีปัญหาใหญ่กว่าอยู่แล้ว แต่การทำม็อกอัปความละเอียดสูงได้ง่ายทำให้ปัญหาแบบนี้แย่กว่าไวร์เฟรม
    • วิธีนั้นง่ายมาก แค่ให้พรอมป์ต์ใหม่กับ GPT-4: "Thanks. Please connect it to the rest of this code:"
      ถ้าอยากให้มันทำได้ดียิ่งขึ้น ก็เติม "it's very important for my career" เข้าไปด้วย
  • นักพัฒนาที่ทำเดโมขยายและหมุนกล่องดูท่าจะกำลังตกงานแล้ว

    • เฉพาะคนที่จัดสไลเดอร์ให้ตรงกันยังไม่ได้เท่านั้น
  • ระหว่างคุยกับลูกค้าเรื่องวิธีผสานซอฟต์แวร์ของเราเข้ากับซอฟต์แวร์ของลูกค้า ลูกค้าส่งสกรีนช็อตของฟอร์มหลักมาให้
    ผมเอาสกรีนช็อตนั้นใส่ใน ChatGPT แล้วบอกว่า “ช่วยทำฟอร์ม React แบบนี้ด้วย Bootstrap ให้หน่อย” หลังปรับแก้ไม่กี่อย่าง ผมก็ต่อซอฟต์แวร์ของตัวเองเข้าไป และไม่กี่ชั่วโมงต่อมาลูกค้าก็ประหลาดใจเมื่อเห็น proof of concept ที่ระบบถูกผสานได้รวดเร็วขนาดนี้ เวลามีปัญหาเลย์เอาต์ CSS ระหว่างพัฒนาเว็บ ผมมักอัปโหลดสกรีนช็อตไปให้ ChatGPT แล้วถามวิธีแก้ ซึ่งเดโมในทวีตก็ดูคล้ายกันทีเดียว

    • การทำหน้าฟอร์มพื้นฐานเดิมทีก็เรียบง่ายอยู่แล้ว สิ่งที่น่าประหลาดใจคือหลังจากพัฒนาเว็บมาราว 25 ปี เรายังคงสร้างเว็บเฟรมเวิร์กใหม่ ๆ และทำให้เรื่องนี้ซับซ้อนเกินจำเป็นต่อไป
      มีเฟรมเวิร์กออกมาเรื่อย ๆ ที่ยอดเยี่ยมกับกรณีใช้งานหวือหวา แต่หนักเกินไปสำหรับงานทั่วไปพื้นฐาน แม้จะมีข้อยกเว้นบ้างเป็นครั้งคราว แต่นักพัฒนาเว็บส่วนใหญ่ก็ไม่ได้ชอบของแบบนั้น มันไม่ได้ดูเท่ในเรซูเม่ด้วย และพูดตรง ๆ ใครกันจะอยากทำเว็บฟอร์มไปตลอดอาชีพ
    • ครั้งแรก ลูกค้าจะประทับใจกับความเร็ว ครั้งที่สอง เขาจะคาดหวังความเร็วนั้น ครั้งที่สาม เขาจะโกรธที่กำหนดการระเบิด เมื่อความต้องการขยายใหญ่เกินกว่าที่ ChatGPT จะรับมือไหว
    • ถ้าคุยกับลูกค้าทางอีเมลหรือแชต ก็ลองจินตนาการได้ว่าลูกค้าเองก็กำลังถาม ChatGPT ว่าจะถ่ายทอดความต้องการให้คุณได้ดีที่สุดอย่างไร
      สุดท้ายก็เป็นเต่าซ้อนเต่าอยู่ดี :+)
    • แต่ลูกค้าอาจไม่ได้ต้องการให้ข้อมูลของตัวเอง ถูกเปิดเผยต่อ ChatGPT ก็ได้
    • การอัปโหลดสกรีนช็อตปัญหาเลย์เอาต์ CSS ไปให้ ChatGPT ช่วยแก้ เป็นไอเดียที่เรียบร้อยดีซึ่งผมไม่เคยนึกถึง ปกติผมจัดการ CSS ได้ถึงขั้นแก้ใน developer tools แล้วค่อยย้ายสไตล์กลับไปไว้ในโค้ด แต่ก็ควรจำไว้
      สำหรับการโค้ด ผมใช้ ChatGPT มากกว่ากับการจัดการข้อมูลอย่างรวดเร็วผ่าน command-line pipe หรือ Bash script ให้มันดูผลลัพธ์ของคำสั่ง แล้วขอ Bash สำหรับจัดรูปแบบ รวบรวม จัดเรียง หรือดึงข้อมูลตามที่ต้องการ ทำให้งานอย่างการดีบักหรือการตรวจสอบสมมติฐานที่ปกติอาจไม่ได้ลองทำ กลายเป็นเรื่องง่ายขึ้น จะทำเองแบบแมนนวลก็ได้แต่ช้า และถ้าจะจำออปชันกับอาร์กิวเมนต์ก็ต้องค้นหาหรือเปิด man page ส่วนโค้ดผมใช้ GH Copilot เป็นหลัก
  • จะเรียกว่าเป็นพวกขี้สงสัยก็ได้ แต่ผมไม่เชื่อใน อนาคตของโซลูชัน no-code เลย ต้องจัดเรียงปุ่มให้เข้ากับความละเอียดหน้าจอของอุปกรณ์ขนาดเล็ก ต้องเว้นระยะให้ดูดีในภาษาอื่น ๆ และยังมีข้อกำหนดอื่น ๆ ตามมาเรื่อย ๆ
    อย่างมากก็คงช่วยให้สร้างแอปได้เร็วขึ้นด้วยภาษาที่มีระดับนามธรรมสูงขึ้นเท่านั้น วิธีนี้ใช้ได้กับสิ่งที่พื้นฐานมากและพบได้ทั่วไปอย่างเกม tic-tac-toe แต่ไม่เหมาะกับงานที่มีเอกลักษณ์เฉพาะ

    • ปัญหาใหญ่ของ no-code ที่ใช้ LLM คือผลลัพธ์เป็นแบบ ไม่กำหนดแน่นอน สุดท้ายจึงทำได้แค่เอาตัวผลลัพธ์เข้า version control เท่านั้น
      ลองนึกภาพว่ามีคนหลายสิบคนที่รู้เทคโนโลยีนิดหน่อยวาดสเก็ตช์ แล้วกด “ช่วยทำให้ใช้งานจริงที” เพื่อเพิ่มฟีเจอร์ แต่ละคนสร้างโค้ดออกมาหลายร้อยบรรทัด พอจบวันก็ต้องมีใครสักคนเข้าใจผลลัพธ์นั้นให้ได้ และเพราะผลลัพธ์ไม่กำหนดแน่นอน สิ่งที่เหลืออยู่กับเราก็มีแค่นั้น
    • คล้ายกับ Auto-Tune ช่างฝีมือที่ร้องเพลงให้ตรงคีย์ได้จะยังคงสร้างสิ่งที่น่าสนใจต่อไป
      ขณะเดียวกัน คนหน้าใหม่จำนวนมากกว่ามากที่ไม่เคยเรียนหรือไม่อยากเรียนวิธีร้องให้ตรงคีย์ ก็จะสร้างแนวเพลงใหม่เอี่ยมและเพลงป็อปกระแสหลักได้ด้วยแรงน้อยลงมาก ช่างฝีมือเองก็จะใช้มันบ้างเป็นครั้งคราวเพื่อเสริมบาง workflow เพิ่มความเนี้ยบ และเร่งความเร็ว
    • เดโมจำนวนมากในลักษณะนี้ไม่ได้พยายามผลักดันแนวทาง no-code ล้วน ๆ เท่าไรนัก แต่เหมือนกำลังแสดงให้เห็นว่าสามารถสร้าง wireframe ที่ใช้งานได้ แทบจะทันทีมากกว่า
      ดูเหมือนว่าเครื่องมืออย่าง Canva, Figma จะนำฟีเจอร์แบบนี้ไปใช้อย่างจริงจัง และช่วยยกระดับ wireframe กับเดโมแบบ high-fidelity ได้มาก
    • ความรู้สึกแรกก็เหมือนกัน การปรับแต่งและการเชื่อมระบบจะกลายเป็นฝันร้ายเต็มรูปแบบ แต่สำหรับ การทำ prototype แล้วถือว่ายอดเยี่ยม
    • LLM/AI จะต้องสมบูรณ์แบบขึ้น หรือไม่เราก็จะเริ่มใช้โค้ดและเฟรมเวิร์กที่ LLM/AI ใช้งานได้ง่ายกว่านี้มาก
  • Squarespace, Wix และบริการทำนองนี้ยึดตลาดระดับล่างไปแล้ว และถ้าไม่ใช่พวกนี้ งานนั้นก็คงตกไปอยู่กับการ outsource ไปอินเดีย
    นี่คือวิวัฒนาการตามธรรมชาติของแนวคิดเดียวกัน ถ้าผมเป็น product manager ของเว็บไซต์บิลเดอร์ คงรีบกระโดดเข้าไปทำ การผสาน AI builder แบบนี้ทันที มันไม่มีทางใช้ได้กับงานธุรกิจที่ซับซ้อนและแทบไม่ได้ถูกนิยามไว้อย่างชัดเจน แต่คงสร้างเครื่องคำนวณค่าใช้จ่ายสำหรับธุรกิจถ่ายภาพได้ดี

    • ธุรกิจขนาดกลางและขนาดเล็กส่วนใหญ่ยังไม่มีแอปหรือเว็บไซต์ หรือถึงมีก็มักไร้ประโยชน์ ตลาดเฉพาะทาง และพื้นที่สำหรับเครื่องมือดี ๆ ยังใหญ่มาก
    • ดูมีประโยชน์ในฐานะเครื่องมือสร้าง เดโมและ prototype แบบโต้ตอบได้ เพื่อ iterate ไอเดียอย่างรวดเร็ว ช่วยให้ feedback loop กับลูกค้าสั้นลงและลดความเข้าใจผิดได้ เช่น Figma น่าจะทำสิ่งนี้ได้
    • ไม่เข้าใจว่าทำไมถึงคิดว่ามันใช้ได้แค่งานจุกจิกเท่านั้น นั่นแทบจะเป็นการปฏิเสธความจริงเลย
      ซอฟต์แวร์ workflow สำหรับกระบวนการธุรกิจค่อนข้างได้รับความนิยม มีแอปจำนวนมากที่ให้ผู้คนทำงานคล้าย ๆ กันด้วย drag and drop หรือเครื่องมือแก้ไข widget แบบโต้ตอบได้ และยังจัดการฟอร์มซับซ้อน ความสัมพันธ์แบบ parent-child และการเปลี่ยนสถานะได้ด้วย ถ้าใช้สิ่งอย่าง GPT Vision ก็ข้ามขั้นตอนลากวาง widget แล้วใช้เครื่องมือวาดที่อิสระกว่า หรือสเก็ตช์ด้วยมือได้ ตัวอย่างที่ได้รับความนิยมที่สุดในปัจจุบันน่าจะเป็น Notion และยังมีตัวอย่างที่ซับซ้อนกว่านี้มาตั้งแต่นานมากแล้ว
  • ตอนนี้รู้สึกแก่แล้ว หลายสิบปีก่อน เราก็ทำสิ่งนี้ด้วย VB หรือ Delphi ได้แทบจะเร็วพอ ๆ กันแล้วมั้ง เพียงแต่ผลลัพธ์ กำหนดแน่นอน กว่านิดหน่อย แทนที่เครื่องมือจะเดาจากชื่อ label
    เราเคยมีสิ่งแบบนี้อยู่แล้ว และลืมไปว่ามันทำได้โดยไม่ต้องยัดทุกอย่างเข้าเบราว์เซอร์ และไม่ต้องใช้พลังคำนวณมหาศาลของโมเดล generative AI รู้สึกเหมือนกลายเป็นคนแก่ที่ตะโกนใส่ก้อนเมฆ

    • คิดคล้ายกัน พูดให้ยั่วขึ้นอีกหน่อยคือ เวลามีคนโชว์ว่าใช้ AI แปลง Figma เป็น HTML ผมจะถามว่า “เคยได้ยิน Dreamweaver ไหม?”
      แน่นอนว่าโค้ดของ Dreamweaver น่าเกลียดและแทบใช้งานไม่ได้ ส่วนโค้ดที่ AI สร้างบางครั้งก็ไม่ได้แย่ขนาดนั้น ถึงอย่างนั้นก็รู้สึกว่าเราเคยมาใกล้ตำแหน่งปัจจุบันมากแล้ว
    • นี่ไม่ใช่ปัญหาของเบราว์เซอร์ แต่เป็นปัญหาว่าเฟรมเวิร์กนั้นมี การออกแบบที่ยึดแนวทางชัดเจน มากแค่ไหน
      VB เป็นเครื่องมือที่ยึดแนวทางชัดเจนมาก และสร้างได้เฉพาะ UI สไตล์ Windows แบบ native เท่านั้น ไม่มีใครเอา mockup ใด ๆ ที่ดีไซเนอร์นำมา หรือ look and feel ที่ custom ทั้งหมด ไปทำซ้ำแบบ pixel-perfect ใน VB วันนี้ GUI ของผลิตภัณฑ์ส่วนใหญ่เป็นส่วนหนึ่งของแบรนด์ ไม่ว่าจะดีหรือร้าย ทุกบริษัทต้องการ look and feel และพฤติกรรม UI ที่เป็นเอกลักษณ์ ดังนั้นเครื่องมือที่ใช้สร้างจึงต้องซับซ้อนกว่ามาก ในเบราว์เซอร์ก็สร้าง VB ขึ้นมาใหม่ได้ และจริง ๆ ก็มีหลายคนทำคล้าย ๆ กันแล้ว แต่บริษัทต่าง ๆ ไม่ต้องการ UI ที่น่าเบื่อและทั่วไป จึงไม่ค่อยถูกใช้ในการพัฒนาผลิตภัณฑ์
    • เข้าใจประเด็นนะ แต่มันใช้ได้เฉพาะกับตัวอย่างที่ง่ายที่สุดเท่านั้น เครื่องมือนี้ทำได้หลายอย่าง ถ้าดู thread นั้นต่อ จะเห็นว่ามัน implement เกม tic-tac-toe ด้วย
      โดยพื้นฐานแล้วมันทำงานด้วยการส่ง screenshot ของ diagram ไปให้ GPT-4 แล้วบอกว่า “ช่วย implement สิ่งนี้ให้ที”
    • นานมาแล้วที่โซนกราฟิกส์ในงาน Comdex มีระบบปฏิบัติการหน้าตาสดใหม่ที่ถูกนำเสนอว่าเป็นก้าวต่อไป มีเนิร์ดตัวใหญ่คนหนึ่งลากนั่นลากนี่ด้วยเมาส์ และกำลัง “พิสูจน์” ว่าไม่จำเป็นต้องเป็นโปรแกรมเมอร์ก็สร้างแอปพลิเคชันได้
      สิบปีหลังจากนั้น ก็มีสิ่งที่ชื่อ Visix Vibe ซึ่งนำเสนอสิ่งเดียวกันสำหรับ Java ที่ตอนนั้นยังเป็นภาษาค่อนข้างใหม่อยู่ และมันวนเวียนอยู่สักหนึ่งถึงสองปี ทุก ๆ ไม่กี่ปี ราว 4–5 ปีหรือ 10 ปี จะมีใครสักคนอยากทำให้ความซับซ้อนทั้งหมดหายไป แต่ท้ายที่สุดพวกเขาก็ลงเอยด้วยการสร้างระบบปฏิบัติการ
    • ถ้าใช้ native UI toolkit หลัก ๆ ก็ยังเห็นสิ่งแบบนี้ได้อยู่ อาจไม่เร็วเท่า RAD แต่ในเว็บ องค์ประกอบและ interaction สารพัดอย่างที่ต้อง custom และมักต้องใช้ JavaScript ที่ไม่เสถียร กลับมีมาให้ “ฟรี”
      และมันทำงานได้ถูกต้องจริง ๆ โต้ตอบกับส่วนที่เหลือของ toolkit ตามแบบที่คาดไว้ รวมถึง internationalization และ accessibility ก็ทำงานได้ดีอย่างสม่ำเสมอ ไม่มีเหตุผลที่ HTML จะทำอะไรได้มากกว่านี้อีกมากด้วยของที่มีมาให้ในตัวไม่ได้ และถ้าทำแบบนั้นก็คงลดเวลานักพัฒนามหาศาลและลดความหงุดหงิดของผู้ใช้ได้ทุกปี แต่เราก็ไม่ทำกัน