HTML First
(html-first.com)- Nếu ưu tiên dùng tính năng native mà trình duyệt cung cấp sẵn, có thể giảm mức độ phụ thuộc vào ngôn ngữ bổ sung và toolchain khi xây dựng ứng dụng web
- React đã nâng cao độ tin cậy của việc phát triển UI bằng các mô hình như
props,state, và component, nhưng cũng đã chuyển trọng tâm của cách phát triển từ HTML sang JavaScript - Trong thời gian đó, W3C, WHATWG, IETF, và TC39 đã bổ sung hàng nghìn cải tiến cho các ngôn ngữ nền tảng của web, và khi các trình duyệt lớn tích hợp chúng, một phần lý do từng khiến React trở nên cần thiết đã suy yếu
- HTML First không hẳn là một trào lưu nhằm thuyết phục những nhà phát triển đã hài lòng với React, mà là để cung cấp ngôn ngữ giúp những người quan tâm đến cách tiếp cận lấy HTML làm trung tâm hệ thống hóa suy nghĩ và thảo luận với đồng nghiệp
- Đây gần hơn với một vấn đề thực tiễn: có nên xem xét lại việc liệu chỉ với các ngôn ngữ nền tảng của web và tính năng trình duyệt cũng có thể tạo ra phần mềm nhanh, dễ tiếp cận hay không
Cách phát triển mà HTML First hướng tới
- HTML First ưu tiên HTML, CSS, JavaScript và tính năng native của trình duyệt khi xây dựng phần mềm web
- Cốt lõi là giảm bớt các lớp trừu tượng được thêm lên trên nền tảng web
- Ngôn ngữ bổ sung và toolchain cũng nằm trong số những lớp cần cắt giảm
- Mục tiêu là một cách phát triển lấy các chức năng mà trình duyệt đã cung cấp làm trung tâm, và chỉ thêm công cụ lên trên khi thực sự cần
Phát triển web trở nên phức tạp hơn sau React
- Trước React, cách làm phổ biến là viết giao diện bằng HTML, rồi dùng các công cụ như jQuery để bù đắp những phần HTML không hỗ trợ sẵn
- Ví dụ tiêu biểu là gửi yêu cầu bất đồng bộ và cập nhật DOM
- Các thư viện như React đã giải quyết nhiều vấn đề của phát triển web truyền thống
- Mô hình
propsvàstate, nơi dữ liệu được truyền tường minh từ phần tử cha sang phần tử con, đã giúp giảm một số loại bug nhất định - Việc gói UI, style, và hành vi thành component giúp dễ dàng cài đặt những gì người khác tạo ra vào codebase của mình
- Mô hình
- Để có được những lợi ích đó, người ta phải chuyển từ cách làm chủ yếu dùng HTML sang cách làm chủ yếu dùng JavaScript
- JavaScript được xem là một ngôn ngữ phức tạp hơn
- Cũng phải học thêm nhiều khái niệm và công cụ mà React mang vào
- Ngành đã chấp nhận sự đánh đổi này dù độ phức tạp tăng lên, và các thư viện như vậy đã trở thành cách mặc định để xây dựng ứng dụng web
- Trước React, người mới thường học HTML và CSS trước rồi mới học JavaScript
- Sau React, xu hướng đã đổi thành học JavaScript và React trước rồi mới học phần còn lại
Điểm cần xem xét lại do nền tảng web được cải thiện
- W3C, WHATWG, IETF, và TC39 đã bổ sung hàng nghìn cải tiến cho các ngôn ngữ native của web trong thời gian cách làm kiểu React lan rộng
- Các cải tiến này đã được tích hợp vào Chrome, Safari, Firefox, và Edge
- Trong số đó, nhiều cải tiến trực tiếp xử lý một phần lý do khiến mọi người từng dùng React
- Khi chi phí phát triển phần mềm tăng lên và các cải tiến trình duyệt được triển khai rộng rãi, ngày càng có nhiều người đặt câu hỏi liệu những lớp bổ sung đó ngày nay còn thực sự cần thiết hay không
- Ý tưởng HTML First hiện vẫn là thiểu số trong ngành
- Cách tiếp cận này tập trung vào việc giúp những người vốn đã quan tâm đến phát triển lấy HTML làm trung tâm củng cố quan điểm của mình và có được ngôn ngữ và khái niệm để giao tiếp với đồng nghiệp
- Thông điệp cốt lõi là: ngay cả khi chủ yếu sử dụng các ngôn ngữ và tính năng native của web, việc tạo ra phần mềm web đẹp, nhanh, dễ dùng và dễ tiếp cận vẫn là điều khả thi, thực tiễn và hợp lý
1 bình luận
Ý kiến trên Hacker News
Tôi thích ý tưởng ở đây, nhưng nói thật là các ví dụ khá yếu
Ví dụ cho phần “hãy định nghĩa style và hành vi bằng thuộc tính HTML inline nếu có thể” thực ra có vẻ sẽ không hoạt động, và nếu muốn thêm style nữa thì cấu trúc sẽ chỉ làm tham số chuỗi truyền vào
ClassList.addngày càng phình toCá nhân tôi thấy
button:active { background: green; }dễ đọc hơn nhiều, nhưng có vẻ tác giả xem cách này là phức tạp vì hướng tiếp cận “Locality of Behaviour”Tôi đồng ý với câu “nếu cần thư viện, hãy dùng thư viện tận dụng thuộc tính HTML thay vì xoay quanh JavaScript hay cú pháp tùy biến”, nhưng ví dụ được khuyến nghị “on input put me into #output” còn gượng gạo hơn thư viện được đưa ra làm ví dụ xấu, và có vẻ chỉ dùng JavaScript không framework cũng đã đủ
Phần “hãy ưu tiên HTML ‘thô’ hơn các lớp ẩn biên dịch ra HTML” lấy ví dụ là đừng dùng Rails ERB tag helper, nhưng các helper này xử lý khá nhiều thứ mà nếu viết trực tiếp bằng template tối thiểu sẽ trở nên lộn xộn. Ví dụ đã bỏ qua những phần thực tế như DOM ID duy nhất, thẻ Turbo, xử lý lặp
Thiết lập style và hành vi nên được tách riêng, và ở quy mô có ý nghĩa thì việc liên kết hai phần này chỉ bằng tham chiếu là cách duy nhất hợp lý
Về mặt kỹ thuật, bạn có thể nhét toàn bộ kết nối cơ sở dữ liệu SQL và SQL hard-code của một ứng dụng Python vào một file dài, nhưng đó là thói quen xấu; nguyên tắc này trông cũng tương tự
Phần này gây bối rối: “nếu cần thư viện, hãy dùng thư viện tận dụng thuộc tính HTML thay vì xoay quanh JavaScript hay cú pháp tùy biến”
Nhưng lại đưa _hyperscript [0] làm ví dụ khuyến nghị. Đây là thư viện xoay quanh cú pháp tùy biến, chỉ là nhét script của một ngôn ngữ mới phải học vào bên trong thuộc tính HTML mà thôi. Không rõ có nghiêm túc không
[0] https://hyperscript.org
Các ví dụ cũng khá yếu. Giải pháp thuần, tức chỉ cần mẹo đầu tiên, cũng làm được y hệt
_trông thật sự kỳ lạ và rối rắmThà đặt các câu JavaScript thuần trong
onclickrõ ràng hoặc các thuộc tính sự kiện khác, để biết ngay chuyện gì xảy ra, còn hơnTôi hiểu mục đích. Dùng tính năng tích hợp sẵn của HTML thì gọn gàng và đơn giản
Nhưng 10 năm trước nó đã không thực dụng, và bây giờ cũng vẫn vậy. Tôi cũng không cảm thấy những thứ như htmx đặc biệt tốt hơn các giải pháp nặng hơn như React
Mỗi khi thấy cách tiếp cận kiểu này, câu hỏi tôi đặt ra luôn giống nhau. Dropdown, chọn nhiều mục, bộ chọn ngày trông như thế nào? Trình duyệt có bộ chọn ngày không? Có. Hình thức và hành vi có nhất quán giữa các trình duyệt không? Không. Có thể dùng styling để làm cho khớp không? Cũng không
Chọn nhiều mục cũng tương tự. Bắt người dùng Shift/Ctrl-click để chọn nhiều mục là hoàn toàn không ổn dưới góc độ trải nghiệm người dùng. Phần tử mặc định đến giờ vẫn hoạt động như vậy và không thể thay đổi. Không chỉ chọn nhiều mục, ngay cả phần tử chọn thông thường cũng trông tệ và nhìn chung khó thay đổi
Có lý do mỗi framework mới đều sinh ra các component bên thứ ba kiểu này. Vì chỉ dùng các phần tử tích hợp sẵn là không đủ. Cũng giống như lý do trang Array của MDN mỗi năm đều có thêm tính năng tích hợp sẵn nhưng 90% dự án của tôi vẫn phụ thuộc vào lodash. Đúng là đã tốt hơn 10 năm trước, nhưng vẫn chưa đủ
Người dùng có thể dùng các trình duyệt khác nhau, nhưng một người dùng nhiều khả năng sẽ dùng cùng một trình duyệt trên mọi website họ truy cập
Vì vậy theo tôi, việc bộ chọn ngày nhất quán trên mọi website trong cùng một trình duyệt quan trọng hơn việc nó nhất quán trên mọi trình duyệt trong một website. Tất nhiên nếu cần tính năng tùy biến thì câu chuyện sẽ khác
Khi muốn chọn 10 hay 15 mục liên tiếp trong danh sách, hiện tại tôi không biết UI nào tốt hơn Shift+click
Sẽ tốt hơn nhiều nếu các component UI của mọi website tuân theo giao diện và cảm giác native của trình duyệt, trừ phần thiết kế thực tế của site, thay vì mỗi nơi lại tự phát minh một kiểu style ngớ ngẩn. Dĩ nhiên các trình duyệt cần quan tâm để làm cho chúng trông đẹp
inputvốn khét tiếng vì cách tương tác khác nhau đáng kể giữa các trình duyệt, còn hầu hết các phần tử HTML khác đều có một hành vi tiêu biểu đã được xác địnhTôi đồng ý với hầu hết các lập luận, nhưng bài viết này có vẻ hơi mâu thuẫn. Vì vừa khuyến nghị Tailwind lại vừa nói “hãy tránh bước build”
Việc triển khai các tài nguyên CSS/JS khổng lồ cũng đi ngược lại nguyên tắc bao hàm. Có rất nhiều người không có internet nhanh hoặc máy tính đủ mạnh
Thực ra tôi hoàn toàn không biết Tailwind xuất ra JavaScript phía client nào. Lần cuối tôi dùng là 2.x nên không chắc có gì đã thay đổi không
Về kích thước CSS thì kinh nghiệm của tôi lại ngược lại, output của Tailwind thường nhỏ hơn nhiều so với CSS viết tay
Tất nhiên tôi cũng không phản đối CSS thuần, nhưng làm nó rối tung lên thì ít nhất cũng dễ như vậy
Tuy nhiên theo tôi nhớ thì nó không cung cấp đầy đủ mọi tính năng mà Tailwind hoàn chỉnh có. Nhìn chung tôi thấy hơi khó chịu vì Fresh về cơ bản được xây dựng phần lớn trên Preact và Twind, nhưng lại không thẳng thắn nói rằng trước tiên bạn phải chấp nhận các thư viện đó
Tôi phần nào đồng ý rằng khuyến nghị nó trong ngữ cảnh bài viết này hơi kỳ, nhưng bước build có thể được làm cực kỳ tối giản, và điểm hay là kết quả vẫn là CSS có thể xem xét được
Tôi dùng Tailwind trên trang cá nhân, còn lại toàn bộ là HTML thuần. Việc chạy CLI ở chế độ watch khi viết style không làm tôi thấy phiền lắm
Cả hai đều nhanh đáng ngạc nhiên và parse được hơn 10.000 mục
Về lý thuyết hoặc các ví dụ đơn giản thì thú vị, nhưng tôi muốn thấy một dự án lớn áp dụng cách này và nó thực sự tạo ra khác biệt gì
Các mục tiêu ở phần đầu bài viết rất hay, nhưng bản thân lời khuyên thì khiến tôi hơi thất vọng. Tôi không thấy rõ nó sẽ hoạt động thế nào ngoài những tình huống rất cơ bản, và càng không rõ nó sẽ đạt được các mục tiêu đó ra sao
Tôi ủng hộ việc tận dụng tối đa nền tảng web, và hoàn toàn ủng hộ việc giảm độ phức tạp hết mức có thể. Nhưng tôi rất hoài nghi rằng các nguyên tắc này sẽ đạt được điều đó; thậm chí có vẻ chúng có thể làm tăng độ phức tạp bằng cách tạo ra nhiều cách làm cùng một việc
Nói với thiện ý, chỉ từ danh sách này thì không thể biết liệu các nguyên tắc này đã thực sự được kiểm chứng hay chỉ được giả định là sẽ hoạt động như kỳ vọng
Tôi thật lòng hỏi vậy. Mọi người hay đưa ra lập luận này nhưng tôi luôn không hiểu
Theo góc nhìn của tôi, 95% web là các dự án từ nhỏ đến vừa. Phần lớn công nghệ nên tập trung vào đó. Dùng giải pháp đơn giản cho dự án đơn giản, rồi thêm độ phức tạp sau
Một thứ tương đối khách quan mà chúng tôi đã đánh mất là khả năng truy cập. Vì đã ngây thơ triển khai lại link bằng div gắn click event listener, nên phần lớn site không thể điều hướng bằng bàn phím
Điều này khá đáng lo. Khi quy định pháp lý ập đến, chúng tôi sẽ cuống cuồng giành lại những gì mình đã vứt bỏ
Dù vậy tôi phần nào đồng ý rằng khó tìm được ví dụ về các site “HTML trước tiên” nổi tiếng. Tôi tin vào hướng này, nhưng chưa thấy trường hợp nào được triển khai thực sự tốt. Tuy nhiên lý do có thể hoàn toàn nằm ở giáo dục. Đến khi HTML trở nên mạnh mẽ, việc đào tạo lập trình frontend đã bám rất sâu vào hướng framework
Có vẻ tác giả chưa từng thực sự làm việc này trong một dự án có hơn hai người tham gia và hỗ trợ 99% trình duyệt hiện có. Ngoài ra dường như tác giả cũng chưa chạy thử code của mình. Có thể là vì màn hình của tôi không ngon, nhưng
onlickkhông phải là handler của divNếu bạn tạo ra một sản phẩm trông có vẻ hoạt động nhưng thực tế không hoạt động, họ sẽ không hiểu. Khi đó bạn bị đẩy vào con đường hứa quá nhiều và giao quá ít
Một trong những lợi ích ít được nhắc đến của unit test là nó giúp phần code mà ban lãnh đạo không nhìn thấy được đảm bảo chất lượng nhiều hơn trước khi được kết nối. Nó thu hẹp khoảng thời gian lúng túng từ khi có màn hình đầu tiên đến lúc phát hành
Năm 1999, tôi đã tạo website đầu tiên bằng HTML thuần, CSS, JS thuần và host trên Geocities
Sau đó tôi đã tạo các site và app bằng PHP/WordPress/Yii/Laravel, Ruby/Rails/Sinatra/Jekyll, React/Typescript, ClojureScript
Giờ đây React, component TSX, CSS-in-TS, Effects, Context khiến tôi thấy như ở nhà. Cuối cùng cũng có cảm giác có một ngôn ngữ lập trình hoàn chỉnh cho web/frontend. Một ngôn ngữ được tạo ra rõ ràng cho frontend, dựa trên các nguyên tắc hiện đại như lập trình hàm và phản ứng
Giờ tôi mới có thể phát triển phần mềm. Trước đó, HTML, CSS, JS thuần, PHP gần như chỉ là hack. Rails tốt cho full-stack nhưng không thực sự tỏa sáng ở frontend
Khi web stack sẵn sàng cho cả app, tôi sẽ bỏ qua framework. Hiện tại tôi thừa nhận có lẽ nó đã đủ cho các site
Năm nay tôi đã bỏ cuộc. Giờ việc tiếp tục chiến đấu với những con quái vật React, Vue, Angular cùng bundler, transpiler và đủ thứ linh tinh đi kèm đã trở nên bất khả thi
Node và npm ném vào cả những dự án vừa mới tạo được vài giây thông báo rằng có “7 lỗ hổng nghiêm trọng và 8 lỗ hổng chí mạng”. Phải tải xuống hàng nghìn file, và trong đó có thể có cả những thứ như wrapper cho giá trị boolean
Có vẻ với tôi, thời kỳ server backend Python đồng thời phục vụ cả frontend đã kết thúc
Thực ra bạn, cũng như bất kỳ ai khác, không thật sự cần sự phình to nặng nề của frontend JavaScript. Chỉ cần từ chối là được
Hãy phục vụ các trang nhẹ từ backend hoặc cache, và nếu thật sự cần thì xử lý các phần hào nhoáng bằng CSS
Bạn sẽ đón nhận thời gian render nhanh và khả năng truy cập trên toàn cầu
Tuy nhiên, nói thật thì các ví dụ trong bài này khá kỳ lạ. Không hiểu vì sao phải tự viết các tag thuần thay vì dùng helper form của Phoenix, vốn tự động xuất ra lỗi và nhiều tiện ích khác. Tôi hiểu tinh thần của nó
Luận điểm cốt lõi có vẻ là người dùng phải có thể nhấn View Source để hiểu chuyện gì đang diễn ra. Nếu là website thì tôi đồng ý
Với webapp, ít nhất là thứ dài hơn 50 dòng, rất có thể bạn sẽ muốn dùng một ngôn ngữ có kiểu. Về mặt kỹ thuật có thể dùng
.jsvới chú thích kiểu bằng comment đặc biệt và gắn compiler TypeScript vào, nhưng trải nghiệm không mấy thú vịTrước đây tôi từng bị ý tưởng này cuốn hút khá mạnh, và thật buồn khi phần lớn website ngày nay là một cục HTML một dòng không thể đọc nổi. Có một vẻ đẹp và sự thanh nhã trong việc triển khai toàn bộ bằng một file HTML duy nhất, không phụ thuộc. Chỉ cần 1 request mạng
Cuối cùng, để chỉnh sửa cho thuận tiện, tôi cũng tạo một “build system”, nhưng build system của tôi là
cat. Nó trở thành một phần mềm tự chứa, di động, nằm trong một file mà con người có thể đọc đượcCùng mạch đó, điều tuyệt nhất của phát triển web là bạn có thể tạo chương trình tương tác đầu tiên chỉ bằng Notepad và trình duyệt mặc định. Chỉ cần kéo thả file HTML vào trình duyệt. Như phép màu vậy
Bổ sung: tôi phát hiện một lợi ích ngoài dự kiến của HTML tự chứa. Phần mềm trở nên miễn nhiễm với bit rot. Tôi mở một dự án cũ trên Web Archive thì file JS bên ngoài không được lưu trữ. Buồn. Trong khi cái này tải tốt vì toàn bộ JS nằm trong HTML. Chiến thắng
https://web.archive.org/web/20210508133239id_/https://andai....
Đây là một lời tri ân dành cho SodaPlay Constructor ngày xưa. Tôi đã không làm được editor. Cứ thoải mái xem source
Có chế độ xem DOM, tab network, chế độ xem heap, và tính năng làm đẹp JavaScript tích hợp
Tất nhiên “xem source” vẫn quan trọng, nhưng tôi nghi ngờ liệu tầm quan trọng đó còn tuyệt đối như những người bên HTMX nói hay không
Giờ đã có URL
data:nên việc này còn dễ hơn. Nó cũng hữu ích để tránh các vấn đề của URLfile://, vốn thậm chí không cần HTTP serverhttps://github.com/tc39/proposal-type-annotations
“Tính cục bộ của hành vi” là một quy tắc được định nghĩa quá lỏng lẻo. Nó chỉ là gọi bằng một cái tên mới cho thứ đi ngược lại với phân tách mối quan tâm
Việc gọi CSS là tác động ma quái từ xa cũng quá phóng đại. Có những nguyên tắc tốt, nhưng lập luận khá yếu và có thể nói đơn giản hơn nhiều
Nếu việc “đổi một nút đỏ nảy tưng tưng thành một nút xanh lam lắc lư” đòi hỏi phải lần theo mê cung 3–7 interface và class để tìm xem class nào cần implementation mới và cái nào có thể tái sử dụng, thì một thay đổi nghe như mất 10 phút sẽ biến thành nửa ngày vừa làm vừa thầm chửi compiler hoặc lập trình viên trước đó
Tất nhiên là nên trừu tượng hóa, nhưng cũng cần có cách gom hành vi vào một chỗ để không phải đụng tới 6 file chỉ để sửa một component
https://htmx.org/essays/locality-of-behaviour/#conflict-with...
Dùng Tailwind nghĩa là tin rằng một thư viện bên thứ ba sẽ trừu tượng hóa đặc tả CSS thay bạn, và rằng đặc tả gần đúng đã được trừu tượng hóa đó sẽ được tuân theo dựa trên cấu hình build
Cần tách cái gì? Chia theo ranh giới nào? Xác định ranh giới đó như thế nào? Khi nào thì hợp lý để đưa một mối quan tâm sang class, framework, markup khác, v.v.? Khi nào thì để chúng nằm cùng nhau lại tốt hơn?
Câu trả lời là “tùy tình huống”
Nếu không tách gì cả thì sẽ thành spaghetti, còn nếu lúc nào ở đâu cũng tách tối đa thì sẽ thành code trừu tượng hóa quá mức, khó bảo trì chẳng kém spaghetti
Nếu mặc định hoạt động tốt thì tùy biến không phải là bắt buộc. Vì vậy lợi ích về hiệu suất của CSS và các thứ tương tự bị xếp sau sự đơn giản
Nếu xem HTML là ngôn ngữ tài liệu/biểu diễn thì không thể phủ nhận styling. CSS không chỉ thêm styling mà còn thêm animation
Dù sao thì CSS cũng có thể được xem là lập trình hướng khía cạnh
Vấn đề thực sự được mô tả ở đây là thiếu công cụ tốt xuyên qua các ngôn ngữ và framework
Dựa vào framework đơn giản hơn khi có thể là hợp lý. Nhưng ý tưởng loại bỏ bước build thì gần như là một trò đùa hoàn toàn
Hãy làm cho bước build hiệu quả hơn, và nếu cần thì đừng đưa nó vào production
Tôi cũng không hiểu tại sao phải ưu tiên việc thêm thuộc tính vào HTML. Có phải là tạo tài liệu rồi host thành website không? Ngoài trường hợp đó, trong thế giới nào thì cách đó được ưa chuộng? CSS không khó điều hướng, và ngược lại ta nên khuyến khích các thực hành CSS tốt hơn
Script frontend có thể làm mờ phần styling, nhưng nếu không cần thì đừng dựa vào cách đó. Đưa vào tài liệu style dễ hơn là thêm thuộc tính bằng JavaScript, nên chuyện này vốn đã hiển nhiên
Một số lời khuyên kiểu chỉ dùng những gì cần thì hợp lý và rõ ràng. Nhưng phần còn lại thì gây bối rối hoặc thẳng thừng là vô lý. Tôi cũng không hiểu vì sao lại mặc định rằng việc có thể sao chép toàn bộ trang HTML là điều tốt. Thành thật mà nói, tôi không bận tâm, và dù không thể xem HTML của vài trang thì tài nguyên để học HTML đã có đúng nghĩa là hàng triệu
Nhìn chung là khiến tôi phải nghiêng đầu thắc mắc
Toàn bộ bài này là anti-pattern và lời khuyên tệ. Đọc như thể được viết bởi người chưa từng trải qua đau đớn khi phát triển một website phức tạp
Ban đầu chúng tôi cũng xây website như thế này, nhưng rồi nó bắt đầu vỡ vì side effect, tên class xung đột và khả năng quan sát nội bộ kém, và React đã đến cứu
Pattern mong muốn là cải tiến lũy tiến, và output phải là HTML sạch, đã nén, còn JavaScript sẽ bổ trợ cho nó. Tức là cần bước build. Điều này hoàn toàn trái ngược với lời khuyên trong bài
Nếu backend chưa dùng NodeJS, thì tốt hơn là nên tránh ReactJS trừ khi thực sự cần