JavaScript แบบอินไลน์ดีหรือไม่ดี

16

ขณะนี้ฉันได้เปลี่ยนจาก WordPress เป็นYii Frameworkและนักพัฒนาภายนอกกำลังสร้างเว็บไซต์ของฉันใหม่

สิ่งหนึ่งที่ฉันสังเกตเห็นคือทุกครั้งที่เขาเรียกใช้ AJAX / jQuery ในแบบ Yii มันฝังตัว~~แทรกแบบอินไลน์ของ JavaScript~~ในหน้าเว็บ แม้ว่าดูเหมือนว่ารหัส JavaScript จะอยู่ด้านล่างส่วนท้าย แต่ก็ยังอยู่ในบรรทัด

โดยทั่วไปดูเหมือนว่ารหัส JavaScript จะถูกวางไว้ในหน้าเว็บบ่อยขึ้น ฉันคิดเสมอว่าควรวางสคริปต์ JavaScript ไว้ในไฟล์ JavaScript ให้มากที่สุดเท่าที่จะทำได้ นี่เป็นแนวโน้ม "ใหม่" หรือไม่? หรือฉันควรจะพยายามเก็บรหัส JavaScript ไว้ในไฟล์แยกกันหรือไม่?

html javascript

— สตีเว่น
แหล่งที่มา

คุณหมายถึงอะไรโดยแทรก JavaScript แบบอินไลน์ในหน้าเว็บ ?

— Salman

3

เพื่อประโยชน์ของผู้อื่นที่พบคำถามนี้และกำลังคิดในเรื่อง<a onClick="function(){/* do stuff */} ">Click Here</a>นี้ฉันเข้าใจว่าเป็นสิ่งที่แย่มากและควรแยกโค้ดออกจาก HTML ของพวกเขาดู: บทความนี้

— TecBrat

1

@ user1066946 t.co/j1RpJgwoku :-)

— Kos

1

@ user1066946 ฉันชอบใช้ Angular ฉันเพิ่งสังเกตว่า "semantic web" สร้างวงกลม (ในแง่ของการเก็บรหัสกาวไว้ติดกับ DOM)

— Kos

1

"แม้ว่าดูเหมือนว่ารหัส JavaScript จะอยู่ใต้ส่วนท้าย แต่ก็ยังอยู่ในบรรทัด" - ฟังดูเหมือนว่าคุณกำลังอ้างถึงJavaScript ที่ฝังตัวแทนที่จะเป็น "inline" JavaScript (ซึ่ง TecBrat อ้างถึง)

— MrWhite

13

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

โปรดทราบว่าเวลาในการดาวน์โหลดหน้าเว็บ (นั่นคือ HTML) และไม่ใช่การเรียกทรัพยากรทั้งหมดที่มีผลต่อการวัดที่มีผลต่อการจัดอันดับ (แม้ว่าจะเป็น PageRank หรือใน SERP ที่ไม่สำคัญ) ประเด็นคือมันมีผลต่อประสิทธิภาพของเว็บไซต์สำหรับ SEO แต่ปรากฏ

— closetnoc
แหล่งที่มา

7

เจรจาต่อรองการเชื่อมต่อที่สองไปยังโฮสต์เดียวกันน่าจะดาวน์โหลดข้อมูลจำนวนเดียวกันเร็วกว่าภายในสตรีมที่ใช้งานอยู่? โดยปกติถ้าคุณได้รับ, พูด, 50Kbps ในไฟล์ไปยังโฮสต์, เริ่มเซสชันที่สองอาจตัดมันเพื่อให้ทั้งสองตอนนี้ 25Kbps เว้นแต่โฮสต์จะควบคุมปริมาณการเชื่อมต่อด้วยเหตุผลบางอย่าง

— EkriirkE

