Tại sao JavaScript chứ không phải là một máy ảo trình duyệt tiêu chuẩn?

Sẽ không có ý nghĩa gì khi hỗ trợ một tập hợp các ngôn ngữ (Java, Python, Ruby, v.v.) bằng một máy ảo được tiêu chuẩn hóa được lưu trữ trong trình duyệt thay vì yêu cầu sử dụng một ngôn ngữ chuyên ngành - thực sự, một mô hình chuyên ngành - chỉ cho kịch bản máy khách?

Để làm rõ đề xuất, một trang web sẽ chứa mã byte thay vì bất kỳ ngôn ngữ cấp cao hơn như JavaScript.

Tôi hiểu thực tế thực tế rằng JavaScript chỉ đơn giản là những gì chúng ta phải làm việc bây giờ vì lý do tiến hóa, nhưng tôi đang suy nghĩ nhiều hơn về lâu dài. Liên quan đến khả năng tương thích ngược, không có lý do gì mà JavaScript nội tuyến không thể được hỗ trợ đồng thời trong một khoảng thời gian và tất nhiên JavaScript có thể là một trong những ngôn ngữ được máy ảo trình duyệt hỗ trợ.

Vâng, vâng. Chắc chắn nếu chúng ta có một cỗ máy thời gian, quay trở lại và đảm bảo nhiều tính năng Javascript được thiết kế khác nhau sẽ là một trò tiêu khiển lớn (điều đó, và đảm bảo những người thiết kế công cụ CSS của IE không bao giờ đi vào CNTT). Nhưng nó sẽ không xảy ra, và chúng ta đang bị mắc kẹt với nó bây giờ.

Tôi nghi ngờ, theo thời gian, nó sẽ trở thành "Ngôn ngữ máy" cho web, với các ngôn ngữ và API được thiết kế tốt hơn khác được biên dịch theo nó (và phục vụ cho các bộ máy công cụ thời gian chạy khác nhau).

Tuy nhiên, tôi không nghĩ rằng bất kỳ "ngôn ngữ được thiết kế tốt hơn" nào sẽ là Java, Python hoặc Ruby. Javascript, mặc dù có khả năng được sử dụng ở nơi khác, ngôn ngữ kịch bản ứng dụng Web. Với trường hợp sử dụng đó, chúng tôi có thể làm tốt hơn bất kỳ ngôn ngữ nào.

Tôi nghĩ rằng JavaScript là một ngôn ngữ tốt, nhưng tôi rất thích có sự lựa chọn khi phát triển các ứng dụng web phía máy khách. Vì lý do di sản, chúng tôi bị mắc kẹt với JavaScript, nhưng có những dự án và ý tưởng đang tìm cách thay đổi kịch bản đó:

1. Google Native Client : công nghệ để chạy mã gốc trong trình duyệt.
2. Emscripten : Trình biên dịch mã byte LLVM sang javascript. Cho phép các ngôn ngữ LLVM chạy trong trình duyệt.
3. Ý tưởng: .NET CLI trong trình duyệt, bởi người tạo ra Mono: http://tirania.org/blog/archive/2010/May-03.html

Tôi nghĩ rằng chúng ta sẽ có JavaScript trong một thời gian dài, nhưng điều đó sẽ thay đổi sớm hay muộn. Có rất nhiều nhà phát triển sẵn sàng sử dụng các ngôn ngữ khác trong trình duyệt.

Trả lời câu hỏi - Không, nó sẽ không có ý nghĩa.

Hiện tại những thứ gần nhất chúng ta có với một VM đa ngôn ngữ là JVM và CLR. Đây không phải là những con thú nhẹ chính xác, và sẽ không có ý nghĩa gì khi thử và nhúng thứ gì đó có kích thước và độ phức tạp này vào trình duyệt.

Hãy xem xét ý tưởng rằng bạn có thể viết một VM mới, đa ngôn ngữ sẽ tốt hơn giải pháp hiện có.

• Bạn đứng sau sự ổn định.
• Bạn bị tụt hậu về sự phức tạp (cách, cách, phía sau vì bạn đang cố gắng khái quát hóa qua nhiều ngôn ngữ)
• Bạn chậm nhận con nuôi

Vì vậy, không, nó không có ý nghĩa.

