ในขณะนี้ภาษาที่รองรับอย่างสมบูรณ์เท่านั้นและมาตรฐาน de-facto สำหรับการจัดการทรี DOM ในเบราว์เซอร์คือ JavaScript ดูเหมือนว่าจะมีปัญหาการออกแบบที่ลึกซึ่งทำให้เป็นแหล่งที่วางทุ่นระเบิดและช่องโหว่ด้านความปลอดภัยสำหรับมือใหม่

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

ฉันใช้ jQuery แล้วและฉันยังอ่าน "javascript: the good parts" ด้วย คำแนะนำนั้นดี แต่สิ่งที่ฉันไม่สามารถเข้าใจได้คือ: ทำไมมีเพียงจาวาสคริปต์ บนฝั่งเซิร์ฟเวอร์ (แพลตฟอร์มที่คุณโปรดปราน), เราสามารถจัดการทรี DOM กับทุกภาษาได้แม้กระทั่งภาษา เหตุใดฝั่งไคลเอ็นต์ (แพลตฟอร์มเบราว์เซอร์) จึงสนับสนุนจาวาสคริปต์เท่านั้น

ปัญหาเกี่ยวกับ javascript ไม่ใช่ภาษาของตัวเอง - เป็นภาษาต้นแบบที่ดีและมีชีวิตชีวา หากคุณมาจากพื้นหลัง OO มีช่วงการเรียนรู้เล็กน้อย แต่ไม่ใช่ความผิดของภาษา

คนส่วนใหญ่คิดว่า Javascript นั้นเหมือนกับ Java เพราะมีไวยากรณ์ที่เหมือนกันและชื่อที่คล้ายกัน แต่จริงๆแล้วมันก็เหมือน lisp มากกว่า จริงๆแล้วมันค่อนข้างเหมาะสมกับการจัดการ DOM

ปัญหาที่แท้จริงคือมันรวบรวมโดยเบราว์เซอร์และนั่นหมายความว่ามันทำงานในลักษณะที่แตกต่างกันมากขึ้นอยู่กับลูกค้า

ไม่เพียง แต่ DOM ที่แท้จริงจะแตกต่างกันขึ้นอยู่กับเบราว์เซอร์ แต่มีความแตกต่างอย่างมากในประสิทธิภาพและการจัดวาง

แก้ไขคำอธิบายที่ชัดเจนในคำถาม

สมมติว่ารองรับหลายภาษาที่แปลแล้ว - คุณยังคงมีปัญหาเดียวกัน เบราว์เซอร์ต่าง ๆ จะยังคงบั๊กกี้และมี DOM ต่างกัน

นอกจากนี้คุณจะต้องมีล่ามติดตั้งไว้ในเบราว์เซอร์หรือติดตั้งอย่างใดอย่างหนึ่งเป็นปลั๊กอิน (ซึ่งคุณสามารถตรวจสอบก่อนที่จะแสดงหน้า) สำหรับแต่ละภาษา ต้องใช้เวลานานกว่าจะได้ Javascript ที่สอดคล้องกัน

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

ตกลงแล้วแซนด์บ็อกซ์สำหรับโค้ดที่คอมไพล์แล้วล่ะ ฟังดูเหมือน Java Applets สำหรับฉัน หรือ ActionScript ใน Flash หรือ C # ใน Silverlight

มาตรฐาน IL บางประเภทเป็นอย่างไร? ที่มีศักยภาพมากขึ้น พัฒนาในสิ่งที่ภาษาที่คุณต้องการแล้วรวบรวมเป็น IL ซึ่งเบราว์เซอร์แล้ว JITs

ยกเว้น Javascript เป็นชนิดของแล้วว่า IL - เพียงแค่มองGWT มันช่วยให้คุณเขียนโปรแกรมใน Java แต่แจกจ่ายเป็น HTML และ JS

แก้ไขคำชี้แจงเพิ่มเติมต่อไปนี้ในคำถาม

Javascript ไม่ได้เป็นหรือไม่ใช่ภาษาเดียวที่เบราว์เซอร์รองรับ: ย้อนกลับไปในยุคมืดของ Internet Explorer ที่คุณสามารถเลือกได้ระหว่าง Javascript หรือ VBScript เพื่อให้ทำงานใน IE ในทางเทคนิคแล้ว IE ไม่ได้เรียกใช้ Javascript ด้วย - มันรันJScript (ส่วนใหญ่เพื่อหลีกเลี่ยงการเสีย Sun สำหรับคำว่าjava , Oracle ยังเป็นเจ้าของชื่อJavascript )