มีการต่อต้านไฟล์ภายนอกแม้ว่า ถ้าไม่ได้ทำอย่างถูกต้องคุณจะสร้างรหัส DOMblocking คือไก doc.ready จะช้าลงซึ่งมีผลต่อการรับรู้ความเร็ว แต่ถ้าทำอย่างถูกต้องภายนอกเป็นวิธีที่จะไป

— Martijn

4

.jsไฟล์ดีกว่าสำหรับการแคชมันไม่สมเหตุสมผลที่การเชื่อมต่อสองครั้งกับโฮสต์เดียวกันจะทำให้ความเร็วในการดาวน์โหลดของคุณใหญ่ขึ้นอย่างน่าอัศจรรย์

ความคิดในการแบ่งแบนด์วิดท์ในขณะที่ฉันเข้าใจตรรกะของคุณและมันก็ไม่ผิดทั้งหมดเป็นความเข้าใจผิดเล็กน้อย HTML มีขนาดเล็กลงใช้เวลาน้อยลงและการโทรใด ๆ ที่ตามมาสามารถรอได้จริง

— Closnoc

3

หากคุณสำลักเวลาคุณผิดที่จะดูแบนด์วิดธ์ ดูที่ profiler ที่เวลาในการโหลด: โดยปกติเวลาในการเชื่อมต่อจะยิ่งใหญ่กว่า 10-100 เท่าเวลาแลกเปลี่ยนข้อมูลจริง นี่หมายความว่าการแยกส่วนเป็นปัญหาที่แท้จริงและการใช้ไฟล์ภายนอกเฉพาะสำหรับไฟล์ js ขนาดเล็กอาจเลวร้ายที่สุดที่อินไลน์ Inline ดีกว่าบนเบราว์เซอร์ที่ไม่ทำการขนานกันจริง

— Lesto

29

ในไซต์การแปลงสกุลเงินของฉันเซสชันส่วนใหญ่เป็นการดูหน้าเดียว นี่เป็นเพราะผู้ใช้สามารถทำการคำนวณสกุลเงินของพวกเขาโดยตรงบนหน้า Landing Page (การคำนวณทั้งหมดได้รับการจัดการด้านลูกค้าด้วย JavaScript)

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

เว็บไซต์ของฉันไม่ปกติ ไซต์ส่วนใหญ่มีหลายหน้าต่อเซสชันและภาพขนาดใหญ่ที่ทำให้เทคนิคของฉันใช้งานได้น้อยลง ไม่มีคำตอบที่ถูกต้องสำหรับคำถามนี้ มันขึ้นอยู่กับเว็บไซต์ คุณต้องวัดด้วยตัวคุณเองตามพฤติกรรมปกติของผู้ใช้ของคุณ

— Stephen Ostermiller
แหล่งที่มา

12

ไม่จำเป็นต้องมี JavaScript ภายในไฟล์ HTML ของคุณ แต่คุณต้องทำการเรียกวิจารณญาณ

มันจะไม่ดีถ้าคุณมี JavaScript จำนวนมากถูกใช้ในหลาย ๆ หน้า ในกรณีดังกล่าว JavaScript ควรอยู่ในไฟล์ภายนอกบีบอัดและสามารถเข้าถึงได้และหากเว็บไซต์ของคุณมีปริมาณการใช้งานมากคุณควรใช้ CDN

อย่างไรก็ตามหากคุณมี JavaScript จำนวนเล็กน้อยการบันทึกการใส่ไว้ในไฟล์ภายนอกอาจไม่ได้ผลเนื่องจากคุณต้องทำการร้องขอ HTTP เพิ่มเติมเพื่อดึงข้อมูล ในกรณีนี้มันจะมีประสิทธิภาพมากขึ้นเพื่อให้ JavaScript ในหน้าของคุณ

จากนั้นอีกครั้งหากมีการใช้ตัวอย่างโค้ดขนาดเล็กเดียวกันนี้ในหลาย ๆ หน้าจะเป็นประโยชน์ในการวางไว้ในไฟล์ภายนอกเพื่อใช้ประโยชน์จากการแคช

