JavaScript nội tuyến tốt hay xấu?


16

Hiện tại tôi đã chuyển từ WordPress sang Yii framework và một nhà phát triển bên ngoài đang xây dựng lại trang web của tôi.

Một điều tôi nhận thấy là mỗi lần anh ta gọi AJAX / jQuery theo cách Yii, nó sẽ chèn JavaScript vào dòng trong trang web. Mặc dù có vẻ như mã JavaScript được đặt bên dưới chân trang, nhưng nó vẫn là dòng.

Nói chung, có vẻ như mã JavaScript thường xuyên được đưa vào bên trong trang web. Tôi đã luôn nghĩ rằng các tập lệnh JavaScript nên, càng nhiều càng tốt, được đặt trong các tệp JavaScript. Đây có phải là một xu hướng "mới" sắp tới? Hoặc tôi vẫn nên cố gắng giữ mã JavaScript trong các tệp riêng biệt?


Chính xác ý bạn là gì khi nó chèn JavaScript nội tuyến vào trang web ?
Salman A

3
Vì lợi ích của những người khác tìm thấy câu hỏi này và đang nghĩ về những điều như thế <a onClick="function(){/* do stuff */} ">Click Here</a>này, tôi hiểu, bị coi là RẤT xấu và người ta nên tách mã của họ khỏi HTML Xem: Bài viết này
TecBrat

1
@ user1066946 t.co/j1RpJgwoku :-)
Kos

1
@ user1066946 Tôi thực sự thích sử dụng Angular, tôi chỉ quan sát thấy "web ngữ nghĩa" đã tạo thành một vòng tròn (về việc giữ một số mã keo bên cạnh DOM)
Kos

1
"Mặc dù có vẻ như mã JavaScript được đặt bên dưới chân trang, nhưng nó vẫn là dòng." - Nghe có vẻ như bạn đang đề cập đến JavaScript nhúng , thay vì JavaScript "nội tuyến" (mà TecBrat đề cập đến).
MrWhite

Câu trả lời:


13

JavaScript nội tuyến tăng thời gian tải xuống cho trang, điều này không tốt. Với một cuộc gọi đến một .jstập tin, ít nhất đây có thể là các cuộc gọi song song và thời gian tải xuống nội dung giảm. Có đôi khi bạn có thể đặt JavaScript trực tiếp vào mã HTML, nhưng bạn thường không nên tải cái này càng nhiều càng tốt.

Hãy nhớ rằng thời gian tải xuống trang (nghĩa là HTML) và không phải tất cả các cuộc gọi tài nguyên đều ảnh hưởng đến các số liệu ảnh hưởng đến xếp hạng (mặc dù là PageRank hoặc trong SERPs, điều đó không quan trọng). Vấn đề là, nó ảnh hưởng đến hiệu suất trang web cho SEO tuy nhiên nó biểu hiện.


7
Đàm phán kết nối thứ hai với một máy chủ có lẽ cùng tải xuống cùng một lượng dữ liệu có nhanh hơn trong luồng hoạt động không? thông thường nếu bạn nhận được, giả sử, 50Kb / giây trên một tệp đến máy chủ lưu trữ, bắt đầu phiên thứ hai có thể cắt nó để cả hai hiện tại là 25Kb / giây. Trừ khi máy chủ lưu trữ trên mỗi kết nối vì một số lý do.
EkriirkE

Có một con đến tập tin bên ngoài mặc dù. Nếu không thực hiện đúng cách, bạn tạo mã DOMblocking, tức là kích hoạt doc.ready là chậm, ảnh hưởng percieved tốc độ. Nhưng nếu được thực hiện đúng cách, bên ngoài là con đường để đi
Martijn

4
.jscác tệp tốt hơn cho bộ nhớ đệm, điều đó không có nghĩa là hai kết nối đến cùng một máy chủ sẽ làm cho tốc độ tải xuống của bạn lớn hơn một cách kỳ diệu.

Ý nghĩ phân chia băng thông, trong khi tôi hiểu logic của bạn và nó không hoàn toàn sai, là một chút sai lầm. HTML nhỏ hơn mất ít thời gian hơn và bất kỳ cuộc gọi tiếp theo nào thực sự có thể chờ.
Closnoc

