คุณควรแยก js, html และ css แยกจากกันจริงๆหรือ


10

ฉันได้ยิน / อ่านตลอดเวลาที่สะอาดเพื่อแยกjs , htmlและcss ของคุณออกจากกัน คาดว่าจะทำให้ง่ายต่อการบำรุงรักษาและแก้ปัญหา คาดคะเนว่ามันมีประสิทธิภาพมากขึ้นเพราะจะช่วยให้แคช / ลดรูปCSSและJSไฟล์

เท่าที่ฉันกังวลการใช้เว็บเฟรมเวิร์ก (Django, Rails, ... ), javascript templating library, ... ฉันมักจะแยกหน้า html เดียวเป็นเทมเพลตที่สามารถนำกลับมาใช้ใหม่ได้จำนวนมาก - ถ้าคุณต้องการ . ตัวอย่างเช่นฉันสามารถมีวิดเจ็ตฟีดข่าววิดเจ็ตที่เลือกได้หลายรายการฯลฯ ... แต่ละรายการมีเลย์เอาต์ที่สอดคล้องกันทั่วหน้าต่างๆและแต่ละอันถูกควบคุมโดยชิ้นส่วนของจาวาสคริปต์

กับองค์กรนี้ - ซึ่งฉันคิดว่าสะอาดที่สุดเท่าที่จะเป็นไปได้การเพิ่มความสามารถในการนำกลับมาใช้ใหม่ - ฉันมีปัญหาในการเข้าใจว่าทำไมการเก็บjsและcss ทั้งหมดในไฟล์แยกต่างหาก ฉันคิดว่ามันจะง่ายกว่ามากเช่น :

ในไฟล์วิดเจ็ตหลายไฟล์ที่เลือก

  • HTML
  • เค้าโครง css ขั้นพื้นฐาน
  • ควบคุมการโต้ตอบโดยตรงและการปรับปรุง UX ด้วยบิตของ JS

ฉันคิดว่ามันเป็นวิธีที่สามารถนำมาใช้ซ้ำได้มากกว่ารักษาได้มากขึ้นเพราะคุณไม่ต้องเลื่อนดูไฟล์fat jsจากนั้นสลับไปที่และเลื่อนดูไฟล์cssไขมันสลับไปที่ไฟล์htmlของคุณอีกครั้ง.

ดังนั้นฉันชอบที่จะรู้ว่าพวกคุณจัดระเบียบรหัสของคุณอย่างไรถ้าคุณยึดติดกับการแยกที่มักจะแนะนำ

  • มีเหตุผลที่ดีที่จะทำเช่นนั้น?
  • ไม่ใช่ว่าคำแนะนำบนเว็บมักจะคิดว่าคุณจะไม่ใช้เครื่องมือแฟนซีใด ๆ (ในกรณีนี้ฉันชอบที่จะได้รับการอ่านออนไลน์ที่ทันสมัยมากขึ้นเพื่อการปฏิบัติที่ดีที่สุด)?
  • มันเป็นเพียงเรื่องของการตั้งค่าหรือไม่?

2
หลักการที่คุณพูดถึงนั้นเรียกว่าการแยกงานนำเสนอและเนื้อหา
Robert Harvey

8
โปรดทราบว่าหากคุณไม่แยกไฟล์ออกผู้ใช้ของคุณจะดาวน์โหลด HTML และ CSS แบบฝังในทุก ๆ หน้าโหลดแทนที่จะดาวน์โหลดหนึ่งครั้งและทำการแคช
นิโคล

@RobertHarvey: ok อ้างอิงที่ดี ... แต่เหตุผลเดียวที่ระบุไว้ที่นั่นสำหรับการแยกเนื้อหา / งานนำเสนอคือการปรับปรุงความสามารถในการอ่านของเครื่อง อย่างไรก็ตามฉันคิดว่ามันไม่สำคัญว่าเมื่อเพิ่มวิดเจ็ตในหน้าเว็บด้วย JS HTML พื้นฐานไม่มีอะไรเลย!
sebpiq

1
@Renesis: มันเป็นข้อเสียเปรียบครั้งใหญ่จริง ... แต่ด้วย Django มันค่อนข้างง่ายที่จะรวบรวม js และ css ของคุณจากหลาย ๆ เทมเพลตและรวมเข้าไว้ในไฟล์เดียว
sebpiq

