- Giải thích về các kỹ thuật phát triển web cơ bản chỉ sử dụng HTML, CSS và JavaScript
- Giới thiệu cách xây dựng trang web và ứng dụng chỉ bằng các công nghệ web tiêu chuẩn, không cần công cụ build hay framework
- Trình bày cách cấu trúc và tạo kiểu bằng Web Components cùng các tính năng CSS hiện đại
- Hướng tới môi trường phát triển đơn giản và lợi ích dài hạn, không có sự phức tạp của framework hay gánh nặng bảo trì
- Hướng dẫn này chủ yếu dành cho developer đã nắm các công nghệ tiêu chuẩn của web
Tổng quan về Plain Vanilla Web
Đây là phần tổng quan về các kỹ thuật chính để tạo trang web và ứng dụng chỉ bằng các công nghệ web tiêu chuẩn, không cần công cụ build hay framework trong phát triển web
- Mô tả môi trường chỉ sử dụng trình soạn thảo, trình duyệt và các tiêu chuẩn web
- Giới thiệu cấu trúc có thể triển khai lên môi trường production mà không cần thiết lập ban đầu phức tạp hay logic phía máy chủ
Các chủ đề được đề cập
1. Components
- Trình bày cách dùng Web Components để kết hợp thành các thành phần cấp cao chỉ với HTML, JavaScript và CSS
- Đây là cách thay thế cho hướng tiếp cận component của các framework như React hoặc Vue
2. Styling
- Trình bày cách tận dụng sức mạnh của CSS hiện đại để thay thế sự tiện lợi mà CSS Modules, PostCSS và SASS mang lại
- Cung cấp khái niệm tổ chức style có tính cấu trúc và mô-đun, vượt ra khỏi CSS cổ điển
3. Sites
- Trình bày cách tổ chức dự án web dựa trên Web Components và triển khai mà không cần công cụ build hay phía máy chủ
- Đưa ra quy trình triển khai thực tế và đơn giản
4. Applications
- Trình bày cách xây dựng ứng dụng web một trang chỉ bằng các kỹ thuật vanilla
- Giải thích cách routing và quản lý trạng thái
Đối tượng phù hợp
Dành cho developer đã có thể sử dụng HTML, CSS và JavaScript ở mức nhất định
- Với người mới bắt đầu học phát triển web, khuyến nghị các lộ trình học nền tảng như Odin Project hoặc MDN
Vì sao chọn cách tiếp cận vanilla
Các framework hiện đại có thể nhanh chóng cung cấp cấu trúc và tính năng mạnh mẽ, nhưng đi kèm là độ phức tạp ngày càng tăng của công cụ và framework cùng gánh nặng bảo trì liên tục
- Cách tiếp cận Plain Vanilla chấp nhận từ bỏ một phần tiện lợi ngắn hạn để đổi lấy lợi ích dài hạn là sự đơn giản và gần như không cần bảo trì
- Trình duyệt ngày nay có khả năng hỗ trợ tiêu chuẩn web rất tốt, nên cách tiếp cận này hoàn toàn khả thi trong thực tế
1 bình luận
Ý kiến trên Hacker News
Giờ tôi đã vượt qua tranh luận kiểu “vanilla hay framework” và chuyển sang nghĩ theo góc nhìn: “Cái này có thực sự cần một website không?”
Khi bắt đầu hoài nghi liệu webapp, đặc biệt trong mảng B2B SaaS, có thực sự cần thiết hay không, bạn sẽ nhận ra rằng doanh nghiệp vẫn có thể đi rất xa mà không cần đụng vào trình duyệt.
Phần lớn thời gian tôi từng đổ vào việc làm website và app thực ra tập trung vào UI/UX cho khâu quản trị, tức là phần để admin thay đổi các trường trong cơ sở dữ liệu để ứng dụng vận hành đúng với kỳ vọng của khách hàng.
Trong nhiều trường hợp, chỉ cần đưa cho doanh nghiệp một mẫu cấu hình đơn giản (như file Excel) rồi chèn hoặc gộp kết quả trực tiếp vào bảng SQL sẽ nhanh hơn, dễ hơn và đỡ việc vô ích hơn nhiều.
Web chỉ cung cấp một kiểu UI/UX. Email hay file văn bản thuần đôi khi còn linh hoạt hơn.
Đặc biệt với các cơ quan chính phủ, bên mua thường không thật sự hiểu rõ và hay trả quá nhiều tiền.
Những người phụ trách mua sắm cần được đào tạo kỹ hơn về cái họ thực sự cần.
Các cửa hàng bán hũ đựng tro cốt ngoài đời cũng đâu có giỏ hàng, vậy tại sao cửa hàng ảo lại cần?
Khi mua dụng cụ mộc chuyên dụng online, tôi cũng chỉ điền vào form rồi nhận linh kiện kèm hóa đơn, thậm chí không trả tiền ngay cũng không sao.
Cả online lẫn offline đều tồn tại nhiều kiểu thương mại khác nhau; nếu để ý những người đang kiếm sống theo cách thú vị, bạn sẽ thấy điều đó ở khắp nơi.
Chỉ cần có chút năng lực bảo trì, cách làm bằng mẫu Excel + script tùy chỉnh đơn giản sẽ linh hoạt hơn nhiều.
Nếu người dùng cuối vốn dĩ là kiểu người dùng làm việc trực tiếp với dữ liệu thô, thì cách này cực kỳ hiệu quả.
Và đến giờ 99% B2B vẫn theo cách này.
Tôi không phản đối framework. Chỉ là trong nhiều trường hợp tôi thấy chúng không cần thiết.
Tôi luôn thắc mắc tại sao lại phải thêm 100KB JS trước cả khi viết một dòng code nào.
Tôi và đội của mình đã xây https://restofworld.org mà không dùng bất kỳ framework nào.
Khảo sát, outreach, phản hồi qua email đều rất tích cực về mặt khả dụng và trải nghiệm đọc.
Sau này có thể vẫn dùng framework, nhưng cho đến giờ vanilla JS vẫn rất phù hợp.
Một bên là những người xây webapp lớn trong các team hơn 30 người, và khi nghe nói làm không framework thì lập tức đặt câu hỏi về cách xử lý các tính năng bắt buộc ở quy mô lớn.
Nhưng câu trả lời ở đây là họ chẳng cần những tính năng đó, và vì đây là thứ kiểu blog nên ngay từ đầu đã không cần framework.
Ngược lại, những người chưa từng có kinh nghiệm với webapp quy mô cực lớn lại nghĩ “tại sao người ta phải dùng framework?”.
Web thực sự là tập hợp của rất nhiều loại phần mềm khác nhau.
Vì vậy khi bàn về framework, tôi nghĩ phải nói rõ đang nói đến loại phần mềm nào.
Trong trường hợp này, đây là một blog WordPress.
Nó đang dùng WordPress, tức là một framework lớn, chỉ là render tĩnh mà thôi.
TFA nói về việc hoàn toàn không có build tool, chỉ dùng các tiêu chuẩn web hiện đại. Chỉ editor, browser và web standards.
Trong các ứng dụng doanh nghiệp tôi từng làm, chuyện 100KB hoàn toàn chẳng đáng bận tâm.
Đa số là app lớn do nhiều team cùng làm, dùng React các kiểu.
Trong Lob/B2B, chẳng ai quan tâm đến tải trang ban đầu.
Người dùng dùng app mỗi ngày, và phần lớn đều lấy ngay các static asset từ cache trình duyệt.
Nếu dùng framework thông minh như Next.js thì nội dung được tách thành các chunk bất biến theo từng route.
Render ban đầu là HTML tĩnh nên từ góc nhìn người dùng, hydration cũng hầu như không thể nhận ra.
Nhưng trong tranh luận vanilla vs framework, những ví dụ kiểu này lúc nào cũng là site tin tức/bài viết, nên tôi lại nghĩ “nếu là tôi thì ngay từ đầu cũng chẳng dùng framework”.
Rốt cuộc ví dụ dùng thực tế nên là các app tương tác nhiều hơn.
Dạo này tôi thích dùng framework và các pattern nhất quán của nó, còn các dependency khác thì giữ ở mức tối thiểu.
Trên iPhone, tôi đã quá quen với chuyện bấm quay lại là cả trang phải tải lại hoàn toàn.
Thế nhưng các dev lại bị ám ảnh bởi màn hình loading cho vui, component hydration, animation quá đà và những modal gây bực mình.
Ngoài ra, infinite scroll khiến rất khó theo dõi mình đang ở đâu thông qua vị trí thanh cuộn, nên rất hại cho usability.
Khen bạn vì đã tham gia xây dựng nó.
Ví dụ Mithril có thể làm mọi thứ chỉ với 10KB gzipped.
Nếu nghĩ đến việc tự làm một bảng reactive có tìm kiếm, hay form có label, validation và error xử lý bài bản, thì tại sao phải tự làm trong khi có thể dùng một thư viện UI Svelte với 25KB overhead để có một sản phẩm được kiểm chứng và hoàn thiện?
Và WordPress cũng là framework.
Dùng framework cũng không có nghĩa là chậm, dù là WordPress hay bất cứ thứ gì.
Nhanh quá mức luôn.
Đó là vì năng suất của lập trình viên (ít nhất trên lý thuyết).
Nhưng thực tế thì nhiều khi cũng chẳng giúp được bao nhiêu.
Tò mò không biết cách tiếp cận này có vấp phải vấn đề sắc bén nào không.
Tôi đang phát triển một hệ thống cho khoảng 2.000 người dùng, và họ hoàn toàn không quan tâm đến UI reactive.
Cách tốt nhất là làm một monolith, đừng bận tâm cả chuyện refresh trang, cứ tập trung để công việc chạy được.
Động cơ của việc đó phần lớn không hẳn là kỹ thuật, mà là vì chi phí phân phối native app quá cao.
Web cung cấp một chuẩn phân phối ứng dụng với chi phí rẻ, nhưng công nghệ UI vẫn còn dở.
Trước đây đã có đủ kiểu nửa vời như X11, Java, Flash, và tôi hy vọng rồi sẽ có một cách làm webapp dễ chịu hơn.
@view-transitioncũng đã có thể tạo chuyển cảnh mượt.https://developer.mozilla.org/en-US/docs/Web/CSS/@view-transition
Phần lớn phần mềm còn chậm và kém phản hồi hơn cả các thiết bị cơ khí từ 120 năm trước.
Không cần kéo bất kỳ gói npm nào về.
Backend là express/node, toàn bộ code nằm cùng nhau, nhưng môi trường dev thì server chạy bằng server mặc định của React, còn lúc deploy thực tế lại chạy khác, nên cuối cùng phải build và vận hành theo một kiểu rất kỳ quặc, làm mất hết ý nghĩa của tiện ích dev server như hot reload.
Ngay cả SPA của các công ty lớn như Reddit, X(Twitter) các kiểu cũng quá bất ổn trên mobile.
Nếu bạn không ở tầm Twitter, hoặc không phải một nền tảng API-first, thì tôi nghĩ chẳng có lý do gì phải cố chấp với SPA.
Đừng quá tự tin rằng mình có thể làm tốt hơn thứ mà không ai, kể cả các công ty hàng chục tỷ đô, làm cho ra hồn.
Không cần phải xé bỏ mọi thứ để viết lại bằng React.
Các tính năng nâng cao kiểu SPA mà tác giả bài gốc nói tới chỉ là tùy chọn.
Bạn có khảo sát cả những người đã bỏ đi hay không?
Tôi muốn sống trong một thế giới như vậy.
Tôi đến từ thời trước framework, khi mọi thứ vẫn còn non nớt và người chỉ biết jQuery cũng rất phổ biến.
Giờ tôi thấy lợi ích so với chi phí của các framework thời hậu-query selector không còn lớn đến vậy nữa (khung kiểm thử thì là chuyện khác, chúng rất tốt).
Chúng ta đang bị nhốt trong nhà tù framework mang tên React, và mọi thất bại đều là hệ quả của sự phức tạp bị biến thành mớ spaghetti.
State machine bị hardcode thành một đống rối rắm, còn kết quả sau khi dịch, nén và transpile thì rất khó nhận diện.
Source map cũng là thêm một tầng phức tạp nữa cho việc bảo trì.
Tôi thừa nhận lý do framework ra đời, nhưng thật khó tin rằng với kỹ sư mới vào nghề, việc tiếp tục học framework lại dễ hơn học vanilla JS.
HTML vốn chỉ là markup để render văn bản dễ hơn, HTTP cũng tương tự.
Ngày xưa tỷ lệ text so với markup phải cao, nhưng giờ thì mọi thứ đã đảo ngược hoàn toàn.
Thế mà chúng ta lại tin rằng việc đặt toàn bộ phát triển ứng dụng lên trên đó là tương lai, trong khi nhìn vào bên trong React cũng chỉ thấy hàng chục năm mẹo vặt và thủ thuật chồng chất.
Ngày trước điều đó cũng vô lý như làm app bằng Excel+VB hay bằng tổ hợp PDF+PostScript vậy.
Vì đã đi theo con đường đó nên vài MB JS nghe mới phi lý đến thế.
Khi dữ liệu thay đổi thì UI phản hồi ngay lập tức; nếu phải tự tay gắn listener, cập nhật diff rồi còn tháo event nữa thì gần như đang quản lý bộ nhớ thủ công vậy.
Thời jQuery đúng là như thế, và sai sót rất nhiều.
Khi nào có thể mô-đun hóa theo kiểu component và khai báo view được trong vanilla JS thì lúc đó tôi mới quay lại, còn hiện tại thì tôi thấy hoàn toàn chưa thể.
Vẫn còn thiếu yếu tố quyết định.
React và Angular chắc chắn có ý nghĩa trước ES2015.
Sau đó thì tôi đã chán ngấy việc frontend framework cứ thay đổi liên tục.
Ngay trong React, cách làm component và quản lý state cũng thay đổi mãi.
Tôi vẫn chưa bị thuyết phục bởi Web Components.
Đặc biệt là dù đã có các tính năng gần đây như
@scoped,import {type:css}, tôi vẫn thấy việc render tĩnh phần tử trước rồi cập nhật động bằng JS hiện đại có ý nghĩa hơn nhiều.Tôi hoài nghi phần lớn các cách tiếp cận Web Components, và vẫn tin rằng cần tiếp tục đổi mới bên ngoài các framework như React/Svelte.
Tôi chưa bao giờ thấy Web Components thực sự hữu ích cho nhiều site mình vận hành.
Mỗi trang đều nhắc đến Shadow DOM hàng chục lần, nhưng phần lớn là để xử lý các vấn đề do chính việc dùng nó tạo ra.
Component dành riêng cho app của tôi thì chẳng có vấn đề Shadow DOM nào cả.
Tôi tò mò không biết Web Components sẽ xử lý chuyện này thế nào ở backend.
Bạn có thể gắn thêm phương thức vào thẻ riêng của mình, và đóng gói logic cập nhật bên trong component.
Cần những thực hành có thể tự viết hoặc dựa trên các thư viện nhẹ.
HTMX có vài điểm hay, nhưng nó vẫn hành xử như thẻ script; URL/method chỉ nên được đặt rõ ràng trong HTML, còn những thứ như
hx-targetthì chỉ cần chỉ định bằngdata-attribute trong JS là đủ.Tôi không muốn phải mang theo toàn bộ các tính năng HTMX mà mình không dùng.
Tôi không nghĩ Web Components là thứ thay thế cho cái mà các framework khác gọi là component.
Bạn không thể đưa các giá trị phức hợp (Object, Array...) vào attribute, boilerplate thì quá nhiều, lại không có tính phản ứng.
Tôi viết kiểu vanilla JS bằng hướng signals[1].
Không phải mọi tiêu chuẩn W3C đều là đáp án đúng, và nên nhìn lại ví dụ thất bại của XHTML.
[1] https://wrnrlr.github.io/prelude/
http://youmightnotneedjs.com
Cách tiếp cận này có vẻ rất hợp với những người làm web như một sở thích.
Framework tồn tại để chuẩn hóa, tích hợp sẵn best practices trong thiết kế, và giúp bắt đầu phát triển nhanh.
Bản thân website không có giá trị cốt lõi; điều quan trọng là phơi bày nội dung đó hiệu quả đến đâu và phát triển nó đúng, đúng lúc như thế nào.
Theo nghĩa đó, framework giúp giảm chi phí hiện tại và tương lai.
Trong các công ty lớn ngoài đời, quyết định thường bị chi phối bởi xu hướng, thói quen và tâm lý phòng thủ quanh các framework phổ biến; sự sụt giảm năng suất do độ phức tạp tăng lên thì không được theo dõi, thậm chí các quyết định sai còn phù hợp với incentive của cá nhân/đội nhóm.
Nói cách khác, không thể biện minh cho việc chọn framework bằng logic “nó tất yếu phải là lựa chọn hợp lý”.
Ngay từ đầu, dùng framework cũng không có nghĩa là best practices sẽ tự động được tuân thủ; ngược lại, nó còn có thể tạo ra những hệ thống phình to và chậm chạp hơn.
Tài liệu này thực sự rất tuyệt.
Tôi nghĩ nếu làm web thì nhất định phải hiểu nguyên lý của các công nghệ nền tảng và biết tận dụng tối đa nền tảng web.
Sau đó việc có dùng build system/framework hay không chỉ là lựa chọn tự do, miễn là ý thức được các trade-off.
Cá nhân tôi thích Remix(/React-router v7+) vì nó chạm tới triết lý web standards.
Tức là làm được nhiều việc hơn với ít công sức hơn, ví dụ thay đổi dữ liệu phía server cũng có thể xử lý chỉ bằng HTML form.
Ngoài ra tôi cũng khuyên dùng https://every-layout.dev vì ở đó bạn có thể học nhiều kỹ thuật layout hiệu năng cao, dễ truy cập và linh hoạt chỉ với CSS native của trình duyệt.
Bản thân tôi đã làm web chuyên nghiệp từ năm 1998.
Tuần trước tôi đã làm một dự án nhỏ hoàn toàn bằng vanilla và nó hoạt động rất tốt.
Đó là một công cụ web để viết các thread dài trên Mastodon.
Trong suốt quá trình làm, tôi cứ nghĩ “không dùng framework liệu có phải mình đang làm sai điều gì không?”
Không khí chung là ai cũng mặc định sẽ có framework.
Splinter, splinter.almonit.club, ai muốn tham khảo thì cứ xem.