ทำไม Claude ถึงเป็นแอป Electron?

 (dbreunig.com)
10 คะแนน โดย GN⁺ 2026-02-22 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • Electron เป็นเฟรมเวิร์กที่ใช้ HTML·CSS·JS ในการสร้างแอปเดสก์ท็อปที่ รองรับ Windows, Mac, Linux พร้อมกัน โดยมีแอปจำนวนมากอย่าง Slack·Discord·VS Code ที่ใช้งานมัน
  • แต่เนื่องจากแต่ละแอป บรรจุเอนจิน Chromium ของตัวเองแยกกัน จึงมีขนาดใหญ่ และเกิดปัญหา หน่วง·ไม่ตอบสนอง ได้ อีกทั้งการผสานกับความสามารถของ OS ก็ยังมีข้อจำกัด
  • เมื่อ coding agent สามารถสร้าง native code แยกตามแพลตฟอร์ม ได้จากสเปกและการทดสอบ ข้อดีของ Electron ก็ดูเหมือนจะลดลง
  • แต่ในความเป็นจริง agent ยังทำงานอัตโนมัติได้เพียง 90% ของการพัฒนา เท่านั้น และ 10% สุดท้ายของการจัดการกรณียกเว้นกับการบำรุงรักษา ก็ยังยากและต้องพึ่งพาคนอยู่ดี
  • ดังนั้น เช่นเดียวกับ แอป Claude ของ Anthropic แม้เทคโนโลยี agent จะก้าวหน้าแล้ว แต่ก็ยังมี เหตุผลเชิงปฏิบัติที่ทำให้ยังเลือกใช้ Electron

ข้อดีและข้อจำกัดของ Electron

  • Electron ทำให้สามารถสร้าง แอปเดสก์ท็อปข้ามแพลตฟอร์ม ด้วยเทคโนโลยีเว็บได้
    • รองรับทั้ง Windows, Mac, Linux ด้วยโค้ดเบสเดียว
    • นำโค้ดของเว็บแอปเดิมกลับมาใช้ได้ จึงมี ประสิทธิภาพในการพัฒนา สูง
  • ข้อเสียคือมีทั้ง ขนาดแอปที่เพิ่มขึ้น และ ประสิทธิภาพที่ลดลง
    • แต่ละแอปบรรจุเอนจิน Chromium ของตัวเอง ทำให้มีขนาดระดับหลายร้อย MB
    • เกิดปัญหาอย่างการตอบสนองช้าลง และการผสานกับความสามารถของ OS ที่ไม่ดีพอ
  • แม้บางปัญหาจะปรับปรุงได้ด้วยการ optimize ตามแต่ละ OS แต่ ข้อได้เปรียบเชิงโครงสร้างของ Electron เองไม่ได้ผลักดันให้ทำเช่นนั้นอย่างจริงจัง

การมาถึงของ coding agent และความคาดหวัง

  • ระยะหลัง coding agent แสดงความสามารถในการทำงาน ข้ามภาษา·ข้ามแพลตฟอร์ม แบบอัตโนมัติ โดยอิงจากสเปก (spec) และการทดสอบ
  • ในทางทฤษฎี สามารถใช้สเปกและชุดทดสอบเพียงชุดเดียวเพื่อสร้าง แอป native ของแต่ละแพลตฟอร์ม ได้
  • สิ่งนี้ชี้ให้เห็นถึงความเป็นไปได้ที่ ทีมขนาดเล็กและโฟกัสชัดเจน จะสามารถส่งมอบ แอป native ประสิทธิภาพสูง ให้ตลาดวงกว้างได้

กรณีของ Claude และ Anthropic

  • Anthropic เคยใช้ coding agent สร้าง คอมไพเลอร์ภาษา C ที่พัฒนาด้วย Rust แต่ก็ ติดข้อจำกัดในช่วงสุดท้าย
    • เมื่อเพิ่มฟีเจอร์ใหม่หรือแก้บั๊ก ก็มักเกิดปัญหาที่ทำให้ฟีเจอร์เดิมพังซ้ำ ๆ
    • แม้ผลงานจะน่าประทับใจ แต่ก็ถูกประเมินว่ายัง ไม่เหมาะกับการใช้งานจริง
  • ตัวแอปเดสก์ท็อป Claude เองก็สร้างบน Electron เช่นกัน และถูกกล่าวถึงว่าเป็น แอปที่ช้า มีบั๊กมาก และมีขนาดใหญ่