Hãy nhớ rằng, để hỗ trợ các ngôn ngữ này, bạn sẽ phải loại bỏ API của chúng một cách dữ dội, loại bỏ bất kỳ phần nào không có ý nghĩa trong ngữ cảnh của tập lệnh trình duyệt. Có một số lượng lớn các quyết định thiết kế được đưa ra ở đây, và một cơ hội lớn cho lỗi.

Về chức năng, có lẽ chúng ta chỉ thực sự làm việc với DOM, vì vậy đây thực sự là một vấn đề về cú pháp và thành ngữ ngôn ngữ, tại thời điểm đó có ý nghĩa gì để hỏi, "Điều này có thực sự đáng không?"

Mang trong tâm trí, duy nhất điều nhất chúng ta đang nói đến là kịch bản phía máy khách, bởi vì kịch bản phía máy chủ đã có sẵn bằng bất kỳ ngôn ngữ nào bạn muốn. Đó là một lĩnh vực lập trình tương đối nhỏ và vì vậy lợi ích của việc mang nhiều ngôn ngữ vào là điều đáng nghi ngờ.

Những ngôn ngữ nào sẽ có ý nghĩa để mang vào? (Cảnh báo, tài liệu chủ quan sau)

Mang một ngôn ngữ như C không có ý nghĩa gì vì nó được tạo ra để làm việc với kim loại và trong trình duyệt không có nhiều kim loại thực sự có sẵn.

Mang một ngôn ngữ như Java không có ý nghĩa gì vì điều tốt nhất về nó là các API.

Mang một ngôn ngữ như Ruby hoặc Lisp không có ý nghĩa gì vì JavaScript là ngôn ngữ động mạnh mẽ rất gần với Đề án.

Cuối cùng, nhà sản xuất trình duyệt nào thực sự muốn hỗ trợ tích hợp DOM cho nhiều ngôn ngữ? Mỗi thực hiện sẽ có lỗi cụ thể của riêng mình. Chúng ta đã trải qua việc đối phó với sự khác biệt giữa MS Javascript và Mozilla Javascript và bây giờ chúng ta muốn nhân lên nỗi đau đó gấp năm hay sáu lần?

Nó không có ý nghĩa.

Trên Windows, bạn có thể đăng ký các ngôn ngữ khác với Scripting Host và cung cấp chúng cho IE. Ví dụ, VBScript được hỗ trợ ngoài hộp (mặc dù nó chưa bao giờ được phổ biến vì nó dành cho hầu hết các mục đích thậm chí còn tồi tệ hơn JavaScript).

Các tiện ích mở rộng Python win32 cho phép một người thêm Python vào IE như thế này khá dễ dàng, nhưng thực sự không phải là một ý tưởng hay vì Python khá khó khăn trong hộp cát: nhiều tính năng ngôn ngữ phơi bày đủ các móc thực hiện để cho phép một ứng dụng bị hạn chế bị phá vỡ .

Nói chung, có một vấn đề là bạn càng thêm phức tạp vào một ứng dụng phải đối mặt với mạng như trình duyệt thì khả năng xảy ra sự cố bảo mật càng cao. Một loạt các ngôn ngữ mới chắc chắn sẽ phù hợp với mô tả đó, và đây là những ngôn ngữ mới vẫn đang phát triển nhanh.

JavaScript là một ngôn ngữ xấu, nhưng thông qua việc sử dụng cẩn thận một tập hợp con các tính năng có chọn lọc và sự hỗ trợ từ các thư viện đối tượng phù hợp, nhìn chung nó có thể được chấp nhận khá dễ chịu. Dường như gia tăng, bổ sung thực tế cho JavaScript là cách duy nhất để kịch bản web có thể tiếp tục.

Tôi chắc chắn sẽ hoan nghênh một VM độc lập với ngôn ngữ tiêu chuẩn trong các trình duyệt (tôi thích viết mã bằng ngôn ngữ được nhập tĩnh).

(Về mặt kỹ thuật) Điều đó hoàn toàn có thể thực hiện được: một trình duyệt chính đầu tiên hỗ trợ nó và máy chủ có khả năng gửi mã byte nếu yêu cầu hiện tại là từ trình duyệt tương thích hoặc dịch mã sang JavaScript và gửi JavaScript văn bản thuần túy.

