ทำไม JavaScript แทนที่จะเป็นเครื่องเสมือนเบราว์เซอร์มาตรฐาน?

มันจะไม่สมเหตุสมผลหรือไม่ที่จะสนับสนุนชุดภาษา (Java, Python, Ruby, ฯลฯ ) โดยใช้เครื่องเสมือนมาตรฐานที่โฮสต์ในเบราว์เซอร์แทนที่จะต้องใช้ภาษาเฉพาะ - จริงๆเป็นกระบวนทัศน์เฉพาะ - สำหรับลูกค้าสคริปต์เท่านั้น

เพื่อชี้แจงคำแนะนำหน้าเว็บจะมีรหัสไบต์แทนภาษาระดับสูงกว่าเช่น JavaScript

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

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

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

ฉันไม่คิดว่า "ภาษาที่ออกแบบดีกว่า" ใด ๆ เหล่านี้จะเป็น Java, Python หรือ Ruby Javascript คือแม้จะมีความสามารถในการใช้งานที่อื่นภาษาสคริปต์เว็บแอปพลิเคชัน เมื่อพิจารณาถึงกรณีการใช้งานเราสามารถทำได้ดีกว่าภาษาใด ๆ

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

1. Google Native Client : เทคโนโลยีสำหรับการเรียกใช้รหัสเนทีฟในเบราว์เซอร์
2. Emscripten : LLVM bytecode คอมไพเลอร์เป็นจาวาสคริปต์ อนุญาตให้ภาษา LLVM ทำงานในเบราว์เซอร์
3. แนวคิด:. NET CLI ในเบราว์เซอร์โดยผู้สร้าง Mono: http://tirania.org/blog/archive/2010/May-03.html

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

ตอบคำถาม - ไม่มันไม่สมเหตุสมผล

ปัจจุบันสิ่งที่ใกล้เคียงที่สุดที่เรามีสำหรับ VM หลายภาษาคือ JVM และ CLR สิ่งเหล่านี้ไม่ใช่สัตว์ที่มีน้ำหนักเบาและมันไม่สมเหตุสมผลที่จะลองและฝังบางสิ่งบางอย่างที่มีขนาดและความซับซ้อนนี้ในเบราว์เซอร์

ลองตรวจสอบแนวคิดที่ว่าคุณสามารถเขียน VM แบบหลายภาษาใหม่ที่ดีกว่าโซลูชันที่มีอยู่

• คุณอยู่ข้างหลังอย่างมั่นคง
• คุณอยู่เบื้องหลังเรื่องความซับซ้อน (วิธี, วิธี, เบื้องหลังเพราะคุณพยายามพูดคุยกับหลายภาษา)
• คุณอยู่ข้างหลังในการนำไปใช้

ดังนั้นไม่มันไม่สมเหตุสมผล

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

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

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

ภาษาใดที่เหมาะสมที่จะนำมาใช้? (คำเตือนวัสดุอัตนัยดังต่อไปนี้)

การนำภาษาในแบบ C เข้าท่าไม่เหมาะสมเพราะมันทำมาเพื่อการใช้งานกับโลหะและในเบราว์เซอร์ก็มีโลหะไม่มากนัก

การนำภาษามาใช้อย่าง Java ไม่สมเหตุสมผลเพราะสิ่งที่ดีที่สุดเกี่ยวกับมันคือ APIs

การนำในภาษาอย่าง Ruby หรือ Lisp ไม่สมเหตุสมผลเพราะ JavaScript เป็นภาษาไดนามิกที่ทรงพลังใกล้กับ Scheme

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

มันไม่สมเหตุสมผล

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

ส่วนขยายของ Python win32 อนุญาตให้เพิ่ม Python ลงใน IE เช่นนี้ได้ค่อนข้างง่าย แต่ก็ไม่ใช่ความคิดที่ดีเพราะ Python นั้นค่อนข้างยากต่อการทดลองใช้: คุณลักษณะหลายภาษาแสดงให้เห็นถึงการใช้งานตะขอที่เพียงพอเพื่ออนุญาตให้แอปพลิเคชั่น .

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

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

ฉันจะต้อนรับ VM มาตรฐานภาษาอิสระในเบราว์เซอร์ (ฉันต้องการรหัสในภาษาที่พิมพ์แบบคงที่)

