Tại sao JavaScript không được sử dụng để phát triển ứng dụng cổ điển (phần mềm được biên dịch)? [đóng cửa]


14

Trong những năm phát triển web với JavaScript, tôi đi đến kết luận rằng đó là một ngôn ngữ mạnh mẽ đáng kinh ngạc và bạn có thể làm những điều tuyệt vời với nó.

Nó cung cấp một bộ tính năng phong phú, như:

  • Gõ động
  • Chức năng hạng nhất
  • Hàm lồng nhau
  • Đóng cửa
  • Chức năng như phương pháp
  • Chức năng như các hàm tạo đối tượng
  • Dựa trên nguyên mẫu
  • Dựa trên đối tượng (hầu hết mọi thứ là một đối tượng)
  • Regex
  • Mảng và đối tượng

Dường như với tôi rằng hầu hết mọi thứ đều có thể đạt được với loại ngôn ngữ này, bạn cũng có thể mô phỏng lập trình OO, vì nó cung cấp sự tự do tuyệt vời và nhiều phong cách mã hóa khác nhau.

Với nhiều chức năng tùy chỉnh hướng phần mềm hơn (I / O, FileSystem, Input device, v.v.) Tôi nghĩ sẽ rất tuyệt khi phát triển các ứng dụng.

Mặc dù, theo như tôi biết, nó chỉ được sử dụng trong phát triển web hoặc trong các phần mềm hiện có làm ngôn ngữ kịch bản mà thôi.

Chỉ gần đây, có lẽ nhờ Công cụ V8, nó đã được sử dụng nhiều hơn cho các loại nhiệm vụ khác (ví dụ: xem node.js).

Tại sao cho đến bây giờ nó chỉ bị xuống hạng để phát triển web? Điều gì đang khiến nó tránh xa sự phát triển phần mềm?


8
Nếu phát triển web không phải là (trường hợp đặc biệt) phát triển phần mềm, thì chính xác thì đó là gì? ...
Péter Török

@ Péter Török: Tôi nghĩ rằng bạn có được điểm. Ý tôi là cho đến bây giờ nó chỉ được sử dụng làm ngôn ngữ kịch bản bởi các phần mềm, để tăng cường tính năng. Nó chưa bao giờ được sử dụng để thực sự lập trình một ứng dụng phần mềm cho HĐH.
Jose Faeti

4
Tôi thấy gõ động là một nhược điểm rất lớn và tôi cũng muốn loại bỏ các giá trị null.
Jonas

2
Bạn có nghĩa là "phát triển ứng dụng cổ điển", không phải "phát triển phần mềm", phải không? Tốt hơn thay đổi tiêu đề của bạn cho phù hợp.
Doc Brown

2
@JoseFaeti cho bản ghi windows 8 cho phép bạn thực hiện một số phát triển trong HTML5 & JS
Raynos

Câu trả lời:


14

Gần đây, node.js đã đưa sự phát triển phía máy chủ về phía trước. Vì vậy, bây giờ có thể viết JavaScript, để phát triển.

Đúng. Trong lịch sử, nó đã không được sử dụng như một ngôn ngữ phát triển. Nhưng, hey, thậm chí script trong môi trường máy khách (User Agents) là một kiểu phát triển. Phải không?

Lý do chính mà tôi đã nghe và đọc trong nhiều weblog là vì mọi người không biết về sức mạnh và sự độc đáo của nó cho đến những năm gần đây . Điều làm cho điều này xảy ra, có lẽ là các ngôn ngữ khác đang làm công việc của họ đủ tốt, và không ai từng nghĩ về việc làm một cái gì đó song song.


Phải như vậy, và tôi có vẻ như một cái gì đó đang thực sự di chuyển bây giờ :)
Jose Faeti

15

Từ đây :

