Trong công ty của chúng tôi, chúng tôi cần xây dựng giao diện web trên nền tảng nhúng Linux. Tôi có thể thấy 2 tùy chọn: Bạn sử dụng một công nghệ trong đó HTML và JavaScript được tạo ở phía máy chủ (Think JSP, Grails, nhưng là một thứ gì đó đang sử dụng C ++ và tạo HTML / JavaScript) hoặc bạn tạo ra một 'máy khách' HTML5 ứng dụng nói chuyện với một phụ trợ tạo JSON hoặc XML.

Tôi có cảm giác rằng các ứng dụng web hiện đang có xu hướng đi sau, nhưng những lợi thế của việc này là gì (Các nhà phát triển trong dự án chọn cái trước, chủ yếu dựa trên thực tế là họ biết C ++ tốt hơn nhiều so với HTML và Javascript)

AJAX

Tôi nghĩ rằng câu hỏi của bạn sôi nổi, "Ứng dụng web của tôi nên tạo HTML ở phía máy khách hay ở phía máy chủ?" Thế hệ phía máy khách giao tiếp với máy chủ bằng AJAX, mặc dù X (XML) thường được thay thế bằng JSON, nhưng hầu hết mọi người vẫn gọi nó là AJAX vì âm thanh tốt hơn. Phía máy chủ, máy chủ chỉ tạo HTML trên máy chủ.

Tôi có nhiều kinh nghiệm với XML và hầu như không có JSON. Mọi thứ tôi biết về XML đều khiến tôi đề nghị bạn nên sử dụng JSON nếu có thể.

Ưu điểm của AJAX:

• Gửi ít dữ liệu hơn HTTP (S) để chúng có thể chạy nhanh hơn.
• Máy chủ về cơ bản là một dịch vụ web để người khác (hoặc bạn) có thể viết khách hàng của riêng họ. Điều này có thể giúp đỡ khi tạo một phiên bản di động của trang web của bạn. Ngoài ra, nhiều phát minh trở nên phổ biến vì lý do người sáng tạo của họ không bao giờ có ý định. Các dịch vụ thân thiện hơn với những người tìm kiếm cách sử dụng mới cho mã của bạn.
• Trông giống như một ứng dụng mới hơn

Nhược điểm AJAX:

• Gỡ lỗi JavaScript
• Phức tạp?
• Những thứ bạn có thể làm với JavaScript thường hoàn toàn không thể cho người mù hoặc người khuyết tật sử dụng.
• Có thể yêu cầu tổng số mã nhiều hơn (tổng dung lượng lớn hơn trên thiết bị nhúng của bạn)

Máy khách / Máy chủ

Tất cả các ứng dụng web sử dụng kiến ​​trúc máy khách-máy chủ. Giao thức HTTP buộc các ứng dụng web hành xử theo cách đó. AJAX sử dụng giải pháp cho giới hạn thiết kế đó, nhưng mô hình cơ bản của HTTP vẫn là máy khách-máy chủ. Tôi sẽ không cảm thấy lo lắng về cách tốt nhất để áp dụng MVC vào các ứng dụng web. Nếu bạn phải làm MVC vì lý do chính trị, hãy xem cách Ruby / Rails thực hiện nó. Trên thực tế, Rails là một kiến ​​trúc tuyệt vời để sao chép (hoặc sử dụng).

Dịch vụ so với ứng dụng.

Một dịch vụ tốt hầu như luôn luôn tốt hơn một ứng dụng. Nhưng làm một dịch vụ tốt thật khó! Bạn có thể cần phải tạo ứng dụng trước khi bạn có thể viết một thông số kỹ thuật được thiết kế đủ cho một dịch vụ. Đừng làm cho công việc của bạn trở nên khó khăn hơn mức cần thiết. Đối với phiên bản 1, tập trung vào việc tạo ra một ứng dụng tuyệt vời. Cho đến khi ứng dụng của bạn tương đối ổn định và bạn chắc chắn rằng nó đáp ứng yêu cầu của người dùng của bạn, có một dịch vụ có thể sẽ không làm bạn tốt chút nào. Thiết kế dịch vụ sai quá sớm là một sự lãng phí thời gian mà vẫn lãng phí khi bạn cố gắng sửa giao diện dịch vụ của mình và xử lý việc tái cấu trúc lớn cả mã máy chủ và máy khách sẽ tuân theo.

