Khi nào JavaScript nên tạo HTML?


34

Tôi cố gắng tạo ra càng ít HTML từ JavaScript càng tốt. Thay vào đó, tôi thích thao tác đánh dấu hiện có bất cứ khi nào tôi có thể và chỉ tạo HTML khi tôi cần chèn động một phần tử không phải là ứng cử viên tốt để sử dụng Ajax. Điều này, tôi tin rằng, giúp duy trì mã dễ dàng hơn nhiều và nhanh chóng thực hiện các thay đổi đối với mã này vì đánh dấu dễ đọc và theo dõi hơn. Nguyên tắc nhỏ của tôi là: HTML dành cho cấu trúc tài liệu, CSS là để trình bày, JavaScript là dành cho hành vi.

Tuy nhiên, tôi đã thấy rất nhiều mã JS tạo ra các ụ HTML, bao gồm toàn bộ các biểu mẫu và hộp thoại phương thức nặng nội dung. Nói chung, phương pháp nào được coi là thực hành tốt nhất? Trong trường hợp nào JavaScript nên được sử dụng để tạo HTML và khi nào thì không nên?


2
Tại sao bạn nghĩ rằng đánh dấu dễ đọc và theo dõi hơn thông qua Ajax?
psr

3
Tôi thường sử dụng Ajax theo một trong hai cách: tải toàn bộ đoạn mã HTML được kết xuất sẵn vào trang hoặc một mảng JSON mà tôi phân tích cú pháp và sau đó chèn dữ liệu vào các phần tử hiện có. Rất hiếm khi tôi tự động tạo HTML từ dữ liệu Ajax và chèn nó vào trang. Vì nội dung Ajax thường được kết xuất trước dưới dạng HTML, nên dễ đọc hơn là cố gắng theo dõi việc tạo phần tử động trong JavaScript. Tôi có thể nhanh chóng lướt qua nó và xem cấu trúc và nội dung.
VirtuosiMedia

2
Câu hỏi cực kỳ gai góc ...
Mark Canlas

2
@VirtuosiMedia - Nhưng các đoạn mã HTML được kết xuất lại có vấn đề tương tự khi kết xuất phía máy chủ như khi chúng được kết xuất qua javascript không? Tôi không cố gắng để gây tranh cãi, tôi thực sự không hiểu vấn đề của bạn là gì.
psr

1
@psr Nói chung là không. Khi sử dụng khung công tác JS hoặc thậm chí chỉ là vanilla JavaScript, cuối cùng bạn sẽ tạo HTML của mình bằng một loạt các lệnh gọi và hàm phương thức. Nếu điều này được thực hiện với một số lượng lớn các yếu tố, có thể rất khó để xem cấu trúc tài liệu thực tế là gì. Ngược lại, phía máy chủ được tạo HTML thường sẽ duy trì cấu trúc sạch và chỉ có mã máy chủ lặp lại dữ liệu vào một mẫu HTML thay vì tự tạo các phần tử. Vì vậy, nếu bạn muốn thực hiện một thay đổi trong hành vi JS, bạn phải theo dõi thông qua các phương thức tạo các phần tử để xem cấu trúc phân cấp.
VirtuosiMedia

Câu trả lời:


19

Bất cứ khi nào tôi gặp phải thế hệ HTML nặng nề trong javascript, nó hầu như chỉ nằm trong một plugin UI độc lập. Điều này có ý nghĩa, vì nó cho phép đóng gói toàn bộ plugin trong một tệp .js (+ a .css để tùy chỉnh kiểu), do đó làm cho nó dễ dàng sử dụng lại, phân phối và độc lập với khung được sử dụng trong ứng dụng.

Vì vậy, nếu bạn đang viết một plugin javascript độc lập hoặc một thành phần UI chung mà bạn muốn sử dụng trên các ứng dụng khác nhau, cách tiếp cận như vậy có những mặt trái của nó. Mặt khác, tôi nghĩ rằng nó vừa sạch hơn, dễ viết hơn và dễ bảo trì hơn khi bạn giữ thế hệ html tránh xa javascript và ở phía máy chủ.


29

Tôi nghĩ rằng vấn đề là bạn đang so sánh khuôn mẫu của máy chủ được viết rõ ràng với việc tạo HTML phía máy khách ad-hoc được viết xấu. Tất nhiên mã được viết sạch sẽ dễ đọc, bảo trì và theo dõi hơn.

Bạn gọi mã phía máy khách là "gò của HTML", nhưng tất nhiên đó là cùng một mã HTML ở bất cứ nơi nào nó được tạo. Các "gò" thực sự là một khối lớn của mã.

