Tại sao không có ngôn ngữ kịch bản phía máy khách khác cho các trang web? [đóng cửa]

35

Tại sao ngày nay chỉ có hỗ trợ cho JavaScript và một số VBScript trong trình duyệt? Tôi biết JavaScript là tốt và tất cả, nhưng sẽ không có tùy chọn sử dụng ngôn ngữ lập trình khác giúp thúc đẩy các phong cách phát triển khác nhau?

web-development javascript browser

— Eric Packwood
nguồn

1

Xem câu hỏi này trên Stack Overflow: stackoverflow.com/questions/2872037/ từ

— Corey

1

Câu hỏi của bạn chính xác là lý do tại sao Google tạo ra GWT .

— jhocking

1

Tôi tin rằng toàn bộ quan điểm của API DOM là cung cấp hỗ trợ cho nhiều ngôn ngữ. Điều quan trọng là, JS thực sự rất phù hợp với thử thách. Nó bình thường hóa như không có chức năng kinh doanh và hạng nhất của ai là rất lớn trong mô hình hướng sự kiện nặng nề. Điều thực sự xảy ra là không ai muốn để MS đưa ra quyết định đó và không ai đưa ra một quyết định tốt hơn JS. Ngoài ra, Java Applet thực sự, thực sự khập khiễng.

— Erik Reppen

33

Không cần thêm suport cho nhiều ngôn ngữ, một giải pháp sẽ là chuẩn hóa một mã byte chung có thể được sử dụng bởi những người thực hiện ngôn ngữ. Nhưng hiện tại không có kế hoạch cho việc này (nó đã được đề xuất).

Các ngôn ngữ cũng có thể được triển khai trên Javascript. Javascript đủ tốt để cho phép các ngôn ngữ khác được triển khai trên đầu trang. Và đã có nhiều ví dụ về điều này rồi.

— khung gầm
nguồn

3

+1 - Để chỉ ra rằng JavaScript là một ngôn ngữ mạnh mẽ có thể được sử dụng làm trừu tượng hóa cho các ngôn ngữ khác. Sẽ là một dự án thú vị để viết một phần mở rộng Firefox sẽ chạy phía máy khách C ++ hoặc Java! <script type="text/cpp" src="test.cpp"></script>.

— jmort253

2

@ jmort253, hãy xem khách hàng bản địa.

— dan_waterworth

Máy khách gốc chắc chắn rất thú vị nhưng trừ khi Mozilla cũng chấp nhận nó, sẽ không có bất kỳ lực kéo nào. Cuối cùng tôi đã kiểm tra họ chưa sẵn sàng để đưa nó vào.

— nkrame

1

Tôi đã tìm thấy Gestalt ~ một vài năm trước đây: cử chỉ.codeplex.com, đây là một ví dụ điển hình về việc xây dựng các ngôn ngữ kịch bản lệnh khác trên Javascript.

— Jim Schubert

2

Một ví dụ khác: Bộ công cụ web của Google ? Java được biên dịch thành JavaScript

— MarkJ

21

JavaScript là tiêu chuẩn thực tế và đã có từ năm 1996. Trở thành một tiêu chuẩn đơn giản vì không có sự cạnh tranh nào là không công bằng, nhưng tôi đã không nghe thấy nhiều phàn nàn về lý do tại sao không có ngôn ngữ khác.

Thêm một ngôn ngữ "tiêu chuẩn" khác thúc đẩy tất cả các loại vấn đề nhỏ thú vị.

Làm thế nào họ sẽ làm việc với các ngôn ngữ khác?
DOM sẽ được chia sẻ?
Kịch bản có thể viết trong cả hai vẫn hoạt động?
Chuyển thư viện sang cả hai

— Josh K
nguồn

8

Thật ra tôi nghĩ JavaScript là ngôn ngữ được sử dụng trong Tắc kè của Mozilla. Trong IE chúng ta có JScript. Hầu hết các trình duyệt khác sử dụng một cái gì đó ít nhiều tuân theo thông số kỹ thuật của ECMAScript. Tất cả các ngôn ngữ này là vì đơn giản được gọi là 'JavaScript', trong khi thực tế chúng khác nhau.

— Mchl

1

Bạn có thể có nhiều ngôn ngữ tạo cùng mã byte. Nhìn vào JVM - Groovy, Java, Scala, Clojure, jRuby có thể được biên dịch trực tiếp thành mã byte JVM. Bằng cách này, họ sẽ chia sẻ cùng một api DOM và có thể tương thích với nhau. Mặc dù khó triển khai hơn với JavaScript VM vì nó được giải thích.

— David Sergey

21

Hãy nghĩ về sự không nhất quán giữa các trình duyệt để họ hỗ trợ javascript. Bây giờ hãy nghĩ về nó sẽ như thế nào nếu có nhiều ngôn ngữ hơn.