2
หมายความว่าคุณสามารถให้บริการหน้าเว็บปกติหน้าเว็บสำหรับมือถือและหน้าเว็บที่พิมพ์ได้โดยไม่ต้องเขียนแต่ละหน้าด้วยมือตั้งแต่เริ่มต้นเพียงแค่ปรับแต่งงานนำเสนอ (เช่น CSS)
Robert Harvey

คำตอบ:


5

ฉันรักษาโครงสร้างนี้

สำหรับแต่ละหน้าหรือตัวควบคุมฉันให้โฟลเดอร์สำหรับหน้า html (หรือ aspx หรือ php ฯลฯ ) ในโฟลเดอร์นั้นยังเป็นโฟลเดอร์สำหรับไฟล์ js, xml, รูปภาพและ css สิ่งเหล่านี้มีไว้สำหรับหน้า / การควบคุมเฉพาะไม่ใช้ทรัพยากรร่วมกัน

ในรูทไซต์ยังมีโฟลเดอร์ js, xml, images และ css ซึ่งแต่ละไฟล์มีทรัพยากรที่มีอยู่ทั่วทั้งไซต์

ไฟล์ js และ css ของไซต์แบบกว้างถูกรวมฝั่งเซิร์ฟเวอร์และส่งคืนเป็นไฟล์ js ไฟล์เดียว สิ่งที่เฉพาะเจาะจงของหน้าเนื่องจากโดยปกติจะมีเพียงหนึ่งหน้าเท่านั้น

สิ่งนี้จัดระเบียบทรัพยากรของฉันตามขอบเขตของพวกเขา และในขณะที่ฉันอาจมีไฟล์ js โหลในโฟลเดอร์ root js พวกเขาจะถูกส่งคืนเป็นทรัพยากร js เดียวโดยรวมและลดขนาดด้านเซิร์ฟเวอร์ (และแคชผลลัพธ์)

ฉันยังไม่ได้โหลดทรัพยากรเฉพาะของ pagex เมื่อฉันอยู่ในหน้า "ขยะ" เพียงอย่างเดียวอาจอยู่ในไฟล์ทรัพยากรทั้งไซต์ แต่เนื่องจากแคชและทรัพยากรจำนวนมากจะถูกใช้ในหลาย ๆ ที่จึงมีประสิทธิภาพมากขึ้น


1
ฟังดูเข้าท่า ! ฉันไม่ได้คิดถึงการจัดกลุ่มไฟล์ในโฟลเดอร์แยกกันและรวบรวมเพื่อให้บริการ! มันแก้ปัญหาทั้งหมด - แคช, SoC, ... - ในขณะที่ช่วยให้การห่อหุ้ม เยี่ยมมาก!
sebpiq

2

โดยทั่วไปการประชุมคือการมีไฟล์แยกต่างหากสำหรับ JS / CSS / HTML เพื่อรักษาแยกเนื้อหานำเสนอและพฤติกรรม อย่างไรก็ตามหากความเร็วกลายเป็นปัญหา


แยกไฟล์ช่วยเพิ่มความเร็วจริง ๆ แล้วลดระดับ: \
Raynos

CSS และ JS ที่น้อยกว่าในไฟล์ HTML คือการร้องขอหนึ่งหน้าแทนที่จะเป็นการร้องขอสามหน้าซึ่งอาจจะดีกว่าสำหรับการแสดงหน้าจำนวนมากอย่างรวดเร็ว หรืออย่างน้อยก็รวมได้ตามต้องการ - code.google.com/speed/page-speed/docs/rtt.html
Bratch

1

ในไฟล์วิดเจ็ตหลายไฟล์ที่เลือก

  • HTML
  • เค้าโครง css ขั้นพื้นฐาน
  • ควบคุมการโต้ตอบโดยตรงและการปรับปรุง UX ด้วยบิตของ JS

ฉันมีเครื่องมือองค์กร ( ทรินิตี้ ) ที่ส่งเสริมให้คุณทำเช่นนั้น