ปัญหาคือ VBScript เป็นกรรมสิทธิ์ของ Microsoft แต่ก็ไม่ได้ดีนัก ในขณะที่ Javascript เพิ่มฟังก์ชั่นการใช้งานและรับเครื่องมือดีบั๊กชั้นนำในเบราว์เซอร์อื่น ๆ (เช่น FireBug) VBScript ยังคงเป็น IE เท่านั้นและไม่สามารถ debuggable ได้ (เครื่องมือ dev ใน IE4 / 5/6 ไม่มีอยู่จริง) ในขณะเดียวกัน VBScript ก็ขยายตัวจนกลายเป็นเครื่องมือการเขียนสคริปต์ที่ทรงพลังในระบบปฏิบัติการ แต่ไม่มีคุณลักษณะเหล่านั้นในเบราว์เซอร์ (และเมื่อพวกเขากลายเป็นช่องโหว่ด้านความปลอดภัยขนาดใหญ่)

ยังคงมีแอปพลิเคชันภายในองค์กรบางส่วนที่ใช้ VBScript (และบางโปรแกรมขึ้นอยู่กับช่องโหว่ด้านความปลอดภัย) และพวกเขายังคงรัน IE7 (พวกเขาหยุด IE6 เพียงเพราะ MS ฆ่าคนในที่สุด)

การใช้ Javascript ในสถานะปัจจุบันเป็นฝันร้ายและใช้เวลา 20 ปี มันยังไม่ได้รับการสนับสนุนที่สอดคล้องกันด้วยคุณสมบัติภาษา (ที่ระบุในปี 1999) ยังคงหายไปจากเบราว์เซอร์บางตัวและต้องการความช่วยเหลือมากมาย

การเพิ่มภาษาอื่นสำหรับการตีความในเบราว์เซอร์ประสบปัญหาสำคัญสองประการ:

• ทำให้ผู้ขายเบราว์เซอร์ทุกรายนำมาตรฐานภาษาใหม่ไปใช้ซึ่งสิ่งเหล่านั้นยังไม่ได้จัดการกับ Javascript ใน 20 ปี

• ภาษาที่สองอาจลดการสนับสนุนที่คุณมีอยู่ซึ่งอนุญาตให้ (เช่น) IE มีการสนับสนุน Javascript ในอัตราที่สอง แต่ VBScript ที่ยอดเยี่ยม (อีกครั้ง) ฉันไม่ต้องการเขียนโค้ดในภาษาต่างๆสำหรับเบราว์เซอร์ที่แตกต่างกัน

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

รวบรวมไปยัง Javascript

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

(แต่ฉันไม่คิดว่านี่เป็นปัญหา Javascript ได้รับการปรับปรุงอย่างดีในขณะนี้รหัสเครื่องยังไม่ปลอดภัยหากเขียนด้วยมือ แต่ทำงานได้ดีเป็นเป้าหมายในการรวบรวมและภาษาในการประมวลผล)

ตัวเลือกมากมาย

มีกลุ่มภาษาที่เพิ่มขึ้นเรื่อย ๆ ที่รวบรวมไปยัง Javascript รายการที่ครอบคลุมค่อนข้างสามารถพบได้ที่นี่:

• รายชื่อภาษาที่รวบรวม JSใน Coffeescript Wiki

น่าสังเกต

ฉันจะพูดถึงบางอย่างที่ฉันคิดว่าเป็นสิ่งสำคัญ (ในขณะที่ไม่ต้องสงสัยเลยว่าละเลยอัญมณีบางอย่างที่ฉันไม่รู้)

• Spiderปรากฏตัวในปี 2559 มันอ้างว่านำไอเดียที่ดีที่สุดของ Go, Swift, Python, C # และ CoffeeScript มันไม่ได้เป็น typesafe แต่มันจะมีเล็กน้อยบางคุณลักษณะด้านความปลอดภัย

• Elm : Haskell อาจเป็นภาษาที่ฉลาดที่สุดของพวกเขาทั้งหมดและ Elm เป็นตัวแปรของ Haskell สำหรับ Javascript มันเป็นประเภทที่รับรู้และรัดกุมและมีฟังก์ชั่นการเขียนโปรแกรมปฏิกิริยาเป็นทางเลือกที่เรียบร้อยเพื่อแม่แบบปฏิกิริยาหรือสปาเก็ตตี้ MVC แต่มันอาจจะค่อนข้างช็อตสำหรับการเขียนโปรแกรมขั้นตอน