— Michael Brown
nguồn

5

Yay, nó đã ở đó, VBScript phía máy khách ... uugh, rùng mình.

— ocodo

1

+1 Tôi nghĩ rằng đầu của chúng tôi sẽ nổ tung nếu chúng tôi có một tập hợp các ngôn ngữ khác để ghi nhớ cho từng trình duyệt chính và các phiên bản của chúng. Câu trả lời tốt.

— jmort253

4

Điều này có thể gây khó chịu, nhưng ... hỗ trợ JavaScript của trình duyệt [ECMAScript] thực sự đã rất nhất quán trên bảng kể từ đầu. Điều không nhất quán là việc họ thực hiện DOM (và các phương thức liên quan). Từ quan điểm thực tế (và lịch sử), thật khó để phân tách hai - vì việc sử dụng thực sự duy nhất của JS là thao túng DOM trong trình duyệt - nhưng với sự gia tăng của JS phía máy chủ (những thứ như NodeJS), điều này thực sự trở thành một sự khác biệt quan trọng.

— josh3736

sẽ viết khá chính xác đây là một câu trả lời, internet có đủ các tiêu chuẩn không được tuân theo hoặc hỗ trợ. thực tế là mớ hỗn độn lộn xộn mà chúng ta có một nửa cũng như nó không có gì là kỳ diệu.

— Ryathal

1

Josh nói đúng. Đó là nơi bạn gắn vào ý tưởng khó hiểu của trình duyệt cá nhân về cách mọi thứ được hiển thị và được truy cập bởi JS, thứ đó trở nên xấu xí nhưng IE cuối cùng ít nhất cũng tham gia vào các vấn đề API độc quyền lâu đời ở mặt trước đó (mặc dù nó vẫn tiếp tục tụt hậu so với mới nhất về mọi thứ do quyết định định mệnh của MS là liên kết trình duyệt của họ với trình điều hướng tệp của họ - jackasses).

— Erik Reppen

6

Các trình duyệt phải được chuẩn hóa, để những gì bạn phát triển hoạt động ở mọi nơi, trên tất cả các trình duyệt.

Nếu bạn có nhiều ngôn ngữ, thì bạn phải đảm bảo rằng tất cả chúng đều hoạt động rất giống nhau. Nếu bạn là nhà phát triển web và bạn có nhiều lựa chọn ngôn ngữ, có thể hoặc không được hỗ trợ ở một số địa điểm, thì đó là một vấn đề đau đầu.

Javascript là một ngôn ngữ rất linh hoạt, nó là bắt buộc, nó là chức năng, nó có thể là OOP (sau một thời trang với các nguyên mẫu), và nó được giải thích. Bây giờ với các công cụ tốt như trong Chrome, nó có khả năng hợp lý để làm một số thứ tốt. Các ngôn ngữ bổ sung sẽ chỉ đặt mọi thứ trở lại đây, chỉ nhìn vào VBScript, IE và do đó, bất cứ điều gì được viết trong đó đều bị ràng buộc với một trình duyệt và nền tảng cụ thể, cơn ác mộng.

— Orble
nguồn

2

Điểm quan trọng ở đây là "với các công cụ tốt như trong Chrome". Làm bất cứ điều gì thậm chí đánh thuế nhẹ khiến thậm chí IE8 bắt đầu khập khiễng như bị gãy chân, trong khi các phiên bản gần đây của Firefox và Chrome mãi mãi tôi đã sử dụng nó (đây là lý do tôi chuyển đổi nguyên vẹn) bỏ qua mà không bỏ lỡ nhịp nào.

— Matthew Scharley

1

@Matthew Scharley: IE nói chung là chậm chạp, thực sự nó dường như trở nên tồi tệ hơn với mọi phiên bản. Họ cần phải lên trò chơi của họ, hoặc họ sẽ ra khỏi nó. Lý do duy nhất khiến IE có bất kỳ sự cố nào là do sự bao gồm của hệ điều hành, bây giờ họ phải đưa bộ chọn lên trong lần sử dụng đầu tiên, điều đó đã giảm đi rất nhiều.

— Orble

"Nó có thể là OOP" ... Đó là OOP! Kế thừa không phải là những gì định nghĩa OOP. Đối tượng là.

— KaptajnKold

@KaptajnKold: Đó là vấn đề của một số cuộc tranh luận trong giới học thuật, thật đáng ngạc nhiên. Tôi đồng ý rằng JS có khả năng OOP, trong đó nó có các đối tượng, chúng không luôn được sử dụng quá mức bởi một số người. Hệ thống nguyên mẫu cũng rất khác với hương vị OOP thông thường, điều này càng loại bỏ nó khỏi định nghĩa chuẩn của "ngôn ngữ OOP". Như với hầu hết các ngôn ngữ, nó phụ thuộc vào cách bạn sử dụng nó - khi tôi sử dụng nó, đó là OOP.

