TSBOARD (โอเพนซอร์สคอมมูนิตี้บิลเดอร์ที่เขียนด้วย TypeScript)

 (github.com/sirini)
19 คะแนน โดย tsboard 2024-05-20 | 21 ความคิดเห็น | แชร์ทาง WhatsApp

TSBOARD คืออะไร?

  • TSBOARD ย่อมาจาก Type Safety BOARD เป็นทั้งคอมมูนิตี้บิลเดอร์และเว็บบอร์ดที่เขียนด้วย TypeScript
  • ใช้รันไทม์ Bun ที่เคยถูกแนะนำใน GeekNews แห่งนี้ และสร้างแบ็กเอนด์ด้วยเว็บเฟรมเวิร์กชื่อ ElysiaJS ทำให้ทำงานได้รวดเร็วกว่าเอนจินเว็บบอร์ดทั่วไป
  • ฝั่งฟรอนต์เอนด์ใช้ Vue และ Vuetify แต่ด้วยเซนส์ด้านความงามของผู้พัฒนาที่ยังไม่ดีนัก จึงเขียนโพสต์นี้ไว้ด้วยความหวังว่าในอนาคตอาจได้รับความช่วยเหลือจากนักออกแบบใจดี (+ และแน่นอนว่าต้องการความช่วยเหลือจากนักพัฒนาใจดีด้วย!)

ทำไมถึงสร้างมันขึ้นมา?

  • ผมเริ่มต้นทำเว็บโปรแกรมด้วย PHP และเป็นนักพัฒนาที่ผ่านยุคของ Zeroboard และ Gnuboard มาแล้ว (ตอนนี้ก็เริ่มเป็นลุงแล้ว)
  • ความทรงจำสุดท้ายที่ผมมีต่อ JavaScript คือมันเป็นภาษาที่ถ้าไม่มี jQuery ก็เหมือนใช้การไม่ค่อยได้(...)
  • แต่หลังจากมาตรฐานได้รับการพัฒนาอย่างต่อเนื่อง การมาของ Node.js และการได้ตกหลุมรัก TypeScript ของ Microsoft แบบช้าไปหน่อย (จริง ๆ น่าจะช้าเกินไปมาก)
  • เลยอยากลองสร้างเว็บโปรแกรมอีกครั้ง และอยากลอง เขียนเว็บบอร์ดที่ทำมาตลอดด้วย TypeScript ล้วน
  • อีกทั้งก็อยากทำให้มันใช้ง่ายขึ้น ทำงานได้เร็วขึ้น และปลอดภัยขึ้นด้วย จึงกลายมาเป็นโปรเจกต์นี้

จุดเด่นเฉพาะของ TSBOARD

  • TSBOARD เขียนทั้งฟรอนต์เอนด์และแบ็กเอนด์ด้วย TypeScript จึง รับประกัน type safety ให้ได้มากที่สุด (แม้ไม่มีอะไรสมบูรณ์แบบ แต่ส่วนที่ใส่ใจมากที่สุดก็คือ type safety)
  • สำหรับผู้ที่เคยทำ full-stack development บนพื้นฐาน Node.js มาก่อน จะเข้าใจได้ง่ายและนำไปใช้งานต่อได้ทันที ผมเองก็เรียนรู้และสร้างมันขึ้นมาตั้งแต่ต้น จึงอ้างอิงแนวปฏิบัติที่ดีของคนอื่นมาไม่น้อย
  • มี ฟังก์ชันทั้งหมดที่จำเป็น สำหรับการสร้างเว็บไซต์คอมมูนิตี้ขนาดเล็กถึงกลางในตัว ตอนพัฒนาผมอ้างอิงจากเว็บไซต์คอมมูนิตี้ชื่อดังในเกาหลี เช่น Clien, Quasar Zone, GiggleHD หรือ Damoang ที่เพิ่งเกิดขึ้นเมื่อไม่นานมานี้

มันก็มีข้อเสียเหมือนกัน

  • รันไทม์ Bun ทำงานบน virtual CPU ได้ไม่สมบูรณ์นัก จึงใช้งานได้ยากบนโฮสติ้ง virtual server ราคาประหยัด TSBOARD ก็เช่นกันเพราะพึ่งพา Bun อยู่
  • TSBOARD ใช้วิธี Client Side Rendering ผมเป็นคนที่ยังชอบ PHP อยู่มาก จนคำว่า Server Side Rendering กลับเป็นคำที่ฟังดูแปลกใหม่เสียด้วยซ้ำ แม้จะมีทั้งข้อดีและข้อเสีย แต่ผมอยากลองแนวทางใหม่ (สำหรับตัวเอง) และพัฒนา TSBOARD โดยมีเป้าหมายเพื่อลดภาระของเซิร์ฟเวอร์ ดังนั้นสำหรับบางคน เรื่องนี้อาจเป็นข้อเสียอย่างชัดเจน
  • ที่จริงเริ่มพัฒนามาราวครึ่งปีแล้ว แต่ก็ยังมีจุดที่ขาดอยู่มากจนเพิ่งพอจะแนะนำได้ในตอนนี้ หวังว่าข้อเสียนี้จะถูกเติมเต็มได้ด้วยความช่วยเหลือจากผู้มีน้ำใจที่อาจได้พบกันในอนาคต