3
nếu bạn đang chờ đợi thời gian, bạn đã sai khi nhìn vào băng thông. nhìn vào profiler tại thời gian tải: thông thường thời gian kết nối là 10 - 100 lần LỚN so với thời gian trao đổi dữ liệu thực. điều này có nghĩa là FRAGMENTATION là một vấn đề thực sự và việc sử dụng một tệp bên ngoài, dành riêng cho các js thực sự nhỏ có thể là điều tồi tệ nhất trong nội tuyến. Inline tốt hơn trên trình duyệt không thực hiện song song hóa
Lesto

29

Trên trang web chuyển đổi tiền tệ của tôi, phần lớn các phiên là lượt xem trang đơn. Điều này là do người dùng có thể thực hiện tính toán tiền tệ của họ trực tiếp trên trang đích (tất cả các tính toán được xử lý phía máy khách bằng JavaScript.)

Trang của tôi tải xuống và hiển thị trong khoảng một nửa thời gian khi tất cả các tài nguyên (css, js và thậm chí cả hình ảnh ) là nội tuyến trong trang. Vì rất ít người dùng của tôi xem nhiều trang, tôi sẽ không được hưởng lợi nhiều từ một số tài nguyên này được lưu trong bộ nhớ cache giữa các lần xem trang.

Trang web của tôi không phải là điển hình. Hầu hết các trang web có nhiều trang mỗi phiên và hình ảnh lớn sẽ khiến kỹ thuật của tôi ít được áp dụng hơn. Không có một giải pháp chính xác cho câu hỏi này; nó phụ thuộc vào trang web Bạn cần tự đo lường nó dựa trên hành vi điển hình của người dùng của bạn.


12

Không nhất thiết phải có JavaScript trong tệp HTML của bạn nhưng bạn phải thực hiện cuộc gọi phán xét về nó.

xấu nếu bạn có một số lượng lớn của JavaScript được sử dụng trên nhiều trang. Trong trường hợp đó, JavaScript phải ở trong một tệp bên ngoài, được nén và có thể lưu trong bộ nhớ cache và nếu trang web của bạn có lưu lượng truy cập rất lớn, bạn nên sử dụng CDN.

Tuy nhiên, nếu bạn có một lượng JavaScript nhỏ, việc lưu nó vào một tệp bên ngoài có thể bị phủ nhận bởi thực tế bạn cần phải thực hiện một yêu cầu HTTP bổ sung để truy xuất nó. Trong trường hợp này, việc giữ JavaScript trong trang của bạn sẽ hiệu quả hơn.

Sau đó, một lần nữa, nếu cùng một đoạn mã JavaScript nhỏ này được sử dụng trên nhiều trang, sẽ có ích khi đặt nó vào một tệp bên ngoài để tận dụng bộ nhớ đệm.

Cuối cùng, bạn phải cân nhắc kích thước của JavaScript so với chi phí thực hiện các yêu cầu HTTP bổ sung. Đối với hầu hết các phần, đối với một trang web 'trung bình', có lẽ nó sẽ không tạo ra nhiều sự khác biệt nếu chỉ đưa nó vào một tệp bên ngoài.


4

Tôi là một nhà phát triển Yii và tôi có thể nói với bạn rằng Yii không liên quan gì đến việc này . Nó hoàn toàn thuộc về phía nhà phát triển , cho dù người đó đặt mã Javascript vào một tệp riêng biệt và đăng ký nó với trang HTML (chế độ xem) bằng CClientScript::registerScriptFilephương pháp hoặc đặt trực tiếp để xem mã (HTML) và đăng ký bằng CClientScript::registerScriptphương thức.

Theo câu trả lời của bạn, hầu hết các nhà phát triển Yii (chuyên nghiệp?) Bầu chọn mạnh mẽ cho cách tiếp cận đầu tiên, đó là - giữ càng nhiều mã Javascript trong các tệp riêng biệt càng tốt. Vì vậy, đây chắc chắn không phải là một xu hướng mới của tiền mã hóa, mà là một thực tiễn nhà phát triển tồi. Ít nhất, đó là cách nó được nhìn thấy trong cộng đồng Yii.

