Bạn có nên thực sự giữ js, html và css của bạn riêng biệt?


10

Tôi nghe / đọc tất cả thời gian rằng nó sạch hơn để giữ js , htmlcss của bạn tách biệt. Giả sử nó làm cho nó dễ dàng hơn để duy trì, gỡ lỗi. Giả sử nó hiệu quả hơn, vì nó cho phép lưu trữ / thu nhỏ các tập tin cssjs .

Theo như tôi biết, sử dụng các khung web (Django, Rails, ...), thư viện tạo khuôn mẫu javascript, ... Tôi có xu hướng chia khá nhiều trang html thành nhiều mẫu có thể sử dụng lại - một số loại widget nếu bạn muốn . Ví dụ: tôi có thể có một tiện ích nguồn cấp tin tức , một tiện ích được chọn nhiều , v.v ... mỗi trang có bố cục nhất quán trên các trang khác nhau và mỗi trang được điều khiển bởi đoạn javascript của nó.

Với tổ chức này - có vẻ như tôi sạch sẽ nhất có thể, tối đa hóa khả năng sử dụng lại - tôi gặp khó khăn để hiểu tại sao việc giữ tất cả jscss trong các tệp riêng biệt sẽ đơn giản hơn . Tôi nghĩ rằng nó sẽ đơn giản hơn rất nhiều ví dụ :

trong tập tin chọn nhiều widget

  • html
  • bố trí css cơ bản
  • kiểm soát các tương tác trực tiếp và các cải tiến UX với một chút JS.

Tôi nghĩ theo cách đó nó có thể tái sử dụng nhiều hơn, dễ bảo trì hơn nhiều, vì bạn không phải cuộn qua tệp js béo , sau đó chuyển sang và cuộn qua tệp css chất béo , chuyển lại sang tệp html của bạn ... qua lại .

Vì vậy, tôi rất muốn biết làm thế nào các bạn tổ chức mã của bạn, nếu bạn tuân theo sự tách biệt thường được đề xuất.

  • Có những lý do thực sự tốt để làm như vậy?
  • không phải là các hướng dẫn trên web thường cho rằng bạn sẽ không sử dụng bất kỳ công cụ ưa thích nào (trong trường hợp đó tôi muốn có được các bài đọc trực tuyến cập nhật hơn cho các thực tiễn tốt nhất)?
  • Có phải chỉ là vấn đề ưu tiên?

2
Nguyên tắc mà bạn ám chỉ được gọi là Phân tách nội dung trình bày và nội dung.
Robert Harvey

8
Hãy nhớ rằng nếu bạn không tách ra các tệp thì người dùng của bạn sẽ tải xuống HTML và CSS được nhúng trên mỗi lần tải trang thay vì tải xuống một lần và lưu vào bộ đệm.
Nicole

@RobertHarvey: ok tham khảo tốt ... Nhưng lý do duy nhất được liệt kê ở đó cho nội dung / trình bày tách biệt là cải thiện khả năng đọc của máy. Tuy nhiên tôi nghĩ nó không thành vấn đề khi các widget được thêm vào trang bằng JS. Các html cơ bản không chứa chúng dù sao!?
sebpiq

1
@Renesis: Đó là một nhược điểm lớn, đúng ... tuy nhiên với Django chẳng hạn, khá dễ dàng để thu thập js và css của bạn từ nhiều mẫu và hợp nhất chúng vào một tệp.
sebpiq

2
Có nghĩa là, bạn có thể phục vụ một trang web bình thường, một trang web di động và một trang có thể in mà không cần phải viết từng trang bằng tay, chỉ bằng cách điều chỉnh bản trình bày (ví dụ CSS).
Robert Harvey

Câu trả lời:


5

Tôi duy trì cấu trúc này

Đối với mỗi trang hoặc điều khiển, tôi cung cấp cho nó một thư mục cho trang html của nó (hoặc aspx hoặc php, v.v.). Trong thư mục đó cũng là các thư mục cho các tập tin js, xml, hình ảnh và css. Đó là cho trang / kiểm soát cụ thể, không chia sẻ tài nguyên.

Trong thư mục gốc, cũng là các thư mục js, xml, hình ảnh và css, mỗi thư mục chứa tài nguyên trên toàn trang web.

Các tệp js và css rộng của trang web được cuộn lên phía máy chủ và được trả lại dưới dạng một tệp js. Các trang cụ thể, vì thường chỉ có một trên mỗi trang, được để lại một mình.

