จาวาสคริปต์ที่ล่วงล้ำตกลงหรือไม่

ฉันคิดว่าถ้าผู้ใช้ทุกคนในเว็บไซต์จะต้องเปิดใช้งาน JavaScript มันก็โอเคที่จะใช้ JavaScript ที่ไม่พึงประสงค์หรือไม่?

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

เรามีกลุ่มเป้าหมายที่บางมากและเราสามารถบอกผู้ชมเป้าหมายของเราว่าต้องใช้เบราว์เซอร์และปลั๊กอิน / ฟังก์ชันใดบ้าง ดังนั้นคำถามของฉันคือการผสม JS และ HTML เอาล่ะในกรณีนี้? เช่นเดียวกับการใช้แอตทริบิวต์ onclick

นี่คือการตัดสินใจทางธุรกิจมากกว่าการตัดสินใจออกแบบ

มีค่าใช้จ่ายในการจัดหารุ่นของเว็บไซต์ที่ใช้งานได้โดยไม่ต้องใช้ JavaScript (หรือแฟลชหรือ Silverlight) ธุรกิจมีการตัดสินใจว่าจะสูญเสียรายได้ / ผู้เข้าชมที่มีมูลค่าหรือไม่

ดังนั้นหากมีค่าใช้จ่าย $ 10,000 ในการเขียนเวอร์ชันนี้ (ตัวเลขอาจมีขนาดใหญ่ แต่มีไว้สำหรับตัวอย่างนี้เท่านั้น) ธุรกิจจะชดใช้ค่าใช้จ่ายตลอดอายุการใช้งานของไซต์หรือไม่ หากไม่เป็นเช่นนั้นอย่าให้รุ่นนั้น

อย่างไรก็ตามหากมีค่าใช้จ่ายเพียง $ 100 ในการเขียนเวอร์ชันนี้ก็จะทำให้รู้สึกถึงความเสื่อมที่สง่างาม

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

บางสิ่งบางอย่างที่ไม่มีใครเทียบได้เป็น ...

99% ของเว็บไซต์ต้อนรับผู้เข้าชมหนึ่ง ๆ โดยที่ไม่มี JavaScript ผู้ที่มีชื่อ: Googlebot

_{เหตุผลใหญ่ที่ทุกคนควรใส่ใจเกี่ยวกับผู้มาเยือนที่ตาบอดเช่นกัน ...}

หากคุณเป็นหนึ่งในไม่กี่คนที่ไม่สนใจเกี่ยวกับปริมาณการใช้เสิร์ชเอ็นจิ้นนั่นคือสิทธิพิเศษของคุณ - แต่แน่นอนว่ามันไม่ได้ทำให้เป็นกฎทั่วไป

คนที่เขียนสิ่งต่าง ๆ สำหรับสภาพแวดล้อมภายในที่เฉพาะเจาะจงนั้นเป็นสาเหตุใหญ่ที่ทำให้ IE6 ยังอยู่ใกล้

ลองคิดดู

หากคุณกำลังทำเว็บไซต์ JS เท่านั้น (บางที 'แอปพลิเคชัน' ในกรณีนี้เป็นคำที่ดีกว่า) 'unobtrusiveness' ของ JS ที่เรียกว่าไม่สำคัญเท่าที่ควรในกรณีที่เมื่อคุณจำเป็นต้องลดระดับลงอย่างงดงาม รุ่น JS

อย่างไรก็ตาม: JavaScript เขียนในลักษณะที่ไม่เป็นการรบกวนโดยทั่วไปแล้วง่ายต่อการเขียน (และอย่างน้อยฉันก็พบวิธีนี้) และบำรุงรักษา ง่ายต่อการแนะนำการเปลี่ยนแปลงเค้าโครง HTML ที่ไม่ทำลาย JS และเปลี่ยนแปลง JS โดยไม่ต้องกังวลกับการทำลาย HTML

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

JavaScript และ HTML5 นั้นยอดเยี่ยมสำหรับการสร้างแอปพลิเคชั่นหากคุณต้องการ แต่มันก็เป็นตัวเลือกทางธุรกิจ

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

สิ่งที่คุณไม่ต้องการทำคือการออกแบบสำหรับตัวส่วนร่วมที่น้อยที่สุด: "มีผู้ใช้บางคนที่ปิดการใช้งาน Javascript ดังนั้นเราจะออกแบบเว็บไซต์ของเราให้ทำงานได้ดีสำหรับพวกเขา - ไม่มี Javascript กดเซิร์ฟเวอร์สำหรับทุกสิ่ง ." นี่เป็นการลงโทษผู้ใช้ส่วนใหญ่ของคุณที่มี Javascript