Lưu ý rằng tôi đang dựa trên tất cả các lập luận của mình về các trường hợp sử dụng trong thế giới thực. Các đối số không thể được sao lưu bằng một ví dụ về việc sử dụng trong một ứng dụng thực tế, đầy đủ, thú vị, hữu ích là không hợp lệ. Tôi đã thấy những "bản trình diễn ngôn ngữ" nhỏ mà mọi người khác có, tôi đã thấy các bài đăng trên blog mô tả chi tiết cách các nguyên mẫu và kiểu gõ động tạo ra một số ví dụ nhỏ tầm thường ngắn hơn vài dòng so với C #, nhưng những thứ đó đơn giản là không liên quan cho đến những vấn đề bạn gặp phải khi viết mã thật chứ không phải micro-demos và đồ chơi. Vì vậy, đây là sự hiểu biết của tôi với JS:

a) Phép thuật 'này'. Đây là cái này, trừ khi cái này là cái kia. JavaScript thúc đẩy bạn sử dụng các hàm ẩn danh ở mọi nơi, ngoại trừ chúng luôn mất bối cảnh thích hợp cho biến 'this', do đó cuối cùng bạn sẽ có mã ngớ ngẩn như "var _this = this" ở khắp mọi nơi và sau đó sử dụng nó bên trong cuộc gọi lại của bạn hoặc các chức năng khác. Đôi khi tôi thề rằng số lượng chức năng tôi quản lý để viết mà không sử dụng tên 'cái này' thực sự nhỏ hơn số lượng thực hiện.

b) 1 + "1" - 1 = 10. Ngoài ra, "1" + 0 = "10". Có, điều này thực sự đã gây ra lỗi cho các ứng dụng của chúng tôi, trong đó dữ liệu được dự kiến ​​là một số được tải từ tệp JSON dưới dạng chuỗi do lỗi trong ứng dụng khác và kết quả không tốt. Tất cả mã tải của chúng tôi phải được cập nhật để thêm một tấn chuyển đổi loại ở mọi nơi. Khi tôi cần một số nào đó để trở thành một số tôi thực sự hoảng hốt hoàn toàn muốn nó là một số, không phải là một chuỗi hoặc một đối tượng hoặc null hoặc bất cứ điều gì khác. Lua, rất giống với JavaScript ở hầu hết các khía cạnh, đã khắc phục vấn đề này bằng cách không bị chậm phát triển đủ để sử dụng cùng một toán tử để thêm và nối chuỗi.

c) Toàn cầu theo các biến mặc định. Vì vậy, ngay cả khi bạn đưa ra lập luận rằng việc gõ động chỉ "dễ dàng" hơn vì bạn không phải suy nghĩ về các khai báo biến, JavaScript sẽ ném đối số đó ra ngoài cửa sổ bằng cách đặt 'var' trước các số nhận dạng mới ở mọi nơi . Và sau đó nó âm thầm vít bạn nếu bạn quên.

d) Nguyên mẫu thay vì các lớp. Có rất ít ứng dụng JavaScript trong thế giới thực tồn tại mà không cắm vào hệ thống lớp của riêng chúng để khắc phục sự vô dụng vốn có của các nguyên mẫu trong kiến ​​trúc ứng dụng lớn. Các ứng dụng tương tự đó sử dụng các nguyên mẫu tối thiểu để mở rộng các loại JavaScript cơ bản và chỉ vì JS được thiết kế kém đến mức ngay cả hai loại tích hợp thú vị mà nó đi kèm cũng thiếu một nửa các tính năng mà bạn mong đợi.