Điều này tổ chức tài nguyên của tôi như phạm vi của họ. Và trong khi tôi có thể có một tá tệp js trong thư mục js gốc, chúng sẽ được trả về dưới dạng một tài nguyên js bằng cách kết hợp và thu nhỏ chúng ở phía máy chủ (và lưu kết quả vào bộ đệm).

Tôi cũng không tải tài nguyên cụ thể cho pagex khi tôi ở trang. "Chất thải" duy nhất có thể nằm trong tệp tài nguyên trên toàn trang, nhưng vì nó được lưu trong bộ nhớ cache và nhiều tài nguyên SILL được sử dụng ở nhiều nơi, nên hiệu quả hơn.


1
Nghe hay đấy! Tôi đã không nghĩ đơn giản là nhóm các tệp trong các thư mục riêng biệt và thu thập chúng để phục vụ! Nó giải quyết tất cả các vấn đề - bộ nhớ đệm, SoC, ... - trong khi cho phép đóng gói. Tuyệt quá !
sebpiq

2

nói chung, quy ước là có các tệp riêng biệt cho JS / CSS / HTML để duy trì sự tách biệt về nội dung, cách trình bày và hành vi. Tuy nhiên, nếu tốc độ trở thành một vấn đề thì bất cứ điều gì cũng xảy ra.


các tệp riêng biệt thực sự cải thiện tốc độ thay vì làm giảm tốc độ của nó: \
Raynos

Số lượng nhỏ CSS và JS trong tệp HTML là một yêu cầu trang thay vì ba yêu cầu trang, có thể tốt hơn để phục vụ một số lượng lớn các trang rất nhanh. Hoặc ít nhất kết hợp chúng khi cần - code.google.com/speed/page-speed/docs/rtt.html
Bratch

1

trong tập tin chọn nhiều widget

  • html
  • bố trí css cơ bản
  • kiểm soát các tương tác trực tiếp và các cải tiến UX với một chút JS.

Tôi có một công cụ tổ chức (bộ ba ) thúc đẩy bạn làm điều đó.

Ngoại trừ tệp widget đó được chia thành 3 tệp nhỏ, HTML, CSS và JS. Điều này có nghĩa là bạn có các tệp riêng biệt nhưng chúng vẫn được liên kết.

Điều này tránh được vấn đề của các tập tin chất béo nhưng vẫn cung cấp cho bạn các tập tin riêng biệt.

Vì vậy, chỉ cần đặt các mối quan tâm không có nghĩa là bạn nên có một tệp HTML / CSS / JS lớn. Bạn nên có nhiều bộ ba <HTML, CSS, JS>cho tất cả mã đóng gói có thể sử dụng lại của bạn

Bây giờ không có gì sai khi có tất cả những thứ này trong một tệp miễn là chúng được phân tách rõ ràng.

Vì vậy, một widget trông giống như

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

Là tốt, và tuyệt vời. Ngoại trừ việc có tất cả mọi thứ trong một tệp, giúp người bảo trì bắt đầu trộn và kết hợp CSS / JS / HTML quá dễ dàng.

Nó làm cho nó quá dễ dàng để biến nó thành spaghetti theo thời gian.

Lý do chính khiến mọi người quảng bá các tệp riêng biệt là hai lần

  • tải xuống riêng biệt. Ngay sau khi bạn sao chép và dán bất kỳ mã css / js nào vào nhiều "widget", bạn cần đưa yếu tố đó vào tập tin của chính nó.
  • Tích cực ngăn chặn mã spaghetti bằng cách không dựa vào tác giả để giữ css / js / html của họ tách biệt trong một tệp duy nhất

Đúng ... đề nghị tương tự như Chad! Và thực sự tôi đã thử ngay lập tức, và tôi được bán :) Cái này sạch hơn rất nhiều như thế ... Công cụ của bạn dành cho nút phải không? Tôi nên tìm thứ gì đó tương tự cho Django ...
sebpiq

@sebpiq nó là nút, nhưng tôi đang chuyển nó đến máy khách. Đó cũng là alpha và tôi đang nỗ lực để biến nó thành toàn bộ nền tảng tổ chức HTML / CSS / JS, bao gồm cả việc sử dụng lại mã máy khách / máy chủ. Cá nhân tôi nghi ngờ bạn sẽ tìm thấy bất cứ thứ gì như thế này trên các nền tảng khác, bạn có thể chuyển nó qua mặc dù o /
Raynos
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.