Tại sao các cơ sở mã trong phát triển n tầng có số lượng bằng nhau, nếu không nhiều hơn, mã JavaScript bây giờ?


32

Tôi đã làm lập trình web từ lâu rồi và ở đâu đó, tôi không biết tại sao chúng ta lại làm những gì chúng ta đang làm hôm nay (hoặc làm thế nào chúng ta đến để làm mọi thứ theo cách này)?

Tôi đã bắt đầu với việc phát triển web ASP cơ bản, và từ rất sớm, logic hiển thị và kinh doanh đã được trộn lẫn trên trang. Sự phát triển phía máy khách rất đa dạng (VBScript, các hương vị JavaScript khác nhau) và chúng tôi đã có nhiều cảnh báo về các xác nhận phía máy chủ (và vì vậy tôi tránh xa logic phía máy khách).

Sau đó tôi chuyển đến ColdFusion một lúc. ColdFusion có lẽ là khung phát triển web đầu tiên tách biệt logic hiển thị và logic kinh doanh bằng cách sử dụng các thẻ của họ. Nó có vẻ rất rõ ràng đối với tôi, nhưng rất dài dòng và ColdFusion không có nhu cầu thị trường cao, và vì vậy tôi đã tiếp tục.

Sau đó tôi đã nhảy vào đoàn xe ASP.NET và bắt đầu sử dụng phương pháp MVC của họ. Tôi cũng nhận ra Java dường như là một ngôn ngữ tháp ngà của các hệ thống doanh nghiệp và cũng đã thử cách tiếp cận MVC của họ. Sau đó, ASP.NET đã phát triển mẫu thiết kế MVVM này và Java (chính xác là J2EE hoặc JEE) cũng vật lộn và đưa ra các cách tiếp cận MVC2.

Nhưng ngày nay, những gì tôi đã phát hiện ra là lập trình phụ trợ không phải là nơi hứng thú và tiến bộ nữa. Ngoài ra, các thực tiễn MVC dựa trên máy chủ dường như đã lỗi thời (mọi người có thực sự sử dụng JSTL nữa không?). Ngày nay, trong hầu hết các dự án mà tôi đang thực hiện, tôi phát hiện ra rằng các khung JavaScript và phát triển phía máy khách là nơi tất cả các tiến trình thú vị và sáng tạo đang được thực hiện.

Tại sao sự chuyển động này từ máy chủ sang phát triển phía khách hàng diễn ra? Tôi đã thực hiện một số dòng đơn giản của một trong các dự án JEE của tôi và có nhiều dòng mã hơn trong JavaScript so với Java (không bao gồm các thư viện của bên thứ ba). Tôi thấy rằng hầu hết phát triển phụ trợ sử dụng các ngôn ngữ lập trình như Java hoặc C # chỉ đơn giản là để tạo giao diện giống như REST và tất cả các nỗ lực hiển thị, trực quan hóa, nhập / xuất dữ liệu, tương tác của người dùng, v.v ... đang được giải quyết thông qua khung phía khách hàng như Angular, Backbone, Ember, Knockout, v.v ...

Trong thời kỳ tiền jQuery, tôi đã thấy rất nhiều sơ đồ trong đó có một đường khái niệm rõ ràng giữa M, V và C trong MVC trong phát triển n-tier. Post-jQuery, những dòng này được vẽ ở đâu? Có vẻ như MVC và MVVM đều có mã JavaScript, phía máy khách.

Điều tôi muốn biết là, tại sao chúng ta lại thực hiện một quá trình chuyển đổi như vậy (từ sự nhấn mạnh của lập trình phía máy chủ sang phía máy khách, từ việc ưu tiên các ngôn ngữ được biên dịch sang các ngôn ngữ kịch bản, từ mệnh lệnh sang lập trình chức năng, tất cả những điều này dường như đã xảy ra đồng thời ) và những vấn đề nào đã làm quá trình chuyển đổi / thay đổi này giải quyết?


8
Bởi vì điện thoại di động có nhiều cơ sở hạ tầng mạng ở giữa và do đó bị ảnh hưởng nhiều bởi độ trễ? Độ trễ cao có nghĩa là người ta phải thực hiện các chuyến đi khứ hồi ít hơn đến phía máy chủ (giả sử, mỗi giây) và do đó, nhiều tính toán phải xảy ra ở phía máy khách. Điều đó lần lượt thúc đẩy sức mạnh tính toán nhiều hơn về phía khách hàng.
rwong