Đã tồn tại một số ngôn ngữ thử nghiệm biên dịch thành JavaScript, nhưng có một VM được xác định sẽ (có thể) cho phép hiệu suất tốt hơn.

Tuy nhiên, tôi thừa nhận rằng phần "tiêu chuẩn" sẽ khá khó khăn. Ngoài ra, sẽ có xung đột giữa các tính năng ngôn ngữ (ví dụ: gõ tĩnh so với gõ động) liên quan đến thư viện (giả sử điều mới sẽ sử dụng cùng một thư viện). Vì vậy, tôi không nghĩ rằng nó sẽ xảy ra (sớm).

Nếu bạn cảm thấy như mình đang bị bẩn tay, thì bạn đã bị tẩy não hoặc vẫn đang cảm thấy những ảnh hưởng sau "năm DHTML". JavaScript rất mạnh và phù hợp với mục đích của nó, đó là phía máy khách tương tác kịch bản. Đây là lý do tại sao JavaScript 2.0 có một bản rap tệ như vậy. Ý tôi là, tại sao các gói, giao diện, lớp và những thứ tương tự, khi đó là những khía cạnh rõ ràng của các ngôn ngữ phía máy chủ. JavaScript chỉ tốt như một ngôn ngữ dựa trên nguyên mẫu, mà không phải là hướng đối tượng toàn diện.

Nếu thiếu tính liền mạch cho các ứng dụng của bạn vì phía máy chủ và phía máy khách không giao tiếp tốt, thì bạn có thể muốn xem xét lại cách bạn kiến ​​trúc các ứng dụng của mình. Tôi đã làm việc với các trang web và ứng dụng Web cực kỳ mạnh mẽ và tôi chưa bao giờ nói: "Hmm, tôi thực sự mong muốn JavaScript có thể làm được (xyz)." Nếu nó có thể làm điều đó, thì đó sẽ không phải là JavaScript - đó sẽ là ActionScript hoặc AIR hoặc Silverlight. Tôi không cần điều đó, và hầu hết các nhà phát triển cũng không. Đó là những công nghệ tốt, nhưng họ cố gắng giải quyết vấn đề bằng một công nghệ, chứ không phải ... à, một giải pháp.

Tôi không nghĩ rằng một máy ảo web tiêu chuẩn là không thể tưởng tượng được. Có một số cách bạn có thể giới thiệu một tiêu chuẩn VM web mới một cách duyên dáng và với sự hỗ trợ đầy đủ, miễn là bạn đảm bảo rằng bất kỳ định dạng mã byte VM nào bạn sử dụng đều có thể được dịch ngược thành javascript và đầu ra kết quả sẽ có hiệu quả hợp lý ( Tôi thậm chí còn đi xa hơn để đoán rằng một trình dịch ngược thông minh có thể sẽ tạo ra javascript tốt hơn bất kỳ javascript nào mà con người có thể tự tạo ra).

Với thuộc tính này, mọi định dạng VM web có thể dễ dàng dịch ngược trên máy chủ (nhanh), trên máy khách (chậm, nhưng có thể trong trường hợp bạn kiểm soát máy chủ hạn chế) hoặc có thể được tạo trước và tải động máy khách hoặc máy chủ (nhanh nhất) cho các trình duyệt không hỗ trợ chuẩn mới.

Những trình duyệt DO thực sự hỗ trợ tiêu chuẩn mới sẽ được hưởng lợi từ tốc độ thời gian chạy tăng lên cho các ứng dụng dựa trên vm web. Trên hết, nếu các trình duyệt dựa trên các công cụ javascript kế thừa của họ theo tiêu chuẩn vm web (nghĩa là phân tích javascript thành tiêu chuẩn vm web và sau đó chạy nó), thì họ không phải quản lý hai thời gian chạy, nhưng điều đó tùy thuộc vào nhà cung cấp trình duyệt .

Mặc dù Javascript là ngôn ngữ kịch bản được hỗ trợ tốt mà bạn có thể điều khiển trang trực tiếp từ đó, Flash có một số tính năng rất hay cho các chương trình lớn hơn. Gần đây, nó có JIT và cũng có thể tạo mã byte một cách nhanh chóng (kiểm tra đánh giá biểu thức thời gian chạy để biết ví dụ về việc họ sử dụng flash để biên dịch các biểu thức toán học đầu vào của người dùng cho đến nhị phân gốc). Ngôn ngữ Haxe cung cấp cho bạn kiểu gõ tĩnh với suy luận và với khả năng tạo mã byte, bạn có thể thực hiện hầu hết mọi hệ thống thời gian chạy mà bạn chọn.