ปิดท้าย: ฝันถึงวันที่เว็บไซต์คอมมูนิตี้ชื่อดังสักแห่งจะเลือกใช้ TSBOARD

  • เมื่อเห็น Gnuboard ขยับจาก PHP ไปสู่ Python ก็รู้สึกว่าเว็บโปรแกรมเองก็ยังคงพยายามทดลองสิ่งใหม่ ๆ อยู่เสมอ เช่นเดียวกับ Rhymix ที่ถือกำเนิดจาก XE เว็บยังคงมีความเคลื่อนไหวอยู่ตลอด และการพัฒนาก็เช่นกัน
  • ผมจึงอยากฝากโพสต์แนะนำนี้ไว้ด้วยความตั้งใจเล็ก ๆ ที่อยากมีส่วนร่วมกับ ecosystem ของเว็บผ่านโปรเจกต์ TSBOARD
  • ผมฝันถึงวันที่เว็บไซต์คอมมูนิตี้ที่จะถือกำเนิดขึ้นใหม่สักแห่งเลือกใช้ TSBOARD ครับ ฮ่า ๆ

ขอบคุณที่อ่านมาจนจบครับ!

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

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

 
tsboard 2024-06-02

แม้จะไม่แน่ใจว่าการมาเขียนคอมเมนต์เพิ่มในโพสต์ที่ลงไว้เมื่อราว 2 สัปดาห์ก่อนจะช่วยได้ไหม ฮ่าๆ
ระหว่างที่กำลังคิดว่าจะนำฟีดแบ็กด้าน SEO ที่ได้รับจาก GeekNews ไปปรับใช้อย่างไร
ผมจึงได้ทำ sitemap.xml ขึ้นมาเพื่อสะท้อนการทำ Search Engine Optimization และขอแชร์รายละเอียดไว้ในคอมเมนต์นี้ครับ!

สรุปสั้น ๆ ก็คือ เสิร์ชเอนจินจะเข้าถึงผ่าน robots.txt > sitemap.xml และสุดท้าย
จะไปเก็บข้อมูลจากเส้นทาง https://tsboard.dev/tsapi/seo/main.html (หน้าตัวอย่าง)
เมื่อผู้ใช้เข้ามาจากการค้นหา ก็ได้ตั้งค่าให้สามารถกดลิงก์จากหน้านั้นกลับเข้าสู่เว็บไซต์เดิมอีกครั้งได้

ดูรายละเอียดเพิ่มเติมได้จากลิงก์ด้านล่างครับ!

https://tsboard.dev/board/free/18
 
dogtree 2024-05-23

ผมก็กำลังคิดอยู่ว่าจะลองรันโปรเจกต์ที่ทำเป็นงานอดิเรกด้วย bun ดีไหม แต่พอได้ยินว่ามันทำงานบน vCPU เสมือนได้ไม่สมบูรณ์ก็น่าตกใจเหมือนกันครับ แล้วตอนสมัครสมาชิกก็เขียนไว้ว่าเงื่อนไขรหัสผ่านคือต้องมีตัวพิมพ์ใหญ่ เลยเข้าใจว่าถ้าไม่ใส่ตัวพิมพ์เล็กก็คงได้ สรุปโดนหลอกเลย 555 น่าจะเขียนว่าอักษรตัวพิมพ์ใหญ่และตัวพิมพ์เล็กนะครับ
 
tsboard 2024-10-19

เผื่อไว้จึงขอฝากคอมเมนต์ตอบกลับไว้ครับ สำหรับผู้ที่กำลังพิจารณา Bun runtime ตอนนี้ไม่ต้องกังวลเรื่องปัญหาการทำงานบน virtual CPU อีกต่อไปแล้ว...! ลองทดสอบบนเวอร์ชัน 1.1.31 แล้ว พบว่าสามารถทำงานได้โดยไม่มีปัญหาครับ :)
 
tsboard 2024-05-23

อ๊ะ ขอบคุณสำหรับคอมเมนต์มากครับ และผมจะรีบแก้ในส่วนเงื่อนไขรหัสผ่านที่คุณพูดถึงไว้ให้เรียบร้อยแน่นอนครับ 555

