เหตุผลที่เลือก Elixir Phoenix แทน Rails, Laravel และ Next.js

 (akarshc.com)
7 คะแนน โดย GN⁺ 2025-10-18 | 3 ความคิดเห็น | แชร์ทาง WhatsApp
  • Phoenix LiveView มอบประสิทธิภาพสูงทั้งในด้าน ความเร็วของแอปพลิเคชันและความเร็วในการพัฒนา
  • ข้อดีคือไม่จำเป็นต้อง ดูแล frontend และ backend แยกจากกัน แต่สามารถจัดการแบบโมโนลิธิกด้วยภาษาเดียวได้
  • แม้จะพิจารณา Rails Hotwire และ Laravel Livewire ด้วย แต่การทำงานแบบเรียลไทม์และการทำ งานเบื้องหลัง ยังต้องตั้งค่าเพิ่มเติมมากกว่า
  • เฟรมเวิร์ก Phoenix ของ Elixir ยังคงความ elegant แบบ Ruby on Rails ไว้ แต่ให้ประสิทธิภาพที่ดีกว่ามาก มี งานเบื้องหลังผ่าน Oban ติดตั้งมาเป็นพื้นฐาน และรองรับไวยากรณ์ที่คุ้นเคยและสะอาดตา
  • LiveView ให้การอัปเดตแบบสองทางเรียลไทม์บนพื้นฐานของ WebSocket สร้างสมดุลระหว่างการเรนเดอร์ฝั่งเซิร์ฟเวอร์แบบดั้งเดิมกับเฟรมเวิร์กที่เน้นฟรอนต์เอนด์ และหากจำเป็นก็สามารถใช้ Alpine.js หรือไลบรารี JavaScript ผ่าน hooks ได้
  • ปัจจัยชี้ขาดสุดท้ายคือ ความเร็วในการพัฒนาสูง การรองรับ concurrent สูง การเขียนงานส่วนใหญ่ได้ด้วยภาษาเดียว ตัวคอมไพเลอร์ช่วยดักบั๊กก่อนล่วงหน้า และสถาปัตยกรรมที่ทนต่อความล้มเหลว บนพื้นฐาน Elixir/Erlang

ทำไมจึงเลือก Phoenix LiveView

  • เป้าหมายของการเขียนโค้ดคือเพื่อ แก้ปัญหาด้วยวิธีที่เหมาะสมที่สุด และสำหรับผู้เขียน ปัจจัยที่สำคัญที่สุดคือ ความเร็วของแอปพลิเคชันและประสิทธิภาพในการพัฒนา
  • หากใช้ React หรือ Next.js ร่วมกับ Laravel หรือใช้ Inertia.js ร่วมกับ Laravel จะต้อง ดูแลทั้งสแตกฝั่ง frontend และ backend ไปพร้อมกัน
  • ในฐานะนักพัฒนาเดี่ยว ไม่มีเวลาจะมาจัดการ สถานะในสองตำแหน่งที่แตกต่างกัน และต้องการ โซลูชันแบบโมโนลิธิกที่แข็งแรงซึ่งจัดการทุกอย่างร่วมกันได้

  • เปรียบเทียบทางเลือก: Laravel Livewire, Rails Hotwire, Next.js

    • Laravel Livewire และ Rails Hotwire เป็นเครื่องมือที่ยอดเยี่ยมสำหรับทำให้งานฝั่ง frontend ง่ายขึ้นโดยไม่ต้องพึ่งพา JavaScript มากนัก
    • เคยพิจารณา full JavaScript stack ด้วย Next.js แต่ ไม่ชอบใช้ JavaScript บนฝั่ง backend
    • Rails Hotwire โดดเด่นเป็นพิเศษเพราะ สามารถสร้าง MVP ด้วย Rails ได้อย่างรวดเร็ว
    • แต่โปรเจ็กต์นี้ต้องการงานเบื้องหลัง การอัปเดตแบบเรียลไทม์ และการสื่อสารสองทาง ซึ่งแม้ Rails และ Laravel จะทำได้เช่นกัน แต่ ต้องใช้ความพยายามในการตั้งค่ามากกว่า

  • จุดเด่นชี้ขาดของ Elixir, Phoenix และ LiveView

    • Elixir และ Phoenix ยังคงความ elegant แบบ Ruby on Rails ไว้ พร้อมมอบ ประสิทธิภาพ ที่สูงกว่ามาก
    • จุดแข็งคือมี background jobs ในตัวผ่าน Oban ไวยากรณ์ที่คุ้นเคยและอ่านง่าย และการสื่อสารสองทางแบบเรียลไทม์ของ LiveView
    • LiveView สร้างสมดุลที่เหมาะสมระหว่างแนวทางเรนเดอร์ฝั่งเซิร์ฟเวอร์กับเฟรมเวิร์กที่หนักไปทางฟรอนต์เอนด์
    • รองรับการอัปเดตแบบเรียลไทม์ผ่าน WebSocket และสามารถเชื่อมต่อกับไลบรารี JavaScript (เช่น Alpine.js) ได้
    • Phoenix มี Oban มาในตัว ทำให้ การประกาศ background jobs และการกู้คืนอัตโนมัติ ทำได้ง่าย

  • ข้อดีของ Elixir/Erlang

    • Elixir เป็นภาษาแบบคอมไพล์ที่สร้างอยู่บน Erlang ซึ่งเป็นรากฐานของระบบที่รองรับ concurrent ขนาดใหญ่ เช่น WhatsApp และ Discord
    • มอบ การรองรับ concurrent สูง ความทนทานต่อความล้มเหลว และการกู้คืนอัตโนมัติเมื่อเกิดปัญหา