1
Nếu phải mất X đơn vị công việc cho mỗi trang kết xuất (giả sử không có bộ nhớ đệm là có thể) và bạn muốn N người nhìn thấy nó, đơn vị công việc N * X phải diễn ra. Bạn có thể thực hiện tất cả các đơn vị công việc N * X hoặc bạn có thể có mỗi đơn vị N thực hiện X đơn vị công việc. Tại sao công việc mà khách truy cập của bạn sẵn sàng thực hiện? (Nhưng, như Robert Harvey trả lời , nó phức tạp hơn thế và mọi thứ thay đổi theo thời gian.)
Joshua Taylor

1
Tôi không phải là người nói tiếng Anh bản địa, nhưng có lẽ tiêu đề có thể được làm rõ?
bigstones

1
Có một tiến bộ trong JavaScript? Ngôn ngữ vẫn là ES5 (11/2014). Hầu hết các tiến bộ dường như xoay quanh việc cố gắng không sử dụng JavaScript trực tiếp: Dart, TypeScript, AtScript, v.v.
Den

1
Bởi vì các thiết bị phân tán / di động hiện có đủ sức mạnh CPU mà chúng có thể thực hiện mọi việc cục bộ được sử dụng để yêu cầu máy chủ trung tâm lớn.
Kilian Foth

Câu trả lời:


62

Thay đổi tải máy tính giữa máy chủ và máy khách là một hiện tượng theo chu kỳ và đã diễn ra khá lâu.

Khi tôi học đại học cộng đồng, Máy tính cá nhân chỉ bị hơi nước. Nhưng Ethernet chưa được sử dụng rộng rãi và không ai có mạng cục bộ. Trước đó, trường đại học có một máy tính lớn xử lý hồ sơ của sinh viên và phục vụ như một nền tảng cho các lớp lập trình. Chính quyền có các thiết bị đầu cuối được kết nối với máy tính lớn trên cơ sở chia sẻ thời gian, nhưng các sinh viên phải đấm thẻ để hoàn thành nhiệm vụ lập trình của họ, một quá trình khó khăn. Cuối cùng, họ đưa vào một phòng thí nghiệm nơi các sinh viên có thể đăng ký thời gian trên một thiết bị đầu cuối, nhưng vẫn phải mất nửa giờ hoặc lâu hơn để có được bản in lỗi dày nửa inch của bạn. Tất cả các công việc xử lý đã được thực hiện trên máy tính lớn (máy chủ).

Nhưng các máy tính lớn thì đắt tiền, vì vậy các công ty bắt đầu đưa lên mạng cục bộ và tải xử lý đã chuyển từ máy chủ sang các máy khách riêng lẻ, đủ mạnh để chạy xử lý văn bản, bảng tính và dòng ứng dụng kinh doanh riêng lẻ, nhưng không đủ mạnh để chia sẻ sức mạnh xử lý của họ với những người khác. Máy chủ là một máy tương tự có khả năng tương tự (có thể nhiều bộ nhớ và dung lượng ổ cứng hơn), nhưng chủ yếu được sử dụng để chia sẻ tệp. Điều này được gọi là Máy khách / Máy chủ. Hầu hết các xử lý đã chuyển sang các máy khách.

Một trong những nhược điểm của việc thực hiện tất cả quá trình xử lý trên các máy khách là bạn bị khóa trong chu trình cài đặt và nâng cấp phần mềm liên tục này và tất cả các vấn đề đau đầu xảy ra. Mô hình lập trình của các máy này (giao diện người dùng dựa trên sự kiện, mã phía sau) đã khuyến khích tạo ra các chương trình lộn xộn, khó bảo trì (những quả bóng lớn của bùn). Hầu hết người dùng cuối không có kỹ năng bảo trì phần cứng và phần mềm của họ đúng cách, đòi hỏi phải có đội quân của nhân viên bảo trì CNTT.