สำหรับ Bun ถ้าจะว่าไปผมเองก็ไม่ได้ใช้งานมันแบบลงลึกมากนัก แต่ระหว่างที่ใช้ก็ได้เจอประสบการณ์ที่น่าประหลาดใจในหลายความหมายครับ มีหลายครั้งที่ฟีเจอร์ซึ่งบน Node.js ใช้งานได้เป็นเรื่องปกติ กลับใช้ไม่ได้ด้วยเหตุผลบางอย่างกับ Bun (ในนั้นก็มีปัญหาอย่างเช่นตอนสร้างโฟลเดอร์แล้วไม่รองรับตัวเลือก recursive: true ด้วย) และก็มีหลายจุดที่เห็นได้ชัดว่ามันหมกมุ่นกับความเร็วอย่างน่าทึ่งมาก (ซึ่งยิ่งทำให้ผมอดจะชอบมันมากขึ้นไม่ได้)

ตอนนี้เหมือนจะเรียกว่า Bundows และ Bun runtime บน Windows ก็รองรับอย่างเป็นทางการแล้ว แต่ก่อนเวอร์ชัน 1.1 มันยังใช้ไม่ได้ เลยต้องรันบน WSL2 ครับ เรื่องการทำงานบน virtual CPU ที่คุณพูดถึงนั้น มีโอกาสสูงว่า Bun จะไม่รองรับต่อไปในอนาคตด้วยซ้ำ แม้ว่าจะมีดิสทริบิวชันสำหรับ CPU ที่ไม่รองรับคำสั่ง AVX2 (baseline) ให้แล้วก็ตาม แต่การที่ไม่รองรับ virtual CPU ก็ยังเป็นเรื่องน่าเสียดายในหลายด้าน ไม่แน่ใจว่านี่เป็นข้อจำกัดของ Zig ซึ่งเป็นภาษาที่ใช้พัฒนา Bun หรือเปล่า โดยสรุปจากที่ผมใช้แล้วรู้สึกก็คือ เพื่อให้ได้ความเร็ว Bun เองก็ดูเหมือนจะมีบางส่วนที่ต้องยอมแลกเหมือนกัน

เผื่อว่าจะมีผู้ใช้ Bun ในอนาคตที่มาเห็นคอมเมนต์นี้ ผมขอเสริมอีกนิดว่า ถึงจะมีข้อจำกัดหลายอย่าง Bun ก็ยังเป็นตัวเลือกที่น่าสนใจมากครับ โดยเฉพาะถ้าคุณเลือก ElysiaJS เป็นเว็บเฟรมเวิร์ก ผมคิดว่าอย่างน้อยในแง่ความเร็วก็คงไม่มีอะไรให้น่าค้างคาใจ ถ้าวันหนึ่งผมต้องย้อนกลับไปเลือก runtime ใหม่ตั้งแต่ต้น... ผมก็คงต้องคิดให้มากขึ้นอีกหน่อย แต่สุดท้ายถึงจะมีปัญหาหลายอย่าง ผมก็น่าจะยังเลือก Bun อยู่ดีครับ ทั้งความหมกมุ่นกับความเร็วแบบสุดทาง และภาพของการท้าทายระบบนิเวศ JS runtime ที่ดูเหมือนมีคำตอบตายตัวอยู่แล้ว มันเป็นอะไรที่ทำให้ใจผมหวั่นไหวจริง ๆ ครับ 555
 
boy672820 2024-05-23

ระหว่างที่กำลังดูโค้ดบน GitHub มีบางจุดที่สงสัยเลยขอฝากคำถามไว้ครับ

  1. พอตรวจดูโครงสร้างตารางแล้วเหมือนว่ายังไม่ได้ตั้งค่าความสัมพันธ์ไว้ มีเหตุผลอะไรเป็นพิเศษหรือเปล่าครับ?
  2. ถ้าไม่ได้ใช้ความสัมพันธ์ของตารางเพื่อประสิทธิภาพด้านดัชนี อยากทราบว่าทำไมถึงไม่ได้พิจารณา NoSQL แทน RDB ครับ

ส่วนตัวรู้สึกประทับใจมากที่มีบอร์ดแนวนี้บนพื้นฐาน TS ออกมาครับ!
 
tsboard 2024-06-02

การตั้งค่า foreign key ถูกนำมาใช้แล้วในการอัปเดต v0.8.40!
https://tsboard.dev/board/free/18
 
tsboard 2024-05-23

ขอบคุณสำหรับคอมเมนต์ครับ!

ที่บอกว่าการตั้งค่าความสัมพันธ์นี่ หมายถึงยังไม่ได้ตั้งค่า foreign key ใช่ไหมครับ! ไม่ได้มีเหตุผลอะไรเป็นพิเศษหรอกครับ ตอนแรกคิดว่าเดี๋ยวพอโครงสร้างตารางนิ่งได้ระดับหนึ่งแล้วค่อยตั้งค่า แต่พอระหว่างทางต้องไปจัดการอย่างอื่น ก็เลยยังไม่ได้สะท้อนไว้จนถึงตอนนี้ ตอนนี้ความสัมพันธ์ระหว่างตารางของ TSBOARD และคอลัมน์ที่อ้างอิงกันก็ค่อนข้างเสถียรในระดับหนึ่งแล้ว ดังนั้นต่อจากนี้จะลองตั้งค่า foreign key ไว้ และปรับให้เป็นแนวทางที่รับประกันความสมบูรณ์ของข้อมูลได้มากขึ้นครับ!

