ฉันจะสามารถใช้รหัสเบราว์เซอร์ฝั่งไคลเอ็นต์ในภาษาที่ฉันเลือกได้หรือไม่? [ปิด]

15

ปิด คำถามนี้เป็นคำถามความคิดเห็นตาม ไม่ยอมรับคำตอบในขณะนี้

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

ปิดให้บริการใน6 ปีที่ผ่านมา

ฉันจะซื่อสัตย์อย่างไร้ความปราณี: ฉันเกลียดการเขียนโค้ดฝั่งไคลเอ็นต์ใน JavaScript ฉันไม่ใช่แฟนของภาษานี้ที่จะพูดน้อย

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

เงินฝากออมทรัพย์ขนาดใหญ่ของความพยายามที่ langauges กลางนำมาเกี่ยวกับที่รู้จักกันดี มีความคิดริเริ่มในการส่งเสริมเบราว์เซอร์ "สคริปต์" ในสิ่งอื่นที่ไม่ใช่ JavaScript และโดยเฉพาะอย่างยิ่งในเครื่องเสมือนที่ออกแบบพัฒนาและปรับแต่งแล้ว พวกเขามีแรงผลักดันหรือไม่?

programming-languages browser

— โรมันสตาร์คอฟ
แหล่งที่มา

ดูเพิ่มเติมที่: ทำไมไม่มีเว็บไซต์สคริปต์ภาษาฝั่งไคลเอ็นต์สำหรับเว็บไซต์อื่น ๆ

— ริ้น

11

เพื่อตอบคำถามของคุณใช่มีการพยายามเลิกจาวาสคริปต์เพื่อให้ได้ภาษาที่เหนียวแน่นสำหรับการเขียนสคริปต์เว็บ Google พยายามอย่างหนักที่อยู่เบื้องหลังภาษาDartของพวกเขา Dart มี VM เป็นของตัวเองซึ่งถูกฝังลงใน Chrome อยู่แล้ว แต่ฉันไม่แน่ใจว่าเบราว์เซอร์อื่น ๆ ได้นำมาใช้หรือไม่ นอกจากนี้ยังมีภาษาที่ค่อนข้างมีแนวโน้มที่เรียกว่าCoffeeScript

นอกจากนี้ยังมีโครงการที่มีความทะเยอทะยานมากที่เรียกว่าHaXeซึ่งมีเป้าหมายที่จะรวมแพลตฟอร์มการพัฒนาทั้งหมดด้วยภาษาเดียว ..

เชื่อฉันว่าคุณไม่ได้อยู่คนเดียวในจาวาสคริปต์ที่น่ารังเกียจ แต่ฉันกลัวว่ามันจะไม่เกิดขึ้นในไม่ช้า - ในความเป็นจริงดูเหมือนว่าจะได้รับแรงผลักดันมากมายกับ Windows 8 HTML5 / JS apps ฯลฯ แต่ทางเลือกอื่น ๆ กล่าวถึงจะเริ่มขึ้นในฤดูใบไม้ผลิ :)

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

9

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

— Timwi

3

@ Timwi, CIL มีน้ำหนักมากเกินไปและมีระบบราชการมากเกินไป มันจะไม่สมเหตุสมผลที่จะแนบไฟล์ bytecode ที่เต็มไปด้วยป่องโดยมีคลาสเฉพาะและเมตาดาต้าขนาดใหญ่ทั้งหมดเข้ากับonSomethingตัวจัดการเหตุการณ์แต่ละอัน- การแยกวิเคราะห์และตีความอักขระ 10-20 ตัวของภาษาสคริปต์อย่างง่ายมีประสิทธิภาพมากกว่า

— SK-logic

1

@ SK-logic: คุณดูเหมือนจะมีภาพที่ไม่ถูกต้องสมบูรณ์ของ CIL และ bytecode โดยทั่วไป ฉันไม่รู้ว่าอะไรจะทำให้คุณคิดว่าข้อมูลเมตาไบนารีนั้น“ ใหญ่โต” เมื่อเปรียบเทียบกับไวยากรณ์ระดับสูงเช่น JavaScript ที่สำคัญที่สุดฉันไม่รู้เลยว่าทำไม "ตัวจัดการเหตุการณ์แต่ละอย่างของทุกอย่าง" โปรแกรม C # อย่างชัดเจนไม่ได้รวบรวมเป็นชุดประกอบหลายรายการสำหรับตัวจัดการเหตุการณ์

— Timwi

1

