Ưu và nhược điểm của ứng dụng web chỉ HTML / JavaScript [đã đóng]


35

Tôi đến từ một nền tảng biểu mẫu ASP.NET và đã thấy mã hóa phía máy chủ rất mạnh trong quá khứ. Tuy nhiên, gần đây, tôi đã muốn loại bỏ mã phía máy chủ của giao diện người dùng và thay thế nó bằng HTML / JavaScript thuần, truy cập dữ liệu thông qua dịch vụ web JSON. Tôi không có kinh nghiệm thực tế trong việc này, và vì vậy tôi muốn biết liệu đây có phải là một mô hình đã được thử nghiệm và thử nghiệm hay không. Ngoài ra, những cạm bẫy xung quanh nó là gì?

Tôi thấy các điều khiển người dùng ASP.NET rất hữu ích, vì vậy tôi muốn giữ lý thuyết đằng sau nó bằng cách lưu trữ các mẫu đánh dấu trong các tệp HTML riêng biệt trên máy chủ. Chúng sẽ được truy xuất và sử dụng thông qua jQuery AJAX và plugin mẫu jQuery jQuery.

Bất kỳ đầu vào sẽ được đánh giá rất cao.

PS Xin lỗi vì câu hỏi không có, nhưng loại kiến ​​trúc Web này được gọi là web-2.0 hay tôi hoàn toàn lạc đề?


1
Bạn có muốn thay thế các điều khiển asp.net bằng HTML / JavaScript hay bạn muốn đưa toàn bộ logic nghiệp vụ (xác thực, v.v.) lên giao diện người dùng?
šljaker

1
Câu hỏi hay. Tôi đang nghĩ đến việc thực hiện frontend chỉ bằng html / javascript để làm sáng trang để nó nhanh hơn trên điện thoại di động / miếng đệm. Vì vậy, có lẽ chỉ cần thay thế điều khiển asp.net. Tất cả các cuộc gọi đến máy chủ thông qua dịch vụ webs, vì vậy dịch vụ wcf bằng cách nào đó sẽ xử lý xác thực, v.v. Bạn có nghĩ rằng điều này là có thể?
hofnarwillie

Tôi đang đặt câu hỏi tương tự ở đây: stackoverflow.com/questions/34020543/ và tại đây: stackoverflow.com/questions/33934101/
trộm

@hofnarwillie để xác thực, tôi nghĩ bạn nên sử dụng JS phía máy khách.
smwikipedia

1
@smwikipedia Cảm ơn, nhưng tôi thấy rằng xác nhận phía khách hàng chỉ nên được sử dụng cho người dùng dễ dàng. Xác nhận thực sự nên được thực hiện phía máy chủ. Xác thực khách hàng làm cho người dùng ứng dụng của bạn thân thiện, nhưng xác thực phía máy chủ đảm bảo tính bảo mật và hiệu lực, bởi vì xác thực phía máy khách có thể dễ dàng bị tắt.
hofnarwillie

Câu trả lời:


31

Tôi đã sử dụng kỹ thuật này dành riêng cho một ứng dụng web mà chúng tôi đang làm việc. Phần cuối của tôi được lưu trữ trên Google App Engine bằng Java SDK và frontend của tôi sử dụng HTML, CSS và JavaScript (với jQuery).

Dự án này là một dự án nhỏ hơn chỉ có bản thân tôi và một nhà thiết kế Web, và cả hai chúng tôi đều cảm thấy rằng phương pháp này đã giúp chúng tôi làm việc nhanh hơn rất nhiều và có được thứ gì đó để tiếp thị sớm hơn nhiều.

Ưu điểm: Làm việc với các nhà thiết kế web

Ưu điểm chính của kỹ thuật này là nhà thiết kế Web, người biết một số PHP nhưng không coi mình là lập trình viên, có thể làm việc không bị cản trở trong HTML và CSS mà không phải lội qua vô số dòng JSP, thẻ taglib và phía máy chủ khác đánh dấu mà chúng ta đã nói trong nhiều năm được cho là làm cho cuộc sống của nhà phát triển phía trước dễ dàng hơn nhiều.

