Chúng ta đã lạc lối trong việc tạo ra phần mềm hiệu quả?
(medium.com/@rufatmammadli)- Khi cố chỉnh sửa một tài liệu Word khoảng 30MB trong trình duyệt và gặp độ trễ khi nhập, đây trở thành một ví dụ cho thấy rõ cái giá về hiệu năng của các ứng dụng web hiện đại
- Tài liệu chủ yếu là văn bản, chỉ có một vài hình ảnh và bảng biểu, nhưng Google Docs hoặc môi trường Chrome vẫn không xử lý mượt mà
- Thay vì Microsoft Office trả phí, tác giả cài LibreOffice và thấy cùng tài liệu đó chạy nhanh hơn hẳn, làm nổi bật sự khác biệt giữa ứng dụng web và ứng dụng native
- Khi các ứng dụng web hiện đại đòi hỏi nhiều bộ nhớ và CPU hơn, vấn đề này dẫn tới câu hỏi rằng việc phần cứng ngày càng mạnh hơn đang song hành với các ứng dụng web ngốn tài nguyên
- Dù PWA và giao diện dựa trên trình duyệt đang ngày càng phổ biến, kết xuất native và thiết kế phần mềm hiệu quả vẫn rất quan trọng đối với trải nghiệm sử dụng thực tế
Vấn đề hiệu năng của ứng dụng web bộc lộ qua tài liệu 30MB
- Google Docs được chọn trước tiên vì có thể tận dụng tài khoản Google và tự động đồng bộ lên đám mây
- Sau khi tải tài liệu lên Google Docs và thử nhập nội dung, phải mất vài giây thì ký tự mới xuất hiện trên màn hình
- Kích thước tệp khoảng 30MB, có một số hình ảnh và bảng đơn giản nhưng phần lớn vẫn là văn bản
- Tác giả kết luận rằng Chrome hoặc Google Docs đã không thể xử lý tài liệu này một cách phù hợp
- Microsoft Office bị loại vì là phần mềm trả phí, còn LibreOffice được cài thay thế thì xử lý cùng tài liệu đó rất nhanh
Câu hỏi lớn hơn về hiệu quả
- Điều này khiến người ta phải nhìn lại xem các công cụ, framework và ngôn ngữ hiện đại có đang làm phần mềm nặng nề hơn về mặt hiệu năng hay không
- Để gánh nổi các ứng dụng web ngốn tài nguyên, cấu hình phần cứng đã tăng lên, và nếu chỉ có các ứng dụng native thuần túy thì có lẽ những yêu cầu đó đã thấp hơn
- Tác giả nêu ví dụ về việc thiết bị di động cần tới 16GB RAM để chỉ ra vấn đề phần mềm ngày càng tiêu tốn nhiều tài nguyên hơn
- Thay vì chỉ dừng lại như một lớp bọc cho công cụ kết xuất giao diện đơn giản, web cần đạt được mức hiệu quả gần với kết xuất native
- Máy tính Apollo năm 1966 có thể đưa con người đáp xuống Mặt Trăng với chỉ 2KB RAM, nhưng đến năm 2024, trình duyệt vẫn khó xử lý ngay cả một tài liệu khoảng 30MB; sự tương phản này nhấn mạnh nhu cầu tối ưu hóa
1 bình luận
Các ý kiến trên Hacker News
Ngay cả khi muốn làm ứng dụng native, tôi vẫn có cảm giác Apple và Microsoft liên tục cản đường. Bạn phải chịu đủ thứ: tài khoản nhà phát triển, chứng chỉ ký nhị phân, rồi cả phí 30% doanh thu chẳng vì lý do gì; đặc biệt API phía Microsoft đã thay đổi đến mức rối rắm
Vì vậy rốt cuộc lại chọn web, đơn giản hơn và rẻ hơn
Ứng dụng chưa ký vẫn có thể chạy trên Windows và macOS, nhưng sẽ hiện nhiều cảnh báo hơn. Phí 30% cũng chỉ áp dụng khi dùng Mac App Store hoặc Microsoft Store; Microsoft Store có vẻ không thu phí nếu không phải game và bạn dùng hệ thống thanh toán riêng
Tôi không rõ về Apple, nhưng rất có thể có thể làm ứng dụng Mac mà không cần tài khoản nhà phát triển; còn iPhone thì cần tài khoản nhà phát triển. Mức giá tôi từng thấy là $99 mỗi năm, và nếu nghiêm túc làm ứng dụng thì đó không phải khoản tiền lớn
Xử lý chargeback và hoàn tiền cũng tốn chi phí, và bạn phải dành thời gian cho hỗ trợ khách hàng hoặc thuê người. Nếu doanh thu hằng năm dưới 1 triệu đô la, phí của Apple là 15%, nên với ứng dụng giá thấp hoặc ứng dụng giá trị gia tăng, Apple có thể là lựa chọn tốt hơn so với tự xử lý thanh toán
Thật mỉa mai khi bài viết này được đăng trên Medium, nơi tải xuống 10,88MB cho một bài chỉ 265 từ
about:process, ngay cả 10 phút sau khi tải xong, bài viết này vẫn dùng 239MB bộ nhớ và 0,06~0,2% CPU; có vẻ 45% thời gian CPU được dùng cho Google reCAPTCHATôi ước những nơi như Mozilla hay Google thu thập thống kê mức dùng CPU, bộ nhớ và năng lượng theo từng tên miền, rồi công khai làm bẽ mặt những nhà phát triển không quan tâm đến hiệu năng
Web lại có cảm giác như năm 2005. Chỉ khác là lần này popup bị nhúng ngay trong trang
gemini://gemi.dev/bin/waffle.cgibằng trình duyệt Gemini rồi dán URL vào. Ai không dùng mạng Gemini thì chỉ cần đổimedium.comtrong URL thànhscribe.ripĐúng là đã lạc đường, và lý do rất đơn giản: vì có thể làm như vậy. Đó là con đường ít lực cản nhất, nên người ta đã chọn con đường đó
Phần mềm đã ăn theo miễn phí sự tiến bộ của phần cứng trong nhiều thập kỷ, đặc biệt là ở web và ứng dụng desktop. Định luật Moore vừa là phước lành vừa là lời nguyền, và phần mềm chúng ta dùng ngày nay được tạo bởi những người học công nghệ đúng vào thời kỳ đang hưởng lợi lớn từ chuyến đi nhờ đó
Giờ máy dưới 8GB thì không dùng nổi, 8GB cũng chỉ vừa đủ chật vật. Phần mềm mới dùng Electron và ngốn tối thiểu 1GB RAM, mọi thứ kể cả trình duyệt đều dùng bộ nhớ nhiều đến phi lý
Windows thì càng khó hiểu hơn. Mỗi lần giúp máy của mẹ tôi, dù là PC i5 đời gần đây với 8GB RAM, nó vẫn quá chậm; khởi động, mở chương trình và cập nhật đều mất nhiều thời gian. Một chiếc máy tính khởi động hơn 1 phút thì tôi chỉ muốn ném nó ra ngoài cửa sổ
Chúng ta không giải quyết việc phân phối ứng dụng qua nhiều ngôn ngữ và môi trường, mà né nó bằng container engine. Nếu người dùng muốn, ta có thể đưa build script cài compiler và công cụ, nhưng rất khó kiểm thử đúng cách nên cuối cùng vẫn dùng container
Redbean và Cosmopolitan libc có vẻ là những thứ đến gần nhất với việc “giải quyết” vấn đề này. Nếu muốn người dùng triển khai ứng dụng dễ dàng và ổn định, container có lợi thế cạnh tranh, và ngay lập tức kéo theo hơn 100MB dung lượng đĩa cùng một container engine
Chừng nào còn lấy cạnh tranh giữa các quốc gia hay doanh nghiệp làm nguyên lý cốt lõi của phát triển công nghệ, sẽ rất khó kiểm soát các khủng hoảng toàn cầu như biến đổi khí hậu, phá hủy hệ sinh thái và AI sát thương. Ở cấp nguyên lý tổ chức cao nhất cần có phối hợp và hợp tác; cạnh tranh tạo ra ngoại tác tiêu cực khổng lồ cho toàn bộ Trái Đất
Các chương trình viết bằng Lazarus, tức Free Pascal, chạy rất nhanh ngay cả trên Windows hiện đại như Windows 11. Duy trì phần mềm được viết đúng cho một mục đích cụ thể trên desktop là tốt nhất về tốc độ và độ ổn định
Mọi sự hiện đại hóa của phần mềm, cả phần cứng lẫn framework, đều hoạt động như một loại thuế đánh lên toàn bộ chức năng hiện có
Độ phức tạp đã tích tụ ở những chỗ hoàn toàn sai
Những lời phàn nàn như thế cứ lặp đi lặp lại, nhưng thực tế đó là một trạng thái mà gần như không ai thật lòng muốn thay đổi
Lập trình viên thích web — một nền tảng điện toán phổ dụng được tích hợp và kết nối hoàn toàn — còn người dùng dường như không quá bận tâm đến hiệu năng miễn là nó đủ ổn. Rốt cuộc, phần mềm được phép tệ đi đến mức miễn là chưa làm người dùng quá khó chịu
Ban lãnh đạo cũng không quan tâm đến việc làm ra phần mềm tốt hơn nếu phần mềm đủ tốt đã được phát triển. Chừng nào chưa có ai kết luận rằng cần một sự rời bỏ đột ngột, sẽ chẳng có gì thay đổi, và nhìn từ góc độ nào thì động lực để thay đổi cũng rất ít
Những người tải ứng dụng lớn trên điện thoại có sóng yếu, sống ở khu vực mạng Internet không ổn định, hoặc dùng thiết bị cũ trong nhóm thu nhập thấp/các nước đang phát triển đều thất vọng vì các ứng dụng lớn và chậm. Nếu bạn cảm thấy họ không quan tâm đến hiệu năng và kích thước ứng dụng, có thể bạn đang hỏi sai người bằng sai câu hỏi
Theo thời gian, chỉ những người phàn nàn mới trở nên khác thường, còn những người còn lại thì nâng cấp, chấp nhận sự cồng kềnh, hoặc tiếp tục dùng phần mềm cũ
Tuy vậy cũng cần nhìn vào lợi ích mà sự cồng kềnh đó mang lại. Nếu Google Docs chỉ là một bản sao của Word thì có lẽ đã không được dùng nhiều, nhưng có người dùng nó vì miễn phí, truy cập được trên nhiều thiết bị và cộng tác trơn tru
Ngoài ra, một phần những gì trông như cồng kềnh thực ra là cải thiện về tiện ích. Các tính năng như phông chữ tỉ lệ trông đẹp ở mọi kích thước, phông Unicode, xử lý tài liệu lớn hơn bộ nhớ, chuyển đổi giữa tài liệu đang làm và tài liệu tham khảo, bảo vệ bộ nhớ tuy tiêu tốn nhiều tài nguyên nhưng nâng cao chất lượng trải nghiệm
Thế giới hiện đại dựa trên cloud hoặc nửa-online khá thiếu tự nhiên từ góc nhìn người dùng, còn những trường hợp không cần kiếm tiền kiểu thuê bao như OpenOffice thì vẫn có thể tồn tại dưới dạng ứng dụng desktop
Không ai phàn nàn về điều đó, và dù hiệu năng ở một số phần của ứng dụng rất tệ, khiếu nại từ khách hàng vẫn hiếm. Phải đến khi thời gian tải khoảng 60 giây thì lời phàn nàn mới bắt đầu xuất hiện
Dù vậy, phần mềm đó giải quyết một vấn đề rất có giá trị, rút công việc mất cả tuần xuống còn vài phút, nên khách hàng hết lời khen ngợi. Khi cạnh tranh trở nên gay gắt hơn thì cần cải thiện, nhưng phần lớn mọi người thật sự không bận tâm và chuyện đó luôn nằm ở cuối danh sách ưu tiên
Mở Task Manager ra và thấy dù phần lớn cơ sở dữ liệu hiện tại đã được nạp lên mà chỉ dùng 20~30MB RAM cũng khá thú vị. VLC và Blender cũng là những ví dụ tương tự
Thú vị là đa số đều đổ lỗi cho lập trình viên, nhưng trên thực tế tất cả đều là quyết định kinh doanh
Việc chuyển lên cloud là vì doanh nghiệp thích nguồn thu ổn định từ thuê bao; khách hàng doanh nghiệp không cần thuê đội IT, trách nhiệm được chuyển ra bên ngoài nên họ có thể yêu cầu uptime cao. Hiệu năng chỉ cần “đủ ổn” với người dùng cuối
Khách hàng từ chối nâng cấp phần mềm on-premises đã dẫn đến chu kỳ bảo trì dài và những bản vá bất tận, còn cách phát triển một lần cho web có lợi về mặt kinh doanh hơn so với việc có riêng lập trình viên và tester cho từng nền tảng. Chỉ chuyên môn của lập trình viên không thể thay đổi những lực nền tảng này
Có thể không dùng được các tính năng mới hào nhoáng, nhưng trên máy Win7, CS4 vẫn dùng được mà không tốn thêm chi phí
Vấn đề nằm ở chỗ lập trình viên phát triển trên những cỗ máy có hiệu năng mà người dùng không thể mua được, và không quan tâm đến hiệu năng hay code hiệu quả
Đầu thập niên 90, tôi nhớ MS Word chỉ nằm gọn trong vài đĩa mềm, và tệp thực thi chính chỉ 2MB. Nó vẫn chạy tốt trên máy 386 16MHz chỉ có tổng cộng 2MB RAM
Hầu hết những việc ta làm bây giờ hồi đó cũng đã làm được, chỉ thiếu cỡ trình kiểm tra ngữ pháp. Giờ mọi thứ được tính bằng GB, phình to gấp 1000 lần, nhưng không rõ ta đã nhận lại được gì. Không chỉ lạc đường, mà còn không biết đích đến là đâu
Ví dụ chỉ riêng
dict.wordstrên Linux đã 4,8MB, còn Arial Unicode là một phông chữ khoảng 20MB. Một biểu tượng ứng dụng tôi đang làm đã 400KB, và Google Crashpad handler để xử lý crash cũng vài MBMàn hình true color 4K lớn hơn màn hình 640x480 16 màu 138 lần
PC thời đó có thể khởi động mà không cần UEFI, và nếu cấu hình đúng thì Windows 3.11 gần như bật lên tức thì, Word cũng mở ngay
Word hiện nay đã thêm khá nhiều tính năng rất nhỏ và một vài tính năng lớn, nhưng tôi tin chắc rằng nếu Microsoft thật sự quan tâm, họ có thể giảm mức dùng bộ nhớ xuống còn một phần mười. Chỉ là họ không có động lực. Máy tính thì nhanh, bộ nhớ thì nhiều, không còn phụ thuộc vào đĩa mềm nữa, nên làm vậy chỉ tốn thêm chi phí
Tôi nghĩ sự phình to của phần mềm cũng có thể có tác động môi trường không thể xem nhẹ, nhưng nếu không có đủ bất mãn mạnh mẽ, hoặc một đạo luật kiểu EU chống phần mềm phình to, thì chuyện này sẽ không thay đổi
Gần đây tôi cũng xem mã nguồn MS Word for Windows 1.0 trên GitHub. Bản công bố gốc nằm ở Computer History Museum và có thể xem tại https://computerhistory.org/blog/microsoft-word-for-windows-.... Nó là C thuần và phần lớn là assembly, nhưng mã thì bừa bộn đến mức không thể so với các chuẩn, mẫu thiết kế hay tính năng ngôn ngữ C/C++ hiện nay
Tôi từng thấy câu ví phần mềm giống như chất khí: nó sẽ giãn nở để lấp đầy không gian được cấp cho nó
Các bản live distro cũng tương tự. Trước kia chúng là 700MB để vừa CD-R, còn giờ khó tìm được bản nào nhét vừa USB 2GB. Dù vậy, thật mừng khi “minimal” đang được chú ý hơn
Tôi tự hỏi Nvidia rốt cuộc đang bắt ta tải cái gì. Có phải là hàng nghìn tổ hợp mã sinh ra mà ta sẽ không bao giờ dùng không
Chỉ là giờ mất nhiều thời gian hơn để tìm thứ mình muốn giữa đống tính năng phình to được thêm vào
Phần mềm tối giản vẫn tồn tại, nhưng mọi người không mấy khi chọn. Nếu dành kha khá thời gian để chọn dependency một cách thận trọng, điều đó sẽ dẫn tới một stack nhẹ và hiệu năng tốt
Dạo này tôi thích các công cụ như Lua, SQLite, Fennel[0], Althttpd[1], Fossil[2], Mako Server[3]. Có thể dùng miễn phí những phần mềm tuyệt vời, nhẹ, ổn định và hiệu quả, nhưng phải bước lệch khỏi con đường phổ biến một chút. Chúng không phải là những thứ bạn thường nghe trên Stack Overflow
Với frontend thì tôi hơi mâu thuẫn. Tôi thích ứng dụng native và trang web hơn, nhưng vẫn dùng Tiddlywiki hằng ngày, và tôi nghĩ web app có chỗ đứng của nó. Tuy vậy, một tab chứa tệp Tiddlywiki 6MB dùng 155MB RAM, trong khi một phiên Emacs đã tùy biến rất nhiều của tôi chỉ dùng 88MB, nên tôi đồng ý với mối bận tâm của tác giả
[0]: https://fennel-lang.org/
[1]: https://sqlite.org/althttpd/doc/trunk/althttpd.md
[2]: https://fossil-scm.org/home/doc/trunk/www/index.wiki
[3]: https://makoserver.net/
Dĩ nhiên vẫn có thể dùng sai, nhưng so với hầu hết các ngôn ngữ khác, mức độ nhỏ gọn và hiệu quả mà một chương trình Lua có thể đạt được gần như gây sốc
Tôi nghĩ vấn đề đại khái là thế này. Lãnh đạo công ty cho rằng để cạnh tranh, lập trình viên cần phần cứng xịn nhất, và lập trình viên xây web app trên chiếc laptop hiệu năng cao với 128GB RAM do công ty cấp
Rồi họ không kiểm thử trên những môi trường như chiếc PC gia đình đời 2010 mà cha mình dùng, hoặc không kiểm thử đủ thường xuyên và kỹ lưỡng để nhận ra rằng nhiều phần bị hỏng đến mức không dùng được
Khi đó, responsive theo mobile-first, không gian màn hình hạn chế, và các vấn đề tiềm ẩn khi kết nối kém sẽ được xem là mối quan tâm hạng nhất
Thường thì khi báo vấn đề cho product owner, họ sẽ bỏ qua. Vì vậy mục thứ ba có thể sửa thành “có kiểm thử cả trên PC gia đình đời 2010, nhưng với các bên liên quan quan trọng hơn thì đó không phải mối bận tâm”
Gần đây, khi chuyển một trang cũ từ HTML thuần và cách tạo từ backend sang React, một dropdown có khoảng một nghìn mục mất vài giây mới mở ra. Trước đây, toàn bộ trang mở chỉ khoảng 100ms
Ban đầu có đề xuất chỉ hiển thị 100 mục đầu tiên và chỉ render khi người dùng nhập ba ký tự. Thực tế ngày nay đúng là như vậy
Tất nhiên, thực tế là chúng tôi đã sửa phần code React tệ hại để nó render ngay lập tức
Nếu framework mới làm vấn đề lộ rõ đến mức ai đó có lý do để thực sự sửa nó, thì ngược lại lại càng có thêm lý do để dùng framework đó
Cứ đề cao những bài như “idiomatic Ruby” hay “tối ưu hóa quá sớm là cội nguồn của mọi điều xấu”, rồi nói “thời gian phát triển quan trọng hơn hiệu năng”, nên mới thành ra thế này
Trước đây từng có những lập trình viên viết code tốt hơn trong ít thời gian hơn
Tôi cũng đã thấy rất nhiều code cũ khủng khiếp mà nếu là bây giờ thì đã không được tạo ra