(ในทางเทคนิค) มันทำได้ค่อนข้างค่อยเป็นค่อยไป: เบราว์เซอร์หลักแรกรองรับและเซิร์ฟเวอร์มีความเป็นไปได้ที่จะส่ง bytecode ถ้าคำขอปัจจุบันมาจากเบราว์เซอร์ที่เข้ากันได้หรือแปลรหัสเป็น JavaScript และส่ง JavaScript ข้อความธรรมดา

มีภาษาทดลองอยู่บ้างที่รวบรวม JavaScript แต่การมี VM ที่กำหนดไว้ (อาจ) ทำให้มีประสิทธิภาพดีขึ้น

ฉันยอมรับว่าส่วน "มาตรฐาน" นั้นค่อนข้างยุ่งยาก นอกจากนี้ยังมีข้อขัดแย้งระหว่างคุณลักษณะภาษา (เช่นการพิมพ์แบบคงที่และแบบไดนามิก) ที่เกี่ยวข้องกับห้องสมุด (สมมติว่าสิ่งใหม่จะใช้ไลบรารีเดียวกัน) ดังนั้นฉันไม่คิดว่ามันจะเกิดขึ้น (เร็ว ๆ นี้)

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

หากไม่มีความต่อเนื่องในแอปพลิเคชันของคุณเนื่องจากฝั่งเซิร์ฟเวอร์และฝั่งไคลเอ็นต์ไม่สามารถสื่อสารได้ดีคุณอาจต้องการพิจารณาวิธีการออกแบบแอปพลิเคชันของคุณอีกครั้ง ฉันได้ทำงานกับเว็บไซต์และเว็บแอปพลิเคชั่นที่มีประสิทธิภาพมากและฉันไม่เคยพูดว่า "อืมฉันอยากให้ JavaScript สามารถทำได้ (xyz)" ถ้ามันสามารถทำเช่นนั้นมันจะไม่เป็น JavaScript - มันจะเป็น ActionScript หรือ AIR หรือ Silverlight ฉันไม่ต้องการสิ่งนั้นและไม่ทำนักพัฒนาส่วนใหญ่ นั่นเป็นเทคโนโลยีที่ดี แต่พวกเขาพยายามที่จะแก้ปัญหาด้วยเทคโนโลยีไม่ใช่วิธีแก้ปัญหา

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

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

เบราว์เซอร์เหล่านั้นที่สนับสนุนมาตรฐานใหม่จะได้รับประโยชน์จากความเร็วที่เพิ่มขึ้นของรันไทม์สำหรับแอปที่ใช้ Web vm ยิ่งไปกว่านั้นถ้าเบราว์เซอร์ใช้เครื่องมือจาวาสคริปต์ดั้งเดิมบนมาตรฐาน web vm (เช่นการแยกจาวาสคริปต์ในมาตรฐาน web vm แล้วเรียกใช้) พวกเขาไม่ต้องจัดการสอง runtimes แต่ขึ้นอยู่กับผู้ขายเบราว์เซอร์ .

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

อัปเดตด่วนสำหรับคำถามเก่านี้

ทุกคนที่ยืนยันว่า "หน้าเว็บจะมีรหัสไบต์แทนภาษาระดับสูงเช่น JavaScript" "จะไม่เกิดขึ้น"

มิถุนายน 2015 W3CประกาศWebAssemblyนั่นคือ

รูปแบบพกพาใหม่ขนาดและความเร็วในการโหลดที่เหมาะสำหรับการรวบรวมเว็บ

นี้ยังคงทดลอง แต่มีอยู่แล้วบางส่วนดำเนินการ prototypal ใน Firefox และ Chrome คืนเกาะคานารีและมีอยู่แล้วบางส่วนทำงานสาธิต

ปัจจุบัน WebAssembly ส่วนใหญ่ได้รับการออกแบบให้ผลิตจาก C / C ++ อย่างไรก็ตาม

เป็น WebAssembly วิวัฒนาการก็จะสนับสนุนภาษามากกว่า C / C ++ และเราหวังว่าคอมไพเลอร์อื่น ๆ จะให้การสนับสนุนเป็นอย่างดี