เคยคิดเรื่อง NoSQL อยู่พักหนึ่งเหมือนกันครับ... แต่เพราะมีของใหม่ที่ต้องเรียนรู้เยอะมากอยู่แล้ว ตั้งแต่ตัวภาษา TypeScript ไปจนถึง Vue, Node.js/Bun เลยตัดสินใจว่าจะยังไม่เปลี่ยนไปใช้ครับ ถึง relational database จะเก่าแล้วตามประวัติศาสตร์อันยาวนานของมัน แต่ก็ยังคิดอยู่เหมือนกันว่า ที่มันยังถูกใช้งานอย่างมีประโยชน์ในหลายที่จนถึงทุกวันนี้ก็น่าจะต้องมีเหตุผลบางอย่างใช่ไหมครับ? ณ จุดที่กำลังพิมพ์คอมเมนต์นี้ก็ยังคิดแบบนั้นอยู่ แต่ถ้าในอนาคตมีความจำเป็นอะไรขึ้นมา ก็อาจจะพิจารณาอะไรอย่าง MongoDB ดูได้เหมือนกันครับ ฮ่าๆ

ส่วนตัวผมก็แปลกใจเหมือนกันนะครับที่ยังไม่เคยมีกระดานสนทนาที่พัฒนาด้วย TypeScript มาก่อน แต่ก็คงเป็นแค่เรื่องของเวลาเท่านั้นเอง ผมหวังว่าจะมีโปรเจกต์อีกหลายตัวที่มีสไตล์ต่างจาก TSBOARD เกิดขึ้นมาเยอะๆ ครับ! ฮ่าๆ ขอบคุณสำหรับคอมเมนต์ครับ!
 
singed 2024-05-22

พูดตามตรง ตอนแรกผมไม่ค่อยคาดหวังอะไร เพราะนึกถึงบอร์ด PHP รุ่นเก่า ๆ แต่พอได้ดูเดโมไซต์ (https://tsboard.dev) ก็เปลี่ยนความคิดเลยครับ คุณภาพดีมาก

  • รองรับ SSR
  • สามารถอนุญาตให้เขียนโพสต์ได้โดยไม่ต้องล็อกอิน (แบบ dc)

รู้สึกว่าจุดแบบนี้น่าจะจำเป็นนะครับ!

ตัวเอดิเตอร์นี่ทำขึ้นมาเองเลยเหรอครับ โอ้โห คิดว่าน่าจะใช้เอนจินเอดิเตอร์(?) อยู่เหมือนกัน แต่สัมผัสได้ถึงความพิถีพิถันระดับช่างฝีมือจริง ๆ
 
tsboard 2024-05-22

ขอบคุณสำหรับคอมเมนต์ครับ! และยิ่งขอบคุณมากขึ้นไปอีกที่มองว่าคุณภาพของเว็บไซต์ tsboard.dev ดีครับ 555

เรื่องการรองรับ SSR ที่คุณพูดถึง ผมได้เตรียมโรดแมปไว้โดยแบ่งเป็น 2 ระยะ และตั้งใจว่าจะนำแนวทางเสริมมาใช้ก่อน จากนั้นในเวอร์ชันถัด ๆ ไปจะค่อย ๆ พัฒนาโดยผสมผสานแนวทาง CSR และ SSR ให้เหมาะสมครับ ถ้าจะคงประสิทธิภาพไว้ให้ดีพอพร้อมกับทำ SEO ให้เหมาะสมยิ่งขึ้น เหนือสิ่งอื่นใดผมเองก็คงต้องเรียนรู้อีกมาก เลยคิดว่าน่าจะต้องใช้เวลาอีกสักหน่อยครับ หวังว่าถ้าไม่ยอมแพ้และทำต่อไปอย่างสม่ำเสมอ ผมก็น่าจะได้พบกับนักพัฒนาผู้มีน้ำใจท่านอื่น ๆ ได้เรียนรู้เร็วขึ้น และอาจได้รับความช่วยเหลือด้วยครับ 555

กรณีที่ไม่ล็อกอิน ตอนทำ TSBOARD ตอนแรกผมไม่ได้พิจารณาไว้ เพื่อย่นระยะเวลาพัฒนาและคงความเรียบง่ายในด้านการออกแบบ แต่จะลองคิดเพิ่มเติมดูครับ! ณ จุดที่กำลังเขียนตอบอยู่นี้ ถ้าจะรองรับผู้ใช้ที่ไม่เป็นสมาชิกจริง ๆ ดูเหมือนว่าจะต้องมีการเปลี่ยนแปลงหลายอย่าง จึงน่าจะยังทำได้ยากในทันทีครับ ^^;;;

ตัว editor นั้นผมค่อย ๆ ประกอบขึ้นมาทีละส่วนบนพื้นฐานของ tiptap editor แต่ใช้เวลากับการทำ editor มากกว่าที่คิดไว้พอสมควรครับ จากความทรงจำเก่า ๆ เหมือนเมื่อก่อนจะเป็น CKEditor หรือเปล่านะ...? ที่แค่หยิบมาใช้เลยก็ได้ แต่เดี๋ยวนี้ต้องมานั่งประกอบทีละชิ้นเหมือนต่อเลโก้แบบนี้แล้วครับ T_T แถมยังต้องลุยแก้ปัญหาเพิ่มอีกเพื่อรวมความสามารถของ TSBOARD เข้าไปด้วย ตอนที่ทำอยู่ก็รู้สึกเลยว่าถ้ามีใครทำ editor ตัวนี้ให้หน่อยก็คงดีมาก 555... ถ้าใครกำลังต้องการ editor ที่ใช้กับ tiptap ได้และพอใช้งานได้(?) ลองอ้างอิงโค้ดที่ผมทำไว้ใน TSBOARD ดูได้ น่าจะช่วยให้พัฒนาได้เร็วและง่ายขึ้นครับ

มีคนมองในแง่ดีเกินคาดเยอะพอสมควร จนรู้สึกเลยว่าเวลาที่เคยนั่งลังเลตอนจะเขียนโพสต์แนะนำว่าจะเขียนดีไหมนั้นช่างน่าเสียดายครับ TSBOARD ยังขาดอีกมาก แต่ก็ขอฝากเนื้อฝากตัวด้วยนะครับ!
 
yeppyshiba 2024-05-21

ผมเริ่มพัฒนาด้วย php และก็เป็นช่วงที่ผมหลงใหล typescript เลยกำลังลองอะไรหลายอย่างอยู่พอดี
รู้สึกมีความเป็นพวกเดียวกันอยู่บ้าง เลยยินดีที่ได้เห็นครับ
 
tsboard 2024-05-21

ยินดีที่ได้รู้จักครับ! ดูเหมือนว่าผมเองก็กำลังเดินอยู่บนเส้นทางคล้าย ๆ กันแบบไม่ทันตั้งตัวเหมือนกัน ฮ่าๆ ส่วนตัวก็เสียดายนิดหน่อยที่ภาษา PHP ยังโดนตำหนิอยู่บ่อย ๆ จนถึงทุกวันนี้ แต่พอได้ลองใช้ TypeScript แล้วก็รู้สึกว่าต่อให้โดนบ้างนิดหน่อยก็คงไม่เป็นไร ฮ่าๆ หวังว่าคุณ yeppyshiba จะได้ลองทำโปรเจกต์สนุก ๆ ด้วย TypeScript เยอะ ๆ นะครับ :)
 