EDIT : Thật ra, tôi đã quên mất lập luận quan trọng nhất. Yii (cũng như hầu hết các khung PHP chuyên nghiệp khác) được xây dựng theo mẫu thiết kế MVC (thực ra là: mẫu kiến ​​trúc). Và mô hình tương tự có thể được sử dụng ở phía trước: mã HTML là mô hình (dữ liệu), CSS là khung nhìn (trang trí) và Javascript là bộ điều khiển. Tất cả trong số họ đưa vào các tập tin riêng biệt , .js.csscác file - minified, obsfucated và gzip trong kịch bản tốt nhất.

Khi bạn xây dựng ứng dụng Yii của mình, bạn có thể phá vỡ mô hình MVC và giữ mọi thứ trong cùng một tệp. Câu hỏi là - nó có đáng để làm như vậy không, những lợi ích (không có gì?) Và điều đó sẽ dẫn bạn đến đâu? Bạn có thể sử dụng cùng một lập luận, khi hỏi, có nên giữ mã JS nội tuyến hay không?


Đồng ý. Nhà phát triển dường như sử dụng các widget của bên thứ 3 cho mọi thứ; Tự động hoàn tất, tải lên hình ảnh ajax, vv Tất cả điều này thêm js nội tuyến.
Steven

Không, tôi không thể đồng ý. Tôi đang sử dụng Twitter Bootstrap trong các ứng dụng Yii của mình (có lẽ là tiện ích mở rộng lớn nhất và bộ công cụ khổng lồ của Yii) cũng như nhiều tiện ích mở rộng khác của Yii và không ai trong số chúng sử dụng JS nội tuyến. Nhà phát triển của bạn sẽ phải thực sự may mắn khi tìm thấy các tiện ích và tiện ích mở rộng, chỉ sử dụng Javascript nội tuyến. Bạn phải khá có kinh nghiệm trong Yii để bắt đầu viết các tiện ích mở rộng của riêng mình (ngoại trừ một số ít, được viết rất kém) và thậm chí nhà phát triển Yii bán kinh nghiệm sử dụng mã nội tuyến làm tùy chọn cuối cùng, nếu mọi thứ khác đều thất bại.
trejder

Sử dụng tiện ích mở rộng và tiện ích của bên thứ 3 trong Yii là một ý tưởng tuyệt vời (bạn không phải phát minh lại bánh xe). Nhưng, sử dụng mã JS nội tuyến trong ứng dụng hoặc tiện ích mở rộng Yii thực sự là một thái độ không tốt. Vì vậy, hoặc buộc nhà phát triển của bạn viết mã tốt hơn / sử dụng các tiện ích mở rộng và tiện ích tốt hơn hoặc ... có được một nhà phát triển tốt hơn! :]
trejder

Ok, cảm ơn đã phản hồi. Ngoài Stackoverflow, tôi có thể tìm thấy một cộng đồng Yii tốt ở đâu?
Steven

Tại diễn đàn Yii . Hầu hết các trang có thể truy cập tự do. Một số yêu cầu phải đăng ký một tài khoản và đăng nhập. Hầu hết các nhà phát triển Yii tại Stack Overflow đều có tài khoản riêng tại diễn đàn. Sau gần sáu năm tồn tại, khung Yii đã kiếm được một cộng đồng lớn các nhà phát triển, vì vậy nếu bạn xem xét kỹ, bạn sẽ có thể tìm thấy một vài nhà phát triển Yii trong cộng đồng địa phương hoặc thậm chí là khu phố. Chúc may mắn.
trejder

3

Nó thực sự phụ thuộc vào mục đích của trang web bạn đang phát triển:

Tôi sử dụng một lượng nhỏ JavaScript nội tuyến, trong khi tôi thích dùng các tệp JavaScript bên ngoài nếu nó lớn.

Dù bằng cách nào, khi trang tải JavaScript, nó phải được thực thi trước. Cách thực hành tốt nhất là sử dụng JavaScript bên ngoài để nó không kéo dài nội dung trang của bạn. Nó cũng làm cho việc gỡ lỗi dễ dàng hơn.


2

Câu trả lời thực sự phụ thuộc vào những gì đang được thực hiện.

Nếu bạn nhận thấy JavaScript nội tuyến được sử dụng trên toàn bộ trang web (ví dụ: tiện ích hiển thị bên trong tiêu đề trên tất cả các trang của trang web) thì có thể phù hợp để chuyển nó sang tệp JavaScript "phổ biến".