Không có tất cả các đánh dấu phía máy chủ, chúng tôi đã nhanh nhẹn hơn. Nhà thiết kế web đã trực tiếp hoán đổi và sửa đổi thiết kế ban đầu của mình 3 hoặc 4 lần, với rất ít thay đổi về phía tôi.

Nhận xét của anh ấy với tôi là anh ấy cảm thấy như HTML còn sống ở chỗ anh ấy có thể chỉnh sửa nó và sau đó ngay lập tức thấy những thay đổi trên máy của anh ấy với dữ liệu động. Cả hai chúng ta đều được hưởng lợi bởi điều này trong đó việc tích hợp chủ yếu là tự động.

Mã phía máy chủ và Handoff HTML / CSS

Trong các dự án trước đây, anh ta phải chuyển giao HTML và CSS cho các nhà phát triển Java, những người sau đó sẽ lấy HTML và CSS của anh ta và viết lại hoàn toàn bằng công nghệ JSP. Điều này sẽ mất rất nhiều thời gian và thường sẽ dẫn đến sự khác biệt tinh tế nhưng quan trọng trong việc hiển thị thực tế của các trang cũng như xác thực nó trong trình xác nhận W3C.

Nhìn chung, cả hai chúng tôi đều khá hài lòng với kỹ thuật này và tôi vẫn không có các trang JSP hoặc mã phía máy chủ trong các trang HTML của mình.

Cạm bẫy của Kỹ thuật REST / JSON

Có lẽ những cạm bẫy lớn nhất là những điều chúng ta chưa gặp phải. Tôi hoàn toàn mong đợi có một số bất đồng với các nhà phát triển Java có kinh nghiệm hơn, những người đã bị tẩy não bởi những gì mà nền tảng Apache và nhóm Spring đã nói với họ về cách các thư viện thẻ giúp các nhà phát triển frontend làm việc với mã dễ dàng hơn. Tôi hoàn toàn mong đợi sẽ có một đường cong học tập khi dự án này mở rộng và chúng tôi tiếp nhận nhiều nhà phát triển hơn, những người có thể phải học những kỹ thuật lỗi thời này, theo kinh nghiệm của tôi, đã làm cho công việc của các nhà thiết kế Web trở nên khó khăn hơn .

Một cạm bẫy khác là mã JavaScript đã trở nên rất lớn. Đây có thể là một vấn đề có lẽ vì lần đầu tiên tôi sử dụng kỹ thuật này và vì chúng tôi đã đưa ra một số nợ kỹ thuật nhỏ để làm việc theo hướng phát hành nhanh chóng. Có lẽ việc chọn một khung tốt hơn sẽ giúp giảm bớt rất nhiều phần lớn mã. Theo tôi, không ai trong số này là showstopper và tôi được khuyến khích tiếp tục sử dụng kỹ thuật này và hoàn thiện các kỹ năng của mình trong lĩnh vực này.

Ưu điểm: Các ứng dụng khác có thể được xây dựng trên nền tảng

Cuối cùng, tôi nên đề cập đến một lợi thế tiềm ẩn. Vì có một mức độ tách biệt tốt giữa các dịch vụ Web RESTful phụ trợ của tôi và giao diện của tôi, tôi cũng đã tạo ra một nền tảng mà tôi có thể dễ dàng mở rộng.

Một trong những người hoạt động của chúng tôi muốn thử một bằng chứng về khái niệm trong một ứng dụng khác và nhờ vào các dịch vụ RESTful của tôi, chúng tôi đã có thể tạo một giao diện hoàn toàn khác với ứng dụng để giải quyết một vấn đề hoàn toàn khác. Bằng chứng khái niệm được phát triển nhanh chóng đã sử dụng HTML, CSS và JavaScript của riêng nó, nhưng nó đã sử dụng các dịch vụ RESTful làm phụ trợ và nguồn dữ liệu.

