Nhà phát triển tiếp cận với giao diện người dùng JavaScript phức tạp [đã đóng]


19

Tôi đang cố gắng tìm hiểu bối cảnh của các cách tiếp cận khác nhau và các thực tiễn tốt nhất, xung quanh việc phát triển JavaScript phía máy khách phức tạp.

Tôi không chắc chắn nên dán nhãn lớp ứng dụng này, có lẽ là AJAX hoặc RIA nặng (nhưng không phải là plugin như Flash / Silverlight). Tôi đang đề cập đến các ứng dụng web có các đặc điểm sau:

  • Giả lập UX máy tính để bàn phong phú / bản địa trong JavaScript
  • Chứa hầu hết / tất cả các hành vi trong JS phía máy khách, sử dụng máy chủ làm API dữ liệu (JSON / Html-Mẫu).

Điều này trái ngược với việc sử dụng máy chủ web để kết xuất giao diện người dùng, tạo ra tất cả HTML trong mô hình làm mới trang.

Một số ví dụ:

  • Google Docs / Gmail
  • Tâm trí
  • Theo dõi quan trọng

Khi chúng ta tiến lên HTML5, tôi có thể thấy phong cách phát triển RIA này, với JavaScript nặng nề, trở nên phổ biến hơn và cần thiết hơn để cạnh tranh.

HỎI: Vậy các cách tiếp cận phổ biến đang nổi lên xung quanh việc quản lý các loại phát triển JS nặng nề này là gì?

Mã phía máy khách, khi một ứng dụng phát triển các tính năng, rất phức tạp. Có những vấn đề mở rộng nỗ lực phát triển trên nhiều nhóm với JS thô (hoặc tôi nghe được và có thể tin điều đó).

Google đã tiếp cận vấn đề bằng cách xây dựng GWT biên dịch từ ngôn ngữ cấp cao hơn (Java) sang JS, dựa trên cơ sở hạ tầng phát triển hiện có mà ngôn ngữ cấp cao hơn có (Eclipse, gõ mạnh, công cụ tái cấu trúc), cùng với khả năng tương thích trình duyệt và các vấn đề khác từ nhà phát triển.

Có những công cụ khác, như Script # cho C # làm điều gì đó tương tự. Tất cả điều này đặt JS nhiều hơn trong vai trò của IL (Ngôn ngữ trung gian). I E. "Bạn không bao giờ thực sự viết bằng 'ngôn ngữ cấp thấp' đó nữa."

Nhưng 'biên dịch thành JS' này không phải là cách tiếp cận duy nhất. Không rõ ràng rằng GWT là phương pháp chi phối ... hoặc thực sự sẽ trở thành nó.

Mọi người đang làm gì với JavaScript khách hàng phong phú? Một số câu hỏi định hướng:

  • Có phải hầu hết các cửa hàng đều tạo ra thủ công JS (trên đỉnh các lib như jQuery et al) không?
  • Hoặc có nhiều cách tiếp cận khác nhau, không có thực tiễn tốt nhất rõ ràng đang nổi lên?
  • Có phải hầu hết các cửa hàng tránh phát triển quy mô RIA để ủng hộ mô hình vẽ lại phía máy chủ / trang đơn giản hơn cho nhà phát triển? Nếu vậy, điều này sẽ kéo dài?
  • Việc biên dịch sang JS có lẽ là một xu hướng mới nổi trong tương lai? Hay đây chỉ là đầu sai?
  • Làm thế nào để họ quản lý sự phức tạp và tái cấu trúc của máy khách JS?
  • Modularization và phân phối công việc giữa các đội?
  • Ứng dụng, thực thi và thử nghiệm các mẫu phía máy khách như MVC / MVP, v.v.

Vậy, những xu hướng mới nổi trong tương lai JavaScript và HTML5 nặng nề này của chúng ta là gì?

Cảm ơn!


Zimbra phụ thuộc rất nhiều vào js phía máy khách để mô phỏng môi trường máy tính để bàn.
ếchstarr78

Cảm ơn. Bạn có biết làm thế nào họ phát triển JS của họ? Thủ công, hoặc công cụ cấp cao hơn?
Phil Cockfield

Câu trả lời này cho câu hỏi tương tự tóm tắt các tùy chọn khá tốt: stackoverflow.com/questions/218699/
Victor Sorokin

1
Google+ tôi sử dụng rất nhiều GWT (dự kiến ​​... sẽ thấy từ Google)
jamiebarrow