• Google's Goมุ่งเน้นที่ความกระชับเรียบง่ายและปลอดภัย รหัสไปสามารถเรียบเรียงโดย Javascript GopherJS

• Dartเป็นความพยายามในภายหลังของ Google เพื่อแทนที่ Javascript มันมีส่วนต่อประสานและคลาสนามธรรมผ่านไวยากรณ์คล้าย C / Java พร้อมการพิมพ์เสริม

• Haxeนั้นเหมือนกับ ActionScript ของ Flash แต่สามารถกำหนดเป้าหมายหลายภาษาเพื่อให้โค้ดของคุณสามารถนำกลับมาใช้ใหม่ได้ในโปรแกรม Java, C, Flash, PHP และ Javascript มันมีประเภทของวัตถุที่ปลอดภัยและแบบไดนามิก

• Opalangเพิ่ม syntactic sugar ให้กับ Javascript เพื่อให้การเข้าถึงฐานข้อมูลโดยตรงการดำเนินการอย่างชาญฉลาดการตรวจสอบประเภทและช่วยในการแยกลูกค้า / เซิร์ฟเวอร์ (เชื่อมโยงกับ NodeJS และ MongoDB)

• GorillaScript , "ภาษาที่รวบรวมการใช้ JavaScript การออกแบบมาเพื่อช่วยให้ผู้ใช้ในขณะที่พยายามที่จะป้องกันไม่ให้เกิดข้อผิดพลาดบางอย่างร่วมกัน." คล้ายกับ Coffeescript แต่มีความครอบคลุมมากขึ้นนำเสนอฟีเจอร์พิเศษมากมายเพื่อเพิ่มความปลอดภัยและลดรูปแบบแผ่นเหล็กซ้ำซ้อน

• LiteScriptอยู่ที่ไหนสักแห่งระหว่าง Coffeescript และ GorillaScript มันมีไวยากรณ์ async / yield สำหรับการโทรกลับ "แบบอินไลน์" และตรวจสอบความผิดพลาดของตัวแปร

• TypeScriptของ Microsoft เป็นชุดของจาวาสคริปต์ขนาดเล็กที่ช่วยให้คุณวางข้อ จำกัด ประเภทกับอาร์กิวเมนต์ของฟังก์ชันซึ่งอาจจับข้อบกพร่องบางอย่าง BetterJSในทำนองเดียวกันช่วยให้คุณสามารถใช้ข้อ จำกัด แต่ในจาวาสคริปต์บริสุทธิ์โดยการเพิ่มการโทรพิเศษหรือโดยการระบุประเภทในความคิดเห็น JSDoc และตอนนี้ Facebook ได้เสนอโฟลว์ซึ่งดำเนินการอนุมานประเภทเพิ่มเติม

• LiveScriptเป็นสปินออกจาก Coffeescript ที่ได้รับความนิยมในช่วงเวลาสั้น ๆ แต่ก็ดูไม่ค่อยน่าอ่านสำหรับฉัน อาจไม่ใช่สิ่งที่ดีที่สุดสำหรับทีม

วิธีการเลือก

เมื่อเลือกภาษาอื่นมีปัจจัยที่ต้องพิจารณา :

• หากนักพัฒนารายอื่นเข้าร่วมโครงการของคุณในอนาคตพวกเขาจะใช้เวลาในการเร่งความเร็วและเรียนรู้ภาษานี้นานเท่าไหร่หรือโอกาสที่พวกเขาจะได้รู้ว่ามีอะไรบ้าง

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

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

อนาคต...

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

ควรเป็น JavaScript เป็นภาษาเดียวที่สนับสนุนบนแพลตฟอร์มเบราว์เซอร์หรือไม่

ใช่และไม่. มีทางเลือกอื่นที่เรียกว่า Dart โดย Google ซึ่งจะรวบรวม JavaScript และเหมือนกับ jQuery ซึ่งพยายามทำให้การจัดการ DOM ง่ายขึ้นเล็กน้อย มันอาจจะสนุกกับการทดสอบลองดูสิ

• จาก Google ดูภาษาโผ
• จาก Microsoft ดูภาษา TypeScript

ดูสิ่งนี้ด้วย

• ไม้ต้นจำพวก ulmus
• Kal

มันเป็นความจริงที่ Javascript เคยมีมาจนถึงจุดหนึ่งที่ยากที่จะจัดการ แต่ชุมชนการพัฒนาเว็บเริ่มมาไกล ฉันขอแนะนำให้คุณดูjQueryแทน ง่ายและเป็นนามธรรมออกไปปัญหาต่าง ๆ ทั้งหมด