Cuối cùng, một người quản lý dự án khác đã nhìn thấy những gì tôi đã làm, và ngay lập tức thấy rõ rằng tính năng này cần nhiều hơn là một bằng chứng về khái niệm, vì vậy nhóm của anh ấy đã thực hiện nó.

Tôi không thể nhấn mạnh đủ mức độ tái sử dụng của kiến ​​trúc này, cả ở cấp độ ứng dụng cũng như cấp độ HTML / CSS / JavaScript và tôi chắc chắn sẽ khuyến khích bạn thử điều này trong dự án tiếp theo của bạn.


2
Cảm ơn bạn. Điều này trả lời câu hỏi của tôi hoàn toàn. Đánh giá cao thời gian bạn đưa ra một câu trả lời rõ ràng và súc tích. +1
hofnarwillie

2
Tôi làm việc trong một công ty có toàn bộ ứng dụng web nội bộ là html / js chỉ với các dịch vụ phụ trợ phục vụ dữ liệu được mã hóa json. Điều này hoạt động rất tốt và nhanh hơn nhiều để tạo các ứng dụng mới bằng mô hình này và bởi vì các nhà phát triển phụ trợ và phía trước hoạt động trong song song, tương đông. Bạn thực sự nên thử điều này.
nohros

@ jmort253 Rất cám ơn câu trả lời tuyệt vời. Tôi đã suy nghĩ về chính xác cùng một kiến ​​trúc và thực hành của bạn làm cho tôi tự tin để đi với nó. Tôi đã hỏi những câu hỏi tương tự ở đây: stackoverflow.com/questions/33934101/ và tại đây: stackoverflow.com/questions/34020543/ trên .
smwikipedia

12

Đây chắc chắn là một chiến lược khả thi, nhưng nó không phải là viên đạn bạc.

Ưu điểm :

  • nếu được thực hiện đúng, các ứng dụng được phát triển theo cách này rất nhạy
  • bạn có sự phân tách rõ ràng về logic (trên máy chủ) và cách trình bày (trên máy khách); máy chủ hoàn toàn không phải lo lắng về các khía cạnh trình bày của ứng dụng
  • có khả năng sử dụng băng thông mạng hiệu quả hơn (bạn chỉ gửi dữ liệu thô, không có bản tóm tắt hiện tại)
  • dễ dàng hơn để phát triển GUI giống như máy tính để bàn, vì bạn ít phụ thuộc vào mô hình yêu cầu / phản hồi

Nhược điểm :

  • bạn phải viết mã máy khách của mình bằng Javascript hoặc ngôn ngữ có thể biên dịch thành Javascript, vì đó là thứ duy nhất có sẵn trong trình duyệt
  • việc sử dụng tài nguyên trên máy khách có thể cao hơn, vì vậy ứng dụng có thể không hoạt động tốt trên các thiết bị không đạt tiêu chuẩn (nghĩ trình duyệt di động, v.v.)
  • nó hoàn toàn không hoạt động với javascript bị vô hiệu hóa; nếu nó có một trang web công khai, bạn phải suy nghĩ kỹ xem bạn có sẵn sàng chấp nhận rủi ro này hay không (đặc biệt nếu bạn xem xét SEO và khả năng truy cập - một cách tiếp cận nặng về javascript thường tàn phá ở hai mặt trận này)
  • rất nhiều logic phải được viết hai lần: một lần trên máy khách và một lần nữa trên máy chủ (vì bạn không bao giờ có thể tin tưởng vào máy khách)
  • đồng thời có thể là một địa ngục, vì vậy bạn cần thiết kế mã phía khách hàng của mình thật cẩn thận và chuẩn bị cho tất cả các loại vấn đề tương tranh

2
Cảm ơn. Bạn có thể đưa ra một ví dụ về các vấn đề tương tranh sẽ được gây ra bởi mô hình này?
hofnarwillie