เหตุผลของการตัดสินใจครั้งสุดท้าย

  • พัฒนาได้รวดเร็ว และ รองรับ concurrent สูง
  • สามารถสร้างได้แทบทุกอย่างด้วย ภาษาเดียว
  • เขียน โค้ดที่อ่านง่าย ได้
  • ตัวคอมไพเลอร์ตรวจจับบั๊กส่วนใหญ่ได้ก่อนขึ้น production
  • สถาปัตยกรรมที่ทนต่อความล้มเหลว ทำให้แอปแทบไม่ล่มและช่วยรับประกัน เสถียรภาพของแอป

บทสรุปและคำแนะนำ

  • Phoenix ไม่ได้ เหนือกว่า Rails, Laravel และ Next.js แบบเด็ดขาด เสมอไป
  • ทุกเฟรมเวิร์กล้วนยอดเยี่ยม และผู้เขียนก็มีประสบการณ์ใช้งานกับโปรเจ็กต์หลากหลายแบบ
  • สำหรับ สถานการณ์เฉพาะ และ โปรเจ็กต์ (Hyperzoned.com) ของผู้เขียนนั้น Phoenix เหมาะสมที่สุด
  • หาก ลองสำรวจสิ่งที่นอกเหนือจากสิ่งที่คุณรู้อยู่แล้ว คุณอาจพบวิธีที่ดีกว่าและมีประสิทธิภาพกว่าสำหรับแก้ปัญหาถัดไป
  • อย่าหยุดเรียนรู้

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

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

 
clastneo 2025-10-23

ด้วยเหตุผลเดียวกับ JSP พอเกินระดับหนึ่งไปแล้วก็รู้สึกว่าใช้งานต่อไม่ไหวครับ
 