@ Timwi ฉันกินอาหารเช้า ECMA-335 ดังนั้นฉันรู้ดีว่า CIL นั้นใหญ่ขนาดไหน โหนด DOM มักจะถูกสร้างแบบไดนามิก ไม่มีวิธีที่จะเพิ่มบางอย่างในโมดูลที่มีอยู่ใน CIL - คุณต้องกำหนดโมดูลใหม่ และคุณไม่สามารถเพิ่มไปยังคลาสได้ - คุณต้องกำหนดคลาสใหม่ (พร้อมเมทาดาทาขนาดใหญ่ที่แนบมา) และเพียงเปรียบเทียบค่าใช้จ่ายในการอ่าน JITing และดำเนินการ CIL กับการแยกวิเคราะห์ดำเนินการและทิ้งสตริงข้อความขนาดเล็กทันที มีหลายกรณีที่การตีความแบบเฉพาะกิจมีประสิทธิภาพมากกว่าการคอมไพล์ประเภทใด

— SK-logic

2

@Timwi คุณกำลังเสนอให้ใช้ bytecode เป็นตัวส่วนร่วมและรูปแบบการสื่อสารใช่ไหม ประเด็นของฉันคือสเปคปัจจุบันของ CIL ค่อนข้างไร้ประโยชน์ ExpandoObject ไม่เกี่ยวข้อง และมุมมองของคุณเกี่ยวกับความซับซ้อนในการแยกวิเคราะห์นั้นถูกบดบัง โมดูล CIL มีตารางอ้างอิงแอสเซมบลีของตัวเองตารางโทเค็นเมทาดาทาและคลาสและเมธอดเท่านั้น เปรียบเทียบความพยายามที่จำเป็นในการอ่านและ JIT ทั้งหมดที่มีขนาดใหญ่นี้ด้วยการตีความสตริงภาษาระดับสูงเล็กน้อย การแยกวิเคราะห์ต้นทุนเกือบเป็นศูนย์ที่นี่ ลองใช้วิธีทั้งสองแล้วเปรียบเทียบตัวเอง

— SK-logic

5

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

— John Snelson
แหล่งที่มา

5

เป็นหลักไม่มี คุณค่อนข้างติดกับ Javascript

ต้องบอกว่ามีความพยายามในอดีตที่จะนำภาษาอื่น ๆ ในคณะกรรมการ (จาวา, VBScript, ฯลฯ ) แต่ละเหล่านี้ไม่เคยได้รับจริงๆฉุดที่มีจาวาสคริปต์เพราะ JavaScript เป็นแบบบูรณาการ

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

แต่ตอนนี้เราเพิ่งอธิบาย Javascript

ดังนั้นในที่สุดตัวเลือกของคุณคือ:

รับใช้ Javascript
ลองใช้ภาษาที่คอมไพล์ลงไปที่ Javascript (โปรดทราบว่าคุณจะยังคงต้องการตรวจสอบ Javascript ซึ่งทำให้กลับไปที่ตัวเลือก 1)
ใช้ภาษาที่มีอยู่เป็นปลั๊กอินในเบราว์เซอร์เช่น actionscript (Flash), ActiveX, java applet, .Net (SilverLight) วิธีนี้จะช่วยหลีกเลี่ยงปัญหาที่เกิดขึ้นกับผู้ขายหลายราย / การใช้งานของภาษา แต่ไม่รวมภาษา

หากคุณต้องการภาษาที่ใช้งานร่วมกันแสดงว่าคุณติดกับจาวาสคริปต์

— ริชาร์ด
แหล่งที่มา

2

อีกทางเลือกหนึ่งคือใช้ภาษาที่คอมไพล์กับ javascript และใช้สิ่งนั้น

— Jetti

@Jetti คุณกำลังคิดCoffeeScriptหรือไม่? มันคำขวัญ - มันเป็น "กฎทอง" ที่พวกเขาเรียกมัน - คือ"มันก็แค่จาวาสคริ" แต่ถ้าคุณกำลังเขียนอะไรบางอย่างที่เป็นจาวาสคริปต์จริงๆแล้วคุณไม่ได้เขียนจาวาสคริปต์จริงๆเหรอ? มันก็เหมือนกับการพิสูจน์ว่า jQuery ไม่ใช่ javascript เพราะทำความสะอาดและใช้งานง่ายกว่า

— Richard

2

ดูรายการภาษาที่รวบรวมเป็นจาวาสคริปต์

— Jetti

