Việc duy trì các ứng dụng web dựa trên Ajax nặng nề có khó khăn hơn không?


8

Có thể tôi đang làm sai, nhưng theo kinh nghiệm của tôi, việc phát triển và duy trì các ứng dụng web dựa trên ajax rất khó khăn hơn nhiều so với một ứng dụng web "chuẩn hơn".

Tôi không nói về một ứng dụng sử dụng ajax để tải một số dữ liệu ở đây và đó, nhưng kiểu mà trang mà máy chủ gửi đi chỉ là một khung và tất cả dữ liệu được điền vào lúc tải.

Tôi rất muốn nghe từ những người có kinh nghiệm trong việc phát triển các loại ứng dụng này. Kinh nghiệm cá nhân của tôi là họ mất nhiều giờ hơn để xây dựng và bảo trì.


Làm thế nào để bạn xác định một ứng dụng web tiêu chuẩn hơn?
Chris

một cái không sử dụng ajax cho mọi thứ? Ví dụ, các ứng dụng web 37signals được quyết định là không phải là ajax, mặc dù thực tế họ sử dụng một rắc ở đây và đó
Erik

1
Khó hơn cái gì? Hơn một cái gì đó sử dụng các công nghệ không chuẩn, hack-together để đạt được kết quả tương tự? Nếu bạn làm cho ứng dụng của mình phức tạp hơn (ví dụ: bằng cách thêm tương tác intrapage), điều hợp lý là bạn sẽ phải trả một số chi phí tăng để duy trì nó.
Alex Feinman

Cụ thể, bạn đang hỏi liệu các loại trang web mà Ajax được sử dụng có xu hướng khó hơn các loại trang web không sử dụng hay bạn đang hỏi liệu các trang web Ajax có khó hơn các trang web không phải Ajax cho cùng chức năng không?
David Thornley

Câu trả lời:


6

Tôi sẽ đưa ra rằng cả việc phát triển và duy trì một ứng dụng sử dụng JavaScript là một nhiệm vụ phức tạp và khó khăn hơn so với việc phát triển các ứng dụng web "cổ điển".

Lý do cho điều đó nằm ở thực tế đơn giản là càng nhiều công nghệ không đồng nhất mà bạn sử dụng thì công việc sẽ càng khó khăn hơn.

Trong trường hợp này với JavsScript, về cơ bản chúng ta có lập trình chống lại đầu ra máy chủ tự động mà chính nó là một ý tưởng kỳ lạ. Các trang của ứng dụng web động được tạo trên máy chủ bằng một số ngôn ngữ lập trình. Ở phía máy chủ, bạn nhận được tất cả các loại kẹo như kiểm tra cú pháp, kiểm tra loại, tất cả các loại công cụ phân tích và tái cấu trúc tự động đều theo ý của bạn.

JavaScript hoạt động ở phía bên kia của hàng rào, nơi không có thông tin về những điều lớn lao xảy ra trên máy chủ. JavaScript hoạt động chống lại một đánh dấu được tạo tự động khá dễ bay hơi và có thể thay đổi. Đó là lý do tại sao một nhà phát triển phải chú ý để giữ cả hai đồng bộ. Một ứng dụng càng lớn thì nhiệm vụ càng trở nên khó khăn. Và nhiệm vụ đó thường là một công việc thủ công không thể tự động đủ để mở rộng quy mô liền mạch với ứng dụng của bạn.

Do đó, có, các ứng dụng giàu JavaScript khó bảo trì hơn.


6

Tôi thấy rằng về lâu dài các ứng dụng ajax của tôi (tất cả các mạng nội bộ) dễ bảo trì hơn vì dường như chúng có tính mô đun hơn nhiều. Chẳng hạn, nếu tôi có một trang sau đó tải nội dung khác vào các thùng chứa thì cùng một nội dung có thể dễ dàng sử dụng lại và hiển thị ở nơi khác. Mã nguồn cho mỗi phần nằm trong các tệp khác nhau cho các khung nhìn và phương thức trên bộ điều khiển giúp việc gỡ lỗi / tăng cường một nhiệm vụ dễ dàng hơn. Nó thực sự phụ thuộc vào cách bạn sử dụng AJAX và cách thiết lập ứng dụng của bạn.


1

Các khó khăn chủ yếu là một câu hỏi kinh nghiệm. Nếu bạn không có kinh nghiệm trong việc duy trì các ứng dụng web dựa trên AJAX, thì có: khó hơn.

Tuy nhiên, dường như có sự phức tạp hơn trong một mô hình UI có khả năng đăng ký lại so với mô hình có một kết xuất duy nhất, giống như một trang web truyền thống được phục vụ thông qua một yêu cầu. Điều này đúng vì một số lý do:

  • Mã kết xuất được chia giữa mã phía máy chủ thực hiện kết xuất ban đầu và mã JavaScript thực hiện kết xuất phía máy khách. Điều này có thể được thực hiện dễ dàng hơn, ví dụ, bằng cách sử dụng JavaScript trên máy chủ cũng như máy khách.
  • Nói chung, rất nhiều mã của bạn có thể cần được sao chép (ví dụ: xác thực) trên cả máy khách và máy chủ.
  • Thay vì trực tiếp kết xuất dữ liệu thành HTML bằng mã phía máy chủ, bạn cần một trình xử lý AJAX định dạng dữ liệu thành JSON và sau đó thêm mã để định dạng JSON thành HTML. Các khung có thể làm cho điều này dễ dàng hơn.
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.