ฉันให้คุณได้ดูหน้าอย่างเป็นทางการของโครงการมันน่าตื่นเต้นจริงๆ!

คำถามนี้มีการ resurfaces อย่างสม่ำเสมอ ท่าทางของฉันเกี่ยวกับเรื่องนี้คือ:

A) จะไม่เกิดขึ้นและB) อยู่ที่นี่แล้ว

ให้อภัยอะไร ให้ฉันอธิบาย:

โฆษณา

VM ไม่ใช่เพียงแค่อุปกรณ์เวทมนต์สากลบางประเภท VMs ส่วนใหญ่ได้รับการปรับให้เหมาะสมกับภาษาและคุณลักษณะด้านภาษาบางอย่าง ใช้ JRE / Java (หรือ LLVM): ปรับให้เหมาะสมสำหรับการพิมพ์แบบสแตติกและมีปัญหาและข้อเสียแน่นอนเมื่อใช้การพิมพ์แบบไดนามิกหรือสิ่งอื่น ๆ ที่จาวาไม่สนับสนุนในตอนแรก

ดังนั้น "VMware อเนกประสงค์ทั่วไป" ที่รองรับคุณสมบัติภาษาจำนวนมาก (การเพิ่มประสิทธิภาพการโทรหาง, การพิมพ์แบบคงที่และแบบไดนามิก, foo bar boo, ... ) จะมีขนาดมหึมาใช้งานยากและอาจปรับให้ได้ประสิทธิภาพที่ดี มัน. แต่ฉันไม่ได้เป็นนักออกแบบภาษาหรือ vm guru บางทีฉันผิด: จริง ๆ แล้วมันค่อนข้างง่ายไม่มีใครมีความคิดเลยเหรอ? hrm, hrm

โฆษณา B

แล้วที่นี่: อาจไม่มีคอมไพเลอร์ bytecode / vm แต่คุณไม่จำเป็นต้องใช้ javascript afaik กำลังทำให้เสร็จสมบูรณ์ดังนั้นควรเป็นไปได้ที่:

1. สร้างนักแปลจากภาษา X ถึง javascript (เช่น coffeescript)
2. สร้างล่ามในจาวาสคริปต์ที่แปลภาษา X (เช่นbrainfuck ) ใช่การแสดงนั้นน่ารังเกียจ แต่เดี๋ยวก่อนไม่สามารถมีทุกอย่างได้

โฆษณา C

อะไร? ไม่มีจุด C ในตอนแรก! เพราะยังไม่มี ... google NACL ถ้าใครสามารถทำได้มันเป็น google ทันทีที่ google ทำให้มันใช้งานได้ปัญหาของคุณจะได้รับการแก้ไข เท่านั้นเอ่อมันอาจไม่ทำงานฉันไม่รู้ ครั้งสุดท้ายที่ผมอ่านเกี่ยวกับเรื่องนี้มีบางปัญหาด้านความปลอดภัยยังไม่แก้ของมันชนิดหากิน

นอกเหนือจากนี้:

• javascript อยู่ที่นั่นตั้งแต่ ~ 1995 = 15 ปี ยังใช้งานเบราว์เซอร์ที่แตกต่างกันในวันนี้ (อย่างน้อยก็ไม่สามารถทนไม่ได้อีกต่อไป) ดังนั้นหากคุณเริ่มสิ่งใหม่คุณอาจมีเบราว์เซอร์รุ่นที่ใช้งานได้ประมาณ 2035 อย่างน้อยก็เซ็ตย่อยที่ใช้งานได้ ที่แตกต่างอย่างละเอียดเท่านั้น และต้องการ libs และเลเยอร์ที่เข้ากันได้ ไม่มีประเด็นที่ไม่พยายามที่จะปรับปรุงสิ่งต่าง ๆ

• นอกจากนี้โค้ดเกี่ยวกับที่อ่านได้จะเป็นอย่างไร ฉันรู้ว่า บริษัท จำนวนมากไม่ต้องการให้บริการรหัสของพวกเขาในฐานะโอเพ่นซอร์ส "แบบ" โดยส่วนตัวฉันมีความสุขมากฉันสามารถอ่านต้นฉบับได้หากฉันสงสัยว่ามีบางสิ่งบางอย่างคาวหรือต้องการเรียนรู้จากมัน ไชโยสำหรับรหัสที่มา!