e) Không có khả năng tạo các loại giá trị truyền qua. Đây thực sự là một vấn đề thường gặp ở mọi ngôn ngữ ngoài C ++ / D. Đối với những người sử dụng JavaScript để viết ứng dụng WebGL, hãy xem tất cả các thư viện đại số tuyến tính cho JavaScript. Trong các ứng dụng 3D, bạn hầu như sử dụng vectơ thường xuyên hơn so với vô hướng. Hãy tưởng tượng nếu mọi số nguyên trong ứng dụng của bạn được truyền bằng tham chiếu, sao cho "a = 1; b = a; b ++" làm cho cả a và b bằng 2. Mỗi vectơ ba thành phần nhỏ là một đối tượng đầy đủ. Chúng được chuyển qua tham chiếu (trên thực tế, nguồn gốc của gần một nửa lỗi trong trò chơi WebGL của chúng tôi). Chúng tồn tại với số lượng lớn, được phân bổ thành từng đống và được thu gom rác, điều này gây áp lực lớn lên GC, điều này có thể và dẫn đến tạm dừng GC trong các trò chơi WebGL đơn giản, trừ khi nhà phát triển nhảy qua các vòng phức tạp lố bịch để tránh tạo ra các vectơ mới ở tất cả những nơi hợp lý để tạo ra các vectơ mới. Bạn không thể có quá tải toán tử, do đó bạn có các biểu thức rất lớn và xấu để thực hiện các thao tác cơ bản. Truy cập các thành phần riêng lẻ là chậm. Các đối tượng không được đóng gói nguyên bản và do đó cực kỳ chậm để đẩy vào bộ đệm đỉnh, trừ khi bạn triển khai chúng dưới dạng phiên bản Float32Array, điều này làm lẫn lộn các trình tối ưu hóa của cả V8 và SpiderMonkey hiện tại. Tôi đã đề cập đến họ thông qua tham chiếu? Truy cập các thành phần riêng lẻ là chậm. Các đối tượng không được đóng gói nguyên bản và do đó cực kỳ chậm để đẩy vào bộ đệm đỉnh, trừ khi bạn triển khai chúng dưới dạng phiên bản Float32Array, điều này làm lẫn lộn các trình tối ưu hóa của cả V8 và SpiderMonkey hiện tại. Tôi đã đề cập đến họ thông qua tham chiếu? Truy cập các thành phần riêng lẻ là chậm. Các đối tượng không được đóng gói nguyên bản và do đó cực kỳ chậm để đẩy vào bộ đệm đỉnh, trừ khi bạn triển khai chúng dưới dạng phiên bản Float32Array, điều này làm lẫn lộn các trình tối ưu hóa của cả V8 và SpiderMonkey hiện tại. Tôi đã đề cập đến họ thông qua tham chiếu?

f) Không tích hợp bao gồm hoặc yêu cầu chức năng. Nghiêm túc, vẫn thế. Các thư viện của bên thứ ba tồn tại nhưng hầu như tất cả chúng đều có một số lỗi hoặc lỗi khác, không ít trong số đó là vấn đề bộ nhớ đệm khó hiểu trong ít nhất Chrome khiến việc phát triển thực sự trở nên khó khăn.

g) Gõ động. Vâng, tôi sẵn sàng bắt đầu cuộc tranh luận đó. Bạn bắt đầu nhận thấy nó nhiều nhất là lần thứ hai bạn dừng viết các ứng dụng Web hoặc trang web nhỏ và bắt đầu viết các ứng dụng lớn trong đó bạn thực sự có dữ liệu tồn tại lâu hơn một lần nhấp chuột hoặc chu kỳ yêu cầu / phản hồi: thêm loại đối tượng sai vào một mảng để xử lý sau và gặp sự cố sau đó từ một phương thức hoặc thành viên bị thiếu trong một đoạn mã hoàn toàn khác so với lỗi thực tế. Thời gian vui vẻ. Vâng, Java làm cho gõ tĩnh có vẻ xấu. Không, Java / C # / C ++ không phải là cách duy nhất và duy nhất để thực hiện gõ tĩnh. Gõ suy luận, ràng buộc giao diện ngầm, v.v. cung cấp cho bạn tất cả các ưu điểm "dễ xử lý và không có nhiều thao tác bàn phím" của việc gõ động mà không gặp phải tất cả các lỗi. Ngôn ngữ Web phổ biến thứ hai - ActionScript 3 - được gõ tĩnh, trên thực tế, mặc dù khác với JS / ECMAScript. Bên cạnh đó, tôi nhận được nhiều sự cố hơn từ các ứng dụng Python trên máy tính để bàn Fedora của tôi so với các ứng dụng C / C ++ (thực ra, không có ứng dụng C / C ++ nào trên máy tính để bàn của tôi, bây giờ tôi nghĩ về nó). Thiếu ngoại lệ thành viên == để phát triển và duy trì ứng dụng dễ dàng hơn nhiều, phải không?

