บันทึกการตัดสินใจด้านสถาปัตยกรรม: เฟรมเวิร์ก CSS

สารบัญ:

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

สรุป

ประเด็น

เราต้องการใช้เฟรมเวิร์ก CSS เพื่อสร้างเว็บแอปพลิเคชันของเรา:

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

• เราต้องการวนซ้ำการออกแบบ เลย์เอาต์ UI/UX ฯลฯ อย่างรวดเร็ว

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

การตัดสินใจ

ตัดสินใจเลือก Bulma

สถานะ

ตัดสินใจเลือก Bulma เปิดรับตัวเลือกเฟรมเวิร์ก CSS ใหม่เมื่อมีเข้ามา

รายละเอียด

สมมติฐาน

เราต้องการสร้างเว็บแอปที่ทันสมัย รวดเร็ว เชื่อถือได้ ตอบสนอง ฯลฯ

เว็บแอปสมัยใหม่ทั่วไปกำลังลดหรือเลิกใช้ jQuery ด้วยหลายเหตุผล:

• JavaScript สมัยใหม่กำลังนำความสามารถหลายอย่างที่ jQuery เคยให้มาใช้ทีละน้อย ดังนั้นจึงต้องการ jQuery น้อยลง และมีโมดูลที่ดีกว่า/เร็วกว่า/เล็กกว่าที่ให้การนำไปใช้เฉพาะ

• แนวทางกว้างของ jQuery คือการจัดการ DOM โดยตรง ซึ่งเป็นแอนตี้แพตเทิร์นสำหรับเฟรมเวิร์ก JavaScript สมัยใหม่ (เช่น React, Vue, Svelte)

• jQuery รบกวนตัวเองหากถูกโหลดสองครั้ง ฯลฯ

ข้อจำกัด

หากเราเลือกเฟรมเวิร์ก CSS ที่ใช้ jQuery เราก็ต้องนำเข้า jQuery เช่น Semantic UI ใช้ jQuery แต่ Tachyons ไม่ใช้

หากเราเลือกเฟรมเวิร์ก CSS ที่น้อยที่สุด เราก็สละคอมโพเนนต์ของเฟรมเวิร์กที่เราอาจต้องการตอนนี้หรือเร็ว ๆ นี้ เช่น Semantic UI มีสไลด์รูปภาพ แต่ Tachyons ไม่มี

จุดยืน

เราพิจารณาการไม่ใช้เฟรมเวิร์ก ซึ่งยังดูเป็นไปได้ โดยเฉพาะเพราะ CSS grid ให้สิ่งที่โครงการของเราต้องการเป็นส่วนใหญ่

เราพิจารณาเฟรมเวิร์ก CSS จำนวนมากด้วยการคัดเลือกรายชื่อสั้นอย่างรวดเร็ว: Bootstrap, Bulma, Foundation, Materialize, Semantic UI, Tachyons ฯลฯ สองตัวเลือกของเราสำหรับการทบทวนเชิงลึกคือ Semantic UI (เพราะมีแนวทางที่ตรงความหมายที่สุด) และ Bulma (เพราะมีแนวทางที่เบาที่สุดซึ่งให้คอมโพเนนต์ที่เราต้องการตอนนี้)

เราพิจารณา Semantic UI ซึ่งให้คอมโพเนนต์จำนวนมาก รวมถึงที่เราต้องการสำหรับโครงการ: แท็บ กริด ปุ่ม ฯลฯ เราทำโครงการนำร่องกับ Semantic UI สองวิธี: ใช้ไฟล์ CDN ทั่วไป และใช้ที่เก็บ NPM เราประสบความสำเร็จกับ Semantic UI ในหน้า HTML แบบสถิต แต่ไม่ประสบความสำเร็จภายในกรอบเวลาของเราในการสร้าง SPA JavaScript (หลัก ๆ เพราะปัญหาการโหลด jQuery) เราพบว่านักเขียนโปรแกรมคนอื่นขอให้นักพัฒนา Semantic UI สร้างเวอร์ชันที่ไม่มี jQuery ด้วยเหตุผลเดียวกับเรา นักเขียนโปรแกรมคนอื่นร้องขอเวอร์ชันที่ไม่มี jQuery มาหลายปี แต่นักพัฒนาตอบปฏิเสธและระบุว่าเวอร์ชันที่ไม่มี jQuery ใด ๆ จะเขียนยากเกินไป เช่น ~"โครงการ Semantic UI มีจุดสัมผัสมากกว่า 22,000 จุดที่ใช้ jQuery"

ตัวอย่างกับ Semantic:

<div class="ui top attached tabular menu">
  <a class="item">Alpha</a>
  <a class="item">Bravo</a>
</div>

เราพิจารณา Bulma Bulma มีความสามารถหลายอย่างคล้าย Semantic UI แม้ไม่มีคอมโพเนนต์ที่ซับซ้อนมากเท่า Bulma สร้างด้วยเทคนิคสมัยใหม่ เช่น ไม่มี jQuery Bulma มีคอมโพเนนต์ของบุคคลที่สามบางส่วน ซึ่งเราอาจต้องการใช้บางตัว

ตัวอย่างกับ Bulma:

<div class="tabs">
  <ul>
    <li><a>Alpha</a></li>
    <li><a>Bravo</a></li>
  </ul>
</div>

ข้อโต้แย้ง

ตามข้างต้น

โดยเฉพาะ Semantic UI ดูเหมือนมีธงเตือนทั้งในแง่เทคโนโลยี (กล่าวคือมีจุดสัมผัส jQuery มากมาย) และในแง่ภาวะผู้นำ (กล่าวคือเวอร์ชันที่ไม่มี jQuery ถูกปฏิเสธอย่างเด็ดขาด แทนที่จะพยายามทำแผนที่นำทาง การปรับปรุงอย่างต่อเนื่อง การระดมทุนบริจาค ฯลฯ)

นัยยะ

หากเราพบเฟรมเวิร์ก CSS ที่ไม่ใช้ jQuery ที่ดี โดยทั่วไปก็เป็นประโยชน์และดี

ที่เกี่ยวข้อง

การตัดสินใจที่เกี่ยวข้อง

เฟรมเวิร์ก CSS ที่เราเลือกอาจส่งผลต่อความสามารถในการทดสอบ

ข้อกำหนดที่เกี่ยวข้อง

เราต้องการส่งมอบแอปที่ทันสมัยล้วน ๆ อย่างรวดเร็ว

เราไม่ต้องการใช้เวลาทำงานกับเฟรมเวิร์กรุ่นเก่ากว่า (โดยเฉพาะ Semantic UI) ที่มีการพึ่งพารุ่นเก่ากว่า (โดยเฉพาะ jQuery)

ผลงานที่เกี่ยวข้อง

ส่งผลต่อ HTML ทั่วไปทั้งหมดที่จะใช้ CSS

หลักการที่เกี่ยวข้อง

ย้อนกลับได้ง่าย

ความต้องการความเร็ว

หมายเหตุ

หมายเหตุใด ๆ ที่นี่