— Orble

3

Thay vì xây dựng các trình duyệt này thành các trình duyệt, các nhà cung cấp muốn xây dựng các trình cắm trình duyệt cồng kềnh - Java, Flash, Silverlight, v.v ... Điều này đảm bảo tính nhất quán đa nền tảng.

— Kirk Broadhurst
nguồn

Vâng, đó không phải là về việc đảm bảo tính nhất quán đa nền tảng nhiều như đảm bảo kiểm soát. Như bạn kiểm soát plugin và bạn không phải trả lời cho bất kỳ ai khác.

— jhocking

So với việc vật lộn với việc chạy javascript bẩn nhanh, các plugin "cục mịch" tốt hơn nhiều. Tôi đã từng cảm thấy tiêu cực về toàn bộ phần mềm tải xuống trình duyệt, nhưng nó chắc chắn mở hơn "javascript được triển khai chung".

— Milind R

2

Một trong những lý do là các nhà cung cấp trình duyệt khác nhau thậm chí không thể đồng ý về việc triển khai Javascript tiêu chuẩn và Javascript đã tồn tại mãi mãi, ít nhất là từ góc độ ngôn ngữ web. Vì vậy, hầu hết mọi người nghĩ rằng việc đưa ngôn ngữ phía khách hàng khác vào hệ sinh thái và nhờ tất cả các nhà cung cấp hỗ trợ là điều thực tế là không thể và hầu hết những người có khả năng khiến nó xảy ra đều liên quan đến các vấn đề tiêu chuẩn hóa Javascript mà tôi nghĩ là tốt hơn nhiều sử dụng thời gian của họ.

— davidk01
nguồn

Gần như những gì tôi sẽ nói. Sự khác biệt quan trọng (trong cuộc thảo luận này) giữa các ngôn ngữ phía máy khách và phía máy chủ là các trình duyệt phải thực hiện ngôn ngữ phía máy khách.

— jhocking

2

Có một số câu trả lời ở đây tuyên bố rằng việc hỗ trợ nhiều ngôn ngữ sẽ khiến cho các nhà xây dựng trình duyệt web rất khó chịu để đảm bảo chúng tuân thủ tất cả các ngôn ngữ. Đối với tôi điều này có vẻ không chính xác.

Java, ví dụ là một tiêu chuẩn được xác định rất tốt. Về cơ bản, tất cả những gì bạn cần làm là hiển thị DOM trình duyệt dưới dạng API Java và chạy Máy ảo Java (JVM) bên trong trình duyệt web của bạn. Bạn có thể chỉ định rằng mã tập lệnh sẽ phải được phân phối dưới dạng các tệp JAR được biên dịch và ký, hoặc dưới dạng mã nguồn JavaScript. Nếu trình duyệt gặp JavaScript, nó có thể chạy nó thông qua một trình thông dịch chuyên dụng (như hiện nay) hoặc thông qua Rhino trên JVM. Nếu nó gặp các tệp jar, nó sẽ tạo một trình nạp lớp và hộp cát bảo mật mới, tải mã byte java vào bộ nhớ và thực thi nó. Điều này sẽ hoàn toàn tương thích ngược với các trang web hiện có và sẽ cho phép trình duyệt, với một nét duy nhất, hỗ trợ hàng tá ngôn ngữ chạy trên JVM.

Ưu điểm khác:

JVM đã được hưởng lợi từ một thập kỷ cải tiến hiệu suất. Bây giờ nó rất nhanh, ổn định và trưởng thành. Tôi cá là bạn sẽ thấy một sự cải thiện hiệu suất lớn so với javascript được giải thích.
Khi các ứng dụng phía máy khách trở nên lớn hơn và phức tạp hơn, lợi ích của các ngôn ngữ được cấu trúc, gõ như Java và Scala sẽ tăng lên.
Bạn sẽ có quyền truy cập vào đa luồng thực sự và thông qua Scala, một thư viện bộ sưu tập được tối ưu hóa cho điện toán đa lõi.
Bạn có thể sử dụng bất kỳ trong số hàng ngàn thư viện java nguồn mở bên trong trình duyệt.
Thông qua các thư viện như openGL, trình duyệt có thể cung cấp quyền truy cập vào các khả năng tính toán đồ họa và card đồ họa tiên tiến.
Nếu bạn có java chạy ở phía máy khách và máy chủ, bạn có thể hưởng lợi nhiều hơn từ giao tiếp giữa máy chủ và máy khách thông qua việc tuần tự hóa biểu đồ đối tượng nhị phân cực kỳ nén = tải và thực hiện nhanh hơn các trang web.

— Patrick Arnesen
nguồn

1