jujumilk3 2024-05-21

เจ๋งมากครับ 👍
 
tsboard 2024-05-21

ขอบคุณครับ!! แม้จะยังเป็นโปรเจกต์ที่ยังไม่สมบูรณ์ แต่ดีใจมากที่มองกันในแง่ดี haha
ถ้าวันหนึ่งถึงเวลาที่คุณต้องการ TSBOARD ผมจะพัฒนามันให้ดียิ่งขึ้นไปอีก เพื่อที่จะได้แนะนำได้อย่างมั่นใจครับ :)
 
filekiwi 2024-05-21

นี่แหละที่รู้สึกว่ายังขาดอยู่.. ขอบคุณครับ
 
tsboard 2024-05-21

ขอบคุณที่แสดงความคิดเห็นครับ! หากวันหนึ่งคุณต้องการเว็บโปรแกรมที่คล้ายกับ TSBOARD ก็หวังว่าจะนึกถึงกันสักครั้งและช่วยลองทดสอบดูนะครับ ผมจะตั้งใจพัฒนาต่อไปอย่างเต็มที่ เพื่อให้คุณใช้งานได้สะดวกยิ่งขึ้นเมื่อต้องการใช้งานครับ!
 
jongpak 2024-05-21

โอ...! ผมยังจำบอร์ด sirini ยุค PHP ได้เลย ไม่ได้ยินชื่อนี้มานานมากจริงๆ
ตอนนั้นผมก็เคยพัฒนาสกินของ Sirini Board อยู่บ้าง และก็เคยรายงานช่องโหว่ด้านความปลอดภัยด้วย สบายดีไหมครับ :)

พอดูโค้ดแล้วความรู้สึกคือ โค้ดฝั่งเซิร์ฟเวอร์มีกลิ่นอายแบบ PHP อยู่เยอะเหมือนกันนะครับ 555 (โค้ด js ที่ให้ฟีลแบบ PHP?)