ในที่สุดคุณต้องชั่งน้ำหนักขนาดของ JavaScript กับค่าใช้จ่ายในการร้องขอ HTTP เพิ่มเติม ส่วนใหญ่สำหรับไซต์ 'เฉลี่ย' มันอาจจะไม่สร้างความแตกต่างอย่างมากมายเพียงแค่วางไว้ในไฟล์ภายนอก

— foamcow
แหล่งที่มา

4

ฉันพัฒนา Yii และผมสามารถบอกคุณได้ว่าYii มีอะไรจะทำอย่างไรกับเรื่องนี้ มันอยู่ในด้านนักพัฒนาไม่ว่าเขาหรือเธอจะใส่รหัส Javascript ไปยังไฟล์แยกต่างหากและลงทะเบียนด้วยหน้า HTML (ดู) ด้วยCClientScript::registerScriptFileวิธีการหรือวางโดยตรงเพื่อดูรหัส (HTML) และลงทะเบียนโดยใช้CClientScript::registerScriptวิธีการ

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

แก้ไข : จริง ๆ แล้วฉันลืมอาร์กิวเมนต์ที่สำคัญที่สุด Yii (รวมถึงเฟรมเวิร์ก PHP มืออาชีพอื่น ๆ ส่วนใหญ่) สร้างขึ้นตามรูปแบบการออกแบบMVC (อันที่จริง: รูปแบบสถาปัตยกรรม) และรูปแบบเดียวกันสามารถใช้ใน fronted: รหัส HTML คือรูปแบบ (ข้อมูล), CSS คือมุมมอง (มัณฑนากร) และ Javascript เป็นตัวควบคุม ทั้งหมดของพวกเขาใส่ลงไปในแฟ้มที่แยกต่างหาก , .jsและ.cssไฟล์ - minified, obsfucated และ gzipped ในสถานการณ์ที่ดีที่สุด

เมื่อคุณสร้างแอปพลิเคชัน Yii ของคุณคุณสามารถทำลายรูปแบบ MVC และเก็บทุกอย่างไว้ในไฟล์เดียวกัน คำถามคือ - มันคุ้มค่าที่จะทำเช่นนั้นประโยชน์อะไร (ไม่มี) และสิ่งที่จะนำคุณไปสู่ คุณสามารถใช้การโต้แย้งเดียวกันเมื่อถามว่าจะเก็บรหัส JS inline หรือไม่?

— trejder
แหล่งที่มา

ตกลง. นักพัฒนาดูเหมือนว่าจะใช้วิดเจ็ตของบุคคลที่สามสำหรับทุกสิ่ง; เติมข้อความอัตโนมัติ, ภาพอาแจ็กซ์ ฯลฯ ทั้งหมดนี้เพิ่ม js แบบอินไลน์

— Steven

ไม่ฉันไม่เห็นด้วย ฉันใช้ Twitter Bootstrap ในแอปพลิเคชัน Yii ของฉัน (อาจเป็นส่วนขยายที่ใหญ่ที่สุดของ Yii และชุดเครื่องมือขนาดใหญ่) รวมถึงส่วนขยายของ Yii อื่น ๆ อีกมากมายและไม่มีการใช้ inline JS นักพัฒนาของคุณจะต้องโชคดีที่พบวิดเจ็ตและส่วนขยายที่ใช้ Javascript แบบอินไลน์เท่านั้น คุณต้องมีประสบการณ์ใน Yii ค่อนข้างมากในการเริ่มเขียนส่วนขยายของตัวเอง (ยกเว้นบางส่วนที่เขียนไม่ดีจริง ๆ ) และแม้แต่นักพัฒนา Yii ที่มีประสบการณ์กึ่งใช้รหัสแบบอินไลน์เป็นตัวเลือกสุดท้ายหากทุกอย่างล้มเหลว

— trejder