Khi các máy tính ngày càng trở nên mạnh mẽ hơn, sự phân công lao động trở nên khả thi. Bây giờ bạn có thể có máy chủ tệp, máy chủ cơ sở dữ liệu, máy chủ web, máy chủ in, v.v. Mỗi máy có thể được tối ưu hóa phần nào cho nhiệm vụ mà nó được cung cấp và được duy trì bởi một người có chuyên môn cần thiết. Các chương trình có thể được viết trong trình duyệt web, do đó không cần cài đặt máy khách. Điều này được gọi là Multi-Tier hoặc n-Tier. Các trình duyệt về cơ bản được sử dụng như các thiết bị đầu cuối câm, giống như trong thời đại máy tính lớn, mặc dù phương thức giao tiếp với máy chủ phức tạp hơn, ít độc quyền hơn và dựa trên các cơ chế ngắt thay vì chia sẻ thời gian và bỏ phiếu. Quá trình xử lý đã chuyển trở lại (các) máy chủ.

Tuy nhiên, phát triển web đi kèm với một loạt các vấn đề đau đầu. Hầu hết các dòng ứng dụng kinh doanh được viết cho trình duyệt là các biểu mẫu và báo cáo tĩnh. Có rất ít tương tác có sẵn trong giao diện người dùng. Javascript vẫn chưa tìm thấy cơn gió thứ hai và có những vấn đề lớn với sự không tương thích của trình duyệt đã không khuyến khích áp dụng rộng rãi. Tuy nhiên, mọi thứ đã trở nên tốt hơn nhiều. HTML5 và CSS3 cung cấp các khả năng mới đáng kể cho mô hình lập trình trình duyệt, jQuery ra đời và giúp cả một thế hệ lập trình viên khám phá ra Javascript có thể hữu ích như thế nào. Các khung giao diện người dùng mới đã xuất hiện. Có thể viết UI tương tác cao trong trình duyệt, thậm chí là các trò chơi hoàn chỉnh. Xử lý chuyển trở lại khách hàng một lần nữa.

Ngày nay, bạn có thể mua sức mạnh xử lý trong đám mây, bao nhiêu hoặc ít tùy thích và chạy các chương trình trên máy chủ. Tôi muốn nói rằng chúng ta đang ở một nơi, với tư cách là một nhà phát triển phần mềm, bạn có rất nhiều sự lựa chọn về nơi bạn có thể thực thi sức mạnh xử lý của mình, cả trên máy khách và trên máy chủ.


1
As the computers became increasingly more powerful, divisions of labor became possible [...] you have lots of choices about where you can execute your processing power, both on the client and on the server.- Tôi muốn nói rằng hai điểm này cùng nhau tạo nên một trường hợp tuyệt vời để đạt đến trạng thái cân bằng giữa máy chủ và máy khách: Chúng đều phù hợp với một nhiệm vụ cụ thể và những nhiệm vụ đó hiện được xác định rõ và dễ dàng thực hiện.
Jess Telford

5

Bạn dường như đang trộn lẫn hai khái niệm rất khác nhau:

  1. Tách trình bày và logic nghiệp vụ (MVC) => tăng khả năng bảo trì
  2. Gán thực thi cho một nút => tăng hiệu quả

Trước đây, máy tính Client / Server thường bị nhầm lẫn khi ngụ ý đầu tiên bởi vì các máy khách thường không cung cấp nhiều sức mạnh tính toán, so với các máy chủ. Vì vậy, có vẻ tự nhiên khi chuyển tính toán logic kinh doanh "nặng" (M) sang máy chủ, trong khi vẫn giữ chế độ xem "nhẹ" (V) cho khách hàng. Đổi lại, bạn phải thực hiện một số loại trọng tài (C) để dịch giữa hai.

Với các máy khách giờ đây dễ dàng có tính năng xử lý mà trước đây ngụ ý một số phần cứng máy chủ đắt tiền, các dòng đã bị mờ đi khi thực hiện logic nghiệp vụ - phía máy khách hoặc phía máy chủ. Thực sự, câu trả lời phụ thuộc vào trường hợp sử dụng cụ thể của bạn và sự lựa chọn đánh đổi của bạn, ví dụ:

  • độ trễ của máy khách so với độ phức tạp: xử lý phía máy chủ giúp hệ thống đơn giản hơn vì không cần phải triển khai / tải xuống mã máy khách, tuy nhiên nó phải trả giá bằng độ trễ phía máy khách trong quá trình tính toán.

  • độ phức tạp so với tải máy chủ: tính toán phía máy khách có thể làm tăng độ phức tạp của hệ thống nhưng nó cũng có thể giúp giảm tải máy chủ.

  • khả năng phục hồi ứng dụng phi tập trung so với thực thi trung tâm: trong một thế giới của ứng dụng di động, điều quan trọng là giữ cho khách hàng làm việc mặc dù ngắt kết nối mạng. Tuy nhiên, điều này đi kèm với chi phí quản lý nhiều phiên bản logic kinh doanh được triển khai.