Trên thực tế, tôi sẽ chuyển càng nhiều JavaScript sang một tệp JavaScript phổ biến càng tốt ngay cả khi nó được sử dụng trên một trang. Tôi sẽ cấu hình máy chủ để gửi các tiêu đề nén và bộ đệm mạnh cho các tệp JavaScript; làm giảm kích thước của trang nhưng không làm tăng kích thước tệp JavaScript nhiều.

Mặt khác, nếu JavaScript chỉ đơn giản là một loạt các tùy chọn cấu hình / khởi tạo, ví dụ:

$(function () {
    myplugin({
        images: ["img1", "img2", "img3"]
    });
});

vì lý do nào đó không thể di chuyển mã sang tệp JavaScript bên ngoài (ví dụ: khi các tham số hình ảnh đến từ cơ sở dữ liệu) tôi sẽ giữ nó trong dòng. Phải nói rằng, tôi sẽ chọn các plugin của bên thứ ba "không phô trương" (hoặc chuyển đổi chúng như vậy).


2

Những câu trả lời bỏ lỡ đánh dấu. Có một cái nhìn vào bộ nhớ đệm nội tuyến .

Vì Yii được mã hóa bằng PHP, nên một mẫu PHP phổ biến (hoặc có thể không phổ biến) mà bạn sẽ thấy là các nhà phát triển đôi khi sẽ viết mã PHP để tạo mã Javascript một cách linh hoạt tại máy chủ - dựa trên một số trạng thái, điều kiện hoặc giá trị mà máy chủ biết - và sau đó gửi tất cả cho máy khách trong một đợt, cho phép máy khách thực thi chức năng và bỏ qua một số tính toán đã được máy chủ thực hiện.

Thay vì gửi toàn bộ các hàm Javascript chung trong tệp .js đến máy khách không có ngữ cảnh cho đến khi được cung cấp dữ liệu (dữ liệu có thể nằm trên máy chủ và yêu cầu một chuyến đi khứ hồi), chúng tôi có thể "nướng" bối cảnh / dữ liệu là một phần của chức năng Javascript. Điều này rất tiết kiệm vì điều đó có nghĩa là bạn đang gửi chức năng / dữ liệu cùng nhau và chỉ gửi chức năng / dữ liệu mà khách hàng có thể cần tại thời điểm đó, thay vì gửi toàn bộ ứng dụng khi tải trang đầu tiên. Điều đó cũng có nghĩa là bạn không cần phải hiển thị toàn bộ ứng dụng của mình để dễ dàng tải xuống và thiết kế ngược khi tải trang đầu tiên vì bạn chỉ tiêm một phần nhỏ chức năng mà mỗi khách hàng có thể cần vào lúc đó. Không chắc chắn mức độ tốt cho SEO, nhưng tôi chắc chắn rằng nó có thể được tối ưu hóa phù hợp.

Hãy xem xét trường hợp người dùng cuối viết một trang trong một số phần mềm CMS bằng trình soạn thảo WYSIWYG. Làm thế nào để người dùng này thêm chức năng mới vào trang khi họ không có quyền truy cập vào các tệp .js nguồn của bạn trên máy chủ? Họ chuyển sang tab HTML và sử dụng Javascript nội tuyến.

Không phải tất cả Javascript nội tuyến là xấu; đôi khi onclick cũng tốt Theo khuyến cáo chung, tránh viết Javascript nội tuyến và bạn sẽ tiếp tục xây dựng thói quen tốt.

Người giới thiệu:


0

Thông thường mã JS nội tuyến là xấu, như những người khác đã nói trước tôi.

Nhưng tôi nghĩ về một trường hợp sử dụng trong đó JS nội tuyến là tốt hơn .

Hãy nghĩ về một CMS chèn một thư viện điều khiển JS. Bộ sưu tập có thể được thực hiện trong jQuery. Nó được xác định bởi một thuộc tính id, không chỉ duy nhất trên trang mà còn duy nhất trên toàn bộ trang web. Trong trường hợp này, tôi nghĩ rằng JS nội tuyến JS sẽ tốt hơn, bởi vì mã JS chỉ được sử dụng trên một trang và bạn không có phí HTTP

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.