Mấy tuần trước, khi Cloudflare công bố EmDash vào ngày 1 tháng 4, đa phần người dùng VN đều không biết đến, bởi còn đang bận chạy theo cơn sốt vibe code, AI Agentic… hoặc hơn những ai biết đến đều nghĩ đó là một trò Cá Tháng Tư. Nhưng không — đây là một dự án thực sự, và nó khiến mình phải suy nghĩ lại về CMS già cỗi WordPress mà mình đang xài trong thời điểm nhà nhà AI, người người AI hiện tại.
Mình không phải người ghét WordPress – thậm chí là người gắn bó với WordPress cũng khá lâu, viết được 1 số plugin được cộng đồng chấp nhận và sử dụng thời gian trước đây. Sau hơn 20 năm làm việc với web, chuyển từ Joomla sang Drupal rồi đến WordPress, mình rất tôn trọng những gì WordPress đã xây dựng — một platform dân chủ hóa việc xuất bản, cho phép bất kỳ ai cũng có thể có một trang web chuyên nghiệp, thế nên mình càng tò mò EmDash sẽ làm gì để thay thế WordPress.
Phụ mục
WordPress Đã 24 Năm: Đây Là Vấn Đề
WordPress hiện kiểm soát 42,5% tất cả website trên thế giới. Con số này không phải tình cờ — nó là kết quả của những quyết định thiết kế tuyệt vời vào năm 2003.
Nhưng năm 2003 là lâu lắm rồi.
Khi WordPress ra đời, AWS, EC2 chưa tồn tại. Internet architecture hoàn toàn khác. Bạn thuê một VPS, chạy PHP trên đó, WordPress xây dựng một hệ thống linh hoạt để plugin có thể mở rộng core bằng cách móc trực tiếp vào execution context. Điều này hoạt động vì:
- Đó là thời đại của máy chủ vật lý — mỗi request phải được xử lý bởi một server process đang chạy 24/7
- Bảo mật chưa phải vấn đề cấp bách — plugin thường được viết bởi cộng đồng, được tin cậy bởi con người, chứ không phải từ các nguồn nghi ngờ
- Không ai nghĩ đến AI — nền tảng được thiết kế cho con người cài plugin, không phải cho agent tự động
Bây giờ, sau 23 năm, WordPress vẫn chạy theo cùng mô hình cơ bản đó. Đó là một thành công lớn ! Nhưng cũng là điểm yếu của sự già cỗi và không còn hợp thời đại.
Ba Vấn Đề Mà WordPress Không Thể Tự Sửa
1. Cuộc Khủng Hoảng Bảo Mật Plugin — 96% Lỗi Hổng Đến Từ Đây
Mình đã đọc báo cáo bảo mật WordPress năm 2025 — và nó khó chịu lắm.
96% lỗ hổng bảo mật WordPress đến từ plugin, không phải từ core.
Cách đó hoạt động rất đơn giản: khi bạn cài plugin WordPress, bạn đang cấp cho nó quyền truy cập vào database toàn bộ, filesystem, tất cả các hàm WordPress, và bất cứ thứ gì khác nó muốn. Không có ranh giới. Không có sandbox. Plugin được viết bằng PHP và nó có thể làm bất cứ điều gì.
Đó là lý do tại sao WordPress.org phải manually review và approve từng plugin trước khi đưa lên official marketplace. Hiện tại, hàng đợi chờ duyệt là 800+ plugin, và thời gian chờ ít nhất 2 tuần.
Đã có rất nhiều trường hợp, ngay cả khi một plugin developer có ý tốt, lỗi bảo mật nhỏ trong code cũng có thể để lỗ hổng rộng mở cho hacker truy cập database của bạn. Mọi chuyện sẽ diễn ra âm thầm, đơn giản cho đến khi mọi thứ đều là quá muộn.
2. Kiến Trúc Lỗi Thời Không Thể Thích Ứng Với Serverless
Năm nay, bạn không nên phải trả tiền cho một server chạy 24/7 nếu website của bạn chỉ nhận 1.000 request mỗi ngày với nhiều gói dịch vụ Free, hoặc dịch vụ dùng thử.
Nhưng WordPress không thể làm gì được. Nó được xây dựng cho PHP-FPM trên máy chủ truyền thống. Cho dù bạn dùng nó trên Cloudflare Pages, Vercel, hay Netlify, nó vẫn cần một runtime process chạy liên tục, chờ request đến.
So sánh với serverless thực sự: request đến → isolate spins up → response gửi → isolate shutdown → không tốn tiền. Bạn chỉ trả chi phí cho CPU time thực tế mà server làm việc.
Đây không phải chi tiết nhỏ. Tôi đã thấy các trang web nhỏ có thể tiết kiệm 80% chi phí hạ tần bằng cách chuyển sang serverless — nếu họ chọn CMS được thiết kế cho nó.
3. Không Được Thiết Kế Cho AI
Năm nay, ai cũng muốn AI quản lý website của họ. Cập nhật sản phẩm tự động? AI agent. Tối ưu SEO? AI agent. Tạo nội dung? AI agent.
Nhưng WordPress không được xây dựng cho điều này. Không có MCP server tích hợp. Không có API chuẩn để AI agent tương tác. Plugin AI phải được viết riêng, không có giao tiếp đơn vị hóa nào.
Với mô hình plugin WordPress hiện tại, nếu bạn cho AI agent trực tiếp truy cập database, bạn có thể cũng cho nó quyền đọc mọi khóa API, mọi email khách hàng, mọi thứ. Đó là không thể chấp nhận được.
EmDash: Một Cách Tiếp Cận Hoàn Toàn Khác
EmDash đến từ Cloudflare — công ty mà mình nghĩ đang nắm giữ xương sống internet của môi trường mạng, gần như mỗi quản trị web đều biết đên snos.
EmDash là gì?
Trong bản chất, đó là một CMS hoàn toàn mới, viết bằng TypeScript, xây trên Astro framework (Cloudflare vừa mua lại vào tháng 1). Nó được thiết kế từ đầu để chạy trên edge network, với plugin sandboxed, và AI-native.
Nhưng hãy để tôi giải thích chi tiết tại sao nó khác — không phải “khác vì khác”, mà thực sự khác ở những chỗ quan trọng.
Plugin Sandbox với Permission Rõ Ràng
Đây là thứ tôi cho là sự thay đổi cấu trúc lớn nhất.
Với EmDash, mỗi plugin chạy trong V8 isolate riêng (Dynamic Worker của Cloudflare). Thay vì cấp quyền truy cập toàn bộ, bạn khai báo một manifest cho plugin:
definePlugin({
id: "send-email-on-publish",
capabilities: ["read:content", "email:send"],
hooks: {
"content:afterSave": async (event, ctx) => {
// Plugin chỉ có thể dùng ctx.email và đọc content
// Không thể truy cập database trực tiếp
// Không có network access ngoại trừ email service
}
}
})
Nói đơn gian: plugin chỉ có thể làm đúng những gì nó khai báo và không bao giờ được vượt qua ranh giới.
Về mặt lý thuyết, bạn có thể tải plugin từ một developer hoàn toàn lạ, vì bạn có thể đọc capability của nó trước. Giống như khi bạn cấp quyền cho ứng dụng trên phone — bạn thấy nó muốn access gì trước khi install.
Content Types Được Định Nghĩa Trong Database
WordPress yêu cầu bạn tạo custom post types bằng code PHP. EmDash thì không.
Bạn đăng nhập vào Admin panel, tạo một collection (ví dụ: “products”), định nghĩa fields bằng UI — và tự động, một SQL table thực sự được tạo với typed columns. Developer có thể generate TypeScript types từ schema trực tiếp.
Điều này giải quyết một vấn đề lâu dài: code và data luôn đồng bộ. Không bao giờ có tình trạng developer quên update types sau khi thay đổi database.
Tối Ưu Hóa Cho Serverless Architecture
Trên Cloudflare Workers (platform mà EmDash chạy tốt nhất), bạn không trả tiền cho time chạy idle. Bạn chỉ trả CPU time thực tế.
Điều này có nghĩa là:
- Blog nhỏ của bạn có thể chạy gần như miễn phí nếu nó chỉ có 1.000 visitor/tháng
- Khi traffic spike, nó scale tự động tới hàng triệu request/giây
- Không cần lo lắng về load balancing hay capacity planning
WordPress không thể làm được cách này, vì nó cần process chạy 24/7.
AI-Native Từ Đầu
EmDash có MCP server tích hợp sẵn. Nó có Agent Skills — những file mô tả cho AI hiểu cách EmDash hoạt động. Nó có CLI và API để AI agent programmatically quản lý site.
Quan trọng nhất: vì plugin chỉ có capability được cấp, bạn có thể tin tưởng AI agent làm việc trên site của bạn mà không lo nó sẽ xóa hết database.
So Sánh Thực Tế: WordPress vs EmDash
Tôi thích so sánh các thứ không phải từ lý thuyết, mà từ kinh nghiệm. Đây là những gì tôi thấy:
| Khía cạnh | WordPress | EmDash |
|---|---|---|
| Bảo mật plugin | 96% lỗ hổng từ plugin, không có sandbox | Plugin sandbox với permission rõ ràng |
| Kiến trúc | PHP monolith từ 2003 | TypeScript serverless, Astro-native |
| Scaling | VPS 24/7, bạn trả dù có traffic hay không | Serverless, scale tới zero, trả CPU time |
| AI integration | Qua plugin bên thứ ba, không chuẩn | MCP server tích hợp, AI-native |
| Content modeling | Custom post types qua code PHP | UI-based, auto-schema generation |
| License | GPL (enterprise friction) | MIT (commercial friendly) |
| Plugin ecosystem | 60.000+ plugin, 23 năm xây dựng | ~0, mới ra đời |
| Community | Khổng lồ, hàng triệu developer | Chưa có (v0.1.0) |
| Maturity | Production-ready, tested | Beta, cần battle-testing |
Đánh Giá Thực Tế: Không Phải Black and White
Mình muốn rõ ràng: không phải WordPress sẽ chết vì EmDash – rõ ràng là vậy.
WordPress có hệ sinh thái khổng lồ. Có hàng triệu developer biết cách làm việc với nó. Plugin WooCommerce, Elementor, Yoast — những thứ mà WordPress ecosystem đã xây dựng trong 20+ năm — không thể thay thế được trong một đêm.
Nhưng mình cũng thấy rõ rằng EmDash đưa ra câu trả lời đúng đắn và phù hợp hơn với thời đại.
Ý tưởng plugin sandbox là ý tưởng tuyệt vời để giải quyết vấn đề bảo mật vốn là vấn đề nhức nhối nhất của WordPress. Kiến trúc serverless-first là thích hợp với thế giới năm 2026.
Nhưng EmDash cũng đang có một số vấn đề – dù không phải là công nghệ. Đó là:
- Nó vẫn ở v0.1.0 — được xây trong 2 tháng bằng AI agents. Đó là nhanh, nhưng không có thay thế cho battle-testing thực tế.
- Chưa có plugin ecosystem — điều này quan trọng hơn bạn nghĩ. Hầu hết trang web thành công của WordPress dựa trên plugin hoạt động tốt, không phải WordPress core.
- CloudFlare-centric — mặc dù bạn có thể chạy nó trên Node.js bất kỳ đâu, plugin sandbox chỉ hoạt động trên Cloudflare runtime. Điều này khiến nó cảm thấy “có chủ ý lock-in”, dù công nghệ là open source.
- Chưa có community — ngay cả kỹ thuật tốt cũng cần một cộng đồng để phát triển.
Vậy Bạn Có Nên Chuyển Sang Không?
- Nếu bạn đang chạy WordPress production site: Không — ít nhất là không ngay bây giờ. WordPress đã được kiểm chứng. Đó không phải “tốt nhất” mà là “đủ an toàn, đủ lớn ecosystem, đủ hỗ trợ”.
- Nếu bạn muốn xây một site mới từ đầu:“hãy thử EmDash”, nhưng phải thực tế: Nếu bạn cần bán hàng, bạn cần WooCommerce. Nếu bạn cần SEO optimization, bạn cần Yoast (hay tương đương). EmDash không có những cái này.
- Nếu bạn xây site nội bộ hoặc side project: Đây là thời điểm tuyệt vời. Hãy thử EmDash. Bạn sẽ học được cách tư duy về bảo mật plugin, cách sử dụng TypeScript trong CMS, cách AI agent tương tác với site. Càng sớm, bạn sẽ càng nhìn thấy 1 điều mới lạ mà có thể sẽ là cách một quản trị viên tương tác với website.
Mình cũng đang cài đặt demo local của EmDash để thử. Không phải vì mình tin nó sẽ thay thế WordPress, mà vì mình muốn hiểu một cách tiếp cận mới là gì.
Nếu trong 12-18 tháng tới, EmDash xây được một cộng đồng khỏe với vài chục plugin chất lượng tốt, thì nó sẽ trở thành một sự chọn lựa thực sự.
Những gì mình chắc chắn là: CMS không nên để nguyên vẹn trong 24 năm. Thế giới đã thay đổi. Platform cũng phải thay đổi. EmDash có thể hoặc không thể là tương lai, nhưng nó chắc chắn là dấu hiệu của một tương lai nào đó.