@Jetti บางทีพวกเขาอาจจะไม่เป็นไร แต่ด้วยการเล่นโวหารของการสนับสนุนข้ามเบราว์เซอร์ฉันจะกังวลเกี่ยวกับการแนะนำใด ๆ เหล่านั้นและไม่ได้ตรวจสอบจาวาสคริปต์ที่เกิดขึ้นจริง

— Richard

1

ยกเว้นจาวาสคริปต์ที่เป็นภาษากลางที่น่ากลัวที่สุดและยากที่จะดำเนินการอย่างสม่ำเสมอ

— Milind R

4

ในความเป็นจริงคุณไม่ได้เกลียดจาวาสคริปต์ที่อธิบายไว้ในมาตรฐาน Ecma แต่คุณเกลียดการดำเนินงานอันยิ่งใหญ่เบราว์เซอร์ต่างๆกับพวกเขา quirks, ข้อบกพร่องและ WTFs Javascript ฝั่งเซิร์ฟเวอร์ค่อนข้างสนุกจริง ๆ นอกจากนี้รูปแบบ DOM ยังเป็นสาเหตุของ 80% ของความเจ็บปวดของจาวาสคริปต์ฝั่งไคลเอ็นต์

หากคุณยังต้องการใช้ภาษาอื่นคุณสามารถใช้GWTซึ่งโดยทั่วไปให้คุณเขียน Java จากนั้นรวบรวมเป็น javascript (น่าเกลียด) หรือCoffeeScriptซึ่งเป็นน้ำตาลเชิงไวยากรณ์ผ่าน JS ซึ่งรวบรวมไว้ใน JS

— Herreman ผ่อนผัน
แหล่งที่มา

9

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

— Timwi

1

@ Timwi มันเป็นฟังก์ชั่นที่ใช้และคุณสามารถเขียนรหัส OO ถ้าคุณต้องการ การพิมพ์แบบสแตติกนั้นดี แต่ถ้าโค้ดของคุณเขียนได้ดี (ฟังก์ชั่นเล็ก ๆ การกำหนดขอบเขตที่เหมาะสม) แสดงว่ามันไม่ค่อยมีปัญหา สำหรับการแทรกอัฒภาคฉันพบว่ามันน่ารำคาญเล็กน้อย มันเคยกัดฉันเพียงครั้งเดียวเพราะฉันมีการกลับมาและการเปิด{ของวัตถุในบรรทัดที่แตกต่างกัน กรอบการทำงานที่ทันสมัยคุณพบว่าอะไรหายไป?

— CaffGeek

2

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

— SK-logic

2

@ Timwi: คุณไม่เห็น objet-oriented เป็นสิ่งที่ไม่ดีในขณะที่มันไม่ได้เป็นอย่างนั้นเสมอ โปรดอย่าเห็น OOP เป็นสัญลักษณ์ของกระบวนทัศน์การพัฒนา วิธีการทำงานเช่น JS หรือ Scala ก็ยอดเยี่ยมเช่นกัน คุณสามารถมี OOP ใน JS ได้ แต่ความแตกต่างที่สำคัญคือมันคือการเขียนโปรแกรมแบบ Prototype แทนที่จะเป็นแบบการเขียนโปรแกรมแบบคลาส OOP เป็นชื่อแบบกว้างและไม่ จำกัด เฉพาะ Java / C # ต้นแบบที่ใช้นั้นแตกต่างจาก Class-based และใช้อย่างดีมันมีประสิทธิภาพเทียบเท่ากับ Class-based

— ผ่อนผัน Herreman

2

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

— Timwi

2

คำถามนี้ปรากฏขึ้นเป็นครั้งคราว

ทำไมเราไม่มีภาษาอื่น ๆ ในแท็กสคริปต์แทนที่จะเป็นเพียง Javascript

ย้อนกลับไปในวันที่ IE แนะนำ VB เป็นทางเลือกแทน Javascript ฉันคิดว่าคุณสามารถเห็นแล้วว่าสิ่งนี้จะนำไปสู่มาตรฐานนรกได้อย่างไรหากติดอยู่กับ ...

แล้วทำไมจึงไม่ใช้ภาษากลางมาตรฐานทั่วไปล่ะ?

มีพอดแคสต์รุ่นเก่าจากเบรนแดนเอชอธิบายว่าทำไมเขาไม่เห็นภาษาไบต์การ์ดตอนกลางในอนาคตอันใกล้:

http://www.aminutewithbrendan.com/pages/20101122

http://news.ycombinator.com/item?id=1893686

ปัญหาพื้นฐานคือในขณะที่ภาษากลาง (เช่น CIL และ JVM bytecodes) พยายามทั่วไป แต่ส่วนใหญ่พวกเขากลับกลายเป็นระดับต่ำเกินไปและผูกพันกับภาษาระดับสูงดั้งเดิมที่รวบรวมไว้ ตัวอย่างเช่นคุณไม่สามารถใช้ฟังก์ชั่นเรียกซ้ำแบบหางใน JVM - คุณลักษณะภาษาอื่นหรือตัวเลือกการใช้งานอื่น ๆ ที่เราจะไม่สามารถนำไปใช้ได้ถ้าเราจับคู่กับการใช้ bytecode ในระดับต่ำเร็วเกินไป?

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

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

แต่อาร์กิวเมนต์นี้ใช้กับ JavaScript ได้มากเท่ากับ JVM และ CIL ใช่ไหม :) สิ่งเดียวที่เกิดขึ้นกับ JavaScript ก็คือมันได้รับการสนับสนุนโดยเบราว์เซอร์ทั้งหมดแล้ว