Có rất nhiều thư viện templating phía khách hàng ngoài kia. Chúng hoạt động tương tự như phía máy chủ. Đối với những gì bạn nên thích, sự cân bằng hiệu năng rất phức tạp, nhưng JSON thường nhỏ gọn hơn HTML mà nó trở thành và có mẫu trên máy khách có thể loại bỏ một số cuộc gọi máy chủ. Mặt khác, máy khách có thể bị vô hiệu hóa hoặc quá chậm để không thực tế, do đó, nó cũng phụ thuộc vào đối tượng mục tiêu của bạn. Nhìn chung, tôi nghĩ rằng các phương pháp tiếp cận khá tương đương, với yếu tố lớn nhất là khả năng trình duyệt của đối tượng mục tiêu của bạn.

Nhưng nó phụ thuộc vào chính xác những gì bạn đang làm, cho dù bạn thích JS với môi trường máy chủ của bạn, giải pháp tạo khuôn mẫu nào bạn thích, v.v.


15

Có một xu hướng sử dụng các mẫu phía máy khách, trong trường hợp cực đoan, bạn có máy chủ chỉ cung cấp API RESTful, ví dụ ở định dạng JSON, trong khi thực hiện tất cả phía máy khách kết xuất. Ưu điểm của cách tiếp cận đó là mã và các mẫu mã JS là các tài nguyên tĩnh có thể được lưu trữ, ủy quyền và phân phối qua CDN. Điều này không thể được thực hiện nếu bạn có HTML động được tạo ở phía máy chủ. Ngoài ra, chỉ trả lại dữ liệu từ API RESTful ở định dạng nhẹ sử dụng ít tài nguyên phía máy chủ hơn, giúp phản hồi nhanh hơn. Ngoài ra, nhẹ hơn là chuyển mạng ít hơn, điều này một lần nữa làm cho nó nhanh hơn. Bằng cách này, bạn có thể có ứng dụng có độ trễ thấp rất nhạy ngay cả trên các kết nối chậm như 3G. Do đó, phương pháp này phổ biến cho các trang và ứng dụng di động.

Có rất nhiều các thư viện thực hiện các mẫu JS, một trong những người nổi tiếng là tinh khiết , Moustachedust.js . Sau này được sử dụng bởi LinkedIn, họ đã mô tả các ưu điểm trong bài viết của họ "Rời khỏi các trang web bụi bặm: chuyển LinkedIn sang các mẫu phía máy khách của Dust.js" .


Tôi đang tạo ứng dụng web đầu tiên của mình (vì chúng được gọi là những ngày này, tôi có nền java / c ++). Và có vẻ tự nhiên đối với tôi để tạo ra nhiều html với JS khi người dùng trải qua một quá trình mà anh ta cần một số thành phần UI khác nhau và tôi không bao giờ tải lại trang
Emile Vrijdags

2

Ưu điểm của việc tạo HTML trên máy khách là bạn giảm tải công việc kết xuất cho từng máy khách, thường không hoạt động để chờ phản hồi. Giải phóng nhiều tài nguyên máy chủ hơn để chỉ cung cấp dữ liệu JSON và nội dung tĩnh (HTML, JS và CSS).

Chúng tôi làm một ứng dụng web tạo HTML độc quyền bằng Javascript. 87% lượt truy cập máy chủ là dữ liệu JSON, nội dung tĩnh thường được tải một lần, sau đó từ bộ đệm của trình duyệt.

Nhưng bạn không thể sử dụng nó - ít nhất là không dễ dàng - nếu bạn cần SEO. Hoặc nếu bạn nhắm mục tiêu một dân số đã tắt Javascript, nhưng tôi không chắc nhóm này vẫn phù hợp với Youtube, Twitter, Facebook, Gmail, ... một cách tự nhiên buộc mọi người phải kích hoạt nó.


0

Về tải trang động, người ta phải nhận ra rằng đằng sau tất cả "Đám mây AJAX của JQuery!" ma thuật, chỉ có hai điều có thể xảy ra:

  1. Mã của một phần tử đang được chèn vào div (xấu) hoặc
  2. Nội dung đang được tải trong iframe (tốt hơn, nhưng nó không giống nhau ...)

Về câu hỏi ban đầu, tôi chỉ tạo nội dung HTML qua Javascript khi tôi đang tạo một ứng dụng web thuộc loại nào đó đọc dữ liệu XML hoặc JSON được lưu trữ trên máy chủ và nó bị thay đổi rất nhiều.