h) Tốc độ. Đúng vậy, đã có một số lượng lớn nỗ lực lố bịch của một số lượng lớn các nhà phát triển siêu lừa đảo đưa vào thời gian chạy ngôn ngữ để làm cho JS nhanh gần một nửa so với trình biên dịch C cấp thấp mà một sinh viên đại học duy nhất có thể viết trong một vài tháng. Và LuaJIT ở cùng một nhóm với JS về các hạn chế ngôn ngữ cơ bản nhưng vẫn quản lý để làm tốt hơn mọi triển khai JavaScript. Những người không hiểu tất cả các tối ưu hóa JS trong V8 hoặc như vậy thực sự là gì làm gìmuốn tuyên bố rằng JS có thể làm những điều đáng kinh ngạc về tốc độ, nhưng thực tế là tất cả những tối ưu hóa đó về cơ bản chỉ là "rất cố gắng phân tích mã để tìm ra các loại cho các biến và sau đó biên dịch nó giống như một kiểu gõ hơi chậm trình biên dịch của ngôn ngữ sẽ làm điều đó. " Ồ, và có dấu vết, nhưng sau đó, dấu vết cũng hoạt động trên các ngôn ngữ được nhập tĩnh (và hoạt động tốt hơn do không cần bộ bảo vệ loại trong mã máy được tạo). Trên thực tế, không có một trong những tối ưu hóa whizbang nào được phát minh bởi hoặc cho JS; hầu hết được lấy từ các JVM nghiên cứu (Java là xấu xa!) hoặc các ngôn ngữ OOP cổ điển (các nguyên mẫu là tuyệt vời!).

i) Không có IntelliSense thậm chí có thể. Bạn muốn xem phương thức nào tồn tại trên biến đó mà bạn đã có trên dòng 187 của foo.js trong trình soạn thảo văn bản của mình? Quá tệ. Đi theo dõi mã cho đến khi bạn tìm ra nơi nó được khởi tạo, sau đó truy tìm mã để tìm hiểu nguyên mẫu của nó có gì trên đó. Và sau đó hy vọng không có mã tự động thay đổi nguyên mẫu phía sau lưng của bạn. Trên thực tế, chỉ cần chạy nó trong trình duyệt và đặt các điểm dừng, bởi vì việc tìm ra bất cứ điều gì hữu ích về giá trị theo bất kỳ cách nào khác về cơ bản là không thể đối với bất kỳ cơ sở mã hóa nào lớn hơn toy_web_app.html các trang web mà người xin lỗi JavaScript sử dụng để tôn vinh sự dễ dàng và đơn giản của JavaScript. Một số trình soạn thảo mã cố gắng thực sự khó khăn để làm tốt hơn và gần như là một loại thành công cho các trường hợp thực sự đơn giản, đôi khi, một lần.