จริง Silverlight มีประสิทธิภาพเพียงแค่นั้น - VM ฝั่งไคลเอ็นต์. Net ที่ใช้ VM

มีข้อผิดพลาดบางอย่างในการให้เหตุผลของคุณ

1. เครื่องเสมือนมาตรฐานในเบราว์เซอร์มาตรฐานจะไม่เป็นมาตรฐาน เรามีเบราว์เซอร์ 4 แห่งและ IE มีความสนใจที่ขัดแย้งกันในเรื่อง 'มาตรฐาน' อีกสามคนกำลังพัฒนาอย่างรวดเร็ว แต่อัตราการยอมรับเทคโนโลยีใหม่ช้า สิ่งที่เกี่ยวกับเบราว์เซอร์บนโทรศัพท์อุปกรณ์ขนาดเล็ก ...

2. การรวมของ JS ในเบราว์เซอร์ที่แตกต่างกันและประวัติที่ผ่านมาทำให้คุณประเมินพลังของ JS น้อยเกินไป คุณจำนำมาตรฐาน แต่ไม่อนุมัติ JS เพราะมาตรฐานไม่ได้ผลในช่วงต้นปีที่ผ่านมา

3. ตามที่คนอื่นบอก JS นั้นไม่เหมือนกับ AIR / .NET / ... และอื่น ๆ JS ในการจุติมาเกิดในปัจจุบันนั้นลงตัวกับเป้าหมาย

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

คุณกำหนดอย่างไรดีที่สุด ดีที่สุดสำหรับเบราว์เซอร์หรือดีที่สุดสำหรับนักพัฒนา (เครื่องหมายบวก ECMAScript นั้นแตกต่างจาก Javascript แต่นั่นคือด้านเทคนิค)

ฉันพบว่า JavaScript สามารถมีประสิทธิภาพและสวยงามในเวลาเดียวกัน น่าเสียดายที่นักพัฒนาส่วนใหญ่ที่ฉันได้พบถือว่าเป็นความชั่วร้ายที่จำเป็นแทนภาษาโปรแกรมจริง

คุณสมบัติบางอย่างที่ฉันชอบคือ:

• ปฏิบัติหน้าที่ในฐานะพลเมืองชั้นหนึ่ง
• ความสามารถในการเพิ่มและลบฟังก์ชั่นไปยังวัตถุใด ๆ ได้ตลอดเวลา (ไม่เป็นประโยชน์มาก แต่ใจเป่าเมื่อมัน)
• มันเป็นภาษาแบบไดนามิก

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

ฉันยอมรับว่ามันน่าหงุดหงิดเมื่อสร้างหน้าเว็บแบบไดนามิกเนื่องจากความเข้ากันไม่ได้ของเบราว์เซอร์ แต่สามารถลดลงได้โดยไลบรารี UI ที่ไม่ควรถูกต่อต้าน JavaScript ตัวเองอีกต่อไปกว่า Swing ควรถูกจัดการกับ Java

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

มันเป็นความคิดที่ยอดเยี่ยม ทำไมไม่ก้าวไปอีกขั้น

• เขียน HTML parser และเครื่องมือเค้าโครง (บิตที่ซับซ้อนทั้งหมดในเบราว์เซอร์จริงๆ) ในภาษา VM เดียวกัน
• เผยแพร่เครื่องมือไปยังเว็บ
• แสดงหน้าด้วยการประกาศว่าจะใช้เอ็นจิ้นโครงร่างใดและ URL ของมัน

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

ฉันยินดีต้อนรับทุกภาษานอกเหนือจากจาวาสคริปต์เป็นภาษาสคริปต์ที่เป็นไปได้

สิ่งที่จะเจ๋งคือการใช้ภาษาอื่นแล้วจาวาสคริปต์ Java อาจจะไม่เหมาะสมระหว่างแท็ก แต่ภาษาเช่น Haskell, Clojure, Scala, Ruby, Groovy จะเป็นประโยชน์

