- Có thể dùng XSLT như một hệ thống build phía client chạy ngay trong trình duyệt web để chuyển dữ liệu XML thành HTML, từ đó giảm bớt sự phức tạp của các static site generator
- Một website tĩnh điển hình gồm dữ liệu như
.json, .md, .txt, hệ thống build như Hugo, Next.js, Astro, và đầu ra HTML tĩnh, nhưng các framework lớn có thể tạo ra độ phức tạp quá mức ngay cả với một blog Markdown đơn giản
- Nếu chỉ muốn dùng HTML và CSS, bạn sẽ phải tự sao chép header và footer cho nhiều trang, không có HTML import, còn Web Component thì cần JavaScript engine
- Nếu thêm
<?xml-stylesheet type="text/xsl" href="blog.xsl"?> vào tài liệu XML và viết template XSLT, trình duyệt có thể tạo đầu ra HTML tại thời điểm truy cập
- Cách này có thể được triển khai dưới dạng file tĩnh mà không cần JavaScript, nhưng không phải là lời giải hoàn hảo thay thế mọi thứ, mà là một lựa chọn khác có thể thêm vào bộ công cụ phát triển web
Độ phức tạp của việc build static site
- Quy trình tạo một website tĩnh thông thường được chia thành dữ liệu, hệ thống build và đầu ra HTML tĩnh
- Dữ liệu được lưu trong các file như
.json, .md, .txt
- Ví dụ về hệ thống build gồm Hugo, Next.js, Astro
- Kết quả cuối cùng là HTML tĩnh
- Ngay cả khi muốn loại bỏ framework và chỉ dùng HTML và CSS đơn giản, khi số lượng trang tăng lên bạn vẫn phải liên tục sao chép header và footer dùng chung
- Mỗi lựa chọn thay thế có thể nghĩ tới đều có các giới hạn riêng
- Không tồn tại HTML import
- Web Component cần JavaScript, và vì vậy cần JavaScript engine
Ý tưởng dùng trình duyệt như một hệ thống build
- Trình duyệt web vốn đã hiểu nhiều định dạng như
text/html, text/markdown, application/xml
- Nếu dùng trình duyệt như một hệ thống tạo HTML từ dữ liệu, có thể xây dựng một quy trình dựa trên tiêu chuẩn web mà không cần công cụ build riêng
- Trong quá trình tìm cách hiển thị RSS feed đẹp hơn, tác giả phát hiện rằng có thể dùng XSLT như stylesheet cho tài liệu XML
- XML trông giống HTML nhưng là một cách biểu diễn dữ liệu không chỉ giới hạn trong dữ liệu web, có thể xem tại XML spec
Cách chuyển đổi từ XML sang HTML
- Tài liệu XML có thể chứa dữ liệu như bài viết blog
<?xml version="1.0"?>
<blog>
<post id="42" publishedAt="2025-06-26">
<title>Hello XSLT</title>
<tags>…</tags>
</post>
</blog>
- Có thể thêm khai báo liên kết stylesheet XSL vào tài liệu XML
<?xml version="1.0"?>
<?xml-stylesheet type="text/xsl" href="blog.xsl"?>
<blog>
<post id="42" publishedAt="2025-06-26">
<title>Hello XSLT</title>
<tags>…</tags>
</post>
</blog>
- Template XSLT nhận đầu vào XML và xuất ra cấu trúc HTML
<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">;
<xsl:output method="html" indent="yes" />
<xsl:template match="/">
<html>
<head> … </head>
<body> … </body>
</html>
</xsl:template>
</xsl:stylesheet>
- Có thể xem XSLT như dạng
(XML) => HTML, đồng thời nó cung cấp các tính năng của hệ thống build như vòng lặp, biến và import
- Dữ liệu từ tài liệu XML cha có thể được lấy vào XSLT và xuất ra một cách động
<head>
<xsl:value-of select="title" /> | Blog
</head>
Cách chạy và triển khai
- Có thể mở file XML trong trình duyệt để chạy phép biến đổi XSLT
open blog.xml -a Safari
- Mọi trình duyệt web đều hỗ trợ biến đổi XSLT khi truy cập trang và hiển thị HTML kết quả
- Cách này hoạt động giống như một hệ thống build phía client chạy trên máy người dùng
- Việc triển khai file tĩnh rất đơn giản và hoạt động mà không cần JavaScript
Giới hạn và vị trí của nó
- Dữ liệu blog phải được lưu dưới dạng XML thay vì JSON, nhưng XML trông giống HTML, dễ parse, linh hoạt và được web hỗ trợ native
- Cách tiếp cận bằng XSLT không hoàn hảo và không thay thế được mọi thứ
- Bằng cách tận dụng các tiêu chuẩn web, đặc tả và tính năng trình duyệt cũ, đây có thể trở thành một công cụ khác để tạo các website tĩnh đơn giản
1 bình luận
Ý kiến trên Hacker News
Tôi từng làm ở một công ty dùng XSLT rất nhiều trong các template XML, và trải nghiệm không tốt, nếu có thể chắc tôi đã chuyển đi
Dù đã có các tiêu chuẩn mới, XSLT 1.0 vẫn còn chiếm ưu thế, trong khi nó hạn chế và kỳ quặc hơn nhiều so với các tiêu chuẩn hiện đại
Giải quyết vấn đề hiệu năng của template XSLT gần như là địa ngục. Đây là một ngôn ngữ kiểu hàm hoàn chỉnh Turing nhưng hiệu năng lại bị trừu tượng hóa quá nhiều, nên những template chạy ổn với hầu hết tài liệu đôi khi lại nổ tung chỉ vì một bảng 100 dòng. Cuối cùng mới phát hiện template xử lý bảng có độ phức tạp O(N^2) trở lên, và XPath cho từng dòng cũng có thể lại là O(N) trở lên, nên cũng không có hướng tối ưu nào thật rõ ràng. Nếu nhớ không nhầm, có tài liệu mất hơn 7 phút để xử lý bằng XSLT
JS chắc cũng có vấn đề khác, nhưng không giải quyết được bài toán độ phức tạp thuật toán thì không phải một trong số đó
Giờ đây có các tính năng như key (chỉ mục) có thể tăng tốc xử lý rất đáng kể, và những implementation XSLT tốt như Saxon cũng giúp rõ rệt về mặt hiệu năng
Khi chuyển đổi XML sang định dạng khác, XSLT khá tiện vì có thể tổ chức logic rất tốt
Tôi dùng XSLT khá nhiều vào năm 2013, và khi đó 1.0 đã gần như chết hẳn ở mọi nơi tôi thấy. Saxon miễn phí cho XSLT 2 và rất xuất sắc
Tôi đã chuyển đổi cả tài liệu khổng lồ lẫn số lượng lớn tài liệu nhỏ mà không gặp bất kỳ vấn đề hiệu năng nào
Khi đã nắm được thì nó mang lại cảm giác thỏa mãn như vừa giải xong Sudoku, nhưng thông thường chỉ cần những công cụ đơn giản hơn nhiều để đạt mục tiêu, nên khó trở thành cách tiếp cận tiêu chuẩn cho build hay template
Hơn nữa XML cũng không phải định dạng mà ai cũng thích
Nếu nhớ đúng thì nó còn có vài tối ưu hóa khá thông minh
Có thể đây là suy đoán hơi quá đà, nhưng vào thập niên 1990~2000, các trình duyệt hoạt động rất khác nhau nên người ta bắt đầu dùng JS để tạo ra cùng một hành vi, trong khi thứ thật sự cần là CSS tốt và hành vi nhất quán
Theo thời gian, các trình duyệt bắt đầu hoạt động giống nhau hơn, nhưng lúc đó mọi người đã quen với các framework giúp trang trông giống nhau trên mọi trình duyệt, và rồi chuyển sang mô hình render dữ liệu JSON
Với trình độ công nghệ hiện nay, trang web kiểu cũ do server tạo ra hoàn toàn đủ sức đáp ứng, lại nhẹ hơn, nhanh hơn và dùng ít bộ nhớ hơn
Gần đây khi di chuyển một hệ thống legacy, tôi thấy kiểu kiến trúc những năm 2000 là “mỗi request HTTP tương ứng một trang”, và dù mọi thao tác như thêm/xóa đều cần refresh, nó vẫn nhanh hơn hẳn hệ thống React. Internet đã nhanh hơn, bộ nhớ điện thoại đang bị các JS framework lãng phí, còn backend thì vẫn chủ yếu là CRUD, phân trang và transaction
Với những nơi đơn giản như HN, refresh toàn bộ trang là phù hợp, và cũng có rất nhiều trường hợp chỉ cần website đơn giản thay vì JS framework
Nhưng không đúng khi nói rằng mọi thứ đều có thể quay lại refresh toàn bộ trang. Có những web application thực sự mà refresh toàn bộ trang sẽ tạo ra trải nghiệm người dùng rất tệ
Nhìn chung, website, tài liệu web và form web có thể hoạt động với refresh toàn trang, nhưng điều đó không phù hợp với các web application cần hiển thị và thao tác những thứ phức tạp
Thời đó người ta dựa vào việc phát hiện user agent và đủ loại quirks theo thứ tự để canh layout, và tôi cũng không nghĩ JS khi ấy dễ tiếp cận các thành phần liên quan đến layout đến vậy
CSS cũng không mang lại tính nhất quán ngay lập tức. Ngay cả khi đã đủ tính năng, nó vẫn là một mớ hỗn độn; đó là thời mà mọi người trầm trồ trước CSS Zen Garden nhưng code thực tế vẫn viết bằng table
Tôi cũng không chắc framework có ảnh hưởng lớn đến chuyện “ngoại hình nhất quán” hay không. Đến lúc rời khỏi jQuery thì CSS đã là thứ đảm nhiệm phần ngoại hình rồi
Đây là trong điều kiện mỗi trang bắn nhiều query, đồng thời dùng khá nhiều join phức tạp để tạo ra dạng phản hồi chỉ dành cho view. Nếu lấy dữ liệu đúng hình dạng trước khi nội suy vào chuỗi HTML thì sẽ giúp hiệu năng rất nhiều trong các tình huống biên như bảng 100 nghìn dòng
Theo kinh nghiệm của tôi, template engine HTML và cơ sở dữ liệu càng gần nhau càng tốt. Suy cho cùng, ngay cả DOM có cấu trúc cũng chỉ là một luồng byte phải gửi tới client
Tôi cho rằng đã hình thành một ngành công nghiệp vô nghĩa và tự mục đích khi người ta ngồi nghĩ về cách tiếp cận AST/parser tinh vi cho những thứ lẽ ra chỉ cần StringBuilder và SQL query đủ thông minh. Lập luận phản đối cuối cùng thường quy về kiểu giám sát an ninh cho rằng lập trình viên không biết dùng đúng hàm escape HTML
Thật đáng tiếc khi công nghệ này trông có vẻ lỗi thời vì sự đồ sộ của XML doanh nghiệp trong thập niên 2000, và mọi người đều đổ sang JSON “gọn gàng” hơn
XSLT và XPath đã rất trưởng thành, và đã giải quyết sẵn nhiều vấn đề mà các định dạng khác đến giờ vẫn còn gặp
Tôi cũng có những ký ức đẹp về việc từng lạm dụng PHP stream wrapper và XSLT include
Có thể chỉ là định kiến cũ, nhưng tôi vẫn hơi bất an khi để trình duyệt xử lý cục bộ, vì ngày xưa đó từng là một bãi mìn về tương thích
Những thứ như schema ở phía XML được định nghĩa tốt hơn nhiều, và có cảm giác phía JSON mất gần 10 năm mới đuổi kịp
Công nghệ XML cuối cùng tôi thực sự đụng tới là EXI, một phương thức truyền tải biến tài liệu XML thành luồng dữ liệu nhị phân nén. Vì việc biến cấu trúc dữ liệu thành ASCII, nén lại, gửi qua HTTP rồi đổi ngược trở lại vốn khá khôi hài
Bây giờ họ protobuf phổ biến hơn, nhưng nếu XML tiếp tục tồn tại mạnh mẽ thì có lẽ đã hình thành một thế giới các tiêu chuẩn tương thích ăn khớp với nhau. Ngược lại, giữa protobuf/gRPC và JSON API lại có một bức tường cứng, mà biết đâu điều đó lại tốt hơn
XPath cũng không tệ. Khó mà nhớ hết cú pháp, nhưng chỉ cần thử nghiệm một chút là thường cũng tới được chỗ mình muốn
Còn XSLT thì là thứ điên rồ hoàn toàn, nên bị thiêu rụi đi thì hơn
Với việc cho phép chỉnh sửa cục bộ tương đối ổn định cho dữ liệu, tổ hợp XML + XPath đang bị đánh giá thấp nghiêm trọng. Có lẽ vì XML mang tiếng là “lỗi thời” nên tôi hiếm thấy ở game khác, nhưng cho mục đích này thì đây là một hệ thống rất vững chắc
https://rimworldwiki.com/wiki/Modding_Tutorials/PatchOperati...
Nhưng khi cơn sốt web bùng nổ, W3C và MS đã tạo ra những thứ như SOAP, WS-*, và cũng xuất hiện khá nhiều ngôn ngữ lập trình dựa trên XML, bao gồm cả XSLT
Không nên nói điều này với người trên HN, nhưng XSLT vốn là Scheme buộc phải là XML, cùng một kiểu điên rồ như việc JavaScript phải mượn cái tên Java
Dạo này tôi dùng XSLT để trang trí feed
Ví dụ như https://susam.net/feed.xml và https://susam.net/feed.xsl
Một trong những dự án đầu tiên tôi nhận khi mới 19 tuổi và làm kỹ sư phần mềm chuyên nghiệp là tùy biến hai chiếc Google Search Appliance mà công ty đã mua
Công ty tin rằng nếu có thể tìm kiếm chuyên biệt trong một kho tài liệu CIFS khổng lồ thì quy trình phát triển kinh doanh sẽ được cải thiện, và đã chi hàng trăm nghìn đô cho những rack server Dell mặt trước màu vàng chạy CentOS và kiểu Python của Google
Khoảng năm 2011, XHTML đang thịnh hành, và GSA hoạt động bằng cách lấy kết quả tìm kiếm được backend cung cấp dưới dạng XML rồi chuyển thành XHTML bằng XSLT
Tôi lấy template mặc định, rồi tạo ra một con quái vật kiểu cổng intranet công ty bằng các trang ứng dụng ColdFusion đã render, cùng tài nguyên và markup chôm từ StackOverflow và hướng dẫn của W3Schools
Sau đó trên LinkedIn, nhiều nhà thầu DoD đã liên hệ mời tôi tham gia các dự án hiện đại hóa tài liệu vì thấy tôi có “chuyên môn XML”, và tôi nhanh chóng học được rằng nên bỏ kinh nghiệm này khỏi CV
Mỗi khi bạn thở dài vì đang lặp qua một mảng interface TypeScript được deserialize từ phản hồi JSON để dựng JSX, hãy nhớ rằng trước đây tôi từng làm đúng việc đó bằng XSLT
Nhiều người phàn nàn rằng XML dài dòng và nhìn từ xa thì có vẻ phức tạp, nhưng điều hay là bạn có thể tạo một định dạng tệp tốt dựa trên XML, xác thực bằng DTD, rồi nếu cần thì định dạng lại bằng XSLT cho dễ đọc với con người
XML giống như C++ của các định dạng tệp dựa trên văn bản: trưởng thành, đầy đủ pin kèm sẵn, mạnh mẽ, và nếu muốn thì có thể dùng từ bất kỳ ngôn ngữ nào
Chuyện chê bai XML cũng đã thành mốt, giống như cách các ngôn ngữ cũ và trưởng thành bị chê vì những cái quirks riêng của chúng. Nếu không hợp với mục đích thì đừng dùng, nhưng cũng không nên coi nó là quái vật
Để thấy XML và XSLT từng đi xa đến mức nào vào đầu những năm 2000, công ty tôi từng làm việc trước đây đã chế tạo một ASIC có thể parse XML ở tốc độ đường truyền và xử lý XSLT native ngay trên chip
Vì họ dự đoán tương lai của Internet sẽ hoàn toàn là XML/XSLT. Intel đã mua lại công ty đó, và công nghệ nội bộ của họ được đưa vào bộ tăng tốc SSE
Thật ngạc nhiên trước kiểu phép màu “XSLT chạy native trong trình duyệt”
Lần cuối cùng tôi dùng XSLT chắc là khoảng 20 năm trước, nhưng hồi đó đã dùng rất nhiều trong vài năm. Khi ấy, để nó chạy được thì cần cả một chồng Java enterprise khổng lồ và mong manh, làm mất đi sự thanh lịch vốn có của XSLT
Nhưng nếu XSLT thực sự chạy được trong trình duyệt, thì hóa ra chén thánh của template tĩnh có thể host ở bất cứ đâu đã luôn ở ngay trước mắt
Nếu thay vào đó có hỗ trợ v3 thì có vẻ sẽ dễ hơn nhiều để phục vụ các trang web tĩnh với hỗ trợ template native
CMS xuất ra các tệp XML có nhúng HTML và cache hoạt động cực kỳ tốt. Cá nhân hóa và render HTML/JS được xử lý phía server cùng với proxy cache
Việc biến đổi XSL chạy phía sau lớp cache và đủ nhanh để theo kịp lượng truy cập lớn. Ở đây mục đích của XML là nhét HTML đã chuẩn bị sẵn vào dưới dạng blob, và chỉ để lại những phần cần cá nhân hóa dưới dạng thẻ XML
Bước biến đổi cuối cùng khá nhanh, và mấu chốt là đẩy đầu ra của bộ biến đổi XSL thẳng vào response output stream thay vì giữ trong một bộ đệm toàn bộ trên bộ nhớ. Với các phản hồi lớn thì đây vẫn là một kỹ thuật tốt đến tận bây giờ, nhưng nhiều framework bỏ lỡ điều này vì mặc định chọn đệm trong bộ nhớ
Tất nhiên ngày nay có thể chạy bất cứ thứ gì muốn trong trình duyệt bằng wasm. Nhưng hồi đó JavaScript rất tệ, và nhà thiết kế giỏi lắm cũng chỉ giao cho bạn file Photoshop. Bạn phải cắt nó ra thành frame và table, và chúng tôi đang xây một CMS UI dùng khá nặng JavaScript, phải hỗ trợ cả Netscape lẫn Internet Explorer vào đúng thời Google Maps và Gmail vừa mới ra mắt
Firefox đặc biệt có một lỗi rất khó chịu: khi cần
disable-output-escapingđể render HTML trong tài liệu thành DOM thực sự, nó không hoạt động đúng mà lại render thành văn bản HTML thôTrong một dự án phản địa đàng từ rất lâu về trước, có người bi quan rằng nhóm sẽ không thể điều phối việc phát triển Java song song với các workbook thay đổi chóng mặt, nên đã đưa ra một giải pháp
Workbook viết bằng Excel được Visual Basic chuyển thành XML, rồi các tệp XSLT sẽ tự động sinh ra các lớp Java để xử lý những Struts action được định nghĩa trong XML đó
https://raganwald.com/2008/02/21/mouse-trap.html
Thảo luận HN: https://news.ycombinator.com/item?id=120379 · https://news.ycombinator.com/item?id=947952