3
Ví dụ: Nếu người dùng nhấp vào Bình chọn và sau đó nhanh chóng nhấp vào Bỏ phiếu trước khi cuộc gọi máy chủ Bầu chọn kết thúc, có bao nhiêu phiếu bầu?
JBRWilkinson

@JBRWilkinson Cờ Boolean kiểm tra trạng thái hoặc thời gian chờ hoặc khoảng thời gian?
Alper Turan

1

Nó chắc chắn có thể, và có lẽ đáng khích lệ là thực hành tốt nhất. Những gì bạn đang đề xuất là tách UI khỏi logic nghiệp vụ để có sự phân tách rõ ràng các mối quan tâm. Cái này thật sự rất tốt.

Quá thường xuyên các khung công tác chúng tôi đã cố gắng trộn lẫn mọi thứ lại với nhau và bạn kết thúc với một phần mềm nguyên khối trong đó giao diện người dùng, logic nghiệp vụ và dữ liệu được đan xen lẫn nhau. Điều đó làm cho nó khó khăn hơn để duy trì và sửa đổi.

Khi bạn chia ứng dụng thành 2 phần, bạn có thể thay thế hoàn toàn UI bằng một thứ khác - chương trình máy tính để bàn hoặc giao diện người dùng khác cho thiết bị di động so với trình duyệt máy tính để bàn.

Các mẹo khó mà bạn sẽ tìm thấy khi thực hiện điều này là một ít mã mà theo lý thuyết nên có trong máy chủ sẽ được đặt tốt hơn trên máy khách - ví dụ như xác thực, nhanh hơn và nhanh hơn cho người dùng đặt mã xác thực vào hình thức trên máy khách hơn là đánh vào máy chủ để kiểm tra, giả sử, một trường văn bản chỉ chứa các ký tự chữ và số. Điều tương tự thường áp dụng cho các lớp dữ liệu và kinh doanh. Bạn chỉ cần đưa ra quyết định sáng suốt và thực tế về việc khi nào vi phạm sự phân biệt giữa các lớp.


1

Một nhược điểm là cần sao chép một số logic trong JavaScript và ASP.net. Điều này có thể không phải là một vấn đề lớn đối với bạn tùy thuộc vào ứng dụng của bạn. Nó thường xuất hiện vì bạn không muốn yêu cầu máy chủ kiểm tra từng điều nhỏ ("Người dùng có được phép nhấn nút này hoặc chọn tùy chọn này trong tình huống này không?") Nhưng bạn cũng không muốn phụ thuộc trên máy khách là người duy nhất thực hiện xác nhận vì người dùng có quyền kiểm soát máy khách.


0

Nếu bạn vẫn đang sử dụng ASP.NET WebForms và muốn tăng tốc ứng dụng của mình, đây là những gì bạn nên làm:

  • Thiết kế ứng dụng của bạn với RẮN trong tâm trí
  • Vô hiệu hóa ViewStatetrên tất cả các trang và kiểm soát người dùng
  • Không sử dụng điều khiển phía máy chủ

    <%: VeiwModel.Title%> thay vì <asp: Literal id = "Title" runat = "server">

  • Trong phần phụ trợ, ghi đè phương thức OnInit và thực hiện tất cả các khởi tạo ở đó:

    được bảo vệ ghi đè khoảng trống OnInit (System.EventArss e) {CreateViewModel (); cơ sở.OnInit (e); }

  • Nén tất cả các tệp .css và .js thành 1 bằng SquishIt

  • Tải hình ảnh lười biếng
  • Cache các đối tượng phức tạp

Cuối cùng, hãy kiểm tra www.pogio.se. Đó không phải là một trang web nhanh chết tiệt?


Đó thực sự là một trang web nhanh chóng. Cảm ơn rất nhiều cho đầu vào. Nhiều đánh giá cao.
hofnarwillie
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.