Bạn đã có thể chạy mã JVM. Nó được gọi là một applet java

— Raynos

1

Tôi tin rằng JavaScript sẽ đạt được nhiều hơn nữa như là ngôn ngữ tiêu chuẩn cho Web. Chúng ta đang chứng kiến sự gia tăng của JavaScript phía máy chủ. Dưới đây là một số ví dụ về việc triển khai ngôn ngữ mạnh mẽ này trên máy chủ:

POW Web Server SJS - JavaScript phía máy chủ cho POW Web Server, chạy dưới dạng tiện ích mở rộng Firefox hoặc dưới dạng ứng dụng XULRunner. SJS đóng vai trò tương tự như PHP trong Apache ở chỗ nó có thể kết nối với cơ sở dữ liệu và tạo nội dung phía máy khách.
NodeJS - JavaScript phía máy chủ sử dụng mô hình dựa trên sự kiện. Nó được xây dựng bằng Công cụ JavaScript V8 của Google . NodeJS được quảng cáo là một công cụ để xây dựng các chương trình mạng có thể mở rộng. Một máy chủ Web "Hello World" có thể được viết chỉ trong 6 dòng ngắn!
Jaxer - Một máy chủ JavaScript diễn giải tất cả các khối tập lệnh với runat="server"dạng JavaScript phía máy chủ. Toàn bộ ứng dụng Web có thể được viết bằng JavaScript.
Rhino - JavaScript cho Java - Mozilla đã tạo triển khai JavaScript phía máy chủ này chạy trên Java. Về cơ bản, đây là một khái niệm tương tự như Querces PHP cho Java , Jython, JRuby và nhiều khái niệm trừu tượng khác của các ngôn ngữ khác chạy trên JVM. Rhino thường được sử dụng để nhúng JavaScript vào Java để cung cấp các công cụ kịch bản cho người dùng cuối, nhưng nó cũng có thể được sử dụng để di chuyển mã phía máy khách sang máy chủ mà không phải viết lại logic nghiệp vụ bằng ngôn ngữ khác!
JQuery Claypool - Khung JavaScript phía máy chủ sử dụng sức mạnh của JQuery trên máy chủ. Rất tuyệt! Nó được phát triển bằng cách sử dụng trình duyệt JavaScript phía EnvJs Server của trình duyệt.
EnvJs - Một trình duyệt không đầu được xây dựng trên đỉnh Rhino.

Điều mà nhiều triển khai và khung công tác này chứng minh là JavaScript đang trở thành một thế lực mạnh mẽ trong phát triển Web đến mức các nhà lãnh đạo cộng đồng đã bắt đầu chuyển JavaScript sang máy chủ. JavaScript là một ngôn ngữ lập trình chức năng cực kỳ mạnh mẽ và khi thời gian trôi qua tôi cảm thấy chúng ta sẽ thấy nó phát triển.

Tóm lại, có vẻ như mâu thuẫn khi chuyển các ngôn ngữ khác sang trình duyệt khi thay vào đó chúng ta có thể chuyển ngôn ngữ trình duyệt đơn này sang máy chủ và thu hẹp khoảng cách đó theo cách thống nhất hơn.

— jmort253
nguồn

+1 để chỉ ra rằng JavaScript không bị giới hạn trong trình duyệt

— Gary Rowe

1

Có một số ví dụ về các công cụ sẽ biên dịch các ngôn ngữ khác thành javascript, bao gồm Haskel, Lisp và Python (Có lẽ là các công cụ khác). Vì vậy, nếu bạn muốn làm việc với một trong những ngôn ngữ đó, bạn có thể làm như vậy.

Và tôi nghĩ một trong những giáo sư của tôi từ trường đại học đã viết một triển khai chương trình trong Javascript. Vì vậy, nếu bạn thích chương trình bạn cũng có thể làm điều đó.

— Zachary K
nguồn

0

Mọi người đã làm việc xung quanh việc thiếu sự đa dạng tích hợp theo hai cách: sử dụng các plugin như flash hoặc java applet và xây dựng các lớp sử dụng javascript làm "mã máy" của họ, như bộ công cụ web jquery hoặc google. Nếu có một phong cách phát triển mới đủ phổ biến, mọi người sẽ tìm cách đưa nó vào.

Chỉ cần lưu ý nếu bạn tạo một thời gian chạy .net trong javascript và nó trở nên phổ biến, một số vòng tròn nhất định sẽ nguyền rủa tên bạn trên internet mãi mãi.

— Karl Bielefeldt
nguồn

Đổ lỗi cho các biểu mẫu web và IE. Bạn sẽ tức giận với các nhà phát triển web UI ít hơn bằng cách chọc ghẹo họ bằng những trò chơi nóng bỏng. Không tốt cho hiệp hội thương hiệu.

— Erik Reppen