คุณพูดถึงการใช้แอตทริบิวต์ onlick คุณวางแผนที่จะใช้ตัวจัดการเหตุการณ์ JavaScript สำหรับการนำทางหน้า?

ฉันจะแนะนำต่อนี้ด้วยเหตุผลเดียว: จะแบ่งการคลิกที่ตรงกลาง

สำหรับการคลิกลิงค์ปกติโดยสมมติว่าเปิดใช้งาน JavaScript สิ่งเหล่านี้จะเทียบเท่ากับการใช้งาน:

<a href="#" onclick="window.location = 'myPage.htm';">Click here</a>
<a href="myPage.htm">Click here</a>

หากคุณลองคลิกกลางตัวอย่างแรกคุณจะได้หน้าเปล่าแทนที่จะเป็น myPage.htm

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

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

หากคุณกำลังสร้างบางสิ่งจากพื้นดินให้ปฏิบัติตามมาตรฐานเขียนโค้ดที่ดีสะอาดและบำรุงรักษาได้ เขียนสิ่งที่คุณจะภาคภูมิใจและจะไม่ทำให้คุณป่วยอีกหนึ่งปีนับจากนี้เมื่อ schmuck ผู้น่าสงสารบางคนขอความช่วยเหลือจากคุณเพราะพวกเขาไม่เข้าใจแฮ็คแฮ็คที่คุณทำ เขียนสิ่งที่รับรองว่านักออกแบบเว็บไซต์ของคุณสามารถสลับ CSS ได้อย่างง่ายดายโดยไม่ต้องขุดผ่าน HTML และ JavaScript ที่ยุ่งเหยิง

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

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

ลองนึกภาพว่าการขายหน้าจะต้องใช้เวลาเท่ากันในการออกแบบใหม่อย่างไร

เชื่อฉันจากประสบการณ์JavaScript ที่ไม่สร้างความรำคาญจะป้องกันคุณจากการทำผิดพลาดที่มีค่าใช้จ่ายสูง

เอาล่ะเรียกฉันว่าผู้ดูแลห้องใต้ดินบน necro ทั้งหมดที่ฉันทำ แต่ฉันไม่เคยรู้สึกว่าคุณค่าที่แท้จริงของสิ่งนี้ได้รับการเข้าใจอย่างเหมาะสมแล้ว ในอดีตมีการยืนยันว่า "JavaScript ที่ไม่สร้างความรำคาญ" หรือทำให้ JS ของคุณไม่ผ่าน HTML ผ่านแอตทริบิวต์ตัวจัดการเหตุการณ์ HTML แบบอินไลน์และแท็กสคริปต์ที่ไม่ได้ลิงก์ไปยังไฟล์ให้มากที่สุดเป็นองค์ประกอบสำคัญของ:

• ปัญหาการเข้าถึง
• SEO
• และการเสริมความก้าวหน้า

โกหก! (ดีตอนนี้พวกเขาจะเป็น)

ความจริงของเรื่องนี้คือคุณสามารถทำ JavaScript ที่ล่วงล้ำทางเทคนิคและยังคงดึงสามรายการด้านบนออก เว้นแต่ว่าคุณกำลังสร้างเนื้อหา HTML แบบไดนามิกซึ่งเป็น SEO ที่ยิ่งใหญ่ในวันนี้

แต่หยุดและคิดว่า ... เกี่ยวกับคุณ!

จริงๆแล้วประโยชน์ที่ยิ่งใหญ่การได้รับชัยชนะที่สำคัญและไม่ได้รับการแยกจากกันนั้นเป็นผลประโยชน์โดยตรงที่ผู้พัฒนาได้รับ คุณสามารถมีตัวจัดการเหตุการณ์ได้มากเท่าที่คุณต้องการในองค์ประกอบ html เดียวกันสำหรับเหตุการณ์เดียวกันที่สะดวก ซึ่งหมายความว่าหากแท็กที่มีclass="some_class"พฤติกรรมบางอย่างมักจะได้รับโบนัสบางอย่างเมื่ออยู่ในแท็กid="bonus_behavior" div เราไม่ต้องเริ่มยุ่งกับตรรกะภายในตัวจัดการเหตุการณ์ที่ได้รับอนุญาตของเราเพื่อแยกสาขานั้น เราสามารถเพิ่มหรือไม่เพิ่มตัวจัดการตามบริบท

อ่านง่ายเกินไป