Cập nhật nhanh về câu hỏi cũ này.

Mọi người khẳng định rằng "trang web sẽ chứa mã byte thay vì bất kỳ ngôn ngữ cấp cao hơn như JavaScript" "sẽ không xảy ra".

Tháng 6 năm 2015, W3C đã công bố WebAssugging , đó là

một định dạng di động, kích thước và tải thời gian hiệu quả mới phù hợp để biên dịch lên web.

Đây vẫn là thử nghiệm, nhưng đã có một số triển khai nguyên mẫu trong Firefox hàng đêm và Chrome Canary và đã có một số trình diễn hoạt động .

Hiện tại, WebAssugging được thiết kế chủ yếu để sản xuất từ ​​C / C ++, tuy nhiên

khi WebAssugging phát triển, nó sẽ hỗ trợ nhiều ngôn ngữ hơn C / C ++ và chúng tôi hy vọng rằng các trình biên dịch khác cũng sẽ hỗ trợ nó .

Tôi cho bạn có cái nhìn cận cảnh hơn về trang chính thức của dự án, nó thực sự rất thú vị!

Câu hỏi này xuất hiện trở lại thường xuyên. lập trường của tôi về điều này là:

A) sẽ không xảy ra và B) đã ở đây.

Xin lỗi, cái gì? hãy để tôi giải thích:

quảng cáo A

VM không chỉ là một loại thiết bị ma thuật phổ quát. hầu hết các VM được tối ưu hóa cho một ngôn ngữ nhất định và các tính năng ngôn ngữ nhất định. lấy JRE / Java (hoặc LLVM): được tối ưu hóa cho kiểu gõ tĩnh và chắc chắn có những vấn đề và nhược điểm khi thực hiện gõ động hoặc những thứ khác java không hỗ trợ ngay từ đầu.

vì vậy, "VM đa năng chung" hỗ trợ nhiều tính năng ngôn ngữ (tối ưu hóa cuộc gọi đuôi, gõ tĩnh & động, foo bar boo, ...) sẽ rất tuyệt vời, khó thực hiện và có lẽ khó tối ưu hóa hơn để đạt hiệu suất tốt nó nhưng tôi không phải là nhà thiết kế ngôn ngữ hay vm guru, có lẽ tôi đã sai: nó thực sự khá dễ dàng, chỉ có ai chưa có ý tưởng nào? giờ, giờ

quảng cáo B

đã ở đây: có thể không có trình biên dịch mã byte / vm, nhưng bạn không thực sự cần một trình biên dịch. afaik javascript đã hoàn tất, vì vậy nó có thể là một trong hai:

1. tạo một trình dịch từ ngôn ngữ X sang javascript (ví dụ: coffeescript)
2. tạo một trình thông dịch trong javascript để diễn giải ngôn ngữ X (ví dụ: brainfuck ). vâng, hiệu suất sẽ rất tệ, nhưng này, không thể có mọi thứ.

quảng cáo C

gì? Không có điểm C ở nơi đầu tiên!? bởi vì không có ... NACL google. Nếu ai cũng có thể làm được thì đó là google. Ngay sau khi google làm cho nó hoạt động, vấn đề của bạn đã được giải quyết. Chỉ, uh, nó có thể không bao giờ làm việc, tôi không biết. lần cuối cùng tôi đọc về nó, có một số vấn đề bảo mật chưa được giải quyết thuộc loại thực sự khó khăn.

ngoài ra:

• javascript đã ở đó từ ~ 1995 = 15 năm. Tuy nhiên, việc triển khai trình duyệt ngày nay đã khác (mặc dù ít nhất nó không thể vượt qua được nữa). vì vậy, nếu bạn bắt đầu một cái gì đó mới, bạn có thể có một phiên bản trình duyệt chéo hoạt động vào khoảng năm 2035. ít nhất là một tập hợp con đang hoạt động. Điều đó chỉ khác nhau một cách tinh tế. và cần libs và lớp tương thích. không có điểm trong việc không cố gắng cải thiện mọi thứ mặc dù.