Đây là một danh sách không đầy đủ của nhiều sự đánh đổi.


4

Bởi vì người dùng luôn muốn có cùng chức năng, chuông và còi với các ứng dụng web của họ (không chỉ các trang web) mà họ có với các ứng dụng máy tính để bàn. Làm cho tất cả điều này chạy trong một trình duyệt (thực ra là nhiều trình duyệt) không giống như ngày xưa khi bạn có thể liên kết một biểu mẫu VB với cơ sở dữ liệu với ít mã. Điều này dễ thực hiện hơn khi bạn không phải thực hiện các chuyến đi trở lại máy chủ.

hầu hết phát triển phụ trợ bằng các ngôn ngữ lập trình như Java hoặc C # chỉ đơn giản là để tạo giao diện giống như REST và tất cả nỗ lực hiển thị, trực quan hóa, nhập / xuất dữ liệu, tương tác của người dùng, v.v ... đều được xử lý thông qua client- khung bên như Angular, Backbone, Ember, Knockout, v.v ...

Có thể chương trình / dịch vụ phụ trợ có vẻ giống như cũ, nhưng đó là trái tim của ứng dụng. Các thực hành mã hóa có thể hiệu quả hơn trong các lĩnh vực này. Các công cụ, ngôn ngữ, trình duyệt và khung vẫn đang phát triển, vì vậy UI / UX rất khó phát triển. Chúng là những thứ mới mà ASP cũ không có. Nếu chúng ta có thể thoát khỏi giao diện người dùng với các biểu mẫu và bảng html đơn giản, thì sẽ không có nhiều sự quan tâm / cường điệu trong các lĩnh vực đó, nhưng người dùng muốn kéo và thả, hình động, chuyển tiếp, cửa sổ bật lên, v.v.


2

Ngày nay, trong hầu hết các dự án mà tôi đang thực hiện, tôi phát hiện ra rằng các khung JavaScript và phát triển phía máy khách là nơi tất cả các tiến trình thú vị và sáng tạo đang được thực hiện.

Tại sao sự chuyển động này từ máy chủ sang phát triển phía khách hàng diễn ra?

Thực tế có hai câu hỏi ở đây:

  1. Tại sao lập trình phía khách hàng nơi tiến trình đang diễn ra?
  2. Tại sao các ứng dụng được viết để chạy trên máy khách chứ không phải máy chủ?

Hai là thực sự khác biệt.

Tại sao lập trình phía khách hàng nơi tiến trình đang diễn ra?

Bởi vì thời gian chạy, môi trường và hệ sinh thái đã trưởng thành đáng kể trong ba năm qua, và điều này đã mở ra những ngóc ngách mới mà các nhà đổi mới đã chờ đợi để khai thác.

Front-end phát triển được sử dụng là khó khăn . Bạn phải lập trình cho các trình duyệt - luôn là môi trường thù địch - sử dụng các tính năng bị ràng buộc của ECMAScript 3, trong một hệ sinh thái không có nghệ thuật hoặc công cụ trước để xây dựng các ứng dụng khách dày. Không có bộ tải mô-đun. Bạn không thể xử lý phụ thuộc đúng cách. Có một số ít các công cụ linting. Các khuôn khổ là những nhà đổi mới kém danh tiếng và không có tiếng tăm của người đi trước có thể giải quyết những vấn đề này.

Khi các yếu tố này đã thay đổi dần dần, họ đã tạo ra một khối lượng quan trọng để phát triển các ứng dụng khách phong phú nhanh chóng và chạy chúng một cách nhất quán.

Sau đó, để trả lời câu hỏi của bạn, không quá nhiều công nghệ mới đã thúc đẩy tiến bộ về phía trước, vì họ đã giải phóng các nút thắt cổ chai và cho phép khách hàng bắt kịp nguyện vọng của người dùng.

Tại sao các ứng dụng được viết để chạy trên máy khách chứ không phải máy chủ?

Có rất nhiều nguyên nhân gần đúng, nhưng khác biệt nhất trong những năm gần đây là sự nổi lên của điện thoại thông minh.

