Khi nào không sử dụng Google Web Toolkit? [đóng cửa]


55

Tôi đang xem xét việc sử dụng GWT trong một dự án phát triển ứng dụng web nội bộ lớn, cụ thể là ưu điểm lớn trong mắt tôi là việc biên dịch chéo với Javascript, ít nhất là về mặt lý thuyết sẽ giúp nhóm của tôi giảm quy mô của công nghệ .

Tuy nhiên, đã bị cháy trước đó (như hầu hết các nhà phát triển), tôi muốn nghe từ các lập trình viên đã thực sự sử dụng nó cho bất kỳ vấn đề nào với GWT sẽ cản trở hoặc hạn chế, nó sử dụng trong một miền vấn đề nhất định.

Các đối số chống lại việc sử dụng GWT là gì và tại sao?


11
Tôi nghĩ rằng GWT đã chết.
Aaron McIver

1
@Aaron, thật sao?
Jas

10
Tôi không đề nghị cá nhân GWT. Lối suy nghĩ buộc bạn phải làm việc cho các ứng dụng máy tính để bàn, nhưng sẽ khiến bạn gặp vấn đề khi cố gắng nghĩ như vậy trong các chức năng HTML. Tôi là một fan hâm mộ của việc kết hợp mô hình mã hóa với vấn đề trong tay, và sự trừu tượng cản trở tôi. Đó là lý do tại sao mỗi lần tôi bắt đầu đánh giá nó, tôi quyết định không sử dụng nó.
Berin Loritsch

2
@ Kinh nghiệm đã được vài năm trở lại; trong giai đoạn trứng nước và nó cảm thấy rất thô sơ vào thời điểm đó. Nó đã thay đổi? Có lẽ .... nhưng tôi đang dần cố gắng tìm hiểu nền tảng của các khung thay vì dựa vào chính các khung đó. Vào cuối ngày, nó là một máy xay thịt để tạo ra JS; không phải đó là một điều xấu nhưng không phải nơi nào tôi muốn nỗ lực. Nhiều trong số các khung này được chọn do thiếu kiến ​​thức về công nghệ X hoặc một cái gì đó ... nhưng cuối cùng bạn sẽ cần phải trở nên am hiểu về công nghệ X tại một thời điểm nào đó .... cũng có thể đi theo con đường đó trước tiên.
Aaron McIver

10
Tôi rất am hiểu về JS, đã viết một số thứ khá nghiêm trọng ở đó, tuy nhiên hiện tại tôi đang chạy một dự án rất quan trọng về thời gian và tôi không đủ khả năng để nhân viên cấp dưới lãng phí thời gian vì lỗi do chuyển ngữ cảnh từ Java sang JS. Vì vậy, xin vui lòng, nếu bạn có một số ví dụ trong thế giới thực về lý do tại sao GWT không hiệu quả với bạn, thì vui lòng mô tả nó, nếu không, đừng lãng phí thời gian của nhau với các cuộc thảo luận mang tính chủ quan và mang tính chủ quan.
Jas

Câu trả lời:


84

Tôi vừa tốt vừa xấu khi trả lời câu hỏi này - tốt, ở chỗ tôi thực sự đã sử dụng nó trước đây và xấu, ở chỗ tôi đã khá có kinh nghiệm với HTML / CSS / JavaScript trước khi làm việc với GWT. Điều này khiến tôi phát điên khi sử dụng GWT theo cách mà các nhà phát triển Java khác, những người không thực sự biết về DHTML có thể không có được.

GWT thực hiện những gì nó nói - nó trừu tượng hóa JavaScript và ở một mức độ HTML nào đó thành Java. Đối với nhiều nhà phát triển, điều này nghe có vẻ tuyệt vời. Tuy nhiên, chúng tôi biết, như Jeff Atwood nói, tất cả các tóm tắt đều là trừu tượng không thành công (đáng để đọc nếu xem xét GWT). Với GWT, điều này đặc biệt giới thiệu các vấn đề sau:

Sử dụng HTML trong GWT hút.

Như tôi đã nói, ở một mức độ nào đó, thậm chí trừu tượng hóa HTML. Nghe có vẻ tốt cho một nhà phát triển Java. Nhưng nó không phải là. HTML là một định dạng đánh dấu tài liệu. Nếu bạn muốn tạo các đối tượng Java để xác định tài liệu, bạn sẽ không sử dụng các yếu tố đánh dấu tài liệu. Thật điên rồ dài dòng. Nó cũng không được kiểm soát đủ. Trong HTML về cơ bản có một cách để viết <p>Hello how are <b>you</b>?</p>. Trong GWT, bạn có 3 nút con (văn bản B, văn bản) được đính kèm vào một Pnút. Bạn có thể tạo P trước hoặc tạo các nút con trước. Một trong các nút con có thể là kết quả trả về của hàm. Sau một vài tháng phát triển với nhiều nhà phát triển, cố gắng giải mã tài liệu HTML của bạn trông như thế nào bằng cách truy tìm mã GWT của bạn là một quá trình gây đau đầu.