C / Web

Ồ Tôi đã làm việc tại C và hội trong 3 năm trước khi tôi chuyển sang phát triển web. Tôi không thể nghĩ ra một ngôn ngữ tồi tệ hơn để viết một ứng dụng web - đặc biệt là từ quan điểm bảo mật. Xác thực đầu vào và thoát đầu ra rất quan trọng ... Sans phát hành một danh sách các lỗi phổ biến nhất hàng năm. Bộ đệm tràn, tiêm, vấn đề chéo trang (mã hóa đầu ra không đúng) ... Tất cả các lỗi này thực sự dễ dàng thực hiện trong C hoặc lắp ráp. Ít nhất một ngôn ngữ như Java có Chuỗi miễn nhiễm với tràn và cơ chế xử lý ngoại lệ thường ngăn các lỗi khác nhau cho phép mã độc truy cập vào bộ nhớ hệ thống. Chưa kể xử lý các bộ ký tự quốc tế (sử dụng UTF-8 khi có thể).

Nếu bạn cần sử dụng C vì lý do bộ nhớ hoặc phần sụn, thì đó là những gì bạn phải làm. Chỉ cần cẩn thận!

Hỗ trợ trình duyệt

Bước đầu tiên để tạo một ứng dụng web là khám phá những trình duyệt nào sẽ được sử dụng bởi khách hàng của bạn ? W3Schools và Wikipedia đều là những nguồn thống kê tổng quát tốt, nhưng YMMV.

Hiện tôi đang làm việc ở đâu, hiện tại chúng tôi xác nhận rằng ứng dụng của chúng tôi chỉ tạo HTML chuyển tiếp XHTML 1.0 hợp lệ. Chúng tôi cũng sử dụng Doctype cụ thể và định dạng cần thiết để tránh Chế độ Quirks trong IE, điều này giúp HTML trình duyệt chéo dễ viết hơn (xem mẹo trên blog của tôi ). Chúng tôi thử nghiệm trên 3 phiên bản IE mới nhất, cộng với Firefox và Chrome trên Windows và Linux (Safari sử dụng cùng một công cụ kết xuất như Chrome). Với việc xác thực và thử nghiệm, ứng dụng của chúng tôi hoạt động khá nhiều ở mọi nơi (Windows, Mac, Linux, iPhone, Android, v.v.) ngoại trừ BlackBerry.

BlackBerry chưa bao giờ có trình duyệt thực sự với JavaScript, vì vậy chúng tôi không hỗ trợ nó. Người dùng BlackBerry đã quen với việc không có trình duyệt web thực sự, vì vậy họ không phàn nàn. Có lẽ điều đó đang thay đổi? Tôi sẽ cố gắng hỏi một vài khách hàng những trình duyệt họ đang sử dụng và đảm bảo kiểm tra với những trình duyệt đó.

Tóm lược

Tất cả các trang web được xây dựng trên HTML và HTTP. Có một tài liệu tham khảo tốt cho các công nghệ này trong tay trong khi bạn đang làm cho ứng dụng của bạn. Trong quá trình tạo một ứng dụng, ngay cả với bộ công cụ, bạn sẽ chạy qua các vấn đề đòi hỏi sự hiểu biết cơ bản về các công nghệ này để giải quyết chúng.

Có lẽ bạn cũng cần phải thoải mái với CSS và nén hình ảnh để tạo ra thứ gì đó có vẻ ổn và đáp ứng nhanh chóng. JavaScript, máy chủ web và trình duyệt là những lĩnh vực kiến ​​thức bổ sung mà cuối cùng bạn sẽ cần.

Nếu bạn xây dựng HTML của mình ở phía máy chủ, cơ sở mã của bạn có thể sẽ nhỏ hơn và bạn có thể không cần phải học JavaScript. Mô hình phía máy chủ có nghĩa là các lập trình viên của bạn sẽ viết mã (C?) Tạo HTML mà họ có thể xem trực tiếp trước khi gửi đến máy khách. Mô hình AJAX có nghĩa là các lập trình viên của bạn sẽ viết JavaScript tạo HTML. Tôi không biết nhiều công cụ để xác thực hoặc thậm chí xem mã HTML được tạo bởi JavaScript trong trình duyệt, khiến việc lập trình chính xác trở nên khó khăn hơn.