และไม่มีทางเลือกอื่นที่สามารถใช้ได้ทั่วกระดาน Flash มาถึงใจ แต่นั่นก็เป็นสคริปต์ ECMA และมันก็น่าจะจบสิ้นลงสำหรับสิ่งส่วนใหญ่

ระยะสั้นฉันจะใช้สิ่งต่าง ๆ เช่น jQuery เพื่อซ่อนความไม่เข้ากันของเบราว์เซอร์ ในระยะยาวเทคโนโลยีเช่น Silverlight หรือ Adobe AIR อาจทำให้เป็นเขตที่วางทุ่นระเบิดที่แตกต่างกันมาก (แต่ยังคงเป็นทุ่นระเบิด) ในอนาคต

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

สำหรับ DOM manipuluation ให้ดูที่ JQuery เป็นไลบรารีฝั่งไคลเอ็นต์ที่แทนที่ DOM API อันน่ากลัวส่วนใหญ่ด้วยการดำเนินการที่เจ็บปวดในการเขียนไปยังโค้ดที่สง่างามและง่ายต่อการเขียน

หากคุณคิดว่า JavaScript มีปัญหาลึกฉันแนะนำหนังสือของ Doug Crockford, JavaScript: The Good Partsส่วนดี (หรือ Google สำหรับ "Crockford JavaScript" เพื่อค้นหางานนำเสนอวิดีโอหลายรายการที่เขาทำ) Crockford วาดชุดย่อยที่ปลอดภัยและชุดของการปฏิบัติและแสดงรายการบางส่วนของภาษาเพื่อหลีกเลี่ยงโดยเฉพาะ

ฉันไม่รู้แผนจะเปลี่ยน JavaScript เป็นพฤตินัยวิธีการจัดการ DOM ดังนั้นควรเรียนรู้วิธีใช้อย่างปลอดภัยและดีที่สุด

ในแง่ของ Javascript ฝั่งไคลเอ็นต์เป็นวิธีเดียวที่จะจัดการ DOM ในแง่ของฝั่งเซิร์ฟเวอร์มีหลายวิธี

Internet Explorer รองรับภาษาสคริปต์แบบเสียบได้แม้ว่าจะมีเพียงหนึ่งภาษาที่เชื่อถือได้กับ IE ที่นอกเหนือจาก JScript คือ VBScript

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

ถ้าคุณยินดีที่จะ จำกัด ลูกค้าของคุณ / ผู้เข้าชมเฉพาะเบราว์เซอร์และอาจจะเต็มใจที่จะต้องการให้พวกเขาติดตั้ง plug-in ที่คุณสามารถดูMS Silverlight - ภาพรวมที่สามารถอ่านได้อยู่ในวิกิพีเดีย ด้วย Silverlight 2 คุณสามารถเรียกใช้ฝั่งไคลเอ็นต์รหัสที่คุณเขียนใน C #, IronPython, IronRuby, VB.NET ฯลฯ ฟรีแสงจันทร์โคลนของ Silverlight จากโครงการโมโนสัญญาว่าจะนำมาซึ่งการทำงานเดียวกันกับลินุกซ์

ในทางปฏิบัตินักพัฒนาเว็บแอปและเว็บไซต์ส่วนใหญ่ต้องการเข้าถึงผู้ชมที่กว้างกว่า Silverlight (และในที่สุด Moonlight) สามารถส่งได้ - ซึ่งหมายถึงการเกาะติด Javascript หรือ Flash (ซึ่งใช้ภาษาการเขียนโปรแกรมที่คล้ายกัน Actionscript)

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