อย่างที่ท่านอื่นพูดไว้ ถ้าเป็น CSR ก็น่าจะมีข้อเสียตรงที่เสียเปรียบเรื่อง SEO เป็นต้น
หวังว่าส่วนนี้จะได้รับการปรับปรุงได้ดีนะครับ 555
 
tsboard 2024-05-21

อ๋อ ที่แท้ก็เป็นผู้มีพระคุณที่เคยช่วยผมไว้เมื่อก่อนนี่เอง! ยินดีมากที่ได้กลับมาพบกันอีกแบบนี้ครับ 555
และก็ทั้งตอนนั้นกับตอนนี้ ผมก็รู้สึกเขินเหมือนกันที่ดูเหมือนจะสร้างแต่ของธรรมดา ๆ ที่ใคร ๆ ก็นึกกันได้ ^^;;

โค้ดฝั่งแบ็กเอนด์ก็อย่างที่คุณบอกเลยครับ มีกลิ่นอายสไตล์ PHP ผสมอยู่ 555 บางทีผมก็เผลอคิดว่า ฟังก์ชันที่เคยใช้ใน PHP ไม่มีใน JS เหรอ? แล้วก็คอยหาอยู่ทุกครั้ง สุดท้ายก็ตั้งชื่อฟังก์ชันใช้งานเองให้คล้าย ๆ กันไปบ้างเหมือนกัน คิดว่าถ้าคุ้นกับโค้ด JS/TS มากขึ้นและค่อย ๆ รีแฟกเตอร์ไป ก็น่าจะดีขึ้นได้อีกนะครับ 5555

เรื่อง SEO ก็อย่างที่คุณแนะนำเลยครับ คงต้องเสริมให้ดีขึ้น ในความคิดสั้น ๆ ของผมตอนนี้คือการเพิ่มหน้าสแตติกอื่น ๆ อย่าง RSS อะไรทำนองนั้น เดี๋ยวจะลองทำโน่นนี่ดูครับ

ว่าแต่ การที่ยังมีคนจำตัวผมในยุค PHP4 ได้ เป็นเรื่องที่ทั้งน่าประหลาดใจและน่าขอบคุณจริง ๆ นะครับ จริง ๆ แล้วก่อนเขียนโพสต์นี้ผมก็ลังเลอยู่เยอะเหมือนกัน 555;; ผมจะพยายามทำให้พอเป็นประโยชน์กับคนอื่นได้มากขึ้นอีกนิดไม่มากก็น้อย ฝากเอ็นดู TSBOARD กันเยอะ ๆ ด้วยนะครับ!
 
superwoou 2024-05-20

อ่านโพสต์แล้วเกิดข้อสงสัยเลยขอคอมเมนต์ไว้ครับ (ยังไม่ได้ดูโค้ด)

อยากทราบเหตุผลที่ไม่ได้พัฒนาแบ็กเอนด์ให้รองรับ Nodejs compatible ครับ (หรือว่าประสิทธิภาพออกมาไม่ดีเกินกว่าจะชดเชยข้อเสียที่กล่าวถึงได้?)
ถ้าเป็น CSR มีแผนจะจัดการเรื่อง SEO อย่างไรครับ? เพราะคอมมูนิตี้ก็น่าจะต้องใส่ใจทราฟฟิกจากการค้นหาด้วยเหมือนกัน
 
tsboard 2024-05-21

สวัสดีครับ! ขอบคุณที่ฝากคอมเมนต์ไว้ครับ (จริง ๆ คิดว่าจะจมหายไปท่ามกลางความไม่สนใจเสียอีก เลยรู้สึกซาบซึ้งมากครับ)
คำถามที่คุณถามมาก็เป็นเรื่องที่ผมคิดหนักอยู่มากเหมือนกัน แต่ขอให้อ่านแบบว่า อ้อ มีมุมคิดแบบนี้อยู่เหมือนกัน นะครับ
อ้อ แล้วก็ขอแจ้งไว้ก่อนว่า หลังจาก PHP แล้ว ผมไม่เคยทำเว็บต่อในชีวิตการทำงานจริงอีกเลยแม้แต่ครั้งเดียว ยุคปฏิวัติของ Node.js หรือช่วงที่ React เปลี่ยนโลกเว็บ ผมก็ไม่ได้สนใจตามดูเลย เลยอาจมีมุมมองที่ค่อนข้างแปลกใหม่อยู่บ้างครับ 555

  1. ทำไมฝั่งแบ็กเอนด์ถึงไม่ทำให้รองรับกับ Node.js?
    ตอนที่ผมเริ่มพัฒนา TSBOARD ผมเดาไปก่อนเลยว่าน่าจะมีบอร์ดหรือบล็อกชื่อดังที่ทำบน Node.js อยู่แล้วสักตัว (ที่ผมไม่รู้จัก) หรืออะไรก็ตามที่คล้ายกับสิ่งที่ผมตั้งใจจะทำ อย่างที่เกริ่นไว้ตอนต้น ชีวิตการทำงานจริงของผมไม่ได้มีงานพัฒนาเว็บ และก็ไม่เคยทำสิ่งที่เรียกว่า side project แบบจริงจังด้วย เลยยิ่งคิดแบบนั้น ผมคิดว่าในเมื่อยังไงก็น่าจะมีอะไรสักอย่างที่ทำบน Node.js อยู่แล้ว การที่ผมจะทำของใหม่ขึ้นมาอีกก็คงไม่ค่อยมีความหมาย งั้นในเมื่อจะต้องเรียนรู้อะไรใหม่อยู่แล้ว ก็ลองทำบน Bun ไปเลยดีกว่า และการตัดสินใจนั้นก็นำมาจนถึงตอนนี้ครับ

