Dino Esposito: Phát triển các ứng dụng web hiện đại. Phân tích các lĩnh vực chủ đề và công nghệ. Những gì bạn cần học để phát triển các ứng dụng web hiện đại
Về vấn đề này, câu hỏi là - bạn cần biết gì nữa?Trong mọi trường hợp, bạn cần có một backend, nếu tôi hiểu chính xác thì Angular, Vue và các framework khác chỉ là frontend.
Đúng vậy, ở mọi nơi bạn đến, phát triển web đều được gọi là phát triển front-end và nó chắc chắn được kết nối với Node.js (để viết thứ gì đó bằng Angular, bạn không thể làm gì nếu không có nó). Tôi không hiểu giao diện người dùng được kết nối với Node.js như thế nào, bởi vì... Node.js về cơ bản là một cách để chạy JS bên ngoài trình duyệt.
Rất có thể, bạn đang đọc các bài viết về frontend, vì trong đó không có gì về backend. Như bạn đã biết, giao diện người dùng được viết bằng JS và nhiều người bị thu hút bởi thực tế là bạn có thể cài đặt NodeJS trên phần phụ trợ và tạo các trang web bằng một ngôn ngữ. Nếu tôi muốn chạy một ứng dụng trên trình duyệt thì tại sao tôi lại cần nút ? Tất cả điều này làm tôi bối rối; tôi chỉ thấy những mâu thuẫn.
Đừng bối rối. Có những công nghệ được sử dụng trong quá trình ứng dụng và có những công nghệ được sử dụng trong quá trình phát triển ứng dụng. Tất cả Gulp, Grunt, Babel, Webpack và những thứ khác đều là công cụ phát triển. Họ tăng tốc, đơn giản hóa và cải thiện chất lượng công việc. Khi đó, jQuery, Angular, React là những thư viện và framework mà ứng dụng sẽ hoạt động.
Nếu các trang web trước đây được tạo bằng cách sử dụng một vài công nghệ thì ứng dụng hiện đại có thể sử dụng hàng chục, thậm chí hàng trăm cái sau. Hơn nữa, đây có thể là các ngôn ngữ lập trình, thư viện, khung, dịch vụ khác nhau, v.v. Tất cả điều này thường được gọi là “sở thú” công nghệ.
Ở đây tôi chỉ có thể giả định rằng máy chủ, thay vì html, nên trao đổi dữ liệu với ứng dụng thông qua json hoặc thứ gì khác.Có, JSON là phổ biến nhất. Bạn cần một khung phụ trợ để có thể triển khai API REST. Theo như tôi biết thì hầu hết các framework hiện đại những ngôn ngữ hiện đại các chương trình lập trình được sử dụng để phát triển web có thể thực hiện việc này. Tôi không thể nói chắc chắn, tôi làm việc trong cùng một ngôn ngữ. Tuy nhiên, máy chủ là nền tảng của bất kỳ ứng dụng mạng nào và trước hết bạn cần phát triển phần máy chủ.
Chắc chắn. Các ứng dụng trang đơn hiện đại (SPA) bao gồm hai phần riêng biệt - frontend và backend. Chúng có thể được tạo hoàn toàn riêng biệt bởi các nhà phát triển khác nhau, điều chính là phải thống nhất về định dạng truyền dữ liệu và tất cả các sắc thái.
Vẻ đẹp của một SPA nằm ở sự tách biệt các bộ phận này. Bất kỳ cái nào trong số chúng đều có thể được thay thế bằng cái khác mà không có bất kỳ hậu quả đặc biệt nào. Một chương trình phụ trợ có thể phục vụ các trang web, ứng dụng di động, cung cấp quyền truy cập vào dữ liệu cho bên thứ ba ứng dụng đối tác và tất cả điều này thông qua một API duy nhất.
Cần nghiên cứu thêm điều gì nữa? Hay kiến thức được liệt kê đã đủ chưa?Tôi không nghĩ thế là đủ. Bạn sẽ xác định chính xác các nhiệm vụ mà dự án của bạn phải giải quyết và lựa chọn công nghệ cho chúng. Bạn cần tập trung vào một điều, bạn sẽ không thể học mọi thứ hiện đại, sẽ không có đủ thời gian, liệu có thể không sử dụng Node.js và theo đó là npm nếu chỉ yêu cầu JS (TS) trong Trình duyệt? Đồng thời, việc kiểm tra cũng là cần thiết.
Vâng, nó khá. Về phía máy khách, ví dụ: JS+Angular. Và về phía phụ trợ, ví dụ: PHP + Laravel. Hiện nay có rất nhiều ngôn ngữ và thậm chí còn có nhiều framework hơn cho chúng. Chọn những gì dễ dàng hơn cho bạn.
Gần đây, chủ yếu là do UX và hiệu suất.
Tôi muốn trình bày 7 nguyên tắc hữu ích dành cho các trang web muốn sử dụng JavaScript để kiểm soát giao diện người dùng. Những nguyên tắc này là kết quả công việc của tôi với tư cách là một nhà thiết kế web và cũng là một người sử dụng WWW lâu năm.
JavaScript chắc chắn đã trở thành một công cụ không thể thiếu đối với các nhà phát triển front-end. Bây giờ phạm vi của nó đang mở rộng sang các lĩnh vực khác như máy chủ và vi điều khiển. Ngôn ngữ lập trình này đã được các trường đại học danh tiếng lựa chọn để dạy cho sinh viên những kiến thức cơ bản về khoa học máy tính.
Đồng thời, có một số câu hỏi liên quan đến vai trò và cách sử dụng cụ thể của nó mà nhiều người cảm thấy khó trả lời, bao gồm cả các tác giả của các framework và thư viện.
- Có nên sử dụng JavaScript để thay thế các chức năng của trình duyệt: lịch sử, điều hướng, hiển thị không?
- Phần phụ trợ có chết không? Có cần thiết phải hiển thị HTML không?
- Có đúng là Ứng dụng Trang Đơn (SPA) là tương lai không?
- JS có nên tạo các trang trên một trang web và hiển thị các trang trong ứng dụng web không?
- Tôi có nên sử dụng các kỹ thuật như PJAX hoặc TurboLinks không?
- Sự khác biệt chính xác giữa một trang web và một ứng dụng web là gì? Có nên còn lại một điều không?
Trước hết, tôi phải chỉ ra lỗi phổ biến khi tách “ứng dụng được hiển thị trên máy chủ” khỏi “ứng dụng một trang”. Nếu chúng tôi muốn đạt được trải nghiệm tốt nhất theo quan điểm của người dùng, chúng tôi không được giới hạn bản thân trong những giới hạn đó và từ bỏ một giải pháp thay thế để ủng hộ một giải pháp thay thế khác.
Những lý do khá rõ ràng. Các trang được truyền qua Internet, có những hạn chế về mặt vật lý, như Stuart Cheshire đã minh họa một cách đáng nhớ trong bài tiểu luận nổi tiếng “Đó là độ trễ, Đồ ngốc”:
Khoảng cách giữa Stanford và Boston là 4320 km.Tốc độ ánh sáng trong chân không là 300.10^6 m/s.
Tốc độ ánh sáng trong sợi quang xấp xỉ 66% tốc độ ánh sáng trong chân không.
Tốc độ ánh sáng trong sợi quang là 300 x 10^6 m/s * 0,66 = 200 x 10^6 m/s.
Độ trễ một chiều khi truyền tới Boston 4320 km / 200 x 10^6 m/s = 21,6 ms.
Độ trễ khứ hồi 43,2 ms.
Ping từ Stanford đến Boston trên Internet hiện đại là khoảng 85 ms (...)
Vì thế, thiết bị hiện đại Internet truyền tín hiệu với tốc độ gấp 0,5 lần tốc độ ánh sáng.
Kết quả 85ms được báo cáo có thể được cải thiện (và đã tốt hơn một chút), nhưng điều quan trọng là phải hiểu rằng có giới hạn vật lýđến sự chậm trễ trong việc truyền thông tin qua Internet, bất kể băng thông trên máy tính của người dùng có tăng bao nhiêu.
Điều này đặc biệt quan trọng với sự phổ biến ngày càng tăng của các ứng dụng JavaScript, thường chỉ chứa đánh dấu và một trường trống bên cạnh nó. Cái gọi là ứng dụng trang đơn (SPA) - máy chủ trả về một trang và mọi thứ khác được gọi bằng mã ở phía máy khách.
Hãy tưởng tượng một tình huống trong đó người dùng truy cập trực tiếp vào app.com/orders. Vào thời điểm ứng dụng của bạn nhận được và xử lý yêu cầu này, nó đã có một thông tin quan trọng rồi. thông tin về những gì cần được hiển thị trên trang. Ví dụ, nó có thể tải một đơn hàng từ cơ sở dữ liệu và thêm nó vào phản hồi. Nhưng hầu hết các SPA trong tình huống này đều trả về một trang trống và một thẻ. Sau đó, bạn sẽ phải trao đổi yêu cầu một lần nữa để nhận được nội dung của tập lệnh và một lần nữa để nhận được nội dung.
Phân tích cú pháp HTML được máy chủ gửi cho mỗi trang SPA
Nhiều nhà phát triển có ý thức hy sinh như vậy. Họ cố gắng đảm bảo rằng mạng bổ sung hoa bia sẽ chỉ xảy ra một lần đối với người dùng, gửi tiêu đề chính xácđể lưu vào bộ nhớ đệm trong các phản hồi bằng tập lệnh và CSS. Sự hiểu biết thông thường cho rằng đây là một thỏa thuận tốt vì khi tất cả các tệp được tải xuống máy tính, hầu hết các hành động của người dùng (như điều hướng đến các phần khác) sẽ diễn ra mà không yêu cầu các trang hoặc tập lệnh bổ sung.
Tuy nhiên, ngay cả khi tính đến bộ đệm, hiệu suất sẽ bị giảm nhất định nếu chúng ta tính đến thời gian phân tích cú pháp và thực thi tập lệnh. Trong bài viết “Có phải jQuery quá lớn đối với thiết bị di động?” nó nói rằng chỉ riêng jQuery có thể làm chậm một số trình duyệt di động trong hàng trăm mili giây.
Tệ hơn nữa, người dùng thường không nhận được bất kỳ phản hồi nào trong khi tập lệnh đang tải. Kết quả - Trang trống trên màn hình, sau đó đột nhiên chuyển thành một trang được tải đầy đủ.
Quan trọng nhất, chúng ta có xu hướng quên rằng việc truyền tải dữ liệu Internet (TCP) phổ biến nhất có khởi đầu chậm chạp. Điều này gần như chắc chắn đảm bảo rằng hầu hết các gói tập lệnh sẽ không được chuyển đi trong một lần, khiến tình trạng trên càng trở nên tồi tệ hơn.
Kết nối TCP bắt đầu bằng việc trao đổi các gói bắt tay. Nếu bạn đang sử dụng SSL, điều quan trọng để truyền tập lệnh an toàn, thì có hai trao đổi gói bổ sung (một nếu máy khách khôi phục phiên). Chỉ sau đó, máy chủ mới có thể bắt đầu gửi dữ liệu, nhưng thực tế cho thấy nó thực hiện việc này một cách chậm rãi và theo đợt.
Một cơ chế kiểm soát tắc nghẽn được gọi là Slow Start được tích hợp vào giao thức TCPđể gửi dữ liệu, tăng dần số lượng phân đoạn. Điều này có hai ý nghĩa nghiêm trọng đối với SPA:
1. Các tập lệnh lớn mất nhiều thời gian để tải hơn chúng tưởng. Như đã giải thích trong cuốn sách "Mạng trình duyệt hiệu suất cao" của Ilya Grigorik, phải mất "bốn lần trao đổi gói (...) và độ trễ hàng trăm mili giây để đạt được 64 KB trao đổi dữ liệu giữa máy khách và máy chủ." Ví dụ: trong trường hợp kết nối Internet nhanh giữa London và New York, phải mất 225 ms trước khi TCP có thể tiếp cận Kích thước tối đa bưu kiện.
2. Vì quy tắc này cũng áp dụng cho tải xuống ban đầu thì điều rất quan trọng là nội dung nào được tải sẽ được hiển thị trên trang trước tiên. Như Paul Irish kết luận trong bài thuyết trình Giao hàng của mình, 14 KB đầu tiên rất quan trọng. Điều này rõ ràng nếu bạn nhìn vào biểu đồ biểu thị khối lượng truyền giữa máy khách và máy chủ trong giai đoạn đầu thiết lập kết nối.
Máy chủ có thể gửi bao nhiêu KB ở mỗi giai đoạn kết nối, theo phân đoạn
Các trang web quản lý việc cung cấp nội dung (ngay cả đánh dấu cơ bản không có dữ liệu) trong cửa sổ này có vẻ phản hồi đặc biệt. Trong thực tế, nhiều tác giả của nhanh ứng dụng máy chủ coi JavaScript là thứ gì đó không cần thiết hoặc phải hết sức thận trọng khi sử dụng. Thái độ này càng được củng cố hơn nếu ứng dụng có cơ sở dữ liệu và phụ trợ nhanh, đồng thời các máy chủ của nó được đặt gần người dùng (CDN).
Vai trò của máy chủ trong việc tăng tốc độ trình bày nội dung phụ thuộc trực tiếp vào ứng dụng web. Giải pháp không phải lúc nào cũng tập trung vào việc "hiển thị toàn bộ trang trên máy chủ".
Trong một số trường hợp, không liên quan đến khoảnh khắc nàyĐối với người dùng, tốt hơn là loại trừ một phần của trang khỏi phản hồi ban đầu và để lại phần đó cho lần sau. Ví dụ: một số ứng dụng chỉ thích hiển thị phần "cốt lõi" của trang để đảm bảo khả năng phản hồi ngay lập tức. Sau đó, họ yêu cầu song song các phần khác nhau của trang. Điều này mang lại khả năng phản hồi tốt hơn ngay cả trong các tình huống có phần phụ trợ cũ, chậm. Đối với một số trang lựa chọn tốt Chỉ phần hiển thị của trang sẽ được hiển thị.
Vô cùng quan trọng đánh giá định tính tập lệnh và kiểu, có tính đến thông tin mà máy chủ có về phiên, ứng dụng khách và URL. Các tập lệnh sắp xếp đơn hàng rõ ràng sẽ quan trọng hơn đối với /orders so với logic trang cài đặt. Có lẽ không quá rõ ràng nhưng có sự khác biệt trong việc tải " CSS cấu trúc" và "CSS để tạo kiểu". Cái đầu tiên có thể cần thiết cho Mã JavaScript, vì thế cần thiết chặn và cái thứ hai được tải không đồng bộ.
Một ví dụ điển hình về SPA không dẫn đến việc trao đổi gói không cần thiết là bản sao khái niệm StackOverflow 4096 byte, về mặt lý thuyết có thể tải gói đầu tiên sau khi bắt tay trên kết nối TCP! Tác giả đã đạt được điều này bằng cách từ chối lưu vào bộ đệm, sử dụng nội tuyến cho tất cả tài nguyên trong phản hồi từ máy chủ. Bằng cách sử dụng tính năng đẩy máy chủ SPDY hoặc HTTP/2, về mặt lý thuyết có thể chuyển tất cả mã máy khách được lưu trong bộ nhớ đệm trong một bước nhảy. Hiện tại, việc hiển thị các phần hoặc toàn bộ trang ở phía máy chủ vẫn là cách phổ biến nhất để loại bỏ các vòng trao đổi gói không cần thiết.
SPA chứng minh khái niệm sử dụng nội tuyến cho CSS và JS để loại bỏ các vòng lặp không cần thiết
Một hệ thống khá linh hoạt phân chia kết xuất giữa trình duyệt và máy chủ, đồng thời cung cấp các công cụ để tải dần các tập lệnh và kiểu có thể làm mờ ranh giới giữa các trang web Và Ứng dụng web. Cả hai đều sử dụng URL, điều hướng và hiển thị dữ liệu cho người dùng. Ngay cả một ứng dụng bảng tính thường dựa vào chức năng phía máy khách trước tiên cũng phải hiển thị cho khách hàng thông tin cần chỉnh sửa. Và thực hiện điều này với số lần khứ hồi ít nhất là điều hết sức quan trọng.
Theo quan điểm của tôi, lỗ hổng hiệu suất lớn nhất trong nhiều hệ thống phổ biến trong thời hiện đại được giải thích bằng sự tích lũy lũy tiến của độ phức tạp trong ngăn xếp. Theo thời gian, các công nghệ như JavaScript và CSS đã được thêm vào. Sự nổi tiếng của họ cũng dần dần tăng lên. Chỉ bây giờ chúng ta mới có thể đánh giá cao cách chúng có thể được sử dụng một cách khác nhau. Chúng ta cũng đang nói về việc cải thiện các giao thức (điều này được thể hiện qua tiến độ hiện tại của SPDY và QUIC), nhưng lợi ích lớn nhất đến từ việc tối ưu hóa ứng dụng.
Có thể hữu ích nếu nhớ lại một số cuộc thảo luận lịch sử xung quanh thiết kế. phiên bản trước HTML và WWW. Ví dụ: danh sách gửi thư từ năm 1997 này gợi ý thêm thẻ trong HTML. Marc Andreessen nhắc lại tầm quan trọng của việc cung cấp thông tin nhanh chóng:
Nhiệm vụ của chúng tôi là gia tốc tối đa phản ứng với hành động của người dùng. Cho dù chúng ta có nỗ lực bao nhiêu để giảm số bước nhảy khi làm việc với một ứng dụng web thì vẫn có những thứ nằm ngoài tầm kiểm soát của chúng ta. Đây là giới hạn lý thuyết về tốc độ ánh sáng và ping tối thiểu giữa máy khách và máy chủ.
Một yếu tố quan trọng là chất lượng liên lạc không thể đoán trước giữa máy khách và máy chủ. Nếu chất lượng kết nối kém thì các gói sẽ được truyền lại. Khi nội dung cần tải trong một vài lượt khứ hồi, bạn có thể cần nhiều hơn thế.
Đây là lợi ích chính của JavaScript trong việc cải thiện UX. Nếu giao diện được viết kịch bản ở phía máy khách, chúng ta có thể ẩn độ trễ của mạng. Chúng ta có thể tạo ấn tượng tốc độ cao. Chúng ta có thể đạt được độ trễ bằng không một cách giả tạo.
Hãy giả sử một lần nữa rằng đây là HTML đơn giản. Các tài liệu được kết nối bằng siêu liên kết hoặc thẻ . Nếu bạn nhấp vào bất kỳ trong số chúng, trình duyệt sẽ thực hiện một yêu cầu mạng, quá trình này sẽ mất một thời gian dài không thể đoán trước, sau đó nhận và xử lý dữ liệu nhận được và cuối cùng chuyển sang trạng thái mới.
JavaScript cho phép bạn phản hồi ngay lập tức và lạc quan với hành động của người dùng. Nhấp vào liên kết hoặc nút sẽ nhận được phản hồi ngay lập tức mà không cần phải truy cập Internet. Một ví dụ nổi tiếng là giao diện Gmail (hoặc Hộp thư đến của Google), trong đó việc lưu trữ thư email diễn ra ngay lập tức, trong khi yêu cầu tương ứng tới máy chủ được gửi và xử lý không đồng bộ.
Trong trường hợp biểu mẫu, thay vì đợi một số mã HTML phản hồi để điền vào biểu mẫu, chúng tôi có thể phản hồi ngay lập tức ngay khi người dùng nhấn “Enter”. Hoặc thậm chí tốt hơn, giống như tìm kiếm của Google, chúng ta có thể phản ứng sớm hơn bằng cách chuẩn bị trước đánh dấu cho một trang mới.
Hành vi này là một ví dụ về những gì tôi gọi thích ứng đánh dấu. Ý tưởng cơ bản là trang "biết" đánh dấu trong tương lai của nó, vì vậy nó có thể chuyển sang đánh dấu đó khi chưa có dữ liệu để chỉ ra. Đây là hành vi "lạc quan" vì vẫn có nguy cơ dữ liệu sẽ không bao giờ đến và sẽ phải báo cáo thông báo lỗi, nhưng điều này rõ ràng là rất hiếm.
Trang chủ của Google là một ví dụ điển hình vì nó thể hiện rất rõ ràng hai nguyên tắc đầu tiên trong bài viết của chúng tôi.
Vào cuối năm 2004, Google đã trở thành công ty tiên phong trong sử dụng JavaScriptđể cung cấp gợi ý theo thời gian thực trong khi gõ truy vấn tìm kiếm(thật thú vị là nhân viên này đã phát triển chức năng này trong 20% thời gian rảnh rỗi từ công việc chính của mình, giống như Gmail). Điều này thậm chí còn trở thành cơ sở cho sự xuất hiện của Ajax:
Nhìn vào Google Đề xuất. Xem cụm từ tìm kiếm của bạn cập nhật khi bạn nhập, gần như ngay lập tức... mà không làm chậm quá trình tải lại trang. Google Đề xuất và bản đồ Google là hai ví dụ về cách tiếp cận mới để tạo ứng dụng web mà chúng tôi tại Adaptive Path gọi là “Ajax”Và vào năm 2010, họ đã giới thiệu Tìm kiếm tức thì, trong đó JS đóng vai trò trung tâm, loại bỏ hoàn toàn việc làm mới trang thủ công và chuyển sang đánh dấu “kết quả tìm kiếm” trong lần nhấn phím đầu tiên, như trong hình minh họa ở trên.
Một ví dụ nổi bật khác về việc thích ứng với đánh dấu có thể nằm trong túi của bạn. Ngay từ những ngày đầu tiên, hệ điều hành iPhone đã yêu cầu tác giả ứng dụng cung cấp hình ảnh mặc định.png, có thể được hiển thị ngay lập tức trên màn hình trong khi ứng dụng đang tải.
Hệ điều hành iPhone buộc default.png tải trước khi khởi chạy ứng dụng
Một loại hành động khác ngoài nhấp chuột và gửi biểu mẫu sẽ cải thiện đáng kể với sử dụng JavaScript, là kết xuất tải tập tin.
Chúng tôi có thể ghi lại nỗ lực tải xuống tệp của người dùng những cách khác: kéo-n-thả, dán từ clipboard, chọn tập tin. Sau đó, nhờ các API HTML5 mới, chúng tôi có thể hiển thị nội dung như thể nó đã được tải xuống. Một ví dụ về loại giao diện này là công việc của chúng tôi với các bản tải xuống trong Cloudup. Lưu ý cách hình thu nhỏ của hình ảnh được tạo và hiển thị ngay lập tức:
Hình ảnh được hiển thị và hiển thị cho đến khi tải xong
Trong tất cả các trường hợp này, chúng tôi cải thiện nhận thức tốc độ. May mắn thay, có rất nhiều bằng chứng cho thấy tính hữu ích của phương pháp này. Hãy lấy ít nhất một ví dụ về cách tăng khoảng cách đến băng chuyền hành lý tại sân bay Houston giảm số khiếu nại về hành lý thất lạc mà không cần phải giải quyết nhanh hành lý.
Ý tưởng này sẽ tác động nghiêm trọng đến giao diện người dùng của các ứng dụng của chúng tôi. Tôi tin rằng các chỉ báo tải sẽ trở nên hiếm hoi, đặc biệt khi chúng ta chuyển sang các ứng dụng thông tin thời gian thực, được mô tả trong phần tiếp theo.
Có những tình huống ảo tưởng về hành động tức thời thực sự có tác động bất lợi đến UX. Đây có thể là một hình thức thanh toán hoặc kết thúc một phiên trên trang web. Bằng cách áp dụng cách tiếp cận lạc quan ở đây, trên thực tế là đánh lừa người dùng, chúng ta có nguy cơ chọc tức anh ta.
Nhưng ngay cả trong những trường hợp này, việc hiển thị vòng quay hoặc chỉ báo tải trên màn hình vẫn phải dừng. Chúng chỉ được hiển thị sau khi người dùng cho rằng phản hồi không ngay lập tức. Theo một nghiên cứu thường được trích dẫn của Nielsen:
Lời khuyên cơ bản về thời gian phản hồi vẫn được giữ nguyên trong suốt ba mươi năm Miller 1968; Thẻ và cộng sự. 1991:*0,1 giây là giới hạn để người dùng cảm nhận được phản hồi ngay lập tức, không cần hiển thị ở đây thông tin thêm, ngoại trừ kết quả của hoạt động.
* 1,0 giây là giới hạn về khả năng suy nghĩ liên tục của người dùng, mặc dù anh ta sẽ nhận thấy sự chậm trễ. Thông thường, không cần chỉ báo bổ sung đối với độ trễ lớn hơn 0,1 giây nhưng nhỏ hơn 1,0 giây, nhưng người dùng sẽ mất cảm giác đang làm việc trực tiếp với dữ liệu.
* 10 giây là giới hạn để giữ sự chú ý của người dùng vào cuộc đối thoại. Tại độ trễ lâu hơn người dùng sẽ muốn thực hiện một tác vụ khác trong khi chờ phản hồi từ máy tính.
Rất tiếc, các kỹ thuật như PJAX hoặc TurboLinks lại thiếu hầu hết các tính năng được mô tả trong phần này. Mã phía máy khách không “biết” về trạng thái tương lai của trang cho đến khi quá trình trao đổi dữ liệu với máy chủ diễn ra.3. Phản hồi với các thay đổi dữ liệu;DR: Khi dữ liệu được cập nhật trên máy chủ, máy khách sẽ được thông báo ngay lập tức. Đây là một hình thức cải thiện năng suất mà người dùng không phải hành động bổ sung(nhấn F5, làm mới trang). Các vấn đề mới: (lại) quản lý kết nối, khôi phục trạng thái.
Nguyên tắc thứ ba liên quan đến phản hồi của UI đối với những thay đổi về dữ liệu tại nguồn, thường là một hoặc nhiều máy chủ cơ sở dữ liệu.
Mô hình truyền tải đang trở thành quá khứ. dữ liệu HTML, vẫn ở trạng thái tĩnh cho đến khi người dùng làm mới trang (trang web truyền thống) hoặc tương tác với trang đó (Ajax).
Giao diện người dùng của bạn sẽ tự động cập nhật.
Điều này rất quan trọng trong một thế giới với luồng thông tin ngày càng tăng từ nguồn khác nhau, bao gồm đồng hồ, điện thoại, máy tính bảng và thiết bị đeo trong tương lai.
Hãy tưởng tượng Facebook News Feed ngay sau khi được giới thiệu, khi thông tin được đăng tải chủ yếu từ máy tính cá nhân của người dùng. Hiển thị tĩnh không phải là tối ưu nhưng nó có ý nghĩa đối với những người làm mới nguồn cấp dữ liệu của họ, chẳng hạn như mỗi ngày một lần.
Giờ đây chúng ta đang sống trong một thế giới nơi bạn tải ảnh lên và gần như ngay lập tức nhận được lượt thích cũng như bình luận từ bạn bè và người quen. Nhu cầu phản hồi tức thì đã trở thành một điều tất yếu trong môi trường cạnh tranh của các ứng dụng khác.
Tuy nhiên, sẽ là sai lầm khi cho rằng lợi ích của việc cập nhật giao diện người dùng tức thời chỉ giới hạn ở các ứng dụng nhiều người dùng. Đó là lý do tại sao tôi thích nói về điểm dữ liệu đã thống nhất, thay vì người dùng. Hãy lấy một tình huống điển hình để đồng bộ hóa ảnh giữa điện thoại và máy tính xách tay của bạn:
Ứng dụng một người dùng cũng có thể được hưởng lợi từ khả năng phản ứng.
Hữu ích để tưởng tượng tất cả thông tin được gửi đến người dùng dưới dạng "phản ứng". Đồng bộ hóa phiên và trạng thái ủy quyền là một ví dụ về cách tiếp cận phổ quát. Nếu người dùng ứng dụng của bạn mở nhiều tab cùng lúc thì việc kết thúc phiên làm việc trên một trong số đó sẽ ngay lập tức hủy kích hoạt ủy quyền đối với tất cả những tab khác. Điều này tất yếu dẫn tới việc cải thiện tính an toàn và bảo vệ tốt hơn thông tin bí mật, đặc biệt trong trường hợp nhiều người có quyền truy cập vào cùng một thiết bị.
Mỗi trang phản ứng với trạng thái phiên và trạng thái ủy quyền
Khi bạn đã thiết lập quy tắc rằng thông tin trên màn hình sẽ tự động cập nhật, điều quan trọng là phải thực hiện theo. nhiệm vụ mới: Phục hồi trạng thái.
Khi gửi yêu cầu và nhận các bản cập nhật nguyên tử, bạn rất dễ quên rằng ứng dụng của mình sẽ cập nhật bình thường ngay cả sau một thời gian dài không hoạt động. Hãy tưởng tượng bạn đóng nắp máy tính xách tay lại và mở nó ra vài ngày sau đó. Ứng dụng sẽ hoạt động như thế nào?
Ví dụ về điều gì sẽ xảy ra nếu kết nối không được cập nhật chính xác
Khả năng kết nối lại của ứng dụng thường tương tác với nguyên tắc số 1. Nếu chọn gửi dữ liệu trong lần tải trang đầu tiên, bạn cũng phải xem xét thời gian trôi qua trước khi tải tập lệnh. Thời gian này về cơ bản tương đương với thời gian ngắt kết nối, vì vậy kết nối ban đầu của tập lệnh của bạn là việc nối lại phiên.
4. Kiểm soát việc trao đổi dữ liệu với máy chủ tl;DR: Bây giờ chúng ta có thể tinh chỉnh việc trao đổi dữ liệu với máy chủ. Đảm bảo xử lý lỗi, yêu cầu lặp lại có lợi cho khách hàng, đồng bộ hóa dữ liệu trong lý lịch và lưu bộ nhớ đệm ngoại tuyến.Khi web ra đời, giao tiếp giữa máy khách và máy chủ bị hạn chế theo một số cách:
Những hạn chế chính liên quan đến điểm thứ hai. Không thể gửi dữ liệu mà không nhất thiết phải tải trang mới là một bất lợi từ góc độ hiệu suất. Nhưng điều quan trọng nhất là nó đã hỏng hoàn toàn nút "Quay lại":
Có lẽ là tạo tác khó chịu nhất của trang web cũ
Đây là lý do tại sao web với tư cách là một nền tảng ứng dụng vẫn chưa hoàn thiện nếu không có JavaScript. Ajax thể hiện một bước nhảy vọt lớn về mặt dễ dàng xuất bản cho người dùng.
Hiện tại, chúng tôi có nhiều API (XMLHttpRequest, WebSocket, EventSource, chỉ kể tên một số API) cung cấp khả năng kiểm soát đầy đủ và chính xác đối với luồng dữ liệu. Ngoài khả năng xuất bản dữ liệu người dùng thông qua biểu mẫu, chúng tôi còn có những cơ hội mới để cải thiện trải nghiệm người dùng.
Liên quan trực tiếp tới nguyên tắc trước đó có một buổi biểu diễn tình trạng kết nối. Nếu chúng tôi mong đợi dữ liệu được cập nhật tự động, chúng tôi phải thông báo cho người dùng thông tin thực tế mất kết nối Và cố gắng khôi phục nó.
Khi phát hiện thấy ngắt kết nối, việc lưu trữ dữ liệu vào bộ nhớ (hoặc tốt hơn là trong localStorage) để có thể gửi sau sẽ rất hữu ích. Điều này đặc biệt quan trọng trong bối cảnh sử dụng ServiceWorker trong tương lai, cho phép Ứng dụng JavaScript công việc trong nền. Nếu ứng dụng của bạn không mở, bạn vẫn có thể tiếp tục thử đồng bộ hóa dữ liệu với máy chủ ở chế độ nền.
Xem xét khả năng hết thời gian chờ và lỗi khi gửi dữ liệu; những tình huống như vậy cần được giải quyết có lợi cho khách hàng. Nếu kết nối được khôi phục, hãy thử gửi lại dữ liệu. Khi lỗi vĩnh viễn, thông báo cho người dùng về điều này.
Một số lỗi cần được xử lý đặc biệt cẩn thận. Ví dụ: lỗi 403 không mong muốn có thể có nghĩa là phiên của người dùng đã bị vô hiệu. Trong những trường hợp như vậy, có thể khôi phục phiên bằng cách hiển thị cho người dùng cửa sổ để nhập thông tin đăng nhập và mật khẩu.
Điều quan trọng nữa là phải đảm bảo rằng người dùng không vô tình làm gián đoạn luồng dữ liệu. Điều này có thể xảy ra trong hai tình huống. Trường hợp đầu tiên và rõ ràng nhất là đóng trình duyệt hoặc tab, đây là điều chúng tôi đang cố gắng ngăn chặn bằng trình xử lý beforeunload.
Cảnh báo trước khi dỡ tải
Một trường hợp khác (và ít rõ ràng hơn) là khi bạn cố gắng điều hướng đến một trang khác, chẳng hạn bằng cách nhấp vào một liên kết. Trong trường hợp này, ứng dụng có thể ngăn người dùng sử dụng các phương pháp khác theo quyết định của nhà phát triển.
5. Đừng phá vỡ lịch sử, hãy cải thiện nó tl;DR: Nếu trình duyệt không quản lý URL và lịch sử, chúng ta sẽ gặp vấn đề mới. Đảm bảo bạn đáp ứng hành vi cuộn mong đợi. Lưu bộ nhớ đệm của riêng bạn để có phản hồi nhanh.Không cần gửi biểu mẫu, chỉ sử dụng siêu liên kết trong ứng dụng web sẽ cung cấp cho chúng tôi điều hướng Tiến/Quay lại đầy đủ chức năng trong trình duyệt.
Ví dụ: một trang "vô tận" điển hình thường được tạo bằng nút JavaScript yêu cầu dữ liệu/HTML bổ sung và chèn nó. Thật không may, ít người nhớ gọi history.pushState hoặc thay thếState như một bước bắt buộc.
Đó là lý do tại sao tôi dùng từ "phá vỡ". Với mô hình đơn giản của web gốc, tình huống này là không thể xảy ra. Mỗi thay đổi trạng thái đều dựa trên sự thay đổi URL.
Nhưng cũng có mặt sau huy chương - cơ hội cải thiện lịch sử lướt web mà hiện chúng tôi kiểm soát bằng JavaScript.
Một khả năng như vậy được Daniel Pipius gọi là Fast Back:
Nút quay lại sẽ hoạt động nhanh chóng; người dùng không mong đợi quá nhiều thay đổi dữ liệu.Nó giống như coi nút quay lại như một nút trong ứng dụng web và áp dụng nguyên tắc số 2 cho nó: phản hồi ngay lập tức với hành động của người dùng. Điều chính là bạn có cơ hội quyết định cách tổ chức bộ nhớ đệm trang trước và ngay lập tức hiển thị nó trên màn hình. Sau đó, bạn có thể áp dụng nguyên tắc số 3 và thông báo cho người dùng khi có dữ liệu mới trên trang đó.
Vẫn có một số trường hợp bạn không thể kiểm soát được hành vi của bộ nhớ đệm. Ví dụ: nếu bạn hiển thị một trang, sau đó truy cập trang web của bên thứ ba và sau đó người dùng nhấp vào “Quay lại”. Các ứng dụng hiển thị HTML ở phía máy chủ và sau đó sửa đổi nó ở phía máy khách đặc biệt dễ mắc phải lỗi nhỏ này:
Hoạt động không chính xác của nút "Quay lại"
Một cách khác để phá vỡ điều hướng là bỏ qua bộ nhớ trạng thái cuộn. Một lần nữa, các trang không sử dụng JS và quản lý lịch sử thủ công có thể sẽ không gặp vấn đề gì ở đây. Nhưng sẽ có các trang động. Tôi đã thử nghiệm hai nguồn cấp tin tức phổ biến nhất trên Dựa trên JavaScript trên Internet: Twitter và Facebook. Cả hai đều mắc chứng mất trí nhớ cuộn.
Lật trang liên tục thường là dấu hiệu của chứng mất trí nhớ khi cuộn trang
Sau cùng, hãy cảnh giác với những thay đổi trạng thái chỉ liên quan khi xem lịch sử. Ví dụ, trường hợp này với việc thay đổi trạng thái của cây con bằng các nhận xét.
Việc thay đổi loại bình luận phải được lưu vào lịch sử
Nếu trang được hiển thị lại sau khi nhấp vào liên kết trong ứng dụng, người dùng có thể mong đợi tất cả nhận xét sẽ được mở rộng. Khi trạng thái thay đổi phải được lưu vào lịch sử.
6. Cập nhật mã qua tin nhắn đẩystl;DR: Chỉ gửi dữ liệu qua tin nhắn đẩy là chưa đủ, bạn còn cần có mã. Tránh lỗi API và cải thiện hiệu suất. Sử dụng DOM không trạng thái để thiết kế lại ứng dụng của bạn một cách dễ dàng.Điều cực kỳ quan trọng là ứng dụng của bạn phản hồi lại những thay đổi trong mã.
Thứ nhất, nó làm giảm số lượng lỗi có thể xảy ra và tăng độ tin cậy. Nếu bạn đã thực hiện một thay đổi quan trọng đối với API phụ trợ thì phải cập nhật mã chương trình máy khách. Nếu không, khách hàng có thể không chấp nhận dữ liệu mới hoặc có thể gửi dữ liệu ở định dạng không tương thích.
Một lý do quan trọng không kém là phải tuân thủ nguyên tắc số 3. Nếu giao diện của bạn tự cập nhật thì có rất ít lý do để người dùng phải tải lại trang theo cách thủ công.
Hãy nhớ rằng đối với một trang web thông thường, việc làm mới trang sẽ kích hoạt hai việc: tải lại dữ liệu và tải lại mã. Việc tổ chức một hệ thống với các bản cập nhật dữ liệu đẩy mà không cập nhật mã đẩy là chưa đầy đủ, đặc biệt là trong thế giới mà một tab (phiên) có thể vẫn mở trong thời gian rất dài. trong một khoảng thời gian dài.
Nếu kênh đẩy máy chủ đang hoạt động thì người dùng có thể được thông báo về tính khả dụng của mã mới. Nếu không, số phiên bản có thể được thêm vào tiêu đề của các yêu cầu HTTP gửi đi. Máy chủ có thể so sánh nó với phiên bản mới nhất đã biết, đồng ý xử lý yêu cầu hay không và đưa ra công việc cho khách hàng.
Sau đó, một số ứng dụng web thay mặt người dùng buộc phải tải lại trang. Ví dụ: nếu trang không nằm trong vùng hiển thị của màn hình và không có biểu mẫu điền nào để nhập.
Một cách tiếp cận tốt hơn nữa là trao đổi nóng mã. Điều này có nghĩa là bạn không cần phải thực hiện khởi động lại hoàn toàn trang. Thay vào đó, nhất định mô-đunđược thay thế nhanh chóng và mã của chúng được gửi lại để thực thi.
Trong nhiều ứng dụng hiện có Việc trao đổi mã nóng khá khó khăn. Để làm điều này, ban đầu bạn phải tuân thủ một kiến trúc tách biệt hành vi(mã) từ dữ liệu(tình trạng). Bộ phận này sẽ cho phép chúng tôi tung ra nhiều bản vá khác nhau khá nhanh chóng.
Ví dụ: trong ứng dụng web của chúng tôi có một mô-đun thiết lập bus để truyền các sự kiện (như socket.io). Khi một sự kiện xảy ra, trạng thái của một thành phần cụ thể sẽ thay đổi và điều này được phản ánh trong DOM. Sau đó, bạn thay đổi hành vi của thành phần đó, chẳng hạn để nó tạo ra đánh dấu DOM khác nhau cho trạng thái hiện tại và trạng thái mới.
Lý tưởng nhất là chúng ta có thể thay đổi mã theo mô-đun. Ví dụ: sẽ không cần thiết lập lại kết nối với ổ cắm nếu có thể chỉ cần cập nhật mã của thành phần được yêu cầu. Do đó, kiến trúc lý tưởng cho việc cập nhật mã đẩy là mô-đun.
Nhưng vấn đề ngay lập tức nảy sinh là làm thế nào để đánh giá các mô-đun mà không có tác dụng phụ không mong muốn. Kiến trúc giống như kiến trúc do React cung cấp là phù hợp nhất ở đây. Nếu mã của một thành phần được cập nhật, logic của nó có thể được thực thi lại một cách đơn giản và DOM được cập nhật. Đọc lời giải thích của Dan Abramov về khái niệm này.
Về cơ bản, ý tưởng là bạn cập nhật DOM (hoặc đổi màu nó), điều này giúp ích rất nhiều cho việc thay thế mã. Nếu trạng thái được lưu trữ trong DOM hoặc trình xử lý sự kiện được ứng dụng cài đặt thì việc cập nhật mã có thể trở thành một nhiệm vụ khó khăn hơn nhiều.
7. Dự đoán hành vi tl;DR: Độ trễ âm.Một ứng dụng JavaScript hiện đại có thể có cơ chế dự đoán hành động của người dùng.
Ứng dụng rõ ràng nhất của ý tưởng này là tải trước dữ liệu từ máy chủ trước khi người dùng yêu cầu. Tải một trang web với con trỏ chuột di chuột qua nó để nhấp vào liên kết sẽ hiển thị nó ngay lập tức là một ví dụ đơn giản.
Một phương pháp giám sát theo dõi chuột tiên tiến hơn một chút sẽ phân tích quỹ đạo của chuột để phát hiện các "va chạm" trong tương lai với các yếu tố tương tác như nút. :
Plugin jQuery dự đoán đường dẫn chuột
Các trang siêu liên kết là những khối xây dựng tốt cho bất kỳ ứng dụng nào. Việc tải dần dần mã, kiểu và đánh dấu khi người dùng tương tác sẽ đảm bảo hiệu suất tuyệt vời mà không làm mất đi tính tương tác.
Các tính năng độc đáo mới được cung cấp bởi JavaScript. Nếu những công nghệ này được sử dụng rộng rãi, chúng sẽ mang lại trải nghiệm tốt nhất cho người dùng trên nền tảng tự do nhất hiện có - WWW.
Thẻ:
- độ trễ
- hiệu suất
- PJAX
- TurboLinks
CÔNG CỤ HIỆN ĐẠI ĐỂ PHÁT TRIỂN TRANG INTERNET VÀ ỨNG DỤNG WEB
Krupina Tatyana Aleksandrovna 1, Shcherbakova Svetlana Mikhailovna 1
1 Sư phạm Mátxcơva Đại học bang, sinh viên thạc sĩ
chú thích
Bài viết này được dành riêng để xem xét phương tiện hiện đại phát triển các trang web Internet và các ứng dụng Web. Các vấn đề về dạy học sinh và học sinh những công nghệ này cũng được thảo luận.
CÔNG CỤ PHÁT TRIỂN HIỆN ĐẠI TRANG WEB VÀ ỨNG DỤNG TRỰC TUYẾN
Krupina Tatiana Aleksandrovna 1 , Shcherbakova Svetlana Mikhajlovna 1
1 Đại học Sư phạm quốc gia Moscow, Tốt nghiệp khoa Toán ứng dụng và CNTT
trừu tượng
Bài viết này cung cấp một cái nhìn tổng quan về sự phát triển của các trang web hiện đại và các ứng dụng dựa trên Web. Nó cũng thảo luận về vấn đề đào tạo sinh viên và học sinh về các công nghệ này.
Thông tin hóa của xã hội hiện đại gắn liền với sự ra đời của các phương tiện và phương pháp thông tin và Công nghệ truyền thông(ICT) ở khu vực khác nhau hoạt động của con người. Một vai trò đặc biệt trong quá trình này chắc chắn thuộc về sự phát triển của công nghệ mạng và truyền thông, trong số những thứ khác, thể hiện ở việc tạo ra các hệ thống tự động hóa của công ty. hệ thông thông tin và các dự án mạng lưới thương mại điện tử. Thật vậy, hoạt động của bất kỳ doanh nghiệp hiện đại, bằng cách này hay cách khác, có liên quan đến việc tạo và duy trì một trang web của công ty.
Các Tiêu chuẩn Giáo dục Hiện đại của Tiểu bang Liên bang (FSES) trong nhiều lĩnh vực không chỉ kỹ thuật mà cả nhân đạo cũng yêu cầu sinh viên tốt nghiệp phải có kỹ năng phát triển và quản lý các trang Internet.
Các phương pháp và công cụ để phát triển các trang Internet và ứng dụng Web đang phát triển năng động từ khả năng tạo các trang danh thiếp đơn giản đến phát triển các ứng dụng máy chủ xử lý và lưu trữ lượng lớn dữ liệu.
Để phát triển một trang web đơn giản, bao gồm trang web danh thiếp có mô tả và thông tin liên hệ, bạn có thể sử dụng các phương pháp khác nhau:
- Sự sáng tạo tài liệu HTML, I E. sử dụng trình soạn thảo Notepad, nhập mã vào ngôn ngữ HTML V. chế độ thủ công và triển khai nó bằng trình duyệt trên máy trạm khách, sau đó xuất bản nó với nhà cung cấp bằng cách sử dụng các dịch vụ lưu trữ của họ;
- tạo cùng một tài liệu HTML bằng cách sử dụng Trình chỉnh sửa Adobe Dreamweaver, tận dụng nhiều tính năng và tiện ích;
- sử dụng các trang web shell được tạo sẵn để phát triển các trang web thuộc nhiều lĩnh vực và thiết kế theo chủ đề khác nhau, đồng thời xuất bản trang này trên Internet bằng cách sử dụng các dịch vụ lưu trữ miễn phí hoặc trả phí.
Không giống như việc phát triển các trang web đơn giản và không tương tác, để phát triển các ứng dụng Web chạy và xử lý dữ liệu trên máy chủ, cần có các phương pháp và công cụ bổ sung cho những phương pháp và công cụ đã nêu trong đoạn trước. Việc phát triển các ứng dụng Web bao gồm, ngoài việc tạo mã HTML, việc lập trình bằng một ngôn ngữ đặc biệt. Ngôn ngữ được sử dụng để phát triển các ứng dụng Web là Lập trình PHP, và cũng không thể làm gì nếu không có, ví dụ, Máy chủ cục bộ Cơ sở dữ liệu Apache và MySQL.
Hãy cùng xem thêm một số công cụ lập trình ứng dụng Web:
- ngôn ngữ Lập trình JavaScriptđược sử dụng để tạo các tài liệu HTML tương tác;
- VBScript được sử dụng để tạo tập lệnh máy khách cũng như tập lệnh máy chủ;
- Perl được sử dụng để phát triển công cụ quản trị hệ thống, cũng như trong việc phát triển các kịch bản CGI, các hệ thống xử lý tự động E-mail và hỗ trợ trang web.
Để phát triển độc lập các ứng dụng Web, bạn có thể sử dụng tài nguyên Denwer được phân phối miễn phí.
Denwer (từ viết tắt DNVR - nhóm các nhà phát triển Web dành cho quý ông) là một tập hợp các bản phân phối và vỏ phần mềm được thiết kế để tạo và gỡ lỗi các ứng dụng Web cũng như nội dung động khác của các trang Web trên PC chạy HĐH.
Bộ Denwer bao gồm:
- địa phương máy chủ Apacheđể chạy các ứng dụng trên máy tính của người dùng, mô phỏng chức năng máy chủ nơi nhà cung cấp sau đó sẽ cài đặt ứng dụng đã phát triển. Apache là phần mềm– đa nền tảng, được phân phối và hỗ trợ miễn phí bởi nhiều hệ điều hành khác nhau;
- Hệ thống lập trình PHP là ngôn ngữ giống C để phát triển mã chương trình được nhúng trong mã HTML của một trang web và được thực thi trên máy chủ nhằm mục đích xử lý dữ liệu nhận được từ người dùng của một trang web cụ thể. PHP (Bộ tiền xử lý siêu văn bản, ban đầu là Công cụ trang chủ cá nhân) là một ngôn ngữ kịch bản mục đích chung, được sử dụng để phát triển các ứng dụng Web, được Rasmus Lerdorf tạo ra vào năm 1994;
- MySQL là phần mềm có sẵn miễn phí để xử lý cơ sở dữ liệu, kể cả khi làm việc với dữ liệu nhận được từ trình duyệt máy khách. MySQL (Ngôn ngữ truy vấn có cấu trúc) được tạo ra bởi Michael Widenius của công ty TcX của Thụy Điển vào năm 1995.
Bộ phần mềm Denwer hoặc các thành phần riêng lẻ của nó được cả người nghiệp dư lẫn chuyên gia sử dụng rộng rãi để tạo và gỡ lỗi các ứng dụng và trang web. Bộ này cũng được sử dụng rộng rãi cho mục đích giáo dục để dạy lập trình Web cho học sinh, sinh viên.
Phát triển ứng dụng web là gì?
Phát triển ứng dụng web là thuật ngữ chung cho quá trình tạo ra các trang web hay website. Các trang web được tạo bằng HTML, CSS và JavaScript. Những trang này có thể chứa văn bản và đồ họa đơn giản, giống như một tài liệu tĩnh. Các trang cũng có thể tương tác hoặc hiển thị thông tin thay đổi. Tạo nên trang tương tác phức tạp hơn một chút nhưng chúng cho phép bạn tạo các trang web có nội dung phong phú. Ngày nay, hầu hết các trang đều có tính tương tác và cung cấp các dịch vụ tương tác nâng cao như giỏ hàng trực tuyến, trực quan hóa động và thậm chí cả mạng xã hội phức tạp.
Phát triển ứng dụng cho máy tính hiện đại thực hiện bằng các ngôn ngữ lập trình chuyên dụng. Những tài liệu giới thiệu này sẽ giúp bạn làm quen với chúng.
Video | 15 phút | Ngôn ngữ lập trình
Báo cáo này nói về lý do tại sao cần có ngôn ngữ lập trình, chúng là gì và mục đích của chúng là gì. Ngôn ngữ đánh dấu (HTML), biểu diễn dữ liệu (XML) và ngôn ngữ truy vấn (SQL) cũng được đề cập ngắn gọn.
Video | 23 phút | Ngôn ngữ lập trình
Báo cáo này cung cấp một cái nhìn tổng quan ngắn gọn về ngôn ngữ lập trình C#, các tính năng và thiết kế chính của nó, đồng thời trình bày các ví dụ về cách tạo các ứng dụng cửa sổ và bảng điều khiển đơn giản cho Windows trong Visual Studio 2010.
Khám phá khả năng phong phú của phòng mổ Hệ thống Windows, có thể và nên được sử dụng khi phát triển ứng dụng web.
| 4 | công cụ phát triển |
Video | 10 phút | WebMa trận
Truyện ngắn về WebMatrix - môi trường phát triển website. WebMatrix cho phép bạn tạo các trang web có độ phức tạp khác nhau: từ trang chủđến nhỏ cổng thông tin doanh nghiệp. Môi trường bao gồm một tập hợp các mẫu trang web có thể được sử dụng làm cơ sở để tạo trang web của riêng bạn. WebMatrix cho phép bạn tạo và chỉnh sửa mã và đánh dấu trang web, cũng như quản lý cơ sở dữ liệu và xuất bản các trang web tạo sẵn lên dịch vụ lưu trữ.
Video | 11 phút | trình duyệt web IE
Bài nói chuyện này cung cấp tổng quan ngắn gọn về công nghệ Trang web được ghim được giới thiệu trong Internet Explorer 9. Trình bày cách làm việc với Danh sách nhảy, Biểu tượng lớp phủ và Nút thanh công cụ hình thu nhỏ.
Các tài nguyên dưới đây sẽ giúp bạn đạt được các kỹ năng bổ sung trong lĩnh vực bạn quan tâm.