Điện thoại thông minh làm cho điện toán vừa phải mạnh mẽ giá rẻ, có mặt khắp nơi và hữu ích. Chúng thuộc sở hữu của hàng tỷ người trên khắp hành tinh và về cơ bản đã mang điện toán đến tầng lớp trung lưu của các nền kinh tế mới nổi. Nhưng các mạng di động chậm chạp, chắp vá và bị hạn chế bởi các vấn đề khó khăn về địa lý, kỹ thuật và chính trị. Trong môi trường này, không thể tránh khỏi các ứng dụng lưu trữ trạng thái cục bộ và vá dữ liệu lên một cách miễn cưỡng và trong các hoạt động không trạng thái.

Làm thế nào nó có thể khác nhau? Hãy tưởng tượng nếu điện thoại thông minh của bạn chỉ là một thiết bị đầu cuối câm. Mọi đột biến trạng thái sẽ phải không đồng bộ và dễ đọc. Mỗi tải nội dung sẽ có giá xu quý. Bạn sẽ phải đầu tư vào các trang trại máy chủ khổng lồ với thời gian hoạt động năm giờ. Các chi phí điện toán sẽ do bạn trực tiếp gánh chịu, do đó, sự nổi tiếng đột ngột thực sự có thể thúc đẩy doanh nghiệp của bạn.

Các ứng dụng phía máy khách cho phép bạn xử lý trạng thái liên quan đến từng người dùng một cách nhanh chóng, đồng bộ. Họ cho phép bạn giảm chi phí điện toán cho người dùng của bạn. Họ cho phép bạn thoát khỏi thời gian chết và kết nối mạng kém. Họ làm cho mã máy chủ trở nên ngu ngốc đến mức có thể lưu vào bộ nhớ cache trong chính cơ sở hạ tầng mạng - các tệp HTML và JS tĩnh hoặc các phản hồi đóng hộp cho các ứng dụng di động.

Nói một cách rất rộng: Phát triển phía khách hàng khai thác chi phí thấp của máy tính cá nhân công suất trung bình và tránh chi phí cao cho điện toán tập trung công suất cao.


-1

Bạn đã hỏi một số câu hỏi, một số trong đó đã có câu trả lời tốt. Một số ít chưa có câu trả lời của họ:

Điều tôi muốn biết là, tại sao chúng ta lại thực hiện một quá trình chuyển đổi như vậy (từ sự nhấn mạnh của lập trình phía máy chủ sang phía máy khách, ... tất cả những điều này dường như đã xảy ra đồng thời) và vấn đề nào đã chuyển đổi / dịch chuyển này?

Robert Harvey đã đưa ra một câu trả lời tuyệt vời.

... từ việc ưu tiên các ngôn ngữ được biên dịch đến các ngôn ngữ scripting,

Các ngôn ngữ script cung cấp nhiều lợi thế ( cũng ) so với các ngôn ngữ được biên dịch, ví dụ:

  • dễ học và dễ sử dụng hơn
  • loại bỏ thời gian biên dịch (phát triển nhanh hơn)
  • cung cấp nhiều tính năng hơn (kiểm soát ứng dụng cao cấp hơn)
  • cho phép thay đổi nhanh chóng để chạy mã
  • v.v.

... từ mệnh lệnh đến lập trình chức năng,

Đây là một so sánh tốt, nhưng tôi sẽ tổng hợp nó bằng cách nói rằng trong phần mềm phân tán (nghĩ điện toán đám mây), việc quản lý các thay đổi trạng thái (đồng bộ hóa qua nhiều nút) có thể là một vấn đề lớn. Trong lập trình chức năng, nhu cầu đối phó với những thay đổi trạng thái thấp hơn rất nhiều.


Sẽ thích nếu cử tri xuống có can đảm nói phần nào trong câu trả lời của tôi mà cô ấy không thích?
Fuhrmanator

Tôi không thể biết tại sao hai cử tri trước đó lại làm vậy, nhưng lý do của tôi là nó giống như một bình luận cho một trong những câu trả lời trước , thay vì liên quan đến câu hỏi được hỏi (xem Cách trả lời )
gnat

@gnat Mình đánh giá cao những phản hồi. Tôi đã trích dẫn các phần khác nhau của câu hỏi (cụ thể là biên dịch so với kịch bản và mệnh lệnh so với chức năng) chưa được trả lời ở nơi khác. Tôi đã nhận được 3 phản hồi về điều này, vì vậy tôi có thể thấy đó là một phản ứng trái chiều.
Fuhrmanator
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.