ดังที่ได้กล่าวไปแล้วว่าคุณมี Flash (ActionScript ซึ่งเป็นภาษาที่ได้รับจาก Javascript) และ Silverlight / Moonlight (IronPython, IronRuby, JScript, VBScript, C #) ที่สามารถเรียกใช้ในเบราว์เซอร์ผ่านปลั๊กอิน (ภาษาแรกที่แพร่หลายมากขึ้น) .

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

สิ่งหนึ่งที่ฉันไม่ได้เห็นกล่าวถึง (โอ้ฉันเห็น Alcides พูดถึง HotRuby ในขณะที่ฉันกำลังเขียนและ Nosredna พูดถึง GWT และสคริปต์ #) และต้องการที่จะโยนออกมีจำนวนของการใช้งานของ [แทรกภาษา] - บน - JavaScript (เช่นนักแปลที่ให้คุณแปลงRuby , Python , C # , Java , Obj-J / Cappuccino [คล้ายกับ Obj-C / Cocoa] หรือกำลังประมวลผล [สำหรับ Canvas] เป็น JavaScript บนไคลเอนต์หรือก่อนการปรับใช้ [และบางอย่าง ซึ่งยังมีห้องสมุดนามธรรมที่หลากหลาย]) แน่นอนว่ามีค่าใช้จ่ายด้านประสิทธิภาพหากมีการแปลให้ลูกค้า แต่ถ้าคุณคุ้นเคยกับภาษาอื่นก็จะทำให้คุณมีความยืดหยุ่น

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

ไม่ใช่ JavaScript คือมัน แต่มันจะพัฒนาขึ้น รุ่นถัดไปคือ "JavaScript Harmony" และคุณสามารถเรียนรู้เพิ่มเติมได้ถ้าคุณเป็น Google

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

ฉันรัก JavaScript แต่มีวิธีแก้ไขปัญหาอื่น ๆ รวมถึง GWT ซึ่งรวบรวม Java กับ JavaScript และ Script # ซึ่งรวบรวม C # ถึง JavaScript

Jquery (ยังเป็น javascript แต่) มันจะช่วยให้คุณได้รับการสนับสนุนสำหรับเบราว์เซอร์เกือบทั้งหมดและมันก็ไม่ยากที่จะเรียนรู้ :)

JavaScript เป็นภาษาอังกฤษของเว็บ ภาษาอังกฤษแพร่กระจายในอดีตเพราะมีกองทัพเรือที่แข็งแกร่งเอาชนะหลายประเทศ นี่เปรียบได้กับ บริษัท ใหญ่ ๆ ที่เอาชนะเว็บด้วย JavaScript มันเป็นภาษาที่รวบรวมเข้าด้วยกันจากแหล่งข้อมูลหลายแห่งในยุโรป (กรีก, ละติน, เยอรมัน, ฝรั่งเศสแม้แต่ภาษาจีนและอินเดียบางคำ) JavaScript ยืมแนวคิดจำนวนมากตลอดหลายปีที่ผ่านมาจากภาษาอื่น ๆ (โครงสร้าง, OO, การทำงาน) การพูดภาษาอังกฤษในสถานที่ต่าง ๆ มีความแตกต่างเล็กน้อยในภาษาและสำเนียงที่สามารถเข้าใจได้ยาก เช่นเดียวกับ JavaScript มีเบราว์เซอร์ที่แตกต่างกันตีความมันแตกต่างกันเล็กน้อย

แม้ว่าภาษาอังกฤษจะเรียนรู้ได้ง่ายในตอนแรกมันมีการออกเสียงที่ไม่สอดคล้องกันและมีข้อยกเว้นมากกว่ากฎ เช่นเดียวกับ JavaScript มันมีอยู่เสมอเพื่อให้แปลกใจ

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

มีความพยายามในการใช้ภาษาอังกฤษแทนภาษาหลักของโลกเช่นภาษาเอสเปรันโต แต่ทุกคนล้มเหลวเพราะคนส่วนใหญ่ในโลกพูดภาษาอังกฤษได้บ้าง ในทำนองเดียวกันมันจะเป็นการยากที่จะแนะนำทางเลือกที่ดีกว่าให้กับ JavaScript

ฉันไม่คิดว่า Javascript จะถูกแทนที่ตลอดเวลาในไม่ช้า สำหรับแนวทางที่แตกต่างอย่างสิ้นเชิงสำหรับลูกค้าที่ร่ำรวยคุณอาจต้องการตรวจสอบ Flex ซึ่งเป็นเทคโนโลยีแฟลช

บางทีสิ่งที่ชอบ haxe (ดู haxe.org) อาจช่วยคุณได้ มันเป็นภาษาที่ดูสะอาดกว่า JavaScript และสามารถเรียบเรียงเป็น JavaScript ได้ดังนั้นจึงสามารถเรียกใช้ในเบราว์เซอร์ได้

ฉันรู้ว่านี่ไม่ใช่คำตอบสำหรับคำถามของคุณโดยตรง แต่ฉันคิดว่ามันอาจจะน่าสนใจสำหรับคุณ

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

สิ่งนี้อธิบายว่าทำไมฉันถึงรู้ว่าไม่มีแผนการเปลี่ยนไปใช้ภาษาฝั่งไคลเอ็นต์ที่แตกต่างกัน

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