ฉันมาข้ามรูบิสสิ ธ เมื่อไม่นานมานี้ ... http://almaer.com/blog/running-ruby-in-the-browser-via-script-typetextrubyและhttp://code.google.com/p/ruby- ในเบราว์เซอร์ /
ยังอยู่ระหว่างการทดลองและอยู่ระหว่างดำเนินการ แต่มีแนวโน้มที่ดี
สำหรับ. Net ฉันเพิ่งพบ: http://www.silverlight.net/learn/dynamic-languages/เพิ่งพบเว็บไซต์ออกมา แต่ก็ดูน่าสนใจเช่นกัน ทำงานได้แม้จากApple MacของฉันMac

ไม่ทราบว่าวิธีการที่ดีในการให้ทางเลือกสำหรับ Javascript นั้นมีประโยชน์อย่างไร อาจเป็นไปได้สิ่งนี้จะอนุญาตให้ใช้ Java หรือ. Net framework ใดก็ได้จากเบราว์เซอร์ - ภายในแซนด์บ็อกซ์ของเบราว์เซอร์

เพื่อความปลอดภัยหากภาษาทำงานใน JVM (หรือ. Net engine สำหรับเรื่องนั้น) VM จะดูแลความปลอดภัยดังนั้นเราจึงไม่ต้องกังวลเกี่ยวกับสิ่งนั้น - อย่างน้อยก็ไม่ควรทำอะไรก็ได้ที่ทำงาน ภายในเบราว์เซอร์

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

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

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

เว็บไซต์เก่า แต่ยังคงเป็นสถานที่ที่ดีที่จะเริ่มต้น: เว็บไซต์ดักลาส Crockford ของ

เรามี VBScript แล้วใช่ไหม รอเพียง IE เท่านั้นที่รองรับมัน!
เหมือนกับความคิดที่ดีของคุณเกี่ยวกับ VM ถ้าฉันเขียนสคริปต์หน้าของฉันโดยใช้ Lua และเบราว์เซอร์ของคุณไม่มีโปรแกรมแยกวิเคราะห์เพื่อแปลงเป็น bytecode แน่นอนว่าเราสามารถจินตนาการแท็กสคริปต์ที่รับไฟล์ bytecode ว่าแม้จะมีประสิทธิภาพมาก
แต่ประสบการณ์แสดงให้เห็นว่าเป็นการยากที่จะนำสิ่งใหม่ ๆ มาสู่เว็บ: มันต้องใช้เวลาหลายปีกว่าจะยอมรับการเปลี่ยนแปลงใหม่ที่รุนแรงเช่นนี้ มีเบราว์เซอร์กี่ตัวที่สนับสนุน SVG หรือ CSS3

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

ลองดูที่http://www.visitmix.com/Labs/Gestalt/ - ให้คุณใช้ python หรือ ruby ​​ตราบใดที่ผู้ใช้ติดตั้ง Silverlight

นี่เป็นคำถามที่ดีมาก

ไม่ใช่ปัญหาเฉพาะใน JS เท่านั้นเนื่องจากไม่มี IDEs ฟรีที่ดีสำหรับการพัฒนาโปรแกรมขนาดใหญ่ใน JS ฉันรู้เพียงหนึ่งเดียวที่ให้บริการฟรี: Eclipse อีกสิ่งที่ดีคือ Visual Studio ของ Microsoft แต่ไม่ฟรี

ทำไมถึงต้องเป็นฟรี หากผู้ขายเว็บเบราว์เซอร์ต้องการแทนที่แอปเดสก์ท็อปด้วยแอปออนไลน์ (และพวกเขาต้องการ) จากนั้นพวกเขาจะต้องให้เราโปรแกรมเมอร์ผู้พัฒนาเครื่องมือที่ดี คุณไม่สามารถสร้าง JavaScript ได้ 50,000 บรรทัดโดยใช้โปรแกรมแก้ไขข้อความอย่างง่าย JSLint และดีบักเกอร์ Google Chrome ในตัว นอกเสียจากคุณจะเป็นคนขี้อาย