ความยากของ ‘10% สุดท้าย’

  • coding agent สามารถจัดการ 90% แรกของการพัฒนาได้อย่างรวดเร็ว แต่
    การจัดการกรณียกเว้นและการบำรุงรักษาในสภาพแวดล้อมจริง ยังคงซับซ้อนและต้องมีคนเข้ามาแทรกแซง
  • ในสภาพแวดล้อมของผู้ใช้จริง จะมี สถานการณ์ที่ไม่คาดคิด สะสมเพิ่มขึ้นจนงานพัฒนาไม่มีวันจบง่าย ๆ
  • หากสร้างแอปแยกตามแต่ละแพลตฟอร์ม ขอบเขตของ บั๊กและงานซัพพอร์ตจะเพิ่มเป็น 3 เท่า ทำให้ภาระการบำรุงรักษาสูงขึ้น
    • Electron ช่วยบรรเทาปัญหานี้ได้บางส่วนผ่าน wrapper ร่วมกัน

เหตุผลที่ยังคงใช้ Electron

  • ต่อให้การพัฒนาแบบอิงสเปกจะเป็นไปได้ แต่ ต้นทุนของการพัฒนา 10% สุดท้ายและภาระการบำรุงรักษา ก็ยังคงอยู่
  • แม้ เทคโนโลยี agent จะพัฒนาไปมาก แต่ ข้อดีของ Electron ในเรื่องโค้ดเบสเดียว ก็ยังใช้ได้จริงในทางปฏิบัติ
  • ณ เวลานี้ Electron ยังถูกมองว่าเป็นตัวเลือกที่สมเหตุสมผล
  • coding agent แม้จะแสดงความก้าวหน้าอย่างน่าทึ่ง แต่ก็ยัง ไม่เพียงพอจะเป็นทางเลือกทดแทนอย่างสมบูรณ์

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

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

 
GN⁺ 2026-02-22
ความเห็นจาก Hacker News

  • Boris จากทีม Claude Code
    ก่อนหน้านี้มีวิศวกรที่เคยพัฒนา Electron อยู่ เลยชอบแนวทางที่ไม่ใช่เนทีฟ
    แบบนี้ทำให้ แชร์โค้ด ระหว่างเว็บกับเดสก์ท็อปได้ จึงคง UI/UX แบบเดียวกันไว้ได้
    แน่นอนว่าทุกอย่างเป็นเรื่องของ trade-off ดังนั้นในอนาคตก็อาจเปลี่ยนได้

    • ถ้ามองจากฝั่งผู้ใช้ ต่อให้ฟีเจอร์น้อยลงนิดหน่อยก็อยากได้แอปที่กิน CPU น้อยกว่าและมี UI ที่ลื่นไม่สะดุด
      น่าจะแก้ได้ด้วยการ optimize ประสิทธิภาพโดยไม่ต้องเปลี่ยนสแตก มือถือก็เหมือนกัน
    • สงสัยว่าถ้าการเขียนโค้ดเป็นปัญหาที่แก้ได้แล้ว ทำไมยังใช้ เทคโนโลยีสแตกที่ง่ายที่สุด อยู่
    • บริษัทอย่าง Anthropic พูดว่าด้วยเครื่องมือเขียนโค้ด AI การพอร์ตข้ามภาษาทำได้ง่าย แต่พฤติกรรมจริงกลับต่างออกไป
      ให้บทเรียนว่า ต้องดูการกระทำมากกว่าคำพูด
    • มีคนแชร์ ลิงก์ YouTube พร้อมแซวว่า “นี่คุณใช่ไหม?”
      ถ้าอย่างนั้นก็น่าจะสั่ง Claude ไปเลยว่า “ช่วยทำอันนี้ให้มันไม่ห่วยได้ไหม”
    • ที่น่าสนใจกว่าการใช้ Electron หรือไม่ คือถ้าต้องทำแอปเนทีฟสำหรับสามแพลตฟอร์ม
      จะเป็นไปได้ไหมที่ AI agent จะดูแลไปจนถึงการบำรุงรักษาได้ด้วยแค่สเปกกับเทสต์
      โดยเฉพาะเมื่อคำนึงถึงข้อจำกัดของโมเดลอย่าง Opus 4.6 ว่าผลลัพธ์จะออกมาแบบไหน

  • เหตุผลที่โค้ดไม่ฟรีนั้นชัดเจนอยู่แล้ว
    ทีมเราก็ใช้ Claude อย่างหนักมา 6 เดือน แต่ อัตราบั๊กก็ยังเหมือนเดิม
    AI ไม่ใช่ยาครอบจักรวาล

    • ผ่านไปสักปีคงไม่มีใครในทีมเข้าใจต้นตอของบั๊กนั้นแล้ว
      ถ้า เอาท์ซอร์สการคิด ให้ AI ก็จะสูญเสียแผนที่ความเข้าใจของระบบไป
    • เพิ่งมีโมเดลที่เขียนโค้ดต่อเนื่องได้จริงจังเมื่อราว 3 เดือนก่อน และเมื่อ 15 วันก่อนก็ยังมีการปรับปรุงใหญ่
      แต่ตอนนี้กลับมีคนถามแล้วว่า “ทำไมยังไม่เขียนทุกอย่างใหม่ด้วย AI” ฟังดูตลกดี
    • ทำให้นึกถึงมีมของ Shen ที่ว่า “I’m stupid faster”
      ดู ลิงก์ Imgur
      เอเจนต์เขียนโค้ดด้วย AI อาจยังไม่ถึงขั้นนั้นทั้งหมด แต่ก็ควรระวัง ความผิดพลาดที่แค่เกิดเร็วขึ้น
    • ถ้าอย่างนั้นก็สงสัยว่าทำไม Claude ถึงไม่ช่วยทำ QA testing

  • เบราว์เซอร์ของ OpenAI ก็ออกมา 4 เดือนแล้ว แต่ยังมีเฉพาะบน macOS
    ทั้งที่รันอยู่บน เอนจินข้ามแพลตฟอร์ม อยู่แล้ว การขยายไปแพลตฟอร์มอื่นกลับช้ามากจนน่าสงสัย

    • เป็นไปได้สูงว่าสาเหตุคือ อัตราการยอมรับของผู้ใช้ต่ำ

  • ชอบสำนวน “Free as in puppy” มาก
    เขาว่าชื่อเดิมเริ่มด้วย “If code is free,”

    • คอมเมนต์นี้ตลกมากจนตามไปหาอ่านบล็อกเลย ซึ่งก็ดีจริง
    • มีคนถามติดตลกว่า “ฉันเป็นลูกหมาเลยไม่เข้าใจ”
    • แล้วก็มีมุกต่อว่า “คล้ายกับรถเยอรมันเก่าที่ได้มาฟรีหรือเปล่า?”

  • ทั้งบทความนี้และทั้งเธรดดูเป็น รูปแบบการถกเถียงสไตล์ HN แบบคลาสสิก
    วนอยู่กับ “AI ไม่ดี”, “JavaScript ไม่ดี”, “Electron ไม่ดี”
    ทั้งที่จริงแล้ว Electron แทบจะเป็น ‘แพลตฟอร์ม OS ตัวที่สี่’ อยู่แล้ว แต่มีนักพัฒนาหลายคนที่ไม่เข้าใจจุดนี้

    • คิดว่าแอป Electron ทั้งหมดควรถูกแทนที่ด้วยแอปเนทีฟ
      ตอนนี้หลายแอป ดูเหมือนเว็บไซต์ที่แปะแพตช์ทับมา, มีความไม่สอดคล้องของสไตล์และบั๊กเยอะ
      การทำแอป Mac แบบเนทีฟให้ความรู้สึกดีกว่ามาก
    • ต้นทุนไม่ใช่โค้ด แต่คือ วิศวกร
      Electron มีข้อดีของมัน แต่แทบไม่มีการ optimize ตาม OS แต่ละตัวเลย
      UI แบบเนทีฟที่แย่ก็มีเยอะ สุดท้ายก็ขึ้นกับว่า คนเขียนโค้ดอย่างไร
      ถ้า Claude มีเครื่องมือ CLI ให้ใช้อยู่แล้ว การเลือก Electron ก็สมเหตุสมผล
    • ในฐานะคนเขียนบทความ ขอย้ำว่าไม่เคยบอกว่า AI แย่
      ยอมรับข้อดีของ Electron และอธิบายเหตุผลของการเลือกมันแล้ว
      เพียงแต่การที่มัน ช้าทั้งที่รันบน Mac Studio RAM 64GB เป็นข้อเท็จจริงที่น่าสนใจ
    • ยากจะยอมรับว่าบริษัทมูลค่า 3 หมื่นล้านดอลลาร์จะปล่อย UX แบบนี้ออกมา
      แถมยังใส่ dependency ของ npm มาตั้งแต่ต้นอีก เหมือน ขาดความภูมิใจเชิงเทคนิค
      มันไม่เข้ากับสโลแกนที่ว่า “เราจ้างคนเก่งที่สุด”
    • Mac 24GB ของฉันก็ใช้ swap ตลอดเพราะแอป Electron
      ฉันชอบ JavaScript นะ แต่ การใช้ RAM มันบ้าคลั่งมาก

  • Anthropic ไม่เคยพูดว่า “โค้ดฟรี”
    สิ่งที่พวกเขาเน้นคือ การเพิ่มผลิตภาพ และในทางปฏิบัติก็เขียนโค้ดส่วนใหญ่ด้วย LLM
    ถ้าจะวิจารณ์ก็ควรชี้ ปัญหาจริง ไม่ใช่สร้างหุ่นฟางขึ้นมา

    • ถึงอย่างนั้นก็ยังมีคำถามว่า “ถ้าผลิตภาพสูงขนาดนั้นและมีวิศวกรราคาแพงอยู่
      ทำไมผลลัพธ์ถึงยังไม่ดีกว่านี้”
    • หัวหน้าทีม Claude Code พูดเมื่อไม่กี่วันก่อนว่า “การเขียนโค้ดแทบเป็นปัญหาที่แก้ได้แล้ว”
      ดู บทสัมภาษณ์ของ Lenny’s Newsletter
    • ในความเป็นจริงก็มีคนจำนวนมากที่อ้างว่า “โค้ดแทบจะฟรี”
      ดูเหมือนบทความนี้จะพุ่งเป้าไปที่คนกลุ่มนั้น

  • Felix เอง รับผิดชอบแอป Electron ของ Claude Code Desktop และ Claude Cowork
    ในแอปของเราก็มีโค้ด Rust, Swift, Go อยู่ไม่น้อย
    เหตุผลที่ใช้ Electron และเหตุผลที่แจกจ่ายเอนจินของตัวเอง
    เขียนอธิบายไว้อย่างละเอียดในเอกสารทางการ
    Electron เป็นแค่ เครื่องมือ เท่านั้น ถ้าจำเป็นก็ใช้ตัวอื่นได้

    • พักเรื่อง Electron ไว้ก่อน ปัญหามีอยู่มากในด้าน UI/UX และประสิทธิภาพ ของแอป
      CEO พูดว่า “การเขียนโค้ดแทบเป็นปัญหาที่แก้ได้แล้ว” เลยอยากถามว่าทำไมผลถึงออกมาเป็นแบบนี้
    • บางคนก็มองว่าถ้าเป็น โค้ดที่ขับเคลื่อนด้วย AI ทั้งหมด จริง ๆ trade-off แบบนี้คงไม่เกิดขึ้นเลย

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

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

  • มองว่าการที่ Claude ใช้ Electron ไม่ใช่ปัญหาทางเทคนิค แต่เป็น ปัญหาทางวัฒนธรรม
    ถ้าเป็นสตาร์ตอัป Electron ก็สมเหตุสมผล
    แต่ถ้าเป็นบริษัทใหญ่ก็ควรลงทุนกับ คุณภาพและ UX ของแอปเนทีฟ
    ต่อให้การเขียนโค้ดแบบอัตโนมัติทำได้แล้ว การที่ยังไม่ทำเช่นนั้น
    สะท้อนว่าวัฒนธรรมการพัฒนาทุกวันนี้สูญเสีย “ความตั้งใจจะสร้างซอฟต์แวร์ที่ดีที่สุด” ไปแล้ว