Nghịch lý của site tĩnh
(kristoff.it)- Ngay cả với các site đơn giản như blog cá nhân hay trang liên hệ, người dùng phổ thông vẫn ở lại với CMS như WordPress, trong khi site HTML tĩnh lại là thứ các kỹ sư chuyên nghiệp dễ vận hành hơn — một hiện tượng đảo ngược
- Để tự tạo site tĩnh, bạn phải tự xử lý nhiều bước trung gian, từ mua tên miền, chọn hosting, thiết lập DNS, chọn SSG cho đến cấu hình pipeline triển khai
- Kỹ sư tận dụng hosting miễn phí và tên miền tùy chỉnh qua GitHub Pages hoặc Cloudflare Pages, còn người dùng phổ thông, dù site tĩnh là đủ, lại phụ thuộc vào các dịch vụ đắt hơn và nặng nề hơn
- SuperHTML được giới thiệu là HTML language server đầu tiên báo cáo chẩn đoán cho người dùng; các công cụ chẩn đoán hiện có nhìn chung gắn với một framework frontend cụ thể, nên khó dùng chỉ với vanilla HTML
- Nếu không thể làm cho phát triển web đơn giản trở nên dễ dàng, web sẽ ngày càng xa rời người không chuyên, và người dùng phổ thông sẽ bị đẩy vào các không gian đóng như mạng xã hội
Nghịch lý: site tĩnh trở nên khó hơn
- Hai ví dụ về website cá nhân được đặt cạnh nhau
- Một site là CMS phức tạp viết bằng PHP, cần web server, nhiều worker, cache Redis và cơ sở dữ liệu SQL
- Frontend cũng được tải dưới dạng Single Page Application, yêu cầu nội dung ở dạng JSON rồi dựng lại ở phía client
- Site còn lại gồm các file HTML tĩnh và một hoặc hai file CSS, không có JavaScript
- Nhìn bề ngoài, có vẻ người dùng phổ thông sẽ dùng site tĩnh đơn giản, còn kỹ sư chuyên nghiệp sẽ dùng kiến trúc phức tạp, nhưng thực tế gần như ngược lại
- Để người dùng phổ thông tự vận hành site tĩnh, họ phải vượt qua nhiều bước
- Mua tên miền
- Tìm nền tảng hosting
- Thiết lập DNS
- Chọn SSG hoặc tự xây dựng
- Cấu hình pipeline triển khai
- Ngược lại, kỹ sư phần mềm có thể tận hưởng hosting miễn phí và hỗ trợ tên miền tùy chỉnh thông qua GitHub Pages, Cloudflare Pages, v.v.
- Kết quả là, ngay cả trong 99% trường hợp chỉ cần website tĩnh là đủ, người dùng phổ thông vẫn bị buộc vào các giải pháp phức tạp, tốn nhiều chi phí hơn và dùng nhiều tài nguyên tính toán hơn
Nhu cầu về công cụ giúp web đơn giản trở nên dễ làm
- Bài nói tại SquiggleConf ở Boston đề cập đến trải nghiệm triển khai HTML language server, và kết luận dẫn đến vấn đề khả năng tiếp cận web
- SuperHTML được giới thiệu là HTML language server đầu tiên báo cáo chẩn đoán cho người dùng, và bài viết liên quan đã lên trang nhất Hacker News
- Linter thì có tồn tại và editor cũng có thể hiển thị chẩn đoán, nhưng thường bị gắn với một framework frontend cụ thể
- Vì vậy người dùng sẽ chọn framework ngay cả khi thực sự không cần sự phức tạp đó
- Web không phải chỉ thuộc về kỹ sư phần mềm; càng làm web phức tạp hơn, người dùng phổ thông càng bị đẩy vào hàng rào mang tên mạng xã hội
- Startup hay Big Tech khó có thể giải quyết thay vấn đề này vì động lực kinh tế không phù hợp, và cần làm cho web đơn giản trở nên dễ làm hơn
1 bình luận
Ý kiến trên Hacker News
Tôi đã có nhiều trải nghiệm cay đắng khi cố thuyết phục các marketer bỏ WordPress để dùng site tĩnh
Rốt cuộc, điểm cốt lõi là dễ biên tập. Site WordPress được tối ưu cho biên tập viên, chứ không phải cho hosting, người phụ trách kỹ thuật, kế toán hay độc giả; và những người chỉnh sửa site sẽ là người quyết định cách triển khai
Nếu bắt họ chọn giữa một site render dưới 100ms, hoàn toàn an toàn, chi phí hosting bằng 0 nhưng cần file Markdown và một chút triển khai bằng Git, với WordPress chậm, đắt, dễ tổn thương và cần bảo trì liên tục nhưng có trải nghiệm biên tập tốt, họ luôn chọn WordPress
Tôi luôn bối rối vì sao những người này lại có quyền lựa chọn, nhưng dù lặp lại cùng một thử nghiệm nhiều lần thì kết quả vẫn luôn như vậy
Tôi không hiểu vì sao việc chọn WordPress thay vì học trình soạn thảo văn bản và Git lại kỳ lạ. Thử nghiệm nên là so sánh WordPress với một công cụ vẫn cung cấp trải nghiệm biên tập tốt nhưng phía sau tạo ra site tĩnh và triển khai bằng Git. Khi đó các yêu cầu phụ như bảo mật và tốc độ mới có ý nghĩa
Thay vì là blog, nó gần với một ứng dụng tùy biến mà người không chuyên có thể nhấp và kéo để đập nặn theo chức năng mong muốn. Không cần lập trình cho đến khi bị hack hoặc phát sinh tính năng tùy chỉnh thật sự cần kỹ sư thực thụ
Dùng Hugo, Ghost, v.v. thì sẽ dẫn đến “cái này cần một nền tảng khác”, và nền tảng đó sẽ là Shopify, hệ thống kế toán, plugin mạng xã hội/thành viên, bảng đăng tin tuyển dụng, v.v. WordPress đã trở thành thứ có thể biến thành bất cứ gì
Khi ai đó nói với consultant điều họ muốn, câu trả lời sẽ là “tôi sẽ cấu hình bằng WordPress cho bạn”; và vì ai cũng dùng WordPress, nên khi có vấn đề, hoặc cần chỉnh nhẹ plugin, hoặc gắn hook gửi email, rất dễ tìm người làm. Thời đại của các consultant PHP đã tạo nên sự thống trị của WordPress
Vấn đề là phần lớn, kể cả các giải pháp trả phí, không phải là giải pháp hoàn chỉnh. Khi bắt đầu dùng, bạn sẽ nhanh chóng nhận ra WordPress áp đặt những ràng buộc vô lý. Bạn không thể thiết kế một cửa hàng online bên ngoài thảm họa hiệu năng của hệ thống entity/metadata, nơi ngay cả truy vấn cỡ vừa cũng mất 5 giây và tạo ra 50 truy vấn phụ không được tối ưu. Một số plugin thậm chí còn né WordPress và tạo bảng cơ sở dữ liệu riêng
Ngoài blog ra thì WordPress có kiến trúc tệ hại, nhưng lại được dùng như công cụ cho mọi thứ. Các CMS khác không làm như vậy, nên người ta không dùng chúng
Nội dung vẫn có thể được phân phối qua CDN dưới dạng các file tĩnh được tạo sẵn. Site tĩnh không nhất thiết phải yêu cầu Markdown và Git
Tôi đã tìm kiếm rất lâu một toolchain cho phép ngay cả thực tập sinh không có chút kinh nghiệm kỹ thuật nào cũng có thể triển khai các chỉnh sửa mà không bị vướng vào chi tiết kỹ thuật, nhưng vẫn chưa tìm được
Gần nhất là đặt static site generator lên trên headless CMS, nhưng nói thật là tất cả đều khá tệ
Năm 2016, khi tôi làm ở một agency chuyên làm site giới thiệu cho doanh nghiệp địa phương, có một khách hàng nhờ chúng tôi chèn một iframe nhỏ cho hệ thống đặt chỗ vào website họ tự làm. Thứ họ gửi là một tài liệu Word, và hóa ra họ xuất nó ra HTML rồi đưa lên một gói shared hosting giá rẻ.
Cách đó cực kỳ phù hợp với họ. Họ có thể luôn giữ menu online cập nhật, vì chỉ cần xuất thẳng từ tài liệu Word vốn dùng để làm menu in. Hồi đó nội bộ chúng tôi hơi cười cợt, nhưng giờ nghĩ lại tôi thấy có lỗi. Khi có cả triệu việc quan trọng hơn như vận hành nhà hàng, đó thực ra là một cách làm thiên tài.
Việc tạo site tĩnh vẫn dễ hơn. Chỉ là các công cụ soạn thảo tạo HTML hiện nay hoặc khá tệ, hoặc dù ổn thì vẫn kèm theo một quy trình phải chạy trên server để phục vụ site.
Việc của tôi không phải là chế giễu rằng “có thể làm tốt hơn”, mà là cải thiện giải pháp của họ, bảo đảm giải pháp tôi đưa ra hoạt động ít nhất tốt bằng cách cũ, nếu có thể thì tốt hơn, đồng thời không cản trở những thành công họ đã đạt được.
Nhiều lập trình viên không muốn thừa nhận, nhưng những giải pháp web tạm bợ kiểu này thường hoạt động tốt hơn nhiều chiến lược mà một web developer lành nghề tự triển khai.
Điều quan trọng là doanh nghiệp cung cấp gì, xây dựng quan hệ và tương tác với khách hàng ra sao. Đôi khi chỉ xuất một tài liệu Word ra HTML là đủ. Công nghệ có thể cải thiện, nhưng phép màu thật sự nằm ở những người vận hành doanh nghiệp.
Tìm cách cải thiện các giải pháp kiểu này đôi khi thực sự khá khó. Ta có thể làm một website tốt hơn và triển khai lên hạ tầng tinh vi, nhưng rốt cuộc khách hàng có thích hơn không? Doanh nghiệp có tốt lên không? Phần đó có thể hoàn toàn không hề nhỏ.
Tôi đã tìm một lựa chọn thay thế tốt trong nhiều năm, thứ tạo HTML đúng chuẩn hơn tính năng xuất HTML của Word và cho nhiều tùy chọn hơn.
Tôi thích những thứ như vậy. Có rất nhiều site dạng một file HTML duy nhất được làm bằng Vue template, rồi các site đăng bằng tài liệu Notion công khai hay thư viện ảnh inline trên iCloud. Thật đáng ngạc nhiên khi việc chỉ kết nối mọi thứ đã trở nên dễ và phổ biến đến thế, và cũng khiến tôi nhận ra chúng ta thường làm phức tạp mọi việc đến mức nào khi cố tự làm từ đầu.
Khi không có thời gian, tôi cũng thích những công cụ như mmm.page để ghép nhanh các micro-site nhỏ hoặc site dùng một lần. Khám phá các công cụ kiểu này rất thú vị.
Nhưng “tài liệu” trên một số trang lại là các cụm bảng có ngày tháng và văn bản, do khách hàng tự quản lý. Cuối cùng giải pháp chúng tôi đi đến cũng tương tự. Họ đặt bảng vào tài liệu Word và đưa cho chúng tôi, rồi chúng tôi xuất ra HTML/CSS và đặt vào đúng vị trí.
Không thanh lịch, cũng không phải giải pháp có khả năng mở rộng, nhưng trong trường hợp sử dụng đó thì rõ ràng là cách dễ nhất.
Khi đó thật kỳ diệu, và bây giờ vẫn vậy. Một cách lặng lẽ, chúng ta đã hoàn thành giấc mơ đưa điện toán đến với mọi người.
Hiện giờ ở Asheville đang gặp vấn đề này rất nặng. Ngay cả khi dịch vụ di động mới chỉ vừa hoạt động trở lại, mọi người vẫn dùng 3G chập chờn liên tục rớt mạng, và không website nào chứa thông tin sinh tồn cơ bản tải được.
Những người tốt bụng đã làm một site tin tức chỉ có văn bản, và hôm nay tôi thấy website của Buncombe County cũng có một site băng thông thấp, nhưng mở ra thì vẫn có 130KB Bootstrap CSS và 50KB jQuery chặn render.
Việc mọi người làm những thứ này là rất đáng quý, nhưng người dân đã cần chúng từ một tuần rưỡi trước. Giờ thì chúng tôi đã biết lấy nước, thực phẩm, nước không uống được, v.v. ở đâu rồi. Trải qua chuyện này và thấy công nghệ thất bại tệ đến vậy khiến tôi mở mắt theo một cách khá u ám.
Bản đồ mất điện của công ty điện lực bị đặt sau đăng nhập, lại được render bằng các tính năng UI và clustering hào nhoáng nên ngay cả khi kết nối tốt cũng đã chậm. Vì vậy chỉ để kiểm tra trạng thái hoặc báo mất điện cũng mất khá lâu.
Cũng có thể gọi điện cho công ty điện lực, nhưng họ chọn menu bằng điều hướng giọng nói thay vì tone bàn phím, và hệ thống không nhận diện tốt giọng nói bị méo trên kết nối 4G hay 2G tệ.
Cần bước sóng dài và công suất thấp. Nhưng khả năng tiếp cận quá thấp, và tôi không chắc điều đó có phải vì những lý do hợp lý hay không.
Kết nối đã bị cắt từ Black Mountain đến tận ranh giới Tennessee và Georgia. Tôi nghi ngờ liệu có nhiều người bắt lại được dù chỉ là 3G tệ hại hay không. Điều tôi biết là rất khó giữ liên lạc với những người tôi quen sống ở đó.
Một số việc tốt nhất tôi từng làm là trên chiếc MacBook 12 inch kết nối với Wi‑Fi khách sạn chập chờn. Vì vậy tôi rất chú ý đến tốc độ trang.
Nếu tóm gọn nỗi khổ của thảm họa này trong một câu, thì đó là sự sụp đổ giao tiếp theo đủ mọi cách.
Tôi rất đồng cảm với câu: “Web không chỉ thuộc về các kỹ sư phần mềm. Càng làm web phức tạp, chúng ta càng đẩy người dùng phổ thông vào những hàng rào mà ta gọi là mạng xã hội”
Cũng có một podcast liên quan đến hội nghị Squiggle Conf gần đây, nơi trích dẫn này xuất hiện: https://changelog.com/jsparty/339
Theo thời gian, những tính năng mà mọi người kỳ vọng ở một “website cơ bản” đã tăng lên rất nhiều
Ngay cả tôi là lập trình viên cũng đã vài lần rơi vào cái bẫy của trình tạo site tĩnh
Thật bực mình khi bắt đầu một side project bằng trình tạo site tĩnh, rồi đến lúc muốn thêm một tính năng nhỏ lại hối hận rằng lẽ ra nên bắt đầu bằng một ứng dụng Rails hoặc PHP đơn giản
Dạo này nếu cần một site tĩnh, tôi chỉ bắt đầu bằng một thư mục các file HTML. Con đường từ ý tưởng đến thực thi ít phức tạp và nhanh hơn nhiều, không phải tranh luận suông hay trì hoãn vì công cụ
Tôi khá hài lòng với việc tự viết HTML và CSS, nhưng không khuyên tất cả mọi người làm vậy
Một điểm hay nữa là về sau nếu quyết định “thoát” sang Rails, chỉ cần sao chép thư mục file HTML vào thư mục public/ của Rails. Lộ trình nâng cấp khá dễ
Trong thế giới Ruby, Jekyll là nổi tiếng nhất, nhưng nó được thiết kế cho một mục đích cụ thể là viết blog bằng Markdown hoặc một ngôn ngữ đánh dấu nhẹ khác. Có thể gò nó sang mục đích khác, nhưng với vai trò một trình tạo site tĩnh đa dụng thì không thật sự tiện
Nếu muốn thứ gì đó dễ sao chép/dán vào Rails, middleman, một trình tạo site tĩnh dựa trên Rack, là lựa chọn tốt. Có thể viết bằng erb/haml và ActiveSupport ngay từ đầu
Nếu muốn giữ sự đơn giản của việc viết HTML và CSS thủ công, nhưng chỉ cần các tiện ích như include, partial template, link helper, thì nanoc là một trình tạo site tĩnh theo hướng tăng dần khá ổn. Hãy bắt đầu bằng HTML/CSS bình thường và chỉ thêm tính năng khi cần
Thỉnh thoảng tôi viết code để tùy biến hành vi, nhưng cũng chỉ vài năm một lần. Nó đơn giản và cứ thế chạy tốt
Có những thứ ở site động mà tôi nhớ, nhưng tôi không rõ một thư mục file HTML đơn giản thì tốt hơn Pelican ở điểm nào
Quy tắc nền tảng tôi đặt ra để ngăn website phình to về tính năng là xác định danh tính mình muốn. Tôi muốn nó là kho lưu trữ những việc mình đã làm, và đã là kho lưu trữ thì phải tồn tại rất lâu theo thời gian. Vì vậy các file tĩnh, dễ sao chép, mirror và chạy trên bất kỳ nền tảng hosting nào là phù hợp
Mất một thời gian để xử lý đúng site đa ngôn ngữ, nhưng ít nhất đó là chi phí chỉ phải trả một lần
Việc đổi style cũng có thể thành vấn đề nếu mọi thứ bị hard-code trong các file HTML
Các tác vụ nâng cao hơn thì tôi viết bằng Django. Với tôi, thêm tính năng vào đó rất dễ
.md→.htmlcho nội dung, nhưng đến giờ vẫn chưa cầnViệc có thể dễ dàng xem site bằng server cục bộ cũng rất tốt. Tốt nhất là có thể xem bằng file://, nhưng tôi chưa hoàn toàn giải quyết được cấu trúc, nên kết lại bằng một bước
make localđể tạo một bản sao riêng cho việc xem dựa trên fileWebsite cá nhân của lập trình viên web có một yếu tố làm nó phức tạp: phát triển theo định hướng CV
Có những chuyên gia muốn dùng side project cá nhân cho phát triển theo định hướng CV, và cho rằng như vậy sẽ giảm khả năng làm hỏng dự án của nhà tuyển dụng
Ví dụ, ngay sáng nay tôi có một website độc lập sắp công khai, chủ yếu vì lý do CV nên nó dùng một web framework hiện đại đang phổ biến, nhưng rồi không thể cập nhật website được nữa
Một gói NPM có vấn đề bảo mật nghiêm trọng, và khi cố cập nhật thì NPM vướng vào xung đột phụ thuộc lẫn nhau mà nó không thể tự giải quyết. Trớ trêu là vì thế tôi không thể push bản cập nhật bảo mật lên site production
Site đó có lẽ chỉ cần 5 file HTML viết tay, một ít JS inline và 2 script Perl CGI nhỏ. Khi đó sau 25 năm nó vẫn có thể hoạt động hoàn hảo
Thay vào đó, chỉ riêng phần NodeJS đã có 129 gói NPM, các bản cập nhật bảo mật thường xuyên cần thiết, một cây mã nguồn khó hiểu gồm các mảnh template, cấu hình TS và handler
Nhưng các chuyên gia không có đủ dư địa để không làm theo cách phức tạp đến vô lý. Ví dụ nếu trên CV có Perl thì đó là một cú đánh chí mạng vào khả năng được tuyển dụng. Ngay cả những người không vứt CV đi vì phân biệt tuổi tác cũng sẽ cho rằng bạn là đồ ngốc vì không phát triển theo định hướng CV
Trường hợp của tôi thì hoàn toàn không quan tâm đến CV hay đề xuất, nhưng tôi vẫn muốn một thứ ergonomic hơn việc xuất HTML từ template JS/Python. Vì vậy các site của tôi là sự kết hợp giữa TypeScript, Mithril, Express và vài thư viện tiện ích
Tôi không biết có bao nhiêu gói và cũng không quan tâm. Miễn là những thứ tôi đưa vào chủ yếu đã trưởng thành và không sinh ra tính năng-lỗ hổng mới mỗi vài phút là được
Bạn không nói stack là gì, nhưng nhiều khả năng là React và hệ sinh thái “luôn cải tiến nhưng không bao giờ kết thúc” của nó. Nếu được đưa ra một lời khuyên không ai hỏi, thì tốt nhất là đừng tin vào lưỡng phân giả. Có một khoảng rất rộng giữa HTML thuần và vũng bùn tệ hại nhất, và tình hình trong thế giới React là đặc thù của React, chứ không đại diện cho cả bên ngoài
Killer app của WordPress là bình luận. Trình tạo site tĩnh gần như theo định nghĩa là không cho phép bình luận, nhưng blog WordPress thì hầu như luôn có sẵn tính năng này
Nếu những thứ như Hugo thật sự muốn nổi lên trong mảng blog, chỉ cần làm một theme đẹp có bình luận là được. Giải quyết ở quy mô lớn là xong. Ví dụ, có thể dùng SQLite được shard theo từng blog để bên thứ ba host với chi phí rất rẻ. Khi đó nó sẽ trở thành một con ngỗng nhỏ đẻ trứng vàng
Bình luận và thảo luận về bài viết nằm ở các cộng đồng bên thứ ba như Reddit, HN, Facebook. Giữa số người lướt danh sách bình luận dưới một bài Substack và số người đọc một hai trang bình luận HN về cùng bài đó, bên nào nhiều hơn?
Nếu là bài viết liên quan đến kỹ thuật, tôi cho rằng thảo luận trên HN gần như chắc chắn có chất lượng cao hơn chuỗi bình luận của riêng bài viết đó. Vì HN đã thu hút được lượng độc giả rộng hơn 99,9% tổng số blog
Ưu điểm chính của việc bình luận trực tiếp trên bài blog chỉ là khả năng tác giả nhìn thấy cao hơn nhiều. Trạng thái chốc lát xuất hiện trên trang nhất HN là rất phù du
Hệ sinh thái WordPress thì hoàn toàn ngược lại. Nó là tập hợp các doanh nghiệp trị giá hàng tỷ đô la, hiểu sâu những người vận hành CMS và website cần gì trong từng ngách thị trường nhỏ của họ; quy mô thị trường này vào khoảng 500 triệu website
Người viết bài này có thể thông minh, nhưng rõ ràng không thông minh về các ứng dụng thực tế của CMS. Thế giới quan rằng “site HTML tĩnh tốt hơn nhưng không phổ biến vì các công ty xấu xa” sẽ nhanh chóng bị chứng minh là gần như sai khi bạn làm website lấy tiền cho khách một hai lần
Trình tạo site HTML tĩnh gần như không có khả năng làm mọi thứ khách hàng muốn. WordPress đã nhận ra từ lâu thị trường này rộng và đa dạng đến mức nào, nên đã triển khai hỗ trợ plugin
Tôi đồng ý 100% rằng bình luận là một trong những mục đích ban đầu để dùng thứ gì đó gần với CMS trên web thay vì trình tạo site tĩnh. Nhưng ngoài ra còn có cả triệu mục đích khác
Chỉ với tài liệu HTML tĩnh thì không đi xa được lắm. Khi rời khỏi blog lập trình viên tối giản, bạn cần rất nhiều logic chương trình để làm những gì người dùng và khách hàng thực sự muốn. Vì vậy hãy dùng CMS phù hợp nhu cầu, và nếu muốn chịu được nhiều lưu lượng thì cache mạnh tay. Đó cũng là một phần của công việc
Tôi thật sự không hiểu vì sao các lập trình viên tự cho mình giỏi lại muốn phát minh lại bánh xe thay vì học một chút về cách caching hoạt động rồi áp dụng nó. Có phải vì đây cũng là một “vấn đề đã được giải quyết” quá nhàm chán không?
Tôi cũng dùng Hugo, nhưng xét từ góc độ kỹ thuật dù footprint của WordPress lớn không cần thiết, trải nghiệm người dùng của WordPress vẫn thân thiện hơn nhiều
Không phải site doanh nghiệp nào cũng muốn bình luận, nhưng có lẽ họ sẽ muốn biểu mẫu liên hệ. Công khai địa chỉ email cũng là một lựa chọn, nhưng xử lý pipeline nhập liệu thì tốt hơn
Với site tĩnh, bạn phải tìm một dịch vụ đáng tin cậy để xử lý submission và gắn nó vào site cho đúng. Lại thêm một bộ phận chuyển động, có thể thành một hóa đơn riêng phải trả, và thêm một thứ cần xử lý khi ngành này hợp nhất
https://hn.algolia.com/?q=%22disqus%22
Facebook cũng từng cung cấp hệ thống bình luận được nhiều site dùng, nhưng đã mất niềm tin và độ phủ vì nhiều bê bối
Tôi cũng đúng với nghịch lý đó. Tôi đã viết lại website cá nhân của mình bằng PHP hiện đại, không framework hay cơ sở dữ liệu
Phần lớn là site tĩnh, nhưng tôi dùng PHP để gắn header và xử lý các danh sách như danh sách bài blog. Không hoàn toàn tĩnh thì tiện hơn một chút. Viết bài, commit, push là nó lên online ngay. Hầu hết trình tạo site tĩnh khiến tôi cảm thấy quá phức tạp
Mã cho một trang đơn đại khái là
title = "Blog Article Title";,$this->shortTitle = "Title";,$this->date = mktime(0,0,0,1,27,2024);,if ($this->mode == PageMode::Meta) return;rồi đến nội dung HTML thôRouter tự động gắn header và footer của site, và nếu thêm file
_layout.phpvào một thư mục thì có thể gắn thêm một tầng layout cho các trang con. Trang danh sách blog quét các file bài viết riêng lẻ trong thư mục để tạo indexĐây là chỗ dùng
$this->mode == PageMode::Meta. Nó chạy mã của từng file để lấy metadata, rồi thoát trước khi render phần còn lại. Nếu nội dung nhiều lên thì khả năng mở rộng sẽ không tốt, nhưng nếu thành vấn đề thì tôi sẽ điều chỉnhToàn bộ mã PHP của “framework” của tôi chỉ gồm bốn file:
init.php,functions.php,Layout.php,Page.phpLợi thế của lập trình viên là có thể dùng code thay vì cấu hình hay dữ liệu. Bạn cũng có thể dùng code để viết nội dung hiệu quả hơn
Kết quả vẫn còn khá dang dở, nhưng ở đây: https://www.codaris.com/
include()Nếu xét trải nghiệm người dùng từ góc nhìn của chủ sở hữu website thì đây không hẳn là nghịch lý. WordPress giúp mọi việc trở nên dễ dàng đến mức khó tin, dù overhead lớn hơn nhiều
Nó chỉ trông giống nghịch lý khi coi đó là sự đánh đổi với việc bỏ thời gian cấu hình đủ thứ. Với phần lớn mọi người, lựa chọn thay thế là trả tiền cho ai đó làm website giúp mình
Nếu bạn làm một trình biên tập WYSIWYG cho Hugo và khiến mọi thứ từ đăng ký domain đến xuất bản site chỉ cần vài cú nhấp chuột, bạn có thể kiếm được rất nhiều tiền
Tôi hiểu ý bạn. Dù các công ty đó đã khá gần với điều bạn nói, nếu có thể xử lý các bước nhỏ ở giữa thì sẽ là lợi thế lớn cho ai đó
[1] https://micro.blog
Phần “Khi công bố SuperHTML, tôi biết đây là language server đầu tiên cho HTML báo cáo chẩn đoán cho người dùng. Tôi đã viết một bài blog, nó lên trang nhất Hacker News và không ai đính chính, nên đó là sự thật” có lẽ là vì phần lớn IDE đã làm việc này trong nhiều năm, từ trước cả khi Microsoft đưa ra LSP
Vim, Neovim, Helix, Zed, VSCode đều dùng chung một triển khai mặc định không hỗ trợ chẩn đoán
Helix dự kiến sẽ bật SuperHTML mặc định từ bản phát hành tiếp theo: https://github.com/helix-editor/helix/pull/11609