เมื่อ Borland สร้าง IDE สำหรับ Turbo Pascal 4.0 ในปี 1987 มันเป็นการปฏิวัติในการเขียนโปรแกรม 24 ปีที่ผ่านมาตั้งแต่ น่าอับอายในปี 2011 โปรแกรมเมอร์จำนวนมากยังคงไม่ใช้โค้ดที่สมบูรณ์การตรวจสอบไวยากรณ์และดีบั๊กที่เหมาะสม อาจเป็นเพราะมีไอดีดีไม่กี่คน

ผู้ขายเว็บเบราว์เซอร์มีความสนใจในการสร้างเครื่องมือ (ฟรี) ที่เหมาะสมสำหรับโปรแกรมเมอร์หากพวกเขาต้องการให้เราสร้างแอปพลิเคชันที่สามารถต่อสู้กับ Windows, Linux, MacOS, iOS, Symbian และอื่น ๆ

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

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

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

บางทีคุณอาจกำลังมองหา Native Client ของ Google

ในแง่หนึ่งการมีภาษาที่แสดงออกเช่น Javascript ในเบราว์เซอร์มากกว่าสิ่งทั่วไปเช่น Java bytecode นั้นหมายถึงเว็บที่เปิดกว้างขึ้น

ฉันคิดว่านี่ไม่ใช่ปัญหาง่ายนัก เราสามารถพูดได้ว่าเราติดอยู่กับ JS แต่มันแย่จริง ๆ กับ jQuery, Prototype, scriptaculous, MooTools และไลบรารี่ที่ยอดเยี่ยมทั้งหมดหรือไม่?

โปรดจำไว้ว่า JS มีน้ำหนักเบามากยิ่งขึ้นด้วย V8, TraceMonkey, SquirrelFish - เครื่องมือ Javascript ใหม่ที่ใช้ในเบราว์เซอร์สมัยใหม่

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

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

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

อย่างไรก็ตามคุณไม่จำเป็นต้อง "สกปรก" เพื่อทำงานกับลูกค้า ตัวอย่างเช่นลอง GWT

... คุณหมายถึง ...

แอปเพล็ต Java และ Java แฟลชและ Adobe AIR ฯลฯ

โดยทั่วไปกรอบงาน RIA ใด ๆ สามารถตอบสนองความต้องการของคุณได้ แต่สำหรับทุกคนมีราคาที่จะต้องจ่ายสำหรับการใช้มัน (ej. รันไทม์ avalible บนเบราว์เซอร์หรือ / และ propietary หรือ / และตัวเลือกน้อยกว่าเดสก์ทอปบริสุทธิ์) http://en.wikipedia.org/wiki/List_of_rich_internet_application_frameworks

สำหรับการพัฒนาเว็บด้วยภาษาอื่น ๆ คุณไม่มี GWT: พัฒนา Java, คอมไพล์เป็น Javascript

เพราะพวกเขาทุกคนมี VM ที่มีล่าม bytecode อยู่แล้วและ bytecode ก็ต่างกันเช่นกัน {Chakra (IE), Firefox (SpiderMonkey), Safari (SquirrelFish), Opera (Carakan)

ขออภัยฉันคิดว่า Chrome (V8) รวบรวมรหัสเครื่อง IA32

ด้วยการพิจารณาว่าเบราว์เซอร์ทั้งหมดใช้ VM อยู่แล้วฉันไม่คิดว่ามันจะเป็นการยากที่จะสร้างภาษา VM สำหรับเว็บ
ฉันคิดว่ามันจะช่วยได้อย่างมากด้วยเหตุผลบางประการ:
1. เนื่องจากเซิร์ฟเวอร์รวบรวมรหัสปริมาณข้อมูลที่ส่งจึงมีขนาดเล็กลงและลูกค้าไม่ได้ใช้เวลาในการรวบรวมรหัส
2. เนื่องจากเซิร์ฟเวอร์สามารถรวบรวมรหัสในการจัดเตรียมและจัดเก็บได้ซึ่งแตกต่างจากไคลเอนต์ที่พยายามที่จะเอวเวลาน้อยเวลารวบรวม JS อย่างรวดเร็วก็สามารถทำให้การปรับรหัสที่ดีขึ้น
3. การคอมไพล์ภาษาเป็นรหัสไบต์เป็นวิธีที่ง่ายกว่าจากนั้นทำการเปลี่ยนเป็น JS

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

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

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