การใช้ส่วนขยายและเครื่องมือของบุคคลที่สามใน Yii เป็นแนวคิดที่ยอดเยี่ยม (คุณไม่ต้องคิดค้นวงล้อใหม่อีก) แต่การใช้โค้ด JS แบบอินไลน์ในแอปพลิเคชันหรือส่วนขยาย Yii จริงๆเป็นทัศนคติที่ไม่ดี ดังนั้นบังคับให้นักพัฒนาของคุณเขียนโค้ด / ใช้ส่วนขยายและวิดเจ็ตที่ดีขึ้นหรือ ... รับนักพัฒนาที่ดีกว่า! :]

— trejder

ตกลงขอบคุณสำหรับคำติชม นอกจาก Stackoverflow ฉันจะหาชุมชน Yii ที่ดีได้ที่ไหน

— Steven

ในฟอรั่ม Yii หน้าส่วนใหญ่สามารถเข้าถึงได้อย่างอิสระ บางคนจำเป็นต้องลงทะเบียนบัญชีและเข้าสู่ระบบ นักพัฒนา Yii ส่วนใหญ่ที่ Stack Overflow มีบัญชีของตัวเองที่ฟอรัม หลังจากเกือบหกปีที่มีอยู่กรอบงาน Yii ได้รับชุมชนนักพัฒนาขนาดใหญ่ดังนั้นหากคุณพิจารณาอย่างรอบคอบคุณควรจะสามารถหานักพัฒนา Yii สองสามคนในชุมชนท้องถิ่นของคุณหรือในละแวกใกล้เคียง โชคดี.

— trejder

3

จริง ๆ แล้วมันขึ้นอยู่กับวัตถุประสงค์ของเว็บเพจที่คุณกำลังพัฒนา:

ฉันใช้จาวาสคริปต์แบบอินไลน์เล็กน้อยในขณะที่ฉันต้องการใช้งานไฟล์ JavaScript ภายนอกถ้ามันใหญ่

ไม่ว่าจะด้วยวิธีใดเมื่อเพจโหลด JavaScript จะต้องดำเนินการก่อน แนวทางปฏิบัติที่ดีที่สุดคือการใช้ JavaScript ภายนอกจึงไม่ทำให้เนื้อหาหน้าของคุณยาวขึ้น นอกจากนี้ยังทำให้การดีบักง่ายขึ้น

— Abhijith Bhattu
แหล่งที่มา

2

คำตอบนั้นขึ้นอยู่กับสิ่งที่กำลังทำ

หากคุณสังเกตเห็น JavaScript แบบอินไลน์ที่ใช้ทั่วทั้งเว็บไซต์ (เช่นวิดเจ็ตที่แสดงอยู่ในส่วนหัวของทุกหน้าของเว็บไซต์) ดังนั้นจึงเป็นการเหมาะสมที่จะย้ายไปยังไฟล์ JavaScript "ทั่วไป"

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

ในทางตรงกันข้ามหาก JavaScript เป็นเพียงตัวเลือก / การกำหนดค่าเริ่มต้นเช่น:

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

ด้วยเหตุผลบางอย่างมันเป็นไปไม่ได้ที่จะย้ายรหัสไปยังไฟล์ JavaScript ภายนอก (เช่นเมื่อพารามิเตอร์รูปภาพมาจากฐานข้อมูล) ฉันจะเก็บไว้ในแบบอินไลน์ ต้องบอกว่าฉันจะเลือกปลั๊กอินของบุคคลที่สามที่ "ไม่เป็นการรบกวน" (หรือแปลงเป็นเช่นนั้น)

— ซัลมาน
แหล่งที่มา

2

คำตอบเหล่านี้พลาดเครื่องหมาย มีลักษณะที่Inline แคช