GN⁺ 2025-10-18
ความคิดเห็นจาก Hacker News

  • เคยมีประสบการณ์เชื่อมต่อ CKEditor ด้วยตัวเองกับ Rails, Livewire, Phoenix และ React ในบรรดาพวกนี้ Phoenix น่าประทับใจที่สุดในแง่ประสบการณ์นักพัฒนา เฟรมเวิร์กถูกออกแบบมาอย่างดีมากจนงานอินทิเกรตเรียบง่ายจริง ๆ ส่วน Rails กับ React โดยเฉพาะ Next.js ไม่ได้ให้ความรู้สึกพึงพอใจแบบนั้นเลย Next.js เปลี่ยน router บ่อยเกินไป เปลี่ยนไปเรื่อยจนเชื่อถือไม่ค่อยได้ Livewire ให้ความรู้สึกคล้าย Phoenix แต่ค่อนข้างไม่ตรงไปตรงมาและมีฟีเจอร์น้อยกว่า ตัวอย่างเช่น Livewire ยังไม่รองรับ component slot แต่ Phoenix จัดการได้ไม่มีปัญหา ถ้าไม่มี slot โครงสร้างเทมเพลตก็จะเละ และโค้ดก็ซับซ้อนโดยไม่จำเป็น ถ้าใครสนใจดูได้ที่ ckeditor5-phoenix GitHub

    • การใช้ PHP(Laravel) ร่วมกับ JQuery ก็ยังใช้ได้ดีอยู่จนถึงปี 2025 แต่ส่วนตัวไม่อยากใช้ Livewire ขณะที่ Node.js อาจมี productivity ต่ำกว่า แต่ก็เหมาะเมื่อจำเป็นต้องใช้ความสามารถที่ทรงพลังกว่า รองรับ async/await, socket.io และ TypeScript ทั้งหมด Next.js ก็มีประโยชน์ถ้าต้องการทั้ง SEO และ UI แบบโต้ตอบ แต่ในความเป็นจริงมีเว็บสักกี่แห่งที่ต้องการทั้งหมดนี้พร้อมกัน น่าจะมีแค่บริการอย่าง LinkedIn เท่านั้น

    • ไม่คิดว่า Livewire เป็นของก๊อปจาก Phoenix ถึงดูจากชื่อแล้วจะชวนให้คิดแบบนั้นก็ตาม เท่าที่รู้ทั้งสองโปรเจกต์เริ่มต้นเกือบพร้อมกัน และจริง ๆ แล้ว Livewire เก่ากว่าด้วยซ้ำ ส่วน Hotwire ออกมาช้าที่สุด ทั้งสองโปรเจกต์ใช้แนวทางที่ต่างกัน และ PHP กับ Elixir ก็มีธรรมชาติที่ต่างกันมาก ผมคิดว่า Livewire ก็มีประโยชน์ไม่น้อย เพราะใน PHP ใช้ WebSocket ได้ไม่ง่ายนัก เลยเน้นการทำงานบน HTTP ซึ่งในสถานการณ์ส่วนใหญ่ก็เพียงพอแล้ว กลับกัน WebSocket ของ Liveview อาจจะเกินความจำเป็นด้วยซ้ำ

    • อยากรู้รายละเอียดเกี่ยวกับปัญหาที่เจอใน Rails มากขึ้น ว่าส่วนไหนที่ลำบากบ้าง

    • สงสัยว่าเวลาคุณใช้ Rails มีจุดไหนที่ยากบ้าง

    • ใน Livewire 4 จะมีการรองรับ component slot แต่ยังต้องรออีกไม่กี่สัปดาห์ เวอร์ชันใหม่ยังบอกว่าจะช่วยปรับปรุงทั้งประสิทธิภาพและความสะดวกในการพัฒนาอีกด้วย

  • บทความนี้ดูเหมือนผู้เขียนกำลังปกป้องเฟรมเวิร์กที่ตัวเองเลือก และตั้งใจมองข้ามความสามารถของเฟรมเวิร์กอื่น ส่วนที่ยกมาเป็นข้อดีของ Phoenix นั้น Rails ก็มีทั้งหมดเหมือนกัน อีกทั้งยังให้โทนเหมือนกับว่า Rails ไม่รองรับการสื่อสารกับฟรอนต์เอนด์และ WebSocket ซึ่งถ้าใครเคยทำแอปด้วย Rails ในช่วง 3 ปีที่ผ่านมา จะรู้ว่าไม่จริงเลย แน่นอนว่า Phoenix และ LiveView ก็เป็นเครื่องมือที่ดี แต่เหตุผลที่ผมยังใช้ Rails ต่อคือ Hotwire Native เพราะมันช่วยให้ผมสร้างทั้งแอปมือถือและเว็บแอปคนเดียวได้ภายในเวลาสั้น ๆ ซึ่งเป็นข้อได้เปรียบด้าน productivity มหาศาล

    • ผมไม่ค่อยได้ใช้ Ruby แต่ก็สงสัยว่านอกจากเรื่องชุมชนแล้ว Ruby on Rails มีข้อไหนเหนือกว่า Elixir & Phoenix บ้าง ด้วยแพลตฟอร์ม BEAM ไม่ว่าจะเป็น soft real-time system, fault tolerance, NIFs, actor model, lightweight process จำนวนมหาศาล, concurrency ที่คิดตามได้ง่าย, functional programming, OTP, GC ที่ไม่หยุดการทำงาน ทำให้ผมคิดว่าในทางทฤษฎี Phoenix เหนือกว่ามาก แน่นอนว่าใครชอบอะไรก็ใช้สิ่งนั้นได้ และผมก็ตั้งใจจะลอง Hotwire Native ดูเหมือนกัน

    • ชัดเจนว่า Rails ก็สื่อสารกับฟรอนต์เอนด์ผ่าน WebSocket ได้ จริง ๆ ผมเป็นนักพัฒนา Rails แต่ถ้าต้องรองรับ socket connection จำนวนมากแบบต่อเนื่อง ผมจะเลือก Phoenix เพราะ Phoenix สามารถรองรับการเชื่อมต่อ socket ระดับ 100,000 ได้ง่ายกว่าและถูกกว่ามากบนบริการอย่าง Gigalixir ถ้าจัดการอินฟราเองเรื่องก็อาจต่างออกไป แต่บน Heroku แม้แต่การเชื่อมต่อหลักพันก็ยังลำบากและค่าใช้จ่ายก็สูง

    • อยากรู้ว่าตรงไหนในบทความที่บอกว่า Rails ไม่รองรับการสื่อสารกับฟรอนต์ผ่าน WebSocket เพราะในต้นฉบับบอกแค่ว่า "เป็นสิ่งที่ทำได้ทั้งใน Rails และ Laravel แต่ต้องใช้เวลาเซ็ตอัปเพิ่มอีกนิด" ซึ่งให้น้ำเสียงต่างกันโดยสิ้นเชิง

    • ชุด Rails + Hotwire ก็ทรงพลังมากจริง ๆ และยิ่งดีขึ้นอีกถ้ามี Hotwire Native ประเด็นของบทความนี้ไม่ใช่ว่า Phoenix กับ LiveView ดีกว่า แต่คือโครงสร้างของ LiveView (state ที่ขับเคลื่อนจากเซิร์ฟเวอร์, การแยก process, lightweight channel ฯลฯ) เหมาะกับบางสถานการณ์ ทั้งสอง ecosystem กำลังแก้ปัญหาคล้ายกันด้วยวิธีที่ต่างกัน Rails ใช้แนวทาง convention และ progressive enhancement ส่วน Phoenix ใช้ concurrency และ fault tolerance ของ BEAM สุดท้ายสิ่งสำคัญคือสถาปัตยกรรมแบบไหนเหมาะกับผลิตภัณฑ์ที่คุณกำลังสร้างมากกว่า

    • เคยได้ยินชื่อ Hotwire Native มานานแล้ว แต่หลังจากนั้นเหมือนข่าวจะเงียบไป อยากรู้ว่ามีประสบการณ์ใช้กับแอปมือถือจริงไหม ทั้งในแง่การซัพพอร์ต เอกสาร และความสมบูรณ์ของการนำไปใช้

  • ผมเองก็มีความรู้สึกเชิงบวกต่อ Elixir ไม่แพ้ผู้เขียน แต่ในฐานะ CTO หลังใช้มันใน production มา 3 ปี ก็รู้สึกข้อจำกัดชัดขึ้นเมื่อระบบโตขึ้น BEAM (concurrency, fault tolerance) ทำได้ตามที่สัญญาไว้ดี และ Ecto, Oban, remote iex รวมถึง talent pool ก็ยอดเยี่ยมทั้งหมด แต่ประสบการณ์นักพัฒนา (DX) กลับกลายเป็นคอขวดมากขึ้นเรื่อย ๆ ในโปรเจกต์ขนาดใหญ่ 300,000 บรรทัด มีปัญหาแบบนี้:

    • เวลา compile: แค่แก้โค้ดบรรทัดเดียว ในสภาพแวดล้อมพัฒนาก็ต้อง compile เกิน 10 วินาที จนเสียสมาธิบ่อย
    • เครื่องมือ: autocomplete ของ ElixirLS ไว้ใจไม่ได้ ทำให้เสียเวลาค้นหาชื่อฟังก์ชันหรือฟิลด์ของ schema
    • LiveView: ไม่เหมาะกับ UI ที่ซับซ้อน เลยจำเป็นต้องเพิ่มฟรอนต์เอนด์ React สุดท้ายความซับซ้อนของ GraphQL และการแยก stack ก็ย้อนกลับมาเหมือนเดิม
      ถ้ากำลังคิดเรื่อง stack ระยะยาว ลองอ่าน Retrospective 3 ปี น่าจะช่วยได้

    • ค่อนข้างตกใจมากที่การ compile ในสภาพแวดล้อมพัฒนาของ Elixir ใช้เวลาเกิน 10 วินาทีต่อครั้ง เพราะก่อนหน้านี้ได้ยินแต่เรื่องว่ามันได้เปรียบกว่า Rails อยากรู้ว่ากรณีแบบนี้พบได้บ่อยในงานจริงไหม

    • ผมก็มีประสบการณ์คล้ายกันตอนเรียน Elixir ชอบตัวภาษา แต่ตอนทำงานบน Windows ผ่าน WSL แล้ว LSP พังบ่อยจนใช้งานลำบาก หวังว่า LSP ทางการ ที่กำลังจะออกจะช่วยให้เรื่องนี้ดีขึ้นมาก

    • ไม่ว่าจะเป็น LiveView หรือ React ถ้าฟรอนต์เอนด์ไม่ได้รับการจัดการที่ดี พอเป็นแอปขนาดใหญ่โค้ดก็เละได้เร็วมาก ยิ่งทีมโตขึ้นก็ยิ่งต้องมี code review และการเก็บกวาด logic ที่ไม่จำเป็นอย่างจริงจัง เรื่องนี้ดูจะเหมือนกันทุกเฟรมเวิร์ก และยังมีพื้นที่ให้พัฒนาอีกมากจริง ๆ

  • ผู้เขียนอ้างว่า "การรองรับ background job, real-time update และการสื่อสารสองทางแบบเบา ๆ นั้น Rails กับ Laravel ก็ทำได้ทั้งหมด เพียงเพิ่มการตั้งค่าอีกเล็กน้อย" แต่ Rails มี Solid Queue (งานเบื้องหลัง) และ Solid Cable (ข้อความแบบเรียลไทม์) มาให้เป็นค่าเริ่มต้นอยู่แล้ว

    • ในฐานะคนที่เพิ่งย้ายมาใช้ Rails ไม่นาน SolidQueue ใช้งานง่ายมาก แค่ตั้งค่าพื้นฐานก็ใช้ได้ทันที ถ้าเพิ่ม Solid Queue Dashboard ก็ยังดูภาพรวมทั้งหมดได้ในหน้าเดียวด้วย

    • ถ้าพูดเฉพาะเรื่องข้อความแบบเรียลไทม์ ผมรู้สึกว่าการตั้งค่า Solid Cable ยังยุ่งยากกว่า LiveView เพราะ LiveView จัดการให้ถึงขั้น render เลย ทำให้รู้สึกว่าในการพัฒนา Rails ด้วย SolidCable ยังตามหลัง LiveView อยู่มาก

    • ทุกอย่างทำได้ด้วย Rails จริง ๆ เป็นเฟรมเวิร์กที่สวยงามมาก และถ้าใช้ Phoenix จะง่ายและสบายใจกว่า แนะนำให้ลองสักครั้ง

    • ในฐานะคนที่เคยใช้ทั้ง Rails และ Elixir ในงานจริง ขอบอกว่าสองระบบนี้ไม่เท่ากันเลย Oban ใช้งานชัดเจน และถ้าจะ rerun งานก็แค่อัปเดตคอลัมน์ใน DB แล้ว Oban supervisor จะจัดการต่อให้เองอย่างดี ส่วน Solid Queue ไม่มีวิธีง่าย ๆ ในการรันงานที่สำเร็จไปแล้วซ้ำอีก จำนวนตารางก็เยอะเกินไปจนจัดการลำบาก Oban ดูแลง่าย แค่สองตารางและทำงานร่วมกับแอปเดียวกันได้อย่างเป็นธรรมชาติ ขณะที่ Solid Queue ต้องไปไล่อ่านหลายบล็อกเพื่อปรับค่าจนทำงานได้ถูกต้อง การตั้งค่าพื้นฐานยังไม่ดีพอ ด้วยคุณสมบัติของ Erlang/Elixir ทำให้ Oban ถูกออกแบบให้เรียบง่ายมากแต่ทำงานได้ยอดเยี่ยม ซึ่งเป็นความสุขของนักพัฒนา ผมตอนนี้ใช้ Solid Queue เพราะจำเป็น

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

    • หลังการมาของ LLM แอปง่าย ๆ แบบนี้สร้างได้ในไม่กี่นาทีแล้ว แต่ในส่วนสำคัญที่ต้องใส่ใจจริง ๆ ผมรู้สึกว่า Phoenix ให้การควบคุมได้มากกว่า

    • อยากฟังให้เจาะจงกว่านี้ว่ามีจุดไหนที่เข้ามือกว่า และอะไรที่รู้สึกว่าดีกว่า

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

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

  • หลายคนบอกว่าชุมชน Elixir เล็ก แต่ก็ยังท้าทายสิ่งที่ล้ำสมัยด้วยไลบรารีระดับสูงไม่น้อย ทำให้นึกถึงคำพูดของนักพัฒนาคนหนึ่งเมื่อก่อนว่า "ยิ่งน้อยยิ่งดีกว่า" มีโอเพนซอร์สดี ๆ มากมาย เช่น elixir-dbvisor/sql

    • ในทางกลับกัน ecosystem ของ JS ใหญ่เกินไปจนรู้สึกเหนื่อย มีไลบรารี 10 ตัวที่ต่างคนต่างอยู่ และไม่มีใครทำตามมาตรฐาน เปรียบได้กับการเลือกรายการอาหารในซูเปอร์มาร์เก็ตใหญ่ของอเมริกา หรือการถูกบังคับให้เลือกจากร้านเชนของ Vercel

  • ถ้าอยากสัมผัสเสน่ห์ที่แท้จริงของ Elixir แนะนำให้ดูวิดีโอบรรยายของ Saša Jurić ให้ครบทั้งหมด

    • Saša Jurić เป็นผู้เขียนหนังสือ 'Elixir in Action' และหนังสือก็ดีมากจริง ๆ

  • บทความนี้โฟกัสที่ Phoenix LiveView มากกว่าตัวเฟรมเวิร์กทั้งหมด จริง ๆ แล้วถึงจะตัด LiveView ออกจากตัวเลือกตอนสร้าง Phoenix แต่โค้ด LV พื้นฐานก็ยังหลงเหลืออยู่หลายจุด ซึ่งผมไม่ชอบ

    • ผมก็เห็นด้วยว่า LiveView มีความ opinionated มากและมี boilerplate เยอะ ผมชอบความกระชับและพลังในการแสดงออกของ Elixir แต่ LiveView กลับให้ความรู้สึกตรงกันข้าม

  • เหตุผลเดียวที่ผมไม่เลือก Elixir คือไม่มี type checker อยากรู้ว่าตอนนี้มีอะไรเปลี่ยนไปไหม
 
colus001 2025-10-18

แม้ว่า Livewire จะสนุกจริง แต่ถ้า UI ซับซ้อนขึ้นมาอีกนิดเดียวก็จะกลายเป็นนรก ทันทีที่ถึงจุดนั้น Phoenix ก็จะเสียข้อดีไปอย่างมาก ยิ่งวงจรยาวขึ้นก็ยิ่งลำบาก ดังนั้นผมเลยไม่ค่อยแนะนำเท่าไรครับ