— Roman Starkov

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

— hugomg

1

ใช่. คุณสามารถรวบรวม Dart, Coffeescript และ Java เป็น Javascript ได้แล้ว คุณมี Emscripten ซึ่งเป็นแบ็กเอนด์ของคอมไพเลอร์สำหรับ LLVM สำหรับสร้าง Javascript bytecode (และ LLVM สามารถจัดการกับภาษาได้ไม่กี่ภาษา)

แต่นอกเหนือจากการคอมไพล์กับ JS ไม่ใช่ในช่วงเวลาสั้น ๆ IE6 อายุ 10 ปีและยังคงเตะ ฉันหวังว่าเบราว์เซอร์ปัจจุบัน (ซึ่งไม่สนับสนุนภาษาอื่น ๆ ) จะไม่สามารถอยู่รอดได้นาน แต่พวกเขาจะอยู่ประมาณสองสามปีเพื่อกระตุ้นรอบการกัดหางของ "เรายังต้องสนับสนุนเบราว์เซอร์ที่รองรับ Javascript เท่านั้น ดังนั้นเราจึงต้องใช้ Javascript "ในทางที่ยากกว่าการพูด CSS3- เว็บไซต์ของคุณอาจทำงานได้โดยไม่ต้องใช้ CSS3 แต่ลองทำให้มันใช้งานได้โดยไม่ต้องใช้สคริปต์ฝั่งไคลเอ็นต์

— อเล็กซ์
แหล่งที่มา

0

คุณอาจจะโชคดี นี่คือย่อหน้าเปิดของการส่งบนฟอรัม webkit-dev:

หลายภาษารวบรวมไปยังจาวาสคริปต์ในวันนี้เพื่อให้ทำงานบนเว็บ เราได้ทำการทดลองกับการเปิดใช้งานภาษาที่ต่างกันใน WebKit เพื่อให้ทำงานในหน้าเว็บควบคู่ไปกับ JavaScript ...

คุณสามารถดูส่วนที่เหลือของข้อความที่นี่

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

0

JavaScript เป็นจิตวิญญาณของเบราว์เซอร์นั่นคือสาเหตุที่ความพยายามใหม่ส่วนใหญ่กำลังสร้าง JavaScript (CoffeeScript เป็นตัวอย่างที่ชัดเจน)
ใน GWT คุณเขียนโค้ดตรรกะฝั่งไคลเอ็นต์ของคุณในภาษาการเขียนโปรแกรม Java และชุดเครื่องมือที่สร้าง JavaScript

ClojureScript เป็นโครงการที่น่าสนใจถ้าคุณอยู่ในการเข้ารหัส Lisp

ดังนั้นจึงดูเหมือนว่าไม่ว่าอะไร JavaScript อยู่ที่นี่อยู่ (ภาษาโคบอลของเว็บอาจจะ?)

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

0

"ลูกค้าทุกคนสามารถมีสีรถที่ต้องการได้ตราบใดที่มันเป็นสีดำ" - เฮนรี่ฟอร์ด

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

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

หากคุณเกลียดจาวาสคริปต์ฉันขอแนะนำให้คุณย้ายเข้าไปในพื้นที่พัฒนาสมองกลฝังตัววิทยาศาสตร์หรือเกมโดยที่ C, Fortran และ C ++ เป็นผู้ควบคุม roost แอปทางธุรกิจมีการเคลื่อนย้ายไปยังเว็บเป็นอย่างมากและนั่นหมายถึง Javascript ที่มากขึ้นไม่น้อย

— Sean McMillan
แหล่งที่มา