ประโยชน์ก็คือความชัดเจน นี่เป็นข้อกังวลที่สำคัญยิ่งขึ้นเมื่อเครื่องมือของเบราว์เซอร์ประกอบด้วยข้อความแสดงข้อผิดพลาดพิเศษของ IE ที่บอกคุณว่ามีบางอย่างผิดปกติ[object]แต่ IMO ยังคงเป็นเรื่องใหญ่ CSS ที่นี่ JS ที่นั่นและ HTML เป็นสถานที่ที่ทั้งคู่และเซิร์ฟเวอร์จะพบปะกัน ด้วยสิ่งเหล่านี้ทั้งหมดมารวมกันในที่เดียวมันสมเหตุสมผลที่จะต้องอาศัย hooks (IDs, คลาสและลำดับชั้น) เพื่อสร้างเลเยอร์ของ abstraction ที่ทุกอย่างใช้เพื่อเชื่อมต่อกับ HTML

IMO ยิ่งคุณแยก HTML, CSS และ JS ออกจากกันมากเท่าไหร่ก็ยิ่งง่ายขึ้นไม่ใช่แค่อ่าน แต่ยังแก้ไขและเข้าใจสิ่งที่เกิดขึ้น ฉันเห็น div ที่ว่างเปล่าที่มี "dynamic_combo_box" เป็นคลาสและฉันมีความคิดที่ดีว่ามีบางสิ่งที่กำลังเลือกแฟนซีที่จะโหลดข้อมูลแบบไดนามิก ฉันมีความเป็นผู้นำในการค้นหาสิ่งนั้นใน JS และ CSS และถ้าฉันเข้าเรียนในข้อกังวลเหล่านั้นฉันจะมีความคิดที่ดีว่ามันเกี่ยวกับอะไรและวิธีการค้นหามันใน HTML

ง่ายเกินไปที่จะทำแม้กระทั่ง Sloppier

และแน่นอนความชัดเจนมีแนวโน้มที่จะไปจับมือกับการบำรุงรักษา เมื่อคุณทำสิ่งต่าง ๆ โดยตรงโดยการทิ้งทุกอย่างไว้ในแท็กสคริปต์ที่ HTML ที่เกี่ยวข้องเกิดขึ้นบ่อยครั้งที่ไม่เป็นเรื่องง่ายสำหรับคนที่จะตัดและวางสคริปต์นั้นใน HTML ของหน้าอื่นที่พวกเขากำลังทำงานอยู่เมื่อ พวกเขาต้องการฟังก์ชั่นที่คล้ายกันซึ่งหมายความว่าคุณมีสิ่งหนึ่งที่น่าจะกลายเป็นสองสิ่งที่น่ารำคาญในที่สุด แต่ไม่เหมือนกัน 100% ซึ่งพฤติกรรมอาจกลายเป็นปัญหาเมื่อเวลาผ่านไปโดยท้าทายความคาดหวังและต้องการการแยกสาขา อื่นไม่ได้

ดังนั้นพฤติกรรมการใช้ตะขอ HTML เหล่านั้นจึงส่งเสริมให้มีการนำรหัสกลับมาใช้อย่างชาญฉลาด หากคุณต้องการพฤติกรรมสาขาสำหรับการใช้งานทางเลือกคุณเพียงแค่ไปที่ฟังก์ชั่นเดียวกันและจัดการมันที่นั่นด้วยลำดับชั้น HTML หรืออาจเป็น data-att เรียกพฤติกรรม alt บางอย่าง มันเป็นแหล่งช้อปปิ้งที่ครบวงจรสำหรับทุกคนที่ต้องการทำความเข้าใจว่าองค์ประกอบ UI ของงานบางประเภทและประเภทการตัดและวางที่ขี้เกียจอย่างเลวร้ายและเลววิธีจะทำสิ่งที่ถูกต้อง / บำรุงรักษามากขึ้นเพราะมันเป็นสิ่งที่ง่ายที่สุดในการ ทำตอนนี้และนั่นคือวิธีที่ดีที่สุดที่จะทำให้การบำรุงรักษาเกิดขึ้น ทำให้มันเป็น "duh" ที่ง่ายที่สุดที่จะทำแม้กระทั่งกับคนที่ไม่สามารถสนใจน้อยลงไม่ว่าจะเกิดจากความตื่นตระหนกหรือความไม่แยแส

แต่อะไรที่เกี่ยวกับปี 2014

อาจเป็นประเด็นที่ถูกต้องว่าในแอพพลิเคชั่นหน้าเดียวที่ทันสมัยสิ่งที่ Stickler เหล่านี้บางอย่างอาจไม่ควรที่จะยึดติดกับเหตุผลตามที่ได้รับ แต่เชื่อฉันเมื่อฉันพูดว่าฉันไม่คิดว่าฉันเป็นคนเดียวที่ ถูกขายเพราะมันทำให้การทำงานง่ายขึ้นในท้ายที่สุด ฉันขี้เกียจใน (ฉันหวังว่า) ส่วนใหญ่เป็นวิธีที่ดี ฉันชอบเมื่อฉันต้องเปลี่ยนสิ่งต่าง ๆ ในที่เดียวเพื่อรับการเปลี่ยนแปลงทั่วแอพเมื่อฉันต้องดูในที่เดียวเพื่อหาว่าบั๊กคืออะไรและเมื่อฉันมีเวลาง่าย ๆ ที่จะเข้าใจว่าห่าคืออะไร เกิดขึ้นและวิธีการใช้รหัสนั้นซ้ำให้ดีที่สุดเพื่อทำสิ่งที่คล้ายกันมาก