เนื่องจาก Yii เขียนโค้ดใน PHP รูปแบบ PHP ทั่วไป (หรืออาจผิดปกติ) คุณจะพบว่านักพัฒนาบางครั้งจะเขียนโค้ด PHP เพื่อสร้างโค้ด Javascript แบบไดนามิกที่เซิร์ฟเวอร์ - ขึ้นอยู่กับสถานะสภาพหรือมูลค่าที่เซิร์ฟเวอร์รู้จัก - จากนั้นส่งให้ลูกค้าทั้งหมดในชุดเดียวทำให้ลูกค้าสามารถใช้งานฟังก์ชั่นและข้ามการคำนวณบางส่วนที่เซิร์ฟเวอร์ได้ทำไปแล้ว

แทนการส่งฟังก์ชั่นจาวาสคริปต์ทั่วไปจำนวนมากในไฟล์. js ไปยังไคลเอนต์ที่ไม่มีบริบทจนกว่าจะได้รับข้อมูล (ข้อมูลที่อาจจะนั่งอยู่บนเซิร์ฟเวอร์และต้องการการเดินทางไปกลับ) เราสามารถ "อบ" บริบท / ข้อมูลซึ่งเป็นส่วนหนึ่งของฟังก์ชัน Javascript นี่เป็นสิ่งที่ประหยัดเพราะหมายความว่าคุณกำลังส่งฟังก์ชั่น / ข้อมูลเข้าด้วยกันและส่งเฉพาะฟังก์ชัน / ข้อมูลที่ลูกค้าอาจต้องการในเวลานั้นแทนที่จะส่งแอปทั้งหมดในการโหลดหน้าแรก นอกจากนี้ยังหมายความว่าคุณไม่จำเป็นต้องเปิดเผยแอพทั้งหมดของคุณให้ดาวน์โหลดได้อย่างง่ายดายและวิศวกรรมย้อนกลับในการโหลดหน้าแรกเพราะคุณเพียงฉีดฟังก์ชันการทำงานบางส่วนที่ลูกค้าแต่ละรายอาจต้องการในเวลานั้น ไม่แน่ใจว่าเป็นลางดีสำหรับ SEO แต่ฉันแน่ใจว่าสามารถปรับให้เหมาะสม

พิจารณากรณีของผู้ใช้ปลายทางที่เขียนหน้าในซอฟต์แวร์ CMS บางตัวโดยใช้เครื่องมือแก้ไขแบบ WYSIWYG ผู้ใช้รายนี้จะเพิ่มฟังก์ชันการทำงานใหม่ให้กับหน้าเว็บอย่างไรเมื่อพวกเขาไม่มีสิทธิ์เข้าถึงไฟล์. js ต้นทางของคุณบนเซิร์ฟเวอร์ พวกเขาสลับไปที่แท็บ HTML และใช้ Javascript แบบอินไลน์

ไม่ใช่ Javascript แบบอินไลน์ทั้งหมดจะไม่ดี บางครั้ง onclick ก็ใช้ได้เช่นกัน ตามคำแนะนำทั่วไปให้หลีกเลี่ยงการเขียน Javascript แบบอินไลน์และคุณจะสามารถสร้างนิสัยที่ดีได้

อ้างอิง:

— น้ำเพริ
แหล่งที่มา

0

โดยปกติโค้ด JS แบบอินไลน์ไม่ดีอย่างที่คนอื่นพูดกันก่อนหน้าฉัน

แต่ฉันคิดว่ากรณีการใช้งานที่ inline JS ดีกว่าดีกว่า

นึกถึง CMS ที่แทรกแกลเลอรี JS ขับเคลื่อน แกลเลอรี่อาจทำใน jQuery มันถูกระบุโดยแอตทริบิวต์ id ซึ่งไม่เพียง แต่ไม่ซ้ำกันในหน้าเว็บ แต่ยังไม่ซ้ำกันทั่วทั้งไซต์ ในกรณีนี้ - ฉันคิดว่า - inline JS น่าจะดีกว่าเพราะรหัส JS ใช้ในหน้าเดียวเท่านั้นและคุณไม่มีค่าใช้จ่าย HTTP

— yunzen
แหล่งที่มา