j) Không có lợi thế. JavaScript thậm chí không đặc biệt so với ngôn ngữ gõ động khác. Nó hoàn toàn không có khả năng làm bất cứ điều gì thú vị mà Lua, Python, Ruby, v.v. Không có cách triển khai JS nào nhanh hơn LuaJIT hoặc PyPy hoặc các triển khai JIT nâng cao khác của động lực khác ngôn ngữ. JS không có điểm cộng nào so với các ngôn ngữ phổ biến khác. Ồ, ngoại trừ nó chạy tự nhiên trong trình duyệt Web mà không cần plugin. Đó là lý do duy nhất trên thế giới tại sao nó rất phổ biến. Trong thực tế, đó là lý do duy nhất nó sự kiện tồn tại. Nếu ai đó 10 năm trước chỉ nghĩ: "quái gì, hãy bỏ một ngôn ngữ được thiết kế tốt và có sẵn vào trình duyệt của chúng tôi và khiến những kẻ khác làm điều tương tự thay vì bắt mọi người sử dụng hackjob nhỏ bé ngốc nghếch này mà NetScape nghĩ ra , "Web sẽ khác rất nhiều (tốt hơn) ngày hôm nay. Chỉ cần tưởng tượng về tương lai nếu Chrome bỏ Python vào Chrome như một ngôn ngữ được hỗ trợ. Hoặc thực tế, hãy tưởng tượng điều này: Google bỏ C / C ++ vào Chrome làm ngôn ngữ được hỗ trợ (http://code.google.com.vn/p/nativeclient/).


Đây là một bài viết thực sự thú vị. Tôi tò mò muốn xem các trường hợp sử dụng của anh ấy tạo thành nền tảng cho các lập luận của anh ấy. Tôi không đồng ý với quan điểm của anh ấy, nhưng tôi đã phát triển các ứng dụng JS có quy mô doanh nghiệp trong gần 10 năm và chưa trải nghiệm một số điều anh ấy đề cập (đặc biệt, điểm đầu tiên của anh ấy về "ma thuật này"). Theo kinh nghiệm của riêng tôi, các lập luận chống lại javascript như những người trong bài đăng này có xu hướng được tạo ra bởi những người có nền tảng truyền thống nặng nề ... trong trường hợp đó, tôi sẽ hiểu sự nhầm lẫn của anh ta.
Ông JavaScript

Thật thú vị khi thấy rằng vào năm 2016, câu trả lời hiện đã hoàn toàn lỗi thời bởi sự phát triển của ngôn ngữ.
Stephan bijzitter

@Ông. Xin chào. Bạn có biết một loạt các hướng dẫn tập trung vào giải quyết các ví dụ về các vấn đề trong thế giới thực thay vì chỉ khám phá JavaScript và các tính năng và cơ chế của nó không? Tôi không gặp may mắn với các tìm kiếm từ khóa. Ví dụ, thay vì đi qua một liên kết hướng dẫn chi tiết như vậy và hàng triệu ví dụ và tính năng của nó, tôi tìm thấy một kho hướng dẫn nhỏ về cách tạo một ứng dụng GUI để quản lý một số hệ thống bảo hiểm hoặc bác sĩ hoặc trường học hoặc một phần hoạt động của siêu thị? Cảm ơn bạn
Joshua

12

Tại sao?

JavaScript là ngôn ngữ bị hiểu sai nhiều nhất

Chúng tôi đã ở thời kỳ đen tối và vẫn để cộng đồng phát triển chung chấp nhận rằng JavaScript là một ngôn ngữ mạnh mẽ và linh hoạt. Nó đơn giản không phải là chủ đạo.

Sự tiến bộ gần đây duy nhất là node.js đã trở thành buzz-wordy và mọi người bắt đầu chấp nhận rằng javascript có cách sử dụng khác ..

Tôi đã theo dõi sự phát triển của JS & HTML5 cho windows 8 và phản ứng từ cộng đồng .NET là "trời ơi tại sao?".

Thực tế đơn giản là hầu hết các trang web không phải là web nhà phát triển vẫn xem JavaScript là ngôn ngữ đồ chơi mà bạn sử dụng để làm cho các menu đó cuộn qua các trình duyệt của bạn.

Phải thừa nhận rằng JavaScript không phù hợp với "thực tiễn phát triển hiện đại". Đối với tôi JavaScript vẫn là một ngôn ngữ hack tôi sử dụng vim và internet là tài liệu của tôi. Không có IDE, không có công cụ phát triển, không có tự động hoàn thành hoặc "intellisense", không có GUI nhấp và kéo.

Trong thế giới của các nhà phát triển Java và .NET, họ được kết hợp với GUI & IDE của họ và sẽ không thể lập trình trong vim.


1
Tôi đồng ý với bạn ngoại trừ "Không có IDE, không có công cụ phát triển, không có tự động hoàn thành hoặc" intellisense ", không có GUI nhấp và kéo." Trên thực tế, bạn có thể có được tất cả những gì sử dụng nhiều IDE khác nhau, tôi sử dụng Visual Studio chẳng hạn và nó đơn giản là tuyệt vời.
Jose Faeti

1
@JoseFaeti xin lỗi, Visual Studio không phải là một IDE javascript. Tôi nhanh hơn trong vim sau đó trong VS2010. Điều này có nghĩa là VS2010 là một IDE IDE bị rò rỉ.
Raynos

2
@Raynos, "Tôi nhanh hơn trong vim sau đó trong VS2010. Điều này có nghĩa là VS2010 là một IDE IDE bị rò rỉ." - hoặc có thể điều này đơn giản có nghĩa là bạn không biết VS cũng như vim.
Péter Török

2
Hoàn toàn không, nhưng tôi sẽ không xây dựng một giao diện RIA trong Silverlight vì tôi yêu thích Resharper và LINQ, hoặc ứng dụng ASP.Net MVC với một lớp jQuery mỏng, bởi vì một lần nữa, nó rất thân thiện với mạng. phù hợp hơn cho công việc.
sa93

1
Chỉ cần thêm giọng nói của tôi vào điệp khúc của những người nói rằng có các IDE JavaScript. Thật là ngớ ngẩn khi yêu cầu khác. Bạn có thể không thích IDE và chúng có thể không hoàn hảo, nhưng chúng vẫn là IDE. Hoặc tôi đã tưởng tượng sự hoàn thành mã và mã hóa của VS khi làm việc với JS?
Ian Newson

10

Danh sách của bạn không chứa bất cứ điều gì về việc ghi tệp vào hệ thống, đây là một phần lớn trong phát triển phần mềm.

Mọi người sẽ không nghĩ đến việc sử dụng JS để xây dựng một ứng dụng vì đây là ngôn ngữ kịch bản thực tế cho web và bạn sẽ luôn sử dụng công cụ phù hợp cho công việc.

Tại sao phải viết một mẫu mã JS để viết ra một tệp khi nó là một hoạt động tầm thường trong Java / .NET / C / C ++?

Như đã nói, như những người khác đã đề cập, node.js và các thư viện của nó đã làm cho các hoạt động phía máy chủ trở nên tầm thường và với node.js trở nên phổ biến, học nó sẽ trở thành một kỹ năng cho CV, vì bạn sẽ có thể duy trì / mở rộng / xây dựng các ứng dụng với nó.


1
+1 hoàn toàn quên mất làm thế nào một thư viện stdio là loại quan trọng.
Raynos

1
Đối với hệ thống tệp như bạn đặt, hiện tại chúng tôi có API lưu trữ cục bộ, mặc dù bạn sẽ không tin tưởng vào độ bền nghiêm trọng. Tuy nhiên, việc ghi vào hệ thống tập tin không cần phải trực tiếp, javascript của bạn có thể thực hiện các cuộc gọi yên tĩnh đến một máy chủ (được viết bằng chính LOLCode hoặc C hoặc JS) ghi vào một dạng lưu trữ nào đó.
sa93

1
Về phía máy chủ. API tệp NodeJS chỉ là tầm thường như C vv ... <- nếu bạn thực hiện IO chính xác trong C (không chặn). Ngoài ra, một cuộc gọi Ajax với bất kỳ trình bao bọc lành mạnh nào cũng có thể là 2-3 dòng. MyLib.Ajax.post ('/ kiên trì / Cái gì đó', {data: blahObj})
sa93

@ sa93 xin đừng nhầm lẫn môi trường máy chủ trình duyệt với JavaScript. localStorage là một API máy chủ trong các trình duyệt. Nó không được định nghĩa trong đặc tả ES5.
Raynos

1
@reinierpost Writing files to the file system has been replaced with HTTP POST.Không phải nếu bạn đang viết API đang xử lý các bài đăng.
Người sử dụng Stuper

5

Hầu hết các ngôn ngữ được sử dụng phổ biến đều mạnh hơn và được thiết kế tốt hơn JavaScript. Tất cả các tính năng bạn đề cập đều được hỗ trợ bởi các ngôn ngữ động khác như Python hoặc Ruby được thiết kế tổng thể tốt hơn. Và một số tính năng bạn đề cập dù sao cũng không nhất thiết phải mong muốn - nhiều người sẽ cân nhắc kiểu gõ tĩnh với kiểu suy luận thích hợp hơn với kiểu gõ động, nếu bạn có sự lựa chọn.

Tôi không nói điều này với Diss JavaScript. Tôi khá thích làm việc với JS khi phát triển web. Nhưng nhìn một cách khách quan, JS có một số nhược điểm so với các ngôn ngữ khác:

  • Vô số sai sót không thể trộn lẫn. Nhiều sai lầm đã được thực hiện khi ban đầu phát triển JS. Không cần liệt kê chúng ở đây, chúng được ghi chép lại. Tất cả các ngôn ngữ có lỗi trong thiết kế ban đầu mà sau đó đã được sửa. Sự khác biệt với JS là ngôn ngữ được phát triển và phát hành nhanh chóng và những lỗi này không bao giờ có thể được sửa chữa do yêu cầu tương thích ngược trong các trình duyệt.
  • Quá trình cực kỳ chậm để giới thiệu các cải tiến và các tính năng mới. Vì tất cả các nhà cung cấp trình duyệt phải đồng ý và thậm chí có thể vì nhiều lý do chính trị muốn làm chậm sự phát triển của ngôn ngữ. Nhìn vào C # thực sự là một ngôn ngữ mới hơn so với JS. Khi C # được giới thiệu, nó không có ví dụ. đóng hoặc các hàm bậc cao hơn như JS, nhưng sau nhiều lần lặp, giờ đây nó có tất cả các tính năng đó và hơn nữa là cú pháp Linq và async mà các nhà phát triển JavaScript chỉ có thể ghen tị.
  • Thư viện tiêu chuẩn nghèo nàn. Các ngôn ngữ hiện đại như Python, Ruby hoặc bất cứ thứ gì dựa trên Java hoặc .net đều có thư viện tiêu chuẩn rộng lớn cho hầu hết mọi thứ bạn cần. Trong JS, bạn thậm chí không thể đọc tệp mà không có thư viện bên thứ 3. Bạn đề cập đến Regex, nhưng tất cả các ngôn ngữ hiện đại đều có điều đó và hàng ngàn thứ khác.
  • Các ngôn ngữ khác đã bắt kịp với một vài lợi thế của JavaScript. Các tính năng như đóng cửa và các hàm hạng nhất rất mạnh khi so sánh với các ngôn ngữ tĩnh cồng kềnh như Java mười năm trước, nhưng các ngôn ngữ động và chức năng từ lâu đã có các tính năng này và thậm chí Java, một ngôn ngữ khá bảo thủ, đã thêm vào ngôn ngữ này trong Java 8.

Tính năng duy nhất thực sự khiến JavaScript khác biệt so với các ngôn ngữ hiện đại khác là tính kế thừa dựa trên nguyên mẫu (trái ngược với dựa trên lớp) và lợi thế của mô hình này là không rõ ràng vì mọi người chỉ sử dụng nó để mô phỏng kế thừa dựa trên lớp.

Đơn giản là không có lý do để chọn JavaScript nếu bạn có tùy chọn chọn ngôn ngữ hiện đại khác. Chỉ có lý do là nếu đó là ngôn ngữ duy nhất bạn biết.

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.