ถ้ามองเรื่องประสิทธิภาพ จริง ๆ สำหรับเว็บไซต์คอมมูนิตี้ขนาดเล็กที่ผมตั้งเป้าไว้ (ผู้ใช้งานพร้อมกันไม่ถึง 10 คน) ผมคิดว่า Node.js ก็เพียงพอครับ ก่อนจะพิจารณา Bun ผมก็เคยทดสอบด้วย Node.js + Hono มาก่อน ซึ่งในความเห็นผมก็ไม่ได้มีปัญหาอะไร แต่ทั้งประสิทธิภาพที่โดดเด่นมากที่ Bun นำเสนอ รวมถึงประสิทธิภาพของ ElysiaJS ที่อยู่บน Bun ก็ทำให้ผมประทับใจมากจนไม่อยากปล่อยมือ ผมคิดว่าถ้ามีใครสักคนทำเว็บบอร์ดบน Node.js ได้ดีมากอยู่แล้วจริง ๆ ถ้าจะไปแข่งกับบอร์ดสมมตินั้น ผมก็น่าจะต้องมีประสิทธิภาพที่สูงกว่า สุดท้ายเลยยอมทิ้งความเข้ากันได้กับ Node.js แล้วออกแบบให้พึ่งพา Bun ไปเลยครับ (ตอนนี้ก็แอบเสียดายนิดหน่อยครับ เพราะพอมาหาดูจริง ๆ กลับไม่ค่อยมีบอร์ดชื่อดังบน Node.js แบบ GnuBoard, Rhymix หรือ XE... หรือว่าผมหาไม่เจอเองนะ??)

  1. ถ้าเลือก CSR แล้ว SEO ล่ะ?
    ส่วนที่คุณพูดมานั้นถูกต้องทั้งหมดครับ ถ้าจะให้มีทราฟฟิกจากการค้นหา ไม่ว่ายังไง Google crawler ก็ต้องอ่านเนื้อหาได้ และต้องจับคู่กับการค้นหาได้ด้วย ส่วนนี้ผมยังไม่ได้ทำครับ แต่กำลังคิดอยู่ว่า ถ้าผู้ใช้ต้องการ เราอาจแยกแชร์คอนเทนต์ล่าสุดออกมาในรูปแบบสแตติกต่างหาก คล้ายกับการเปิดเผย RSS feed ก็น่าจะดี ผมก็คิดอยู่เหมือนกันว่าถ้าเปิดให้ภายนอกเห็นเป็น JSON ตัวเก็บข้อมูลน่าจะอัปเดตข้อมูลได้สะดวกขึ้นไหม เดี๋ยวคงต้องคิดต่ออีกหน่อยครับ (ตอนแรกผมนึกถึง RSS แต่เหมือนสมัยนี้คนส่วนใหญ่ไม่ค่อยใช้กันแล้วใช่ไหมครับ?? หรือว่าผมห่างจากวงการเว็บมานานเกินไป T_T)

แยกจากมาตรการเสริม SEO เหตุผลที่ผมเลือก CSR ก็เพราะอยากลดภาระฝั่งเซิร์ฟเวอร์ให้มากขึ้นอย่างจริงจังครับ อย่างกรณีของเว็บไซต์ Damoang ที่เพิ่งเกิดขึ้นไม่นานมานี้ (ไม่แน่ใจว่าเอ่ยชื่อคอมมูนิตี้ตรง ๆ แบบนี้ได้ไหมนะครับ) เท่าที่ผมทราบก็มีทั้งภาระทราฟฟิกและภาระเซิร์ฟเวอร์ค่อนข้างสูง เมื่อคิดในฐานะที่มันเป็น community builder แน่นอนว่า SEO สำคัญ แต่ผมคิดว่าควรแก้ปัญหาที่เชื่อมตรงกับต้นทุนก่อน เลยเลือก CSR เป็นอันดับแรก สำหรับผมที่ยังรัก PHP อยู่เสมอ จริง ๆ SSR กลับเป็นสิ่งที่คุ้นเคยมากกว่า แต่ก็เลือกแบบนี้เพราะคิดว่า ถ้าให้ไคลเอนต์ใช้พลังการประมวลผลอย่างจริงจังมากขึ้น เซิร์ฟเวอร์ก็น่าจะมีทรัพยากรเหลือมากขึ้นใช่ไหมครับ