Quá tệ, câu hỏi này đã bị đóng :( ... IMHO nên được mở lại
dagnelies

Câu trả lời:


6

Hầu hết các ứng dụng Web tôi thấy (và các nhà phát triển Web mà tôi đã nói chuyện), những người đang di chuyển theo hướng này đều sử dụng jQuery làm cơ sở.

Toàn bộ lý do đằng sau GWT (và các ngôn ngữ đa cấp tương tự) là JavaScript quá hoàn hảo / quá mong manh / quá dễ thay đổi để "lập trình viên thực sự" sử dụng. Nhưng nếu bạn có một khung xử lý các bit flakey / mong manh / có thể thay đổi cho bạn, thì không có lý do gì để thêm vào lớp phức tạp thêm đó.

Chỉ là ý kiến ​​của tôi


Tôi nghi ngờ rằng bất kỳ framwork nào cũng có thể loại bỏ "sự mong manh" của javascript. Bản chất năng động của nó làm cho rất khó để đảm bảo tính nhất quán và dễ bị lỗi thời gian chạy. Nó đủ cho thấy một thuộc tính json đã được đổi tên ở một nơi nào đó và không được sửa lại toàn bộ để phá vỡ mọi thứ. ... Đó không phải là vấn đề với các tập lệnh nhỏ điển hình, nhưng trong RIA phức tạp với hàng ngàn LỘC, điều này có thể nhanh chóng xảy ra và nhanh chóng không được chú ý. Không có khuôn khổ nào có thể tránh được điều đó.
dagnelies

5

Tôi sẽ nói rằng GWT là rủi ro. Một khi bạn quyết định sử dụng nó, bạn sẽ bị mắc kẹt với nó. Về cơ bản, điều đó có nghĩa là bạn coi việc đánh dấu, DOM và một số khía cạnh của CSS là môi trường thực thi. Thật khó để trộn JavaScript được viết thủ công với GWT khi mã máy khách của bạn ngày càng tinh vi hơn. GWT có các phương thức riêng nhưng chúng khá hạn chế về khả năng áp dụng. Đó là một sự đánh đổi lớn và đó là một vụ cá cược lớn.

Google cố gắng bán GWT như một môi trường thực thi nền tảng X rất nhanh với sự tích hợp phía máy chủ. Nhưng như những người khác đã chỉ ra rằng nó không còn là vấn đề nữa - JQuery và YUI cũng nhanh như vậy nếu không nhanh hơn. Và việc cấu hình và tối ưu hóa các trang của bạn sẽ dễ dàng hơn nhiều khi chúng được lắp ráp thủ công để bạn có toàn quyền kiểm soát CSS, đánh dấu và JavaScript.

GWT cố gắng che giấu nền tảng cơ bản khỏi bạn, đây thực sự có thể là một cách làm sai. Rất nhiều cái gọi là khung thành phần web đã làm như vậy. Bạn phải viết mã có nguồn gốc XML mơ hồ với EL và các thẻ tùy chỉnh được đưa vào. Đầu ra sẽ là một mớ hỗn độn của HTML được tạo kém với các đoạn JavaScript nhỏ rắc rối được rắc khắp nơi. Các trang bị chậm, lỗi và hoàn toàn không thể nhầm lẫn.

Trong dự án hiện tại của chúng tôi, chúng tôi sử dụng Sọc - khung dựa trên hành động ở mức độ thấp - và JQuery ở phía máy khách. Thật dễ dàng để làm Ajax khi bạn thấy rõ tất cả các mảnh ghép: đây là mã phía Máy chủ của bạn hoạt động trên dữ liệu. Đây là mã phía máy khách của bạn - để truy xuất dữ liệu và để thực hiện mọi thứ trên một trang. Đây là CSS của bạn, đây là đánh dấu của bạn, đây là khuôn mẫu của bạn - mọi thứ đều sạch sẽ và tách rời. Dễ dàng mở rộng, có thể hack, điều chỉnh và gỡ lỗi. Tôi thích nó.

Tôi yêu JQuery với thái độ của nó đối với tốc độ và sự đơn giản. Tôi yêu YUI3 cho các mô-đun và các vật dụng toàn diện. Tôi yêu CSS YUI vì đã mang lại cho tôi sự nhất quán trên các trình duyệt. Tôi yêu JavaScript cho các phần tốt. Tôi yêu Java vì đã để tôi hoàn thành công việc.

Chỉ cần HÔN, và bạn sẽ ổn thôi!


2
Và BTW, Google không sử dụng GWT cho GMail - họ sử dụng thư viện Đóng cửa của họ.
Andrew Андрей Листочкин

1
Thực sự đánh giá cao phân tích này về các rủi ro xung quanh GWT và tổng hợp từ các ngôn ngữ cấp cao hơn nói chung.
Phil Cockfield

2
Tôi nghĩ rằng tôi đồng ý với Andrew. Bạn không cần các khung công tác cấp cao hơn nếu bạn hiểu JavaScript. Ví dụ, ASP.NET WebForms là một khung sử dụng XML và các thẻ tùy chỉnh để tạo ra những thứ như trình hướng dẫn và cửa sổ bật lên cho mô hình lập trình đơn giản hơn cho người có ít kinh nghiệm với web nhưng có nhiều kinh nghiệm hơn với Windows Forms. Để cố gắng giữ một mô hình. Nhưng ASP.NET MVC đang trở nên phổ biến và IMO tiêu chuẩn, bởi vì nó gần với web hơn - mô hình phù hợp với thực tế.
jamiebarrow

3

Tôi đã nghe những cái này được gọi là "Ứng dụng một trang".

Đây là một môi trường mới và các quy tắc chưa được viết hoàn toàn. Tôi đã làm việc trên một ứng dụng một trang tương đối lớn vào năm ngoái (2010) và đây là những công cụ chúng tôi đã sử dụng.

Phần cuối là Java, sử dụng các servlet để cung cấp dịch vụ JSON, trang cuối cùng được sử dụng để gửi thứ tự đã chuẩn bị. Dịch vụ này cũng được sử dụng cho một số bước xác nhận và giá cả.

Mã mặt trước là javascript. Chúng tôi đã sử dụng jQuery để thực hiện các thao tác của các phần tử trang, Pure để tạo khuôn mẫu và RequireJs để chia mã thành các mô-đun. (Công cụ xây dựng của RequireJs đã được sử dụng để cung cấp các bản tải xuống tối ưu hơn.)

Chúng tôi đã viết các bài kiểm tra của mình bằng cách sử dụng qUnit và đã có một bài kiểm tra jUnit sử dụng htmlunit để chạy từng bài kiểm tra qUnit, sau đó quét đầu ra để có kết quả và vượt qua hoặc thất bại dựa trên trạng thái vượt qua / thất bại của qUnit. Những người đã được thêm vào các bài kiểm tra jUnit của chúng tôi cho mặt sau và cuộn vào ci của chúng tôi, sử dụng Hudson / Jenkins .


2

Tôi làm việc trên một ứng dụng như vậy, được xây dựng dựa trên Ext JS. Ứng dụng này được tổ chức theo mô-đun. Các mô-đun khác nhau được triển khai dưới dạng các thành phần độc lập tự dọn sạch khi chúng bị xóa khỏi hệ thống phân cấp thành phần Ext. Các trình tải theo yêu cầu tải các thành phần bổ sung ngay trước khi cần (một tệp js = một thành phần).

Tôi thấy rằng phương pháp này không khó để mở rộng quy mô. Các giới hạn thực duy nhất tôi gặp phải có liên quan đến việc có quá nhiều phần tử DOM trong cây cùng một lúc trong IE. Giải pháp là có chiến lược dỡ bỏ các phần ẩn của ứng dụng. Bởi vì tất cả các thao tác DOM xảy ra thông qua hệ thống phân cấp thành phần Ext, DOM gần như được trừu tượng hóa hoàn toàn và việc phát triển vẫn đơn giản.


ExtJS thực sự thú vị khi xem xét (cảm ơn), khi thấy rằng Sencha tạo ra cả libs JS và GWT gốc (ExtGWT). Có vẻ như họ đang phòng ngừa các vụ cá cược.
Phil Cockfield

0

Cá nhân tôi nghĩ rằng các khung như jQuery rất quan trọng không chỉ để xử lý các biến thể trên các trình duyệt khác nhau mà còn để loại bỏ những khác biệt đó để chúng không thêm nhiễu vào mã. Các công cụ như GWT, Websharper và các công cụ khác đưa nó đi xa hơn và chắc chắn có một vị trí nhưng tôi tự hỏi liệu nó chỉ là một lớp bổ sung trong hầu hết các trường hợp.

Một cái gì đó mà tôi cho rằng không ai nhắc đến là thử nghiệm đơn vị. Hiện tại, người ta thường chấp nhận rằng các ứng dụng phía máy chủ phức tạp nên có các thử nghiệm đơn vị tự động và tôi nghĩ rằng đã đến lúc mà các ứng dụng JS trong RIA đủ phức tạp để cần thử nghiệm đơn vị - cùng với kiến ​​trúc / mã có thể thực hiện được.

Tuy nhiên, không giống như các ứng dụng phía máy chủ phức tạp, cảm giác ruột thịt của tôi dựa trên những gì tôi thấy và nghe thấy là phần lớn các ứng dụng phía máy khách phức tạp hoàn toàn không có thử nghiệm đơn vị (tôi không nói về thử nghiệm selen ở đây, thử nghiệm đơn vị thực sự).

Tôi nghĩ rằng xu hướng mới nổi tiếp theo sẽ là việc giới thiệu thử nghiệm đơn vị (và mã có thể kiểm tra được đơn vị). Vừa hoàn thành một dự án với một lượng JavaScript không phải đơn vị thử nghiệm vừa phải, tôi hy vọng nó sẽ là dự án cuối cùng.


Đây là một bài viết hay về TDD với JavaScript có thể được quan tâm [ msdn.microsoft.com/en-us/scriptjunkie/ff452703 ]
jamiebarrow
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.