Bây giờ tôi làm việc, chúng tôi sử dụng một cách tiếp cận hỗn hợp đôi khi liên quan đến mã Java tạo JavaScript tạo HTML. Nếu các bạn chưa quen với phát triển web, đó không phải là nơi để bắt đầu. Tôi đoán tôi sẽ phải nói rằng trừ khi bạn có lý do thuyết phục để sử dụng mô hình AJAX, tôi sẽ bắt đầu với mô hình thế hệ HTML phía máy chủ cũ hơn và xem nó giúp bạn tiến xa đến đâu.

Cái sau có lợi thế là nó làm cho "back end" của bạn trở thành một "dịch vụ dữ liệu" chung chung (bất cứ điều gì có thể có nghĩa trong ngữ cảnh của bạn).

Máy khách HTML của bạn sau đó chỉ là một trong nhiều người tiêu dùng có thể của dữ liệu đó. Hãy nghĩ ứng dụng iOS, ứng dụng Andriod, ứng dụng Windows 8, API, v.v. - như những người tiêu dùng khác.

Một cách phổ biến ngày càng tăng của một ứng dụng web là sự kết hợp của cả hai, chăm sóc một hoặc một mặt khác.

Cách tiếp cận đầu tiên là truyền thống hơn, đã có ở đó trong nhiều năm và tài liệu tốt của nó, (mặc dù c ++ không phải là một ngôn ngữ phổ biến cho điều đó).

Các thứ hai lựa chọn là hiện đại hơn, và có mặt trong các blog và các diễn đàn phát triển hiện nay. Một trong những lý do cho điều đó, là nhu cầu ngày càng tăng để phục vụ cùng một ứng dụng cho các giao diện, API dịch vụ và thiết bị di động khác. Cách tiếp cận thứ hai có xu hướng hướng tới một khách hàng phong phú hơn và phản ứng nhanh hơn.

Tất cả trong tất cả, điều đó phụ thuộc vào các ràng buộc khác, như sự quen thuộc của nhóm và trường hợp kinh doanh.

Một số câu hỏi có thể giúp bạn đánh giá các lựa chọn của mình:

1. Đội có kinh nghiệm về ngôn ngữ và nền tảng không?
2. Đội ngũ có sẵn sàng tìm hiểu phương pháp và công nghệ mới không?
3. Ứng dụng có lợi dụng việc lập trình dễ dàng hơn cho các thiết bị khác không (iPhone, android, windows 8, v.v.)
4. Ứng dụng khác, nội bộ hay bên ngoài được tích hợp với các dịch vụ hoặc dữ liệu có sẵn cho ứng dụng không?

Đối với các ứng dụng "mạng nội bộ" như vậy, tôi sử dụng phương pháp tiếp cận khách hàng (JavaScript / HTML5-app + JSON) với ExtJS4.

Đối với các trang web "internet" thông thường, tôi sẽ sử dụng cách tiếp cận "cổ điển" hơn.

Các máy khách phải hiển thị trang web bằng mọi cách, vậy tại sao không tính phí cho toàn bộ quá trình và chỉ cung cấp cho chúng dữ liệu để điền vào. Nó chỉ đơn giản là mã máy chủ để tạo phản hồi (chỉ đơn giản là JSON hoặc XML), giúp tiết kiệm hiệu suất. Ngoài ra vì luôn có nhiều máy khách hơn máy chủ, toàn bộ hệ thống sẽ có quy mô tốt hơn nhiều nếu nhiều công việc được thực hiện bởi khách hàng.

Mã khách hàng được phân phối với HTTP, bạn vẫn có thể dễ dàng gửi các phiên bản mới cho người dùng mà không cần bất kỳ cơ chế cập nhật tối nghĩa nào. (Chỉ cần thay thế HMTL / JS / CSS)

Lý do duy nhất tôi muốn mở đầu một cách tiếp cận cổ điển trên các trang web bình thường, là các công cụ tìm kiếm.