ยกเว้นว่าไฟล์วิดเจ็ตนั้นแบ่งออกเป็น 3 ไฟล์ย่อยคือ HTML, CSS และ JS ซึ่งหมายความว่าคุณมีไฟล์แยกต่างหาก แต่ยังคงเชื่อมโยงอยู่

วิธีนี้ช่วยหลีกเลี่ยงปัญหาไฟล์ไขมัน แต่ยังคงให้ไฟล์แยกกัน

ดังนั้นการแยกความกังวลออกมาจึงไม่ได้หมายความว่าคุณควรมีไฟล์ HTML / CSS / JS ขนาดใหญ่ คุณควรมีรหัสสามเท่า<HTML, CSS, JS>สำหรับทุกรหัสที่คุณใช้ซ้ำได้

ตอนนี้ไม่มีอะไรผิดปกติในการมีสิ่งเหล่านี้ในไฟล์เดียวตราบใดที่พวกเขาแยกอย่างชัดเจน

วิดเจ็ตที่ดูเหมือน

<div id="wrapper">
  <style scoped> CSS code </style>
  <script> JS code </script>
  HTML code
</div>

ดีและยิ่งใหญ่ ยกเว้นการมีทุกสิ่งในไฟล์เดียวทำให้ผู้ดูแลระบบเริ่มผสมและจับคู่ CSS / JS / HTML ได้ยากเกินไป

มันทำให้ง่ายเกินไปที่จะเปลี่ยนเป็นสปาเก็ตตี้เมื่อเวลาผ่านไป

เหตุผลหลักที่ผู้คนโปรโมตไฟล์แยกต่างหากคือสองเท่า

  • แยกการดาวน์โหลด ทันทีที่คุณคัดลอกและวางรหัส css / js ลงใน "widgets" หลาย ๆ ตัวคุณจะต้องแยกมันออกเป็นไฟล์ของตัวเอง
  • โค้ดสปาเก็ตตี้ที่มีความน่าเชื่อถือแบบอุกอาจโดยไม่ต้องพึ่งพาผู้เขียนเพื่อเก็บ css / js / html ของพวกเขาไว้ในไฟล์เดียว

อ๋อ ... คำแนะนำเดียวกับชาด! และแน่นอนฉันลองใช้ทันทีและฉันขาย :) นี่มันสะอาดกว่านี้ ... เครื่องมือของคุณสำหรับโหนดใช่มั้ย ฉันควรหาอะไรแบบนั้นสำหรับ Django ...
sebpiq

@sebpiq สำหรับโหนด แต่ฉันจะย้ายไปยังไคลเอนต์ นอกจากนี้ยังเป็นอัลฟาและฉันกำลังทำงานอย่างหนักเพื่อทำให้เป็นทั้งแพลตฟอร์มองค์กร HTML / CSS / JS รวมถึงการใช้งานโค้ดไคลเอนต์ / เซิร์ฟเวอร์อีกครั้ง ฉันสงสัยว่าคุณจะพบอะไรเช่นนี้บนแพลตฟอร์มอื่น ๆ คุณสามารถพอร์ตได้แม้ว่า o /
Raynos

1

เป็นวิธีปฏิบัติที่ดีในการแยก html, css และ js เนื่องจากทำให้การจัดการเว็บไซต์ของคุณง่ายขึ้น

เมื่อคุณเริ่มต้นคุณอาจมี index.html หลักและไฟล์ styles.css เพียงไฟล์เดียว แต่มีแนวโน้มมากขึ้นเมื่อเว็บไซต์ของคุณเติบโตขึ้นคุณจะพบกับสคริปต์และสไตล์ชีทที่หลากหลายสำหรับแต่ละองค์ประกอบหรือ ปลายทาง

ใช้แยก:

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

ควรกล่าวถึง CSS / JS ด้วยหากใช้กับหลาย ๆ หน้าในเว็บไซต์ของคุณ


... และมี "เครื่องมือสร้าง" จำนวนมากซึ่งสามารถรวบรวมเนื้อหา JS และ CSS จาก (ไม่ได้ปรับใช้) แต่ละไฟล์เพื่อสร้างไฟล์จริงที่นำไปใช้ ... รวบรวมเนื้อหาการลบ (หรือตรวจจับ) การทำซ้ำการลดขนาดและ ดังนั้นบน
Mike Robinson
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.