หวังว่าจะช่วยคลายข้อสงสัยได้บ้างนะครับ และการตัดสินใจที่ผมเลือกมาก็มีทั้งข้อดีข้อเสียที่ชัดเจน ดังนั้นผมไม่ได้คิดว่า TSBOARD คือคำตอบที่ถูกต้องเสมอไป มันเป็นผลจากการชั่งน้ำหนัก trade-off หลายอย่าง และเป็นการตัดสินใจจากมุมมองอันสั้นน้อยของผมในตอนนั้นมากกว่า ถ้าต่อไป TSBOARD ถูกนำไปใช้งานมากขึ้น ผมก็อาจเปลี่ยนความคิดและลองแนวทางอื่นได้เสมอครับ 555
 
jongpak 2024-05-21

เนื่องจากการออกแบบเดิมถูกวางมาให้เหมาะกับ CSR อยู่แล้ว ถ้าจะเปลี่ยนเป็น SSR ก็ดูเหมือนว่าจะต้องทำงานในระดับแทบจะพัฒนาใหม่ทั้งหมดเลยครับT_T

ช่วงหลัง ๆ เสิร์ชครอว์เลอร์ก็ว่ากันว่ารองรับ JS ได้ดีขึ้นบางส่วนแล้ว แต่ยังไงก็คงตาม plain HTML ไม่ทันอยู่ดีครับ
สำหรับเบราว์เซอร์ทั่วไปอาจประมวลผลแบบ CSR แต่ในกรณีของ search bot (เช่น GoogleBot, Yeti) ก็อาจมีวิธีจัดการแบบ SSR ได้เหมือนกัน

ส่วนตัวผมมองว่าวิธีแบบนั้นเป็นเพียงการแก้ปัญหาเฉพาะหน้า และสุดท้ายถ้าจะรองรับ SEO ให้ดีจริง ๆ คำตอบก็น่าจะเป็น SSR นะครับ

ถึงจะเป็น CSR แต่สุดท้ายถ้ามีปริมาณคำขอมากขึ้น ก็ย่อมเกิดภาระกับแบ็กเอนด์อยู่ดี และผมคิดว่าทิศทางที่ดีกว่าน่าจะเป็นการลดภาระของแบ็กเอนด์ผ่านการออกแบบแคชและกลไกต่าง ๆ ครับ^^;
 
tsboard 2024-05-21

ในกรณีของ TSBOARD อย่างที่คุณกล่าวไว้ ตอนนี้ทุกอย่างถูกพัฒนาบนพื้นฐานของ CSR ทั้งหมด ดังนั้นอย่างน้อยในเวอร์ชัน v1.y.z ก็น่าจะต้องทำงานบนเกณฑ์แบบ CSR only ไปก่อนครับ ถ้าจะลองเสริมบางส่วน โครงสร้างตอนนี้คือโพสต์ทั้งหมดจะแสดงในหน้าแรก ดังนั้นอาจใช้วิธี SSR เฉพาะหน้าแรก หรือไม่ก็อย่างที่คุณบอก อาจต้องเพิ่มหน้าแยกต่างหากเพื่อให้บอตสามารถครอว์ลฝั่ง plain HTML ได้ครับ! แนวทางปรับปรุงเหล่านี้จะลองนำไปสะท้อนในช่วงเวอร์ชัน v0.9.z ดูครับ!

อ๊ะ แล้วผมขอเสริมเผื่อว่าจะมีคนคิดว่า TSBOARD ใช้ CSR เลยค้นหาไม่เจอ! สำหรับ Googlebot เอง เขาว่ากันว่าตอนนี้ก็พัฒนาจนสามารถดึงเนื้อหาจากเว็บไซต์ที่สร้างด้วย CSR ได้แล้วครับ! (เพราะเป็น Google เลยทำได้...?) แม้จะชัดเจนว่าเป็นแนวทางที่เสียเปรียบด้าน SEO แต่ก็ไม่ถึงกับว่าใช้ไม่ได้เลย ดังนั้นคิดว่าไม่ต้องกังวลมากเกินไปครับ

ไม่ใช่แค่ CSR กับ SSR เท่านั้น น่าจะยังมีแนวทางอื่นที่อยู่กึ่งกลางอีกด้วย เดี๋ยวผมจะลองคิดเพิ่มเติมและวางโรดแมป v2.0.0 โดยมีเป้าหมายเพื่อปรับปรุง SEO ด้วยครับ (แม้ตอนนี้จะยังเป็นเรื่องไกลตัวอยู่บ้าง 555) ขอบคุณสำหรับคำแนะนำครับ และแม้จะยังเป็นโปรเจกต์ที่ขาดตกบกพร่องอยู่บ้าง ก็ขอฝาก TSBOARD ด้วยนะครับ!