มันดีเหมือนการแยก DB หรือ data-layer นั้นดี ในท้ายที่สุดมันเป็นเหตุผลว่าทำไมฉันไม่เพียงแค่ทำอย่างนั้นประหยัดเวลาเหมือนใช้เวลาทั้งหมดห้านาทีในการซักผ้าในคืนก่อนแทนที่จะใช้เวลา 10 นาทีในการทำให้นักมวยของคุณวุ่นวายและทำการตรวจสอบกลิ่นหวาดระแวงในเช้าวันรุ่งขึ้น

สำหรับฉันมันเป็นแรงบันดาลใจที่เห็นแก่ตัวซึ่งเป็นประเด็นหลักเสมอว่าทำไมฉันถึงไม่ได้แค่ JS ที่ไม่สร้างความรำคาญ แต่เป็นการแบ่งแยกสไตล์ / พฤติกรรม / เนื้อหาที่เกี่ยวข้องให้มากที่สุดเท่าที่จะเป็นไปได้แม้ว่า WHAT-freaking-WG ยุ่งเหยิงความกังวลเหล่านั้นด้วยวิธีที่ยอดเยี่ยมและยอดเยี่ยม / มีประโยชน์

ตอนนี้ทุกคนกำลังทำ SPAs และมันก็เกือบจะโง่เขลาที่จะโน้มน้าวใจธุรกิจว่าเราควรจะใส่ใจคนที่ทำงานโดยไม่มี JS (ตอนนี้ความสามารถในการเข้าถึงควรจะจัดการกับเนื้อหาที่สร้างโดย JS) ดูเหมือนว่ารุ่นต่อไปของ JS devs จะสนใจน้อยลง เกี่ยวกับสิ่งนี้ แต่ IMO ยังคงมีชัยชนะอยู่และส่วนใหญ่สำหรับคุณนักพัฒนาเขียนและดูแลสิ่งนี้ และที่จริงแล้วการชนะนั้นควรจะเป็นจุดเน้นย้ำที่สุดเสมอ แต่ไม่เคยมีด้วยเหตุผลบางอย่างเพราะในท้ายที่สุดมันจะเป็นประโยชน์ต่อคุณและผลิตภัณฑ์โดยอุบัติเหตุที่เกิดจากความสุขผ่านการปรับแต่ง / แก้ไข / ดีบักได้ง่ายขึ้น

มันเคยโอเคไหม

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

หากคุณรู้ว่า Javascript และเฟรมเวิร์กเช่น jQuery นั้นเป็นสวรรค์ที่แท้จริง ตัวอย่างเช่นในสภาพแวดล้อมแบบองค์กรที่ SOE มี Javascript และ IE8 มากกว่าความปลอดภัยในการเขียนแอปพลิเคชันเบราว์เซอร์ฝั่งไคลเอ็นต์แบบเข้มข้น

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

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

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

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

ตัวอย่าง: Google Search เป็นเว็บไซต์ Google เอกสารเป็นเว็บแอปพลิเคชัน Google Search ไม่มีความหรูหราและสามารถทำงานได้เหมือนกันหากไม่มี JavaScript, CSS และ / หรือรูปภาพ ฯลฯ ... - มันทำงานในเบราว์เซอร์ในโหมดข้อความเช่นเดียวกับในเบราว์เซอร์ GUI ล่าสุด Google เอกสารใช้งานไม่ได้เมื่อปิดการใช้งาน JavaScript และไม่ได้ลดระดับลงอย่างงดงาม - ไม่แม้แต่คำเตือนให้เปิดใช้งาน JavaScript

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

ตรงกับคำตอบของคำถาม: ฉันไม่ชอบ JavaScript ที่จำเป็น แต่มีกรณีธุรกิจที่จำเป็นต้องใช้ตามที่ ChrisF ระบุไว้

Javascript เป็นมาตรฐานข้อบกพร่องเมื่อพูดถึงเนื้อหาแบบไดนามิกใด ๆ ที่ส่งมอบให้ฝั่งไคลเอ็นต์หากพวกเขาไม่มี JS พวกเขาอาจจะไม่มี Silverlight

ถ้าอย่างนั้นคุณต้องคิดถึงตลาด / ผู้ชมของคุณว่าคุณเป็นโปรแกรมเมอร์หรือไม่ ผู้ชมที่แตกต่างกันมาก

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

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