Mặc dù, theo ý kiến cá nhân của tôi, bối cảnh phát triển web đã chậm lại trong một vài năm [2016 - 2021], nhưng nó đã bắt đầu đạt được nhiều sức hút vào năm ngoái [cũng xem State of JS nơi lấy các hình ảnh cho bài viết này]. Trong bài viết này, tôi muốn chỉ ra các xu hướng phát triển web mới mà tôi đã thấy, đó chắc chắn là những xu hướng mà tôi mong đợi sẽ tiếp tục thu hút sự quan tâm của các nhà phát triển web và là xu hướng mà tôi rất hào hứng trong năm tới. Hãy đi thẳng vào chúng
[Siêu] Khung
Các ứng dụng một trang [SPA] và các khung tương ứng của chúng [e. g. Phản ứng. js, vue. js, Mảnh dẻ. js] đã trải qua ít nhiều chu kỳ cường điệu hóa và đã tồn tại được nhiều năm rồi. Tuy nhiên, với sự gia tăng của các khung meta trên các giải pháp này, chúng ta có thể thấy xu hướng rõ ràng với các ứng dụng chuyển từ kết xuất phía máy khách [CSR] sang kết xuất phía máy chủ [SSR]. SSR ở khắp mọi nơi khi làm việc với các khung JavaScript ngày nay
Khung meta phổ biến nhất được gọi là Tiếp theo. js xuất hiện trên React. js. Andrew Clark, nhà phát triển cốt lõi của React, đã gọi nó là "bản phát hành React 18 thực sự" vào năm 2022, vì nó đi kèm với tất cả pin [e. g. Hồi hộp, phát trực tuyến SSR] bao gồm mà nhóm React cung cấp dưới dạng các khối xây dựng cơ bản ở cấp thấp hơn của thư viện. Cả hai, Vercel [công ty đứng sau Next. js] và Phản ứng. js đang hợp tác chặt chẽ với nhau để mang lại trải nghiệm tuyệt vời cho nhà phát triển
Trong khi nhiều nhà phát triển chú ý đến mối quan hệ chặt chẽ giữa Next. js và phản ứng. js với lập trường có liên quan, có những lựa chọn thay thế cho React. js như Remix [được Shopify mua lại gần đây] ngoài kia. Remix có một cách tiếp cận khác khi biến React. js vào một khung meta [e. g. sử dụng các tiêu chuẩn web như công dân hạng nhất], nhưng cũng có những tính năng hội tụ [e. g. định tuyến lồng nhau] giữa cả hai khung do sự cạnh tranh của chúng
Mặc dù tiếp theo. js đã là một ứng cử viên sáng giá trong không gian SSR hiện đại và đã biến nhiều nhà phát triển giao diện người dùng trở thành nhà phát triển full-stack một cách tự nhiên, các framework khác cũng nên nằm trong danh sách theo dõi của bạn. SvelteKit [xây dựng trên Svelte. js] với 1 gần đây. 0 được hỗ trợ bởi Vercel và SolidStart [xây dựng trên Solid. js] với DX được cải tiến so với React. js
Các mẫu ứng dụng và kết xuất
Trong khi thập kỷ qua [2010 - 2020] bị thống trị bởi Ứng dụng một trang [SPA] với kết xuất phía máy khách [CSR] của họ, bắt đầu từ Knockout. js và Ember. js qua góc. js, phản ứng. js và Vue. js, những năm qua đã chứng kiến sự quan tâm ngày càng tăng đối với kết xuất phía máy chủ [SSR] với các khung meta. Nhìn từ bên ngoài, có vẻ như chu kỳ đang khép lại, bởi vì chúng tôi đã sử dụng SSR với JavaScript rắc rối [e. g. jQuery, MooTools, võ đường. js] trong các ứng dụng nhiều trang [MPA] trước đó khá lâu [2005 - 2010]. Tuy nhiên, ngược lại vào thời Java [e. g. JSP] hoặc Ruby on Rails mới hơn đã được sử dụng cho SSR, lần này sẽ khác vì chúng tôi đang dựa vào JavaScript để thay thế. Trong vài năm tới. js đã là động lực thúc đẩy xu hướng này, tuy nhiên, các meta framework khác như SvelteKit đang bắt kịp
SSR đã cạnh tranh với việc tạo trang web tĩnh [SSG] trong một thời gian dài để đạt được hiệu suất hoàn hảo [xem Tiếp theo. js đấu với Gatsby. js] mặc dù cả hai mẫu phục vụ các mục đích hoàn toàn khác nhau. Trong khi mẫu thứ hai được sử dụng cho nội dung tĩnh [e. g. các trang web như blog], cái trước được sử dụng cho nội dung động [e. g. Ứng dụng web]. Nếu SEO có liên quan, thì cả SSR và SSG đều có ý nghĩa. Tuy nhiên, với yêu cầu nội dung động cao hoặc nội dung lấy người dùng làm trung tâm có xác thực, nhà phát triển không thể chọn SSG [xây dựng một lần trước khi triển khai, do đó tĩnh] và phải quyết định giữa SSR [xây dựng theo yêu cầu theo yêu cầu với dữ liệu riêng lẻ trên máy chủ]
Mặc dù vậy, CSR, SSR, SSG không phải là xu hướng mới nhất cho các kỹ thuật kết xuất. Mặc dù SSR và SSG đã bắt đầu xu hướng tối ưu hóa hiệu suất cách đây vài năm, nhưng các kỹ thuật kết xuất nhiều sắc thái hơn như Tái tạo tĩnh tăng dần [ISR] và Truyền SSR đã trở nên sống động. Cái trước nâng cao SSG, vì nó cho phép xây dựng lại tĩnh một trang web trên cơ sở mỗi trang [e. g. xây dựng lại trang X cứ sau 60 giây] thay vì xây dựng lại toàn bộ trang web. Hơn nữa, ISR theo yêu cầu, còn được gọi là Xác thực lại theo yêu cầu, có thể được sử dụng để kích hoạt quá trình xây dựng lại thông qua API tiếp xúc với ứng dụng [e. g. khi cập nhật dữ liệu CMS]
Mặt khác, truyền phát SSR tối ưu hóa nút cổ chai đơn luồng của kết xuất phía máy chủ. Mặc dù SSR thông thường phải đợi trên máy chủ để dữ liệu gửi nội dung được kết xuất tới máy khách cùng một lúc, SSR truyền trực tuyến cho phép các nhà phát triển chia ứng dụng thành các phần có thể được gửi song song dần dần từ máy chủ đến máy khách
Trong những năm qua, các mẫu kết xuất khá đơn giản với SSG và SSR trong các SPA/KBTB. Tuy nhiên, các phiên bản nhiều sắc thái hơn đang là xu hướng ngày nay. Nhưng không chỉ phát trực tuyến ISR và SSR trở nên phù hợp hơn mà cả Hydrat hóa một phần [e. g. React Server Components] chỉ cho phép hydrat hóa một số thành phần của bạn trên máy khách, Progressive Hydration cho phép kiểm soát chi tiết hơn đối với thứ tự hydrat hóa, Island Architectures [e. g. Astro] cho các ứng dụng hoặc thành phần biệt lập trong KBTB và sử dụng khả năng phục hồi thay vì hydrat hóa [e. g. Qwik với khung meta Qwik City] đang trở thành cách tiếp cận hợp lệ ngày nay
Máy chủ không giới hạn
Các kỹ thuật kết xuất như SSR và SSG có mối tương quan cao với xu hướng không có máy chủ ở vùng biên, bởi vì cả hai đều được thúc đẩy bởi hiệu suất với mục tiêu cung cấp trải nghiệm người dùng liền mạch trong trình duyệt. Về cơ bản, mong muốn phục vụ người dùng các trang web và ứng dụng web nhanh hơn đã khơi dậy mối quan tâm đến việc không có máy chủ ở rìa
Nhưng hãy bắt đầu lại từ đầu. Serverless hay còn gọi là các chức năng không có máy chủ, tính toán không có máy chủ [e. g. AWS Lambda] hoặc chức năng đám mây [e. g. Google/Firebase Cloud Function] đã là một xu hướng lớn trong điện toán đám mây trong vài năm nay. Mặc dù serverless vẫn có nghĩa là có một máy chủ đang chạy [từ xa], nhưng nhà phát triển không phải quản lý máy chủ và các tác vụ liên quan của nó [e. g. mở rộng cơ sở hạ tầng theo yêu cầu]. Thay vào đó, người ta phải triển khai một chức năng duy nhất dưới dạng chức năng không có máy chủ do nhà cung cấp dịch vụ đám mây đảm nhận
Các chức năng serverless đã mở ra một lợi thế khác, bởi vì thay vì triển khai máy chủ ứng dụng của bạn tới một [hoặc một vài] trung tâm dữ liệu, có thể có hàng chục trung tâm dữ liệu như vậy trên khắp thế giới. Do đó, trong một thế giới hoàn hảo, các chức năng không có máy chủ sẽ chạy càng gần người dùng của họ càng tốt, bởi vì điều đó có nghĩa là chuyến khứ hồi máy khách-máy chủ ngắn nhất và do đó trải nghiệm người dùng được cải thiện. Triển khai các chức năng serverless càng gần người dùng càng tốt đã tạo ra các thuật ngữ điện toán biên và chức năng biên
Nhiều nhà cung cấp đám mây [e. g. Cloudflare với Cloudflare Worker, Vercel với Edge Network, Deno với Deno Deploy] đang cạnh tranh trong không gian này, nơi mọi người tối ưu hóa để có trải nghiệm tương tác [TTI] tốt nhất cho người dùng cuối của họ. Các chức năng cạnh không chỉ phục vụ nội dung SSG/SSR nhanh hơn [vì dây dẫn đến người dùng cuối ngắn hơn] mà còn có thể lưu trữ kết quả của chúng gần người dùng hơn
Nhưng không chỉ vấn đề về hiệu suất, mặc dù đó là động lực chính, các lợi ích khác như giảm chi phí cũng đi kèm với tính toán vượt trội. Ví dụ: thường không phải tất cả dữ liệu gửi giữa máy khách và máy chủ [ở đây là chức năng cạnh] đều cần được tính toán bởi một trung tâm dữ liệu chính. Trong IoT, có rất nhiều dữ liệu không liên quan [e. g. các bản ghi video không có thay đổi trên mỗi khung hình] gửi đến một trung tâm dữ liệu chính thay vào đó có thể được lọc đơn giản trên cạnh. Rốt cuộc, các chức năng cạnh chỉ là khởi đầu
Cơ sở dữ liệu Renaissance
Với sự ra đời của serverless [ở rìa], cơ sở dữ liệu cũng trải qua thời kỳ phục hưng. Với một chức năng không có máy chủ, các nhà phát triển nhanh chóng gặp phải vấn đề mở quá nhiều kết nối cơ sở dữ liệu, bởi vì không có một máy chủ nào giữ một kết nối mở, mà có nhiều chức năng không có máy chủ với 1. 1 kết nối với cơ sở dữ liệu. Tổng hợp kết nối là giải pháp cho vấn đề này, nhưng một trong hai người phải tự xử lý hoặc nhờ dịch vụ của bên thứ ba xử lý.
Các ứng cử viên phổ biến trong không gian cơ sở dữ liệu không có máy chủ là PlanetScale [MySql], Neon [PostgreSQL] và Xata [PostgreSQL] đi kèm với nhiều tính năng như phân nhánh cơ sở dữ liệu, khác biệt lược đồ và tìm kiếm/phân tích/thông tin chuyên sâu mạnh mẽ. Khi nói đến serverless trên khắp thế giới, họ cung cấp bộ nhớ đệm biên hoặc cơ sở dữ liệu chỉ đọc phân tán để di chuyển dữ liệu của bạn đến gần người dùng hơn với độ trễ tối thiểu
Nếu dịch vụ của bên thứ ba không chỉ phân phối cơ sở dữ liệu của bạn mà còn cả ứng dụng của bạn, thì Fly. io gói mọi thứ vào một nền tảng. Điều này đưa chúng ta vượt ra ngoài cơ sở dữ liệu, nơi cũng có rất nhiều chuyển động đang diễn ra. Đường sắt, được coi là người kế nhiệm Heroku, mang đến mọi thứ cho Nền tảng dưới dạng Dịch vụ [PaaS] để triển khai ngăn xếp công nghệ của bạn. Nếu bạn muốn tiến thêm một bước trong chuỗi dịch vụ tới Backends as a Service [BaaS], bạn sẽ có một giải pháp thay thế nguồn mở cho Firebase với Supabase đi kèm với các chức năng lưu trữ, xác thực và biên ứng dụng/cơ sở dữ liệu
Thời gian chạy JavaScript
Mọi chuyện bắt đầu khi Ryan Dahl công bố Node. js tại một hội nghị năm 2009. Khởi đầu là một thử nghiệm tách JavaScript khỏi trình duyệt và cung cấp nó trên máy chủ, đã trở thành một trong những động lực lớn nhất cho câu chuyện thành công của JavaScript trong thập kỷ qua. Về cơ bản, Ryan Dahl đã sử dụng Công cụ JavaScript có tên V8 [do Chrome triển khai] cho Node. js không có trình duyệt. Do đó cả trình duyệt Chrome và Node. js sử dụng cùng một Công cụ JavaScript, nhưng có Thời gian chạy JavaScript của riêng chúng [e. g. API trình duyệt so với API nút] để tương tác với nó
Một thập kỷ sau, Ryan Dahl công bố Deno là người kế nhiệm Node với lời hứa cung cấp cho các nhà phát triển một môi trường an toàn hơn và nhanh hơn, đi kèm với các API tương tự như trình duyệt, TypeScript và một thư viện tiêu chuẩn sẵn có. Mặc dù vậy, Deno, cũng chạy trên V8, chỉ là một trong nhiều Thời gian chạy JavaScript ngày nay
Trong vùng đất cạnh tranh của các hàm biên, nhiều nhà cung cấp đám mây triển khai Thời gian chạy JavaScript của riêng họ [e. g. Công nhân Cloudflare] tối ưu hóa cho cơ sở hạ tầng của riêng họ [e. g. đám mây]. Do đó, mô hình kinh doanh của Deno cũng đang trở thành nhà cung cấp đám mây với Deno Deploy và khung SSR kết xuất biên đúng lúc của họ [bắt đầu là bằng chứng về khái niệm] được gọi là Deno Fresh. Các giải pháp độc lập của nhà cung cấp đám mây như Bun [chạy trên JavaScriptCore Engine và được triển khai nổi tiếng trong Zig] đã trở thành một cú hit lan truyền khác trong cuộc đua giành Thời gian chạy JavaScript nhanh nhất gần đây
Đầu óc nhạy bén sẽ thấy [một lần nữa] rất nhiều phân mảnh trong bối cảnh JavaScript do các thời gian chạy khác nhau. Nếu mọi thứ trở nên rối tung, chúng tôi sẽ rơi vào tình huống tương tự mà chúng tôi đã gặp phải với hỗ trợ JavaScript bị phân mảnh trong các trình duyệt trong nhiều năm, nhưng lần này là trên máy chủ nơi không phải tất cả JavaScript có thể được hỗ trợ như nhau trong các thời gian chạy khi được triển khai trên các nhà cung cấp đám mây khác nhau. Do đó tất cả các bên liên quan [e. g. Deno, Vercel, Cloudflare] đã tham gia WinterCG để cộng tác về khả năng tương tác API giữa Thời gian chạy JavaScript của họ
Monorepos
Trước đây, monorepos chủ yếu được sử dụng cho các ứng dụng quy mô lớn trong đó một dự án chứa các dự án nhỏ hơn trong một kho lưu trữ được kiểm soát phiên bản. Mỗi dự án nhỏ hơn này có thể là bất kỳ thứ gì từ ứng dụng riêng lẻ [e. g. SPA, MPA] thành gói tái sử dụng [e. g. chức năng, thành phần, dịch vụ]. Việc thực hành kết hợp các dự án có từ đầu năm 2000 khi nó được gọi là cơ sở mã dùng chung
Tuy nhiên, ngày nay các monorepos không chỉ dành riêng cho các ứng dụng quy mô lớn mà còn cả các công ty nhỏ hơn và các dự án nguồn mở, những người chắc chắn sẽ được hưởng lợi từ chúng. Ví dụ: một công ty có thể có nhiều gói khác nhau trong một đơn đăng ký từ các thành phần giao diện người dùng được chia sẻ, hệ thống thiết kế được chia sẻ [e. g. thiết kế hợp tác có thể tái sử dụng] và các chức năng tiện ích thường được sử dụng cho miền tương ứng của chúng
Các gói này có thể được nhập trong các ứng dụng khác nhau. ứng dụng thực tế [e. g. ứng dụng. trang web của tôi. com với kết xuất phía máy khách] sử dụng tất cả các gói được chia sẻ này, trang chủ/sản phẩm/trang đích [e. g. trang web của tôi. com với kết xuất phía máy chủ hoặc tạo trang tĩnh] có lưu ý đến SEO chỉ sử dụng gói hệ thống thiết kế dùng chung và trang tài liệu kỹ thuật [e. g. tài liệu. trang web của tôi. com] sử dụng các thành phần giao diện người dùng được chia sẻ và các gói hệ thống thiết kế được chia sẻ
Turborepo [do Vercel mua lại] lại làm dấy lên sự cường điệu về monorepo trong JavaScript/TypeScript. Turborepo cho phép các nhóm tạo các quy trình xây dựng cho tất cả các ứng dụng và gói của họ trong một monorepo. Người bắt mắt. bộ nhớ đệm của các bản dựng trong quy trình trên máy cục bộ hoặc trên đám mây giữa các nhóm. Turborepo kết hợp với các công cụ monorepo quan trọng khác như không gian làm việc npm/yarn/pnpm [quản lý phụ thuộc] và bộ thay đổi [tạo phiên bản] làm cho chuỗi công cụ này trở thành một không gian đáng xem trong năm nay
Đối thủ cạnh tranh của Turborepo là Nx, Rush và Lerna [không được duy trì trong một thời gian, sau đó được công ty Nrwl của Nx mua lại]
Tiện ích-Đầu tiên CSS
Các nhà phát triển yêu hoặc ghét nó. Tailwind CSS là nền tảng tiêu biểu cho CSS ưu tiên tiện ích. Trong khi một bên các nhà phát triển ghét nó vì nó xuất hiện dài dòng trong mã giao diện người dùng của họ, thì bên kia các nhà phát triển lại yêu thích nó vì DX tuyệt vời của nó. Là nhà phát triển, bạn định cấu hình nó một lần trong dự án của mình và sử dụng CSS được xác định trước ngay lập tức trong HTML
Mặc dù vậy, sự phân chia yêu và ghét về CSS ưu tiên tiện ích này có thể chấm dứt với sự gia tăng gần đây của kết xuất phía máy chủ [SSR]. Trong một vài năm, các giải pháp CSS-in-JS như Thành phần được tạo kiểu [SC] và Cảm xúc đã trở thành lực lượng phổ biến để tạo kiểu cho các ứng dụng web dựa trên thành phần hiện đại. Tuy nhiên, nếu hiệu suất trong thế giới SSR là một trong những mục tiêu chính, CSS-in-JS đi kèm với các tác động tiêu cực. tăng kích thước bó [SC với 12. 7kB, Cảm xúc với 7. 9kB] và quan trọng hơn là chi phí thời gian chạy do quá trình tuần tự hóa CSS trước khi chèn nó vào DOM
Do đó, chúng tôi có thể thấy các nhà phát triển chuyển sang các giải pháp thân thiện hơn với SSR như tiện ích-đầu tiên-CSS [e. g. Tailwind CSS, UnoCSS] được ghép nối với thành phần giao diện người dùng được xác định trước [e. g. DaisyUI], các lựa chọn thay thế phổ biến không kém khác như Mô-đun CSS hoặc các dịch vụ kém hơn được gọi là CSS-in-JS không thời gian chạy/thời gian biên dịch [e. g. chiết xuất vani, linaria, astroturf, đã biên dịch]
An toàn loại từ đầu đến cuối với TypeScript
Quá trình phát triển từ JavaScript sang TypeScript là không thể ngăn cản. Trong quá trình chuyển đổi lớn của phát triển web này, an toàn kiểu E2E cho các ứng dụng full-stack chắc chắn là một xu hướng quan trọng. Việc triển khai khái niệm này tồn tại và thất bại với lớp giao tiếp [API] được yêu cầu để kết nối các thực thể đã nhập [e. g. type User, type BlogPost] từ máy chủ đến ứng dụng khách
Các nghi phạm thông thường trong phát triển web cho giao tiếp máy khách-máy chủ là REST và GraphQL. Cả hai đều có thể được sử dụng với OpenAPI cho REST và Trình tạo mã GraphQL cho GraphQL để tạo tệp lược đồ đã nhập cho ứng dụng giao diện người dùng
Tuy nhiên, có một ngôi sao đang lên mới cho các API an toàn loại được gọi là tRPC có thể được sử dụng làm thay thế REST/GraphQL. Nếu bạn đang làm việc trong một TypeScript monorepo nơi giao diện người dùng và chương trình phụ trợ đang chia sẻ mã, tRPC cho phép bạn xuất tất cả các loại từ chương trình phụ trợ sang ứng dụng giao diện người dùng mà không cần tạo bất kỳ sơ đồ trung gian nào. Sau đó, giao diện người dùng có thể gọi API của chương trình phụ trợ bằng cách chỉ sử dụng các chức năng đã nhập được kết nối bởi HTTP dưới mui xe để cho phép giao tiếp máy khách-máy chủ thực tế. Xu hướng chung chắc chắn hướng tới việc sử dụng nhiều hơn các giải pháp an toàn kiểu này cho các ứng dụng toàn ngăn xếp như tRPC, Zod, Prisma và TanStack Router, tất cả đều cung cấp kiểu an toàn ở biên của ứng dụng
Công cụ xây dựng
Ở React-land, ứng dụng tạo phản ứng [CRA] đã thống trị toàn cảnh trong một vài năm. Đó là một cuộc cách mạng nhỏ vào thời điểm đó, bởi vì những người mới bắt đầu đã được cung cấp một dự án khởi động React sẵn sàng hoạt động mà không cần phải định cấu hình Webpack tùy chỉnh với thiết lập React nữa. Tuy nhiên, trong năm qua Webpack đã lỗi thời khá nhanh
Vite là đứa trẻ mới trong khối khi nói đến các ứng dụng một trang [SPA], bởi vì nó hoạt động với tất cả các khuôn khổ phổ biến [e. g. Phản ứng. js] để tạo dự án khởi động. Được thực hiện bởi Evan You, người tạo ra Vue. js, nó tự coi mình là công cụ giao diện người dùng thế hệ tiếp theo. Về cơ bản, nó có được sức mạnh từ esbuild, so với các trình đóng gói JavaScript khác được viết bằng Go và do đó, các gói phụ thuộc nhanh hơn 10-100 lần so với các đối thủ cạnh tranh của nó [e. g. gói web]
Trong khi hệ sinh thái của Vite phát triển mạnh với các bổ sung như Vitest [thử nghiệm thay thế cho Jest], các đối thủ cạnh tranh khác như Turbopack của Vercel mới xuất hiện gần đây. Turbopack được coi là sự kế thừa của Webpack, bởi vì nó đã được dẫn đầu bởi Tobias Koppers, người tạo ra Webpack. Bởi vì tiếp theo. js vẫn đang sử dụng Webpack và Turbopack được phát triển bởi cùng một công ty, chúng ta có thể mong đợi Tiếp theo. js và Turbopack có lẽ sẽ là một sự kết hợp hoàn hảo trong tương lai
Phát triển theo định hướng AI
Cuối cùng AI sẽ đảm nhận công việc của nhà phát triển? . Với việc phát hành GitHub Copilot, các nhà phát triển đã có thể kết hợp với một lập trình viên AI trong IDE yêu thích của họ. Nó đơn giản như viết mã [hoặc viết nhận xét cho biết bạn muốn viết mã gì] và GitHub Copilot sẽ tự động hoàn thành các chi tiết triển khai để hiểu rõ nhất
Nhưng nó không dừng lại ở đây. ChatGPT của OpenAI là một mô hình ngôn ngữ tổng quát hơn, đảm nhận cả các tác vụ lập trình. Mặc dù bạn có thể đặt câu hỏi ở dạng miễn phí ChatGPT, nhưng nó cũng có thể thực hiện các tác vụ viết mã. Nhiều nhà phát triển đã bắt đầu sử dụng ChatGPT để thay thế StackOverflow. Trong nhiều tình huống, ChatGPT đã đưa ra các câu trả lời hữu ích [mặc dù không phải lúc nào cũng hoàn hảo] khi được sử dụng làm công cụ tìm kiếm thay thế. Vì ChatGPT phải đối phó với rất nhiều thư rác SEO [không chỉ đối với nội dung liên quan đến phát triển], ChatGPT được coi là một giải pháp thay thế khả thi vào lúc này
"Tại thời điểm này" là thuật ngữ quan trọng ở đây mặc dù. Từ góc nhìn toàn cảnh, nội dung do AI tạo ra cũng có thể [và sẽ] gây hại cho world wide web. Trước đây, nội dung SEO được tạo thủ công đã là một vấn đề, không ai ngăn cản ai đó sản xuất nhiều nội dung SEO được tạo tự động hơn với ChatGPT. Cuối cùng, ChatGPT sẽ đào tạo nội dung do chính nó tạo ra chứ?
Có một vài đề cập đáng chú ý mà tôi không muốn quên nhưng điều đó đã không lọt vào xu hướng được liệt kê. Tauri là giải pháp thay thế cho Electron cho các ứng dụng máy tính để bàn do JavaScript/CSS/HTML triển khai, Playwright là giải pháp thay thế cho Cypress để thử nghiệm E2E, Warp và Fig là thiết bị đầu cuối thế hệ tiếp theo, Truy vấn bộ chứa CSS là giải pháp thay thế cho Truy vấn phương tiện CSS cho thiết kế đáp ứng và cuối cùng nhưng . Vì tôi chỉ đưa ra một bản tóm tắt nhỏ ở đây, tôi khuyến khích bạn tự kiểm tra chúng
Dù sao đi nữa, hy vọng rằng tôi có thể cung cấp cho bạn một cái nhìn tổng quan tuyệt vời về hiện trạng trong hệ sinh thái phát triển web. Nếu bạn thích bài viết, vui lòng đăng ký nhận bản tin của tôi bên dưới. Tôi cũng có ý định viết thêm về một số công nghệ này trong năm nay, vì vậy nếu bạn đang làm việc cho một trong số chúng, hãy liên hệ với tôi và chúng ta có thể hợp tác về nó