Sẽ không có ý nghĩa gì khi tải nội dung tĩnh trên một trang bằng Javascript, vì luôn có khả năng nó sẽ không tải đúng hoặc khách hàng sẽ bị vô hiệu hóa ("hãy xem quảng cáo phiền phức đó!"). Ngoài ra, điều này khiến cho việc thay đổi nội dung HTML trở nên rất khó khăn khi nó bị nhòe bên trong document.write()một chuỗi xấu xí hoặc một chuỗi document.createElement().

Vì vậy, bạn đã đúng; hoặc nhập HTML thô hoặc nếu nội dung động là cần thiết, hãy sử dụng tập lệnh phía máy chủ để xuất những gì cần thiết. Sử dụng Javascript để tiêm HTML chỉ khi trang web hoạt động mà không có kết nối Internet hoặc trường hợp tương tự.

Một lưu ý cuối cùng, nếu bạn muốn triển khai xmlhttprequests, er, AJAX, vào một trang web, có lẽ cách tốt nhất / an toàn nhất là lưu trữ dữ liệu theo định dạng dữ liệu (như XML), tải và xuất dữ liệu theo đó trên máy khách. document.writeelement.innerHTMLthực sự không phải là cách tốt nhất để thao túng nội dung và nhất định sẽ gây ra những cơn đau đầu tiềm năng trong tương lai (tại sao tập lệnh này không chạy? <i>Thẻ bị hỏng của tôi đang in nghiêng mọi thứ! v.v.).


1
Đó chắc chắn không phải là những điều duy nhất có thể xảy ra. Javascript có toàn quyền truy cập vào DOM và bạn có thể thao tác với cây DOM khi bạn thấy phù hợp khi xử lý phản hồi AJAX.
tdammers

Tại sao tiêm nội dung vào một div xấu?
Peter Taylor

Nội dung tiêm @PeterTaylor không tệ, sử dụng innerHTMLlà.
Raynos

@PeterTaylor Nếu một hoặc hai yếu tố được thêm vào document.appendChildhoặc một cái gì đó, có lẽ sẽ không có bất kỳ vấn đề nào. Vấn đề là với mã trông giống như thế này div.innerHTML="<table cellpadding='0'><tr><td><label>Val:</label></td><td><input type='text' /></td></tr></table>- đây là một cơn ác mộng để gỡ lỗi.
Jeffrey Sweeney

Nhưng điều đó có liên quan gì với '"JQuery AJAX Cloud!" ma thuật'? Ví dụ của bạn trông giống như phản đề của nó.
Peter Taylor

0

Câu thần chú của tôi về điều đó là: khi nó dễ dàng hơn và không ai quan tâm đến việc đánh dấu.

Bạn cũng có thể tận dụng cả hai và xác định giới hạn trong đó quá khó để quan tâm đến việc đánh dấu và bạn muốn tập trung vào cây DOM. Ví dụ: một biểu mẫu có các hàng động (ví dụ: "thêm tệp đính kèm khác"), bạn có thể muốn biểu mẫu trong HTML, nút "thêm hàng" và nút gửi ... bạn có thể không muốn tạo HTML với ngôn ngữ phía máy chủ của bạn hoặc một cái gì đó.

Một quy tắc khác của ngón tay cái có thể được tái sử dụng. Nếu giải pháp của bạn có thể được áp dụng cho các vấn đề khác ở phía máy khách, hãy gói nó trong js.


0

Chúng tôi xây dựng các ứng dụng một trang (ala Google Mail) và có nghĩa là không có thế hệ server-side của HTML trong các ứng dụng của chúng tôi cả. Thay vào đó, chúng tôi đang sử dụng Backbone.js để cấu trúc phía máy khách và Tay cầm của chúng tôi để hiển thị JSON của chúng tôi thành các mẫu đi vào trang. Nó thực sự hoạt động rất tốt và chúng tôi sắp kết thúc ứng dụng đầu tiên sử dụng nó và chúng tôi sẽ giải quyết một dự án thậm chí còn lớn hơn trong tương lai.

Bất kỳ loại máy khách béo nào mà máy chủ chỉ được sử dụng để duy trì dữ liệu và trả về kết quả truy vấn là con đẻ trong một thời gian mà bạn sẽ muốn JavaScript tạo HTML. Chỉ cần chắc chắn sử dụng một công cụ mẫu tốt để làm cho nó sạch sẽ và dễ dàng.


0

Tôi đang tạo mã html trong jquery vì tôi đang sử dụng một portlet và sau khi thực thi mã jsp, tôi cần tạo một vòng lặp với mã html, mà tôi không thể vào một vòng lặp java với một số mã javascript bên trong. Vì vậy, tôi đang hiển thị danh sách mảng java trong một mảng javascript và sử dụng các chuỗi để tạo html.

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.