• Ngoài ra, những gì về mã nguồn có thể đọc được? tôi biết nhiều công ty không muốn sử dụng mã nguồn của họ dưới dạng "loại". Cá nhân, tôi khá vui khi tôi có thể đọc được nguồn nếu tôi nghi ngờ điều gì đó tanh hoặc muốn học hỏi từ nó. hooray cho mã nguồn!

Thật. Silverlight thực sự chỉ là như vậy - một máy khách .Net dựa trên VM.

Có một số lỗi trong lý luận của bạn.

1. Một máy ảo tiêu chuẩn trong một trình duyệt tiêu chuẩn sẽ không bao giờ là tiêu chuẩn. Chúng tôi có 4 trình duyệt và IE có các mối quan tâm xung đột liên quan đến 'tiêu chuẩn'. Ba người khác đang phát triển nhanh nhưng tỷ lệ áp dụng công nghệ mới là chậm. Còn trình duyệt trên điện thoại, thiết bị nhỏ, ...

2. Sự tích hợp của JS trong các trình duyệt khác nhau và lịch sử trong quá khứ của nó dẫn bạn đến việc đánh giá thấp sức mạnh của JS. Bạn cam kết một tiêu chuẩn, nhưng không chấp thuận JS vì tiêu chuẩn không thành công trong những năm đầu.

3. Như đã nói với những người khác, JS không giống như AIR / .NET / ... và tương tự. JS trong hóa thân hiện tại của nó hoàn toàn phù hợp với mục tiêu của nó.

Về lâu dài, Perl và Ruby cũng có thể thay thế javascript. Tuy nhiên, việc áp dụng các ngôn ngữ đó là chậm và được biết rằng họ sẽ không bao giờ tiếp quản JS.

Làm thế nào để bạn xác định tốt nhất? Tốt nhất cho trình duyệt, hay tốt nhất cho nhà phát triển? (Plus ECMAScript khác với Javascript, nhưng đó là tính kỹ thuật.)

Tôi thấy rằng JavaScript có thể mạnh mẽ và thanh lịch cùng một lúc. Thật không may, hầu hết các nhà phát triển mà tôi đã gặp đều coi nó như một điều ác cần thiết thay vì một ngôn ngữ lập trình thực sự.

Một số tính năng tôi thích là:

• đối xử với các chức năng như công dân hạng nhất
• có thể thêm và xóa các chức năng cho bất kỳ đối tượng nào vào bất kỳ lúc nào (không hữu ích lắm nhưng hãy chú ý khi có)
• nó là một ngôn ngữ năng động.

Đó là niềm vui để đối phó và nó được thành lập. Hãy tận hưởng nó trong khi nó ở xung quanh bởi vì trong khi nó có thể không phải là "tốt nhất" cho kịch bản ứng dụng khách thì chắc chắn nó rất dễ chịu.

Tôi đồng ý rằng thật là bực bội khi tạo các trang động vì sự không tương thích của trình duyệt, nhưng điều đó có thể được giảm bớt bởi các thư viện UI. Điều đó không nên được tổ chức đối với chính JavaScript nữa so với Swing nên được tổ chức đối với Java.

JavaScript là máy ảo tiêu chuẩn của trình duyệt. Chẳng hạn, cả OCaml và Haskell đều có trình biên dịch có thể xuất JavaScript. Giới hạn không phải là ngôn ngữ JavaScript, giới hạn là các đối tượng trình duyệt có thể truy cập qua JavaScript và mô hình kiểm soát truy cập được sử dụng để đảm bảo bạn có thể chạy JavaScript một cách an toàn mà không ảnh hưởng đến máy của bạn. Các điều khiển truy cập hiện tại rất kém, vì vậy JavaScript chỉ được phép truy cập rất hạn chế vào các đối tượng trình duyệt vì lý do an toàn. Dự án Harmony đang tìm cách khắc phục điều đó.

Đó là một ý tưởng tuyệt vời. Tại sao không đưa nó một bước xa hơn?

• Viết trình phân tích cú pháp và trình phân tích HTML (thực sự là tất cả các bit phức tạp trong trình duyệt) bằng cùng một ngôn ngữ VM
• Xuất bản công cụ lên web
• Phục vụ trang với một tuyên bố về công cụ bố trí sẽ sử dụng và URL của nó

Sau đó, chúng ta có thể thêm các tính năng cho các trình duyệt mà không cần phải đẩy các trình duyệt mới ra cho mọi máy khách - các bit mới có liên quan sẽ được tải động từ web. Chúng tôi cũng có thể xuất bản các phiên bản HTML mới mà không có sự phức tạp lố bịch trong việc duy trì khả năng tương thích ngược với mọi thứ từng hoạt động trên trình duyệt - khả năng tương thích là trách nhiệm của tác giả trang. Chúng tôi cũng có thể thử nghiệm các ngôn ngữ đánh dấu khác với HTML. Và, tất nhiên, chúng tôi có thể viết các trình biên dịch JIT ưa thích vào các công cụ để bạn có thể viết kịch bản trang web của mình bằng bất kỳ ngôn ngữ nào bạn muốn.

Tôi sẽ hoan nghênh bất kỳ ngôn ngữ nào ngoài javascript là ngôn ngữ kịch bản có thể.

Điều tuyệt vời là sử dụng các ngôn ngữ khác sau đó là Javascript. Java có thể không phù hợp lắm giữa thẻ nhưng các ngôn ngữ như Haskell, Clojure, Scala, Ruby, Groovy sẽ có lợi.

Tôi đến một Rubyscript chéo somewhile trước ... http://almaer.com/blog/running-ruby-in-the-browser-via-script-typetextruby và http://code.google.com/p/ruby- trong trình duyệt /
Vẫn đang thử nghiệm và đang tiến hành, nhưng có vẻ đầy hứa hẹn.
Đối với .Net tôi vừa tìm thấy: http://www.silverlight.net/learn/dynamic-lacular/ Chỉ cần tìm thấy trang web, nhưng trông cũng thú vị. Hoạt động ngay cả từ Apple Mac của tôi .

Không biết làm thế nào tốt công việc trên trong việc cung cấp một sự thay thế cho Javascript, nhưng nó trông khá tuyệt vời từ cái nhìn đầu tiên. Về tiềm năng, điều này sẽ cho phép một người sử dụng bất kỳ khung Java hoặc .Net nào từ trình duyệt - trong hộp cát của trình duyệt.

Về an toàn, nếu ngôn ngữ chạy bên trong JVM (hoặc công cụ .Net cho vấn đề đó), VM sẽ đảm bảo an ninh nên chúng tôi không phải lo lắng về điều đó - ít nhất là không hơn chúng ta nên làm bất cứ điều gì chạy bên trong trình duyệt.

Có thể, nhưng để làm như vậy, chúng ta cần phải có các trình duyệt chính để hỗ trợ chúng. Hỗ trợ IE sẽ là khó khăn nhất để có được. JavaScript được sử dụng vì đó là điều duy nhất bạn có thể tin tưởng vào việc có sẵn.

Phần lớn các nhà phát triển mà tôi đã nói về ECMAScript et. al. cuối cùng thừa nhận rằng vấn đề không phải là ngôn ngữ kịch bản, đó là DOM HTML lố bịch mà nó phơi bày. Kết hợp DOM và ngôn ngữ kịch bản là một nguồn đau đớn và thất vọng phổ biến liên quan đến ECMAScript. Ngoài ra, đừng quên, IIS có thể sử dụng JScript để tạo kịch bản phía máy chủ và những thứ như Rhino cho phép bạn xây dựng các ứng dụng độc lập trong ECMAScript. Hãy thử làm việc trong một trong những môi trường này với ECMAScript một lúc và xem ý kiến ​​của bạn có thay đổi không.

Loại tuyệt vọng này đã xảy ra trong một thời gian. Tôi khuyên bạn nên chỉnh sửa phần này để bao gồm hoặc đăng lại các vấn đề cụ thể. Bạn có thể ngạc nhiên một cách thú vị bởi một số cứu trợ bạn nhận được.

Một trang web cũ, nhưng vẫn là một nơi tuyệt vời để bắt đầu: trang web của Douglas Crockford .

Chà, chúng ta đã có VBScript rồi phải không? Đợi đã, chỉ có IE hỗ trợ thôi!
Tương tự cho ý tưởng hay của bạn về VM. Điều gì xảy ra nếu tôi kịch bản trang của mình bằng Lua và trình duyệt của bạn không có trình phân tích cú pháp để chuyển đổi nó thành mã byte? Tất nhiên, chúng ta có thể tưởng tượng một thẻ script chấp nhận một tệp mã byte, điều đó thậm chí sẽ khá hiệu quả.
Nhưng kinh nghiệm cho thấy thật khó để mang lại một cái gì đó mới cho Web: phải mất nhiều năm để áp dụng một thay đổi mới triệt để như thế này. Có bao nhiêu trình duyệt hỗ trợ SVG hoặc CSS3?

Bên cạnh đó, tôi không thấy những gì bạn thấy "bẩn" trong JS. Nó có thể xấu nếu được mã hóa bởi những người nghiệp dư, tuyên truyền thực hành xấu được sao chép ở nơi khác, nhưng các bậc thầy cho thấy nó cũng có thể là một ngôn ngữ thanh lịch. Một chút giống như Perl: thường trông giống như một ngôn ngữ bị xáo trộn, nhưng có thể được thực hiện hoàn hảo có thể đọc được.

Kiểm tra điều này http://www.visitmix.com/Labs/Gestalt/ - cho phép bạn sử dụng python hoặc ruby, miễn là người dùng đã cài đặt Silverlight.

Đây là một câu hỏi rất hay.

Đây không chỉ là vấn đề trong JS, vì nó thiếu các IDE miễn phí tốt để phát triển các chương trình lớn hơn trong JS. Tôi chỉ biết một thứ miễn phí: Eclipse. Một cái tốt khác là Visual Studio của Microsoft, nhưng không miễn phí.

Tại sao nó sẽ miễn phí? Nếu các nhà cung cấp trình duyệt web muốn thay thế các ứng dụng máy tính để bàn bằng các ứng dụng trực tuyến (và họ muốn) thì họ phải cung cấp cho chúng tôi, các lập trình viên, các công cụ phát triển tốt. Bạn không thể tạo 50.000 dòng JavaScript bằng trình soạn thảo văn bản đơn giản, JSLint và trình gỡ lỗi Google Chrome tích hợp. Trừ khi bạn là một người theo chủ nghĩa vĩ mô.

Khi Borland tạo ra một IDE cho Turbo Pascal 4.0 vào năm 1987, đó là một cuộc cách mạng trong lập trình. 24 năm đã trôi qua kể từ đó. Đáng xấu hổ, trong năm 2011, nhiều lập trình viên vẫn không sử dụng hoàn thành mã, kiểm tra cú pháp và trình gỡ lỗi thích hợp. Có lẽ bởi vì có rất ít IDE tốt.

Việc các nhà cung cấp trình duyệt web quan tâm đến việc tạo ra các công cụ (MIỄN PHÍ) phù hợp cho các lập trình viên nếu họ muốn chúng tôi xây dựng các ứng dụng mà họ có thể chiến đấu với Windows, Linux, MacOS, iOS, Symbian, v.v.

Trên thực tế, Javascript là ngôn ngữ duy nhất mà bất kỳ trình duyệt nào sẽ sử dụng trong một thời gian dài, vì vậy trong khi sử dụng các ngôn ngữ khác sẽ rất tuyệt, tôi không thể thấy nó xảy ra.

"VM được tiêu chuẩn hóa" mà bạn nói đến sẽ rất lớn và sẽ được tất cả các trình duyệt chính chấp nhận và hầu hết các trang web sẽ tiếp tục sử dụng Javascript vì nó phù hợp với các trang web hơn nhiều trình duyệt khác.

Bạn sẽ phải sandbox từng ngôn ngữ lập trình trong VM này và giảm lượng truy cập của mỗi ngôn ngữ đối với hệ thống, đòi hỏi nhiều thay đổi về ngôn ngữ và loại bỏ hoặc thực hiện lại nhiều tính năng. Trong khi đó Javascript đã có sẵn điều này trong tâm trí và đã thực hiện từ lâu.

Có lẽ bạn đang tìm kiếm Khách hàng bản địa của Google.

Theo một nghĩa nào đó, việc có một ngôn ngữ biểu cảm hơn như Javascript trong trình duyệt thay vì một thứ gì đó chung chung hơn như mã byte Java có nghĩa là một trang web mở hơn.

Tôi nghĩ rằng điều này không dễ dàng vấn đề . Chúng tôi có thể nói rằng chúng tôi bị mắc kẹt với JS, nhưng nó thực sự quá tệ với jQuery, Prototype, scriptacificent, MooTools và tất cả các thư viện tuyệt vời?

Hãy nhớ rằng, JS rất nhẹ , thậm chí còn hơn thế với V8, TraceMonkey, SquirrelFish - các công cụ Javascript mới được sử dụng trong các trình duyệt hiện đại.

Nó cũng đã được chứng minh - vâng, chúng tôi biết nó có vấn đề, nhưng chúng tôi có rất nhiều trong số này được sắp xếp, như các vấn đề bảo mật ban đầu. Hình ảnh cho phép trình duyệt của bạn chạy mã Ruby hoặc bất cứ thứ gì khác. Sandbox an ninh sẽ phải được thực hiện cho đầu. Và bạn biết những gì? Python folks đã thất bại hai lần với nó.

Tôi nghĩ Javascript sẽ được sửa đổi và cải thiện theo thời gian, giống như HTML và CSS. Quá trình có thể kéo dài, nhưng không phải mọi thứ đều có thể xảy ra trong thế giới này.

Tôi không nghĩ bạn "hiểu vấn đề thực tế rằng JavaScript chỉ đơn giản là những gì chúng ta phải làm việc với bây giờ". Thật ra nó là ngôn ngữ rất mạnh. Bạn đã có applet Java của mình trong trình duyệt trong nhiều năm và bây giờ nó ở đâu?

Dù sao đi nữa, bạn không cần phải "làm bẩn" để làm việc trên máy khách. Ví dụ: hãy thử GWT.

... ý bạn là...

Java và Java applet Flash và Adobe AIR, v.v.

Nói chung, bất kỳ khuôn khổ RIA nào cũng có thể đáp ứng nhu cầu của bạn; nhưng với mỗi người đều có một cái giá phải trả cho việc sử dụng nó (ví dụ: thời gian chạy có sẵn trên trình duyệt hoặc / và tùy chọn hoặc / và ít tùy chọn hơn máy tính để bàn thuần túy) http://en.wikipedia.org/wiki/List_of_rich_iNET_application_frameworks

Để phát triển Web với bất kỳ languaje không phải web nào, bạn đã GWT: phát triển Java, biên dịch sang Javascript

Bởi vì tất cả chúng đều có VM với các trình thông dịch mã byte, và mã byte cũng khác nhau. {Luân xa (IE), Firefox (SpiderMonkey), Safari (SquirrelFish), Opera (Carakan).

Xin lỗi, tôi nghĩ Chrome (V8) biên dịch thành mã máy IA32.

tốt, xem xét tất cả các trình duyệt đã sử dụng VM, tôi không nghĩ việc tạo ngôn ngữ VM cho web sẽ khó khăn đến vậy.
Tôi nghĩ rằng nó sẽ giúp ích rất nhiều cho một số lý do:
1. vì máy chủ biên dịch mã, lượng dữ liệu được gửi nhỏ hơn và khách hàng không mất thời gian biên dịch mã.
2. vì máy chủ có thể biên dịch mã để chuẩn bị và lưu trữ nó, không giống như máy khách cố gắng giảm bớt thời gian biên dịch mã nhanh, nó có thể tối ưu hóa mã tốt hơn.
3. biên dịch một ngôn ngữ thành mã byte là cách dễ dàng hơn sau đó chuyển mã sang JS.

như một lưu ý cuối cùng (như ai đó đã nói trong một nhận xét khác), HTML và CSS biên dịch thành ngôn ngữ đơn giản hơn, không chắc nó có được tính là mã byte hay không, nhưng bạn cũng có thể gửi html và css được biên dịch từ máy chủ đến máy khách. giảm thời gian phân tích và tìm nạp

IMO, JavaScript, ngôn ngữ, không phải là vấn đề. JavaScript thực sự là một ngôn ngữ mạnh mẽ và biểu cảm. Tôi nghĩ rằng nó có một đại diện xấu bởi vì nó không có các tính năng OO cổ điển, nhưng đối với tôi càng đi với rãnh nguyên mẫu, tôi càng thích nó.

Vấn đề như tôi thấy đó là việc triển khai không ổn định và không nhất quán trên nhiều trình duyệt mà chúng tôi buộc phải hỗ trợ trên web. Các thư viện JavaScript như jQuery đi một chặng đường dài để giảm thiểu cảm giác bẩn thỉu đó.