it-swarm-vi.tech

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ợ.

165
newdayrising

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.

28
Adam Wright

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 khách hàng. 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 Client 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ẽ sớm thay đổi. 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.

19
Manuel Ceron

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 đa ngôn ngữ VM 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 này và sự phức tạp trong một trình duyệt.

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

  • Bạn đang đứ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 bối 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ự dù sao cũng 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 đó thật có ý nghĩa để hỏi, "Đây có thực sự là câu hỏi không có đáng không? "

Hãy nhớ rằng, chỉ điều 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 vì JavaScript là ngôn ngữ động mạnh mẽ rất gần với Lược đồ.

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.

18
the happy moron

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 phần 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 nó không thực sự là một ý tưởng tốt như Python khá khó khăn với sandbox: nhiều tính năng ngôn ngữ phơi bày đủ các móc triển khai để cho phép một ứng dụng được cho là bị hạn chế 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.

14
bobince

Tôi chắc chắn sẽ chào đón một ngôn ngữ tiêu chuẩn độc lập VM trong 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 việc xác định VM 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).

12
Aivar

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ệ Nice, 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.

10
user4903

Tôi không nghĩ rằng một trang web tiêu chuẩn VM 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 trang web mới VM tiêu chuẩn một cách duyên dáng và đầy đủ Hỗ trợ kế thừa, miễn là bạn đảm bảo rằng bất kỳ VM định dạng mã byte bạn sử dụng có thể được dịch ngược nhanh chóng thành javascript và kết quả đầu ra sẽ có hiệu quả hợp lý (tôi thậm chí sẽ đ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 web VM 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 bị hạn chế quyền kiểm soát máy chủ) hoặc có thể được tạo trước và được tải động bởi máy khách hoặc máy chủ (nhanh nhất) cho các trình duyệt không hỗ trợ tiêu 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 web vm. 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 .

7
Jeremy Bell

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 khi đang di chuyển (kiểm tra đánh giá biểu thức thời gian chạy cho một ví dụ trong đó 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.

6
jjrv

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 B) đã ở đây.

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

quảng cáo A

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 gõ tĩnh và chắc chắn có 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 không 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 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 của thực sự loại khó khăn.


ngoài điều đó:

  • 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 hoạt động trên trình duyệt chéo 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!

5
stefs

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 công bố WebAssugging đó là

một định dạng di động, kích thước và thời gian tải 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 xem xét kỹ hơn trang chính thức của dự án, nó thực sự rất thú vị!

5
Quentin Roy

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ó xung đột lợi ích liên quan đến 'tiêu chuẩn'. Ba trình duyệt khác đang phát triển nhanh nhưng tốc độ áp dụng công nghệ mới 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ữ đó rất chậm và được biết rằng họ sẽ không bao giờ tiếp quản JS.

4
ydebilloez

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

4
redcalx

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 thứ xấu xa 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.

3
Rontologist

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 đó.

3
naasking

Đó 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) trong 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ề việc sử dụng công cụ bố trí nào 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.

3
p-static

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 cách đây một lúc nào đó ... http://almaer.com/blog/rucky-Ruby-in-the-browser-via-script-typetextrubyhttp://code.google.com.vn/p/Ruby-in-browser/
[.__.] 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 ra, nhưng trông cũng thú vị Hoạt động ngay cả từ Apple Mac của tôi .

Không biết các công cụ trên có hiệu quả như thế nào trong việc cung cấp một giải pháp thay thế cho Javascript, nhưng thoạt nhìn nó trông khá tuyệt. Có khả năng, điều này sẽ cho phép một người sử dụng bất kỳ Java hoặc .Net framework tự nhiên 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 .Net engine cho vấn đề đó), thì 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 nhiều hơn chúng ta nên cho bất cứ thứ gì chạy trong trình duyệt.

3
Gerbrand

Chà, chúng ta đã có VBScript rồi phải không? Đợi đã, chỉ IE hỗ trợ nó!
[.__.] Tương tự cho ý tưởng hay về VM của bạn. Đ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.

2
PhiLho

Đâ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à Google Chrome trình gỡ lỗi. Trừ khi bạn là một người nghiện ma túy.

Khi Borland thực hiện 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. Thật đáng tiếc, 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ẽ vì có quá í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.

2
user561168

Hãy xem đ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.

2
mcintyre321

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. IE hỗ trợ sẽ là khó nhất để có được. JavaScript được sử dụng vì đó là điều duy nhất bạn có thể tin cậy khi có sẵn.

2
Jeff Olhoeft

Đại đa số 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 trong một thời gian, và xem ý kiến ​​của bạn thay đổi.

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 .

2
Dustman

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 nó sẽ rất tuyệt khi sử dụng các ngôn ngữ khác, 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à cần được chấp nhận bởi tất cả các trình duyệt chính 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 này VM và giảm lượng truy cập của mỗi ngôn ngữ đối với hệ thống, yêu cầu nhiều thay đổi về ngôn ngữ và loại bỏ hoặc triển khai lại nhiều tính năng. Javascript đã có sẵn điều này trong tâm trí và đã thực hiện từ lâu.

1
HappySmileMan

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

1
Ebrahim Mohammadi

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ư Java bytecode có nghĩa là một trang web mở hơn.

1
Grav

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.

0
Stephen

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 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.

0
Marko Dumic

... ý 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 hơn so với 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

0
obesga

Tôi nghĩ rằng đây là không dễ dàng như vậy 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 là 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 là đã đượ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 Ruby hoặc bất cứ thứ gì khác. Hộp cát bảo mật sẽ phải được thực hiện để cào. ​​Và bạn biết gì không? Python folks đã - thất bại hai lần tại đó.

Tôi nghĩ Javascript sẽ trở thành đượ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.

0
Paweł Hajdan