Cuối cùng, nhóm đã quyết định rằng có thể sử dụng HTMLPanel cho tất cả HTML là cách phù hợp. Bây giờ, bạn đã mất nhiều lợi thế của GWT khi có sẵn các phần tử cho mã Java để liên kết dễ dàng với dữ liệu.

Sử dụng CSS trong GWT hút.

Bằng cách đính kèm với trừu tượng HTML, điều này có nghĩa là cách bạn phải sử dụng CSS cũng khác nhau. Nó có thể đã được cải thiện kể từ lần cuối tôi sử dụng GWT (khoảng 9 tháng trước), nhưng tại thời điểm đó, hỗ trợ CSS là một mớ hỗn độn. Do cách thức GWT tạo cho bạn tạo HTML, bạn thường có các mức nút mà bạn không biết đã bị tiêm (bất kỳ nhà phát triển CSS nào cũng biết cách điều này có thể ảnh hưởng đáng kể đến kết xuất). Có quá nhiều cách để nhúng hoặc liên kết CSS, dẫn đến một mớ hỗn độn về không gian tên. Trên hết, bạn có hỗ trợ sprite, nghe có vẻ hay, nhưng thực sự đã làm biến đổi CSS của bạn và chúng tôi gặp vấn đề với việc viết các thuộc tính mà sau đó chúng tôi phải ghi đè lên một cách rõ ràng, hoặc trong một số trường hợp, đã cản trở những nỗ lực của chúng tôi để khớp với bàn tay của chúng tôi đã mã hóa CSS và phải thiết kế lại nó theo cách mà GWT không làm hỏng nó.

Liên minh các vấn đề, giao điểm của lợi ích

Bất kỳ ngôn ngữ nào cũng sẽ có bộ vấn đề và lợi ích riêng. Cho dù bạn sử dụng nó là một công thức trọng số dựa trên những. Khi bạn có một sự trừu tượng, những gì bạn nhận được là sự kết hợp của tất cả các vấn đề và sự giao thoa giữa các lợi ích. JavaScript có vấn đề và thường bị các kỹ sư phía máy chủ chế giễu, nhưng nó cũng có khá nhiều tính năng hữu ích để phát triển web nhanh. Hãy nghĩ rằng các bao đóng, tốc ký cú pháp, các đối tượng đặc biệt, tất cả những thứ được thực hiện bởi Jquery (như truy vấn DOM bằng bộ chọn CSS). Bây giờ hãy quên việc sử dụng nó trong GWT!

Tách biệt mối quan tâm

Chúng ta đều biết rằng khi quy mô của một dự án phát triển, việc phân tách các mối quan tâm là rất quan trọng. Một trong những điều quan trọng nhất là sự tách biệt giữa hiển thị và xử lý. GWT đã làm điều này thực sự khó khăn. Có lẽ không phải là không thể, nhưng đội tôi tham gia không bao giờ đưa ra một giải pháp tốt, và ngay cả khi chúng tôi nghĩ rằng chúng tôi có, chúng tôi luôn có một người bị rò rỉ vào đội kia.

Máy tính để bàn! = Web

Như @Berin Loritsch đã đăng trong các bình luận, mô hình hoặc suy nghĩ GWT được xây dựng cho các ứng dụng sống, trong đó một chương trình có màn hình sống kết hợp chặt chẽ với một công cụ xử lý. Điều này nghe có vẻ tốt bởi vì đó là điều mà rất nhiều người cảm thấy web đang thiếu. Nhưng có hai vấn đề: A) Web được xây dựng trên HTTP và điều này vốn đã khác nhau. Như tôi đã đề cập ở trên, các công nghệ được xây dựng trên HTTP - HTML, CSS, thậm chí tải tài nguyên và bộ đệm (hình ảnh, v.v.), đã được xây dựng cho nền tảng đó. B) Các nhà phát triển Java đã và đang làm việc trên web không dễ dàng chuyển sang tư duy ứng dụng máy tính để bàn này. Kiến trúc trong thế giới này là một ngành hoàn toàn khác nhau. Các nhà phát triển Flex có lẽ sẽ phù hợp với GWT hơn các nhà phát triển web Java.

Túm cái vạy lại là...

GWT có khả năng tạo ra các ứng dụng AJAX nhanh và bẩn khá dễ dàng chỉ bằng Java. Nếu nhanh và bẩn không giống như những gì bạn muốn, đừng sử dụng nó. Công ty tôi đang làm việc là một công ty quan tâm rất nhiều đến sản phẩm cuối cùng, và đó là cảm giác đánh bóng, cả về hình ảnh và tương tác, cho người dùng. Đối với chúng tôi, các nhà phát triển front-end, điều này có nghĩa là chúng tôi cần kiểm soát HTML, CSS và JavaScript theo cách sử dụng GWT như thử chơi piano với găng tay đấm bốc.


2
Tôi nhận ra một số lý do chúng tôi chọn Wicket thay vì GWT, ngả mũ trước bài thuyết trình.
biziclop

12
-1 cho FUD, trải nghiệm của tôi với GWT được sử dụng cho các ứng dụng quy mô nhỏ và quy mô đã tích cực hơn tiêu cực. Và tôi đã không gặp phải một trong những "vấn đề" do đó bình luận của FUD. Chúng tôi đã nhúng thành công các widget được tạo ra vào các trang HTML rất phức tạp với rất ít nỗ lực. Nếu bạn biết những gì bạn đang làm thì thật tuyệt vời, nếu bạn không muốn xem xét có thể có một cách làm việc mới tốt hơn thì hãy làm theo "câu trả lời" này và bỏ qua nhận xét này.

9
@Jarrod Đây không phải là "vấn đề" gặp phải, mà là những mô tả đơn giản về bản chất của GWT. Nếu có liên quan, tôi tiếp tục coi chúng là những tiêu cực cụ thể trong lăng kính của các mục tiêu dự án của chúng tôi. Nếu bạn có một kinh nghiệm thay thế, hãy viết nó lên. Cho đến lúc đó, thông tin duy nhất chưa được chứng minh là tuyên bố của bạn rằng GWT là "mới và tốt hơn". Nhân tiện - kể từ khi tôi viết câu trả lời này, công ty (tôi không còn làm việc nữa) đã ném ra hơn một năm làm việc của một số kỹ sư và viết lại dự án mà không cần GWT. Trong thời gian ít hơn.
Nicole

1
@JarrodRoberson Tôi đồng ý với NickC, sẽ rất tuyệt khi đọc một bài viết chi tiết không kém về kinh nghiệm của bạn.
funkybro

8
@NickC "Trong thời gian ngắn hơn" để viết lại một dự án không được coi là một cú đánh lớn đối với GWT IMO; bất kỳ dự án nào mà về cơ bản bạn đang lặp lại những gì đã được thực hiện trước đó ngay cả trong một khuôn khổ hoặc ngôn ngữ khác phải mất "ít thời gian hơn".
funkybro

24

Chúng tôi sử dụng GWT cho một ứng dụng web chính phủ điện tử lớn (SOA trong phần phụ trợ) có mức độ sử dụng lớn. Giao diện người dùng cũ là trong DHTML nhưng chúng tôi gặp vấn đề với khả năng tương thích trình duyệt, tối ưu hóa hiệu suất và quá trình phát triển, vì vậy chúng tôi đã tìm kiếm các lựa chọn thay thế.

Yêu cầu của chúng tôi là:

  • lớp UI phía máy khách để giảm thiểu tải máy chủ
  • tính tương thích của trình duyệt web
  • RIA dựa trên web
  • Tối ưu hóa hiệu suất dễ dàng
  • Không cần cài đặt plugin khách, nên hoạt động với cài đặt windows đơn giản

Chúng tôi đã chọn GWT và tôi không bao giờ hối tiếc. Nhóm mới không có hoặc có ít kinh nghiệm về DHMTL và do đó, quy trình phát triển Java của GWT rất hữu ích. Những gì bạn nhận được của hộp là:

  • tính tương thích của trình duyệt web
  • Quá trình phát triển dựa trên Java và tái sử dụng mã
  • dễ dàng giảm thiểu các yêu cầu (gói hình ảnh, ...)
  • bộ nhớ đệm dễ dàng (ứng dụng mới được lưu hoàn toàn ở phía máy khách)
  • dễ dàng nén tất cả các nguồn tài nguyên (ngay cả với js trên các IE lỗi cũ)
  • và nhiều hơn nữa, rất nhiều để đề cập ở đây

Ứng dụng của chúng tôi chỉ phát hành một yêu cầu cho máy chủ khi khởi động. Về mặt tiêu cực là GWT (và cả Android) có thiết kế kém hoàn hảo, nhưng dù sao nếu bạn áp dụng giao diện của riêng mình, bạn phải điều chỉnh CSS. Ngoài ra, bạn có thể sử dụng các thư viện thành phần khác nhau cho GWT để dễ dàng áp dụng các kiểu và chủ đề phù hợp.

Đối với tôi không có điểm nào có thể là DOM DOM không tốt như thủ công, điều này không bao giờ là vấn đề. Khi tôi phát triển trong C ++, tôi không nhìn vào mã trình biên dịch được tạo. Khi tôi phát triển trong GWT, không bao giờ có lý do để tôi xem mã JS và chỉ một lần lý do để xem DOM và thực hiện một số tái cấu trúc.

Đối với tôi, GWT là lựa chọn duy nhất khi phát triển RIA và tôi hy vọng rằng GWT có một tương lai tươi sáng. Xem tuyên bố sứ mệnh tại:

[1] http://code.google.com.vn/intl/de-DE/webtoolkit/makinggwtbetter.html#int sinhtion

Nhưng không nên đề cập rằng Google không sử dụng GWT cho nhiều dự án nội bộ của họ và hiện tại có một số tin đồn xung quanh về tương lai của GWT, xem

[2] http://googlewebtoolkit.blogspot.com/2011/11/gwt-and-dart.html
[3] https://plus.google.com/105933370793992913359/posts/bLfSagtziBC

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.