Có thực sự có ai thích React không?

 (jsx.lol)
1 điểm bởi GN⁺ 4 giờ trước | 2 bình luận | Chia sẻ qua WhatsApp
  • Một bộ sưu tập tư liệu được tuyển chọn từ các bài viết chỉ trích React và các công cụ thuộc hệ React, được sắp xếp theo dạng trích dẫn từ nhiều lập trình viên và blogger khác nhau
  • Bao gồm nhiều bài viết chỉ ra những giới hạn mang tính cấu trúc của React như suy giảm hiệu năng, độ phức tạp gia tăng, và các vấn đề hydration
  • Việc lựa chọn công nghệ lấy React làm trung tâm bị cho là đã trở nên cố định bởi quán tính và hiệu ứng mạng lưới hơn là sự phù hợp kỹ thuật, với giả định rằng “ai cũng biết React” còn được đặt lên trước cả quyết định kiến trúc
  • Mối lo ngại về bảo mật và quản trị xoay quanh React Server Components và Next.js đã gia tăng, trong đó CVE-2025-55182 được công bố là lỗ hổng thực thi mã từ xa không cần xác thực với mức CVSS 10.0
  • Sự hỗn loạn trong thiết kế API và khủng hoảng chất lượng của hệ sinh thái React, cùng với độ phức tạp ngày càng tăng, khiến việc bảo trì dài hạn và học tập trở nên khó khăn, đồng thời dẫn tới tranh cãi về định hướng của React, từ Hooks, các tính năng UI hiện đại cho tới quy trình phát hành

Tổng quan về trang web

  • Một trang tuyển chọn nội dung với câu hỏi khiêu khích: "Does anybody actually like React?"
  • Bộ sưu tập được cherry-pick các bài viết chỉ trích React và những công cụ chịu ảnh hưởng từ React
  • Có cung cấp tính năng đăng ký RSS

Những chỉ trích mang tính nền tảng đối với chính React

  • The End

    • React gần như luôn là lời giải sai, và đã trở thành chiếc búa khiến mọi thứ trông như cái đinh
    • Có thể dùng React cho tốt, nhưng trên thực tế hiếm khi nó được dùng tốt

  • JS-heavy approaches are not compatible with long-term performance goals

    • Các dự án lấy JS làm trung tâm từ một quy mô nhất định trở lên thì chậm hơn quảng cáo, và càng về sau càng chậm hơn
    • Cần nhiều công sức hơn để phát triển và bảo trì, đồng thời cũng có nhiều lỗi không kém các cách tiếp cận khác

  • React Still Feels Insane And No One Is Talking About It

    • Dễ đi tới kết luận rằng React “đơn giản là điên rồ”, nhưng vẫn cần nỗ lực để hiểu nó một cách hợp lý

  • Stop Using and Recommending React

    • Dựa trên kinh nghiệm dùng React trong thời gian dài, tác giả cho rằng không có lý do để dùng nhưng có rất nhiều lý do để phản đối

  • Please don't use React

    • Lập luận rằng nên ngừng dùng React, và lẽ ra ngay từ đầu đã không nên dùng nó

  • Tech Founder? Entrepreneur? This is why you should avoid React.js in your app

    • React không chỉ chậm, mà còn là một hệ sinh thái cồng kềnh với nợ kỹ thuật được khắc ngay trong DNA
    • Đồng thời đặt câu hỏi về thực tế rằng nó vẫn liên tục được lựa chọn

Vấn đề bảo mật và quản trị

Vấn đề thiết kế API và đường cong học tập

  • Is it Time to Regulate React?

    • Thất bại cốt lõi của React trở nên nặng nề hơn vì thiết kế API gây bối rối
    • Tài liệu thiếu dứt khoát, và tranh cãi về cách dùng đúng cứ kéo dài bất tận

  • I don't have time to learn React

    • Trái với tuyên bố rằng React dạy UI hiện đại, trên thực tế nó hầu như không xử lý được UI hiện đại
    • autofocus bị hỏng, còn custom elements thì không hoạt động ngoài các phiên bản thử nghiệm
    • Muốn dùng các tính năng hiện đại như dialog hay popover thì phải cần tới useEffect
    • Vì hệ thống synthetic event nên gần như không học được cách DOM thực sự vận hành
    • Đây không phải UI hiện đại mà là UI ở trình độ năm 2013

  • The React Blog Post: Reflections and Reactions

    • Thái độ quy mọi vấn đề thành “skill issue” và nói rằng có thể giải quyết bằng thư viện bên ngoài là điều kỳ lạ
    • Một công nghệ đáng ra phải cho phép quay lại sau 3 năm vẫn làm việc được, nhưng frontend, đặc biệt là React, thì không như vậy

  • React, where are you going?

    • Hai vấn đề khiến React ngày nay kém thú vị hơn: ownership và complexity
    • Bày tỏ lo ngại rằng các lập trình viên mới có thể bị React làm cho chùn bước

Vấn đề hiệu năng và trải nghiệm người dùng

  • Why use React?

    • Về cơ bản người dùng bị mắc kẹt trong mô thức hydration khét tiếng
    • Cấu trúc là chạy toàn bộ tính toán bằng JS ở phía máy chủ, gửi HTML ngay lập tức, rồi lại gửi đúng phần JS đó xuống client một lần nữa

  • How React 19 (Almost) Made the Internet Slower

    • Sau làn sóng phản đối công khai và tranh cãi dữ dội, đội ngũ React đã hoãn thay đổi này

  • An even faster Microsoft Edge

    • Chuyển từ React sang Web Components hiện đại + kiến trúc HTML-first
    • Đặc biệt mang lại lợi ích lớn cho người dùng phần cứng cấu hình thấp

  • Switching costs

    • Mong rằng sẽ có nhiều phàn nàn hơn về trải nghiệm người dùng tệ hại mà React phía client áp đặt
    • Nhưng trên thực tế, các phàn nàn hầu như chỉ tập trung vào trải nghiệm lập trình viên

  • Pivoting From React to Native DOM APIs: A Real World Example

    • Một đội phát triển đã chuyển từ “VDOM áp đảo” của React sang các DOM API hiện đại
    • Tốc độ và khả năng tương tác được cải thiện ngay lập tức

Vấn đề trên di động và nền tảng

Vấn đề hệ sinh thái và cộng đồng

  • React Won by Default – And It's Killing Frontend Innovation

    • Khi cần một frontend mới, điểm khởi đầu không phải là "các ràng buộc là gì và công cụ nào phù hợp" mà là "dùng React đi, ai cũng biết rồi"
    • Một chu kỳ tự củng cố trong đó hiệu ứng mạng lưới chứ không phải độ phù hợp kỹ thuật quyết định kiến trúc

  • Conferences, Clarity, and Smokescreens

    • Từ công việc tư vấn và dữ liệu ngành, cộng đồng React đang rơi vào một cuộc khủng hoảng chất lượng sâu sắc và có thể đo lường được
    • Người tham dự React Summit không được nghe về điều này

  • Why Silicon Valley CTOs Are Secretly Moving Away from React

    • Có rất nhiều lập trình viên React, nhưng những người thật sự thành thạo và hiểu các pattern chuyên sâu ngày càng hiếm và đắt đỏ hơn
    • Những kỹ sư giàu kinh nghiệm nhất đang chán nản vì độ phức tạp và chuyển sang các stack công nghệ khác

  • Increasingly miffed about the state of React releases

    • Đã một năm rưỡi trôi qua kể từ lần phát hành React gần nhất, lâu hơn bất kỳ chu kỳ phát hành nào trước đó

Phê phán React Server Components

  • React Server Components: the Good, the Bad, and the Ugly

    • React gần như đã buông hẳn việc cải thiện phía client (kể từ khi dừng thử nghiệm vào năm 2019)
    • Một framework di sản được tạo ra để giải quyết các vấn đề ở quy mô Facebook bằng nguồn lực quy mô Facebook, không phù hợp với phần lớn trường hợp sử dụng

  • React Server Components are a bad choice (for shipping)

    • Nếu muốn phát hành nhanh, không nên dùng React Server Components
    • Có thể dùng nếu mục đích là học tập, thử nghiệm hoặc làm nội dung

Quay về nền tảng cơ bản và nhấn mạnh các lựa chọn thay thế

  • HTML is better than React!?

    • Ưu điểm của progressive enhancement dựa trên HTML
      • Mang lại trải nghiệm có thể sử dụng được cho người dùng nhanh hơn
      • Trang web không trông tệ hại ngay cả trên kết nối chậm
      • Ngay cả khi có sự cố, người dùng vẫn có thể tiếp tục sử dụng trang web

  • How to build a counter component using the HTML Framework in just 1 line of code

    • Lời khuyên châm biếm: "hãy tìm thư mục node_modules rồi kéo nó vào thùng rác"

  • Liskov's Gun: The parallel evolution of React and Web Components

    • React đã trở thành một đống tàn tích phình to bởi những lời hứa sai lệch, các tuyên bố dễ gây hiểu nhầm và vô tận các lớp tương thích ngược
    • Ngay cả khi cập nhật, nó cũng thường xuyên làm hỏng mã

  • Removing React is just weakness leaving your codebase

    • Rời xa các framework nặng như React và tập trung vào nền tảng cốt lõi của web để bảo đảm tương lai cho sự nghiệp và codebase

  • Concatenating text

    • Tại sao mỗi khi cần cập nhật giao diện, mọi người lại nghĩ ngay đến React
    • Hoài nghi về xu hướng gộp mối quan tâm của frontend và backend lại với nhau

Các trường hợp migration và chuyển đổi

  • We Rewrote our React App in Svelte in Three Weeks

    • Từng phớt lờ những tiêu đề gọi Svelte là framework "được yêu thích nhất", nhưng giờ đã gia nhập phe Svelte

  • Moving on from React

    • Sau một khởi đầu sai lầm với React trong năm 2023, đã chuyển sang một stack công nghệ phù hợp hơn với miền nghiệp vụ của khách hàng

  • Moving on from React, a Year Later

    • Frontend nặng JavaScript của thời đại "fat client" đang dần biến mất
    • Cơn sốt ứng dụng edge là không cần thiết đối với việc xây dựng nhiều loại hình kinh doanh khác nhau

  • Replacing React: How Liveview solved our performance problems

    • Khám phá LiveView vì các vấn đề hiệu năng của React SPA
    • Chỉ sau 2 ngày tìm hiểu đã có niềm tin, và trong vài tuần đã thay React SPA bằng LiveView

Xu hướng tổng thể và triển vọng sắp tới

Hooks và các mô hình thay thế

  • Why Signals Are Better Than React Hooks

    • Hooks của React khó dùng đúng, và còn khó hơn để dùng sao cho hiệu năng tốt
    • Là nguyên nhân khiến chất lượng mã và hiệu năng suy giảm ở nhiều ứng dụng

Phê bình mang tính ẩn dụ

  • What Is React.js?

    • Video ví sự kỳ lạ của những người ủng hộ, sự quá mức nghiêm trọng hóa bản thân và tài liệu bất tận với Cơ đốc giáo

Bài viết liên quan

2 bình luận

 
bichi 54 giây trước

React chỉ là một thứ tín ngưỡng thôi (tà đạo)
 
GN⁺ 4 giờ trước
Ý kiến trên Hacker News

  • Có vài điểm tôi không thích ở React. React là một framework để vẽ HTML tương tác lên màn hình, chứ không phải để làm kiểu lập trình cực kỳ phức tạp
    Thứ nhất, nó dựa quá nhiều vào các khái niệm và thuật ngữ phức tạp. So với Vue thì useEffect tương ứng với watch, còn useMemo tương ứng với computed
    Thứ hai, kiểu làm việc “thông minh” không cần thiết này đã lan từ thuật ngữ sang cả hệ sinh thái. Redux ngày xưa ngay cả để tăng một con số lên một đơn vị cũng phải viết rất nhiều code ở nhiều file, và trông như vậy là vì tác giả thích các khái niệm khoa học máy tính bóng bẩy. Cùng thời đó, với VueX thì chỉ cần tăng con số đó lên là xong. May là dạo này trong hệ sinh thái React đã có nhiều công cụ quản lý trạng thái tỉnh táo hơn
    Thứ ba, React không cung cấp sẵn công cụ làm việc với CSS
    Thứ tư, React không tự tối ưu giúp bạn. Bạn phải biết khi nào và bằng cách nào nên hoặc không nên dùng useEffect và useMemo, và còn có rất nhiều kiểu truyền miệng về tối ưu hóa React. Vấn đề là chuyện này lại xảy ra trong khi mục đích cốt lõi của nó là re-render. Trong Vue, framework buộc bạn dùng các công cụ của nó và tự xử lý phần lớn tối ưu bên trong, nên tôi chưa từng nghĩ mình phải tối ưu thủ công một ứng dụng Vue
    Thứ năm, chính cái kiểu truyền miệng đó cũng là vấn đề. API của React và “cách viết React đúng” đã thay đổi lớn quá nhiều lần, nên đến giờ vẫn rất khó phân biệt điều gì còn đúng và điều gì không
    Tóm lại, có thể nói React tập trung quá nhiều vào ý tưởng, khoa học máy tính và các lớp trừu tượng cấp cao, còn ít tập trung hơn vào việc thực sự giúp bạn dễ dàng vẽ HTML tương tác lên màn hình
    Tôi dùng rất nhiều cả React, Vue lẫn Svelte, nhưng khi dùng React thì cứ phải liên tục để ý những thứ mà nếu là Vue hay Svelte thì đã xử lý sẵn rồi. Về hiệu năng thì cả ba khá giống nhau
    Trước đây tôi cũng từng viết bài liên quan: https://www.brachkow.com/notes/what-i-like-in-vue/

  • Với tư cách là người đã trải qua hầu như toàn bộ dòng chảy chính của JavaScript trong khoảng 16 năm qua, thì theo một nghĩa nào đó tôi có thích React
    React là framework JavaScript tệ nhất nếu bỏ qua tất cả những thứ khác mà chúng ta từng thử
    So với thời Angular 1 thì tôi sẽ chọn React bất cứ lúc nào. So với kiểu Backbone phải tự ráp mọi thứ từ đầu mỗi lần, tôi sẽ chọn MVC nặng nề của Angular 1, còn so với cấu trúc súp JQuery cổ điển thì ngay cả cấu trúc MVC tối thiểu của Backbone cũng còn tốt hơn. Thời đó, so với các API native thì tôi sẽ lập tức chọn thao tác DOM của JQuery cùng phần thư viện tiêu chuẩn được bổ sung của nó
    React cũng có những đánh đổi, nhưng đây là điểm đến sau khi đã trải qua quá lâu vô số phương án thay thế không hoạt động hiệu quả

    • Tôi thích dùng React và sẽ chọn React hơn những thứ xuất hiện trước nó. Nhưng nếu nhu cầu chỉ đến mức đó thì tôi sẽ không chọn React thay vì htmx/data-star và render phía server, kể cả khi có thêm vài trang phức tạp hơn một chút cũng vậy
    • Nhưng tôi không hiểu vì sao lại chọn React thay vì Vue. Điều làm tôi bức bối nhất là cuối cùng Vue cũng lại đi theo hướng của React. Cấu trúc component nguyên bản của Vue, tức là template HTML, state JavaScript và style CSS nằm cùng nhau, thực sự rất tuyệt. Cách lấy dữ liệu bằng URL ngay trong component cũng cực kỳ trực quan
    • Đồng ý. Tôi đã đi từ HTML cgi-bin viết tay sang JQuery, Angular v1 rồi đến React, và React là công cụ tôi sẵn sàng dùng. Nó làm được điều tôi cần làm
    • React tốt hơn Angular, còn Vue tốt hơn React
    • Không biết bạn đã thử Svelte chưa. Tôi thật sự không hiểu vì sao ai đó lại thích React hơn. Theo tôi, ưu điểm duy nhất của React là nó giống như IBM của frontend. Chọn React thì sẽ không ai bị sa thải

  • Tất nhiên là có người thích React. Nó đâu có giống JavaScript là thứ trên thực tế gần như buộc phải dùng, và cũng không ai bị ép phải dùng React hay các framework web khác, vậy mà React đã thắng. Ít nhất có thể xem đó là bằng chứng rằng nó được thích đủ nhiều, hơn phần lớn các framework khác
    Cho đến cuối thập niên 2010, lời phàn nàn phổ biến về phát triển web là mọi thứ thay đổi quá nhanh và luôn có cái mới phải học, và lời phàn nàn đó là hợp lý. Nhưng khi văn hóa đơn nhất của React leo lên đỉnh, giờ mọi người lại phàn nàn vì không thích điều đó. Đúng là chẳng thể thắng kiểu gì

    • Ở chỗ làm, tôi gần như chưa bao giờ được chọn framework hay library. Hầu như lúc nào cũng là tiếp quản thứ ai đó đã bắt đầu từ vài năm trước, hoặc bị buộc trong một tổ chức với các lựa chọn rất chặt. Về cá nhân thì tôi sẽ không chọn React
      React thắng vì nó trở thành lựa chọn mặc định và vì mọi người thích thứ quen tay với sở thích của mình
    • React có những điểm mạnh, nhưng nó cũng thường được chọn vì quán tính hơn là vì đó là công cụ tốt nhất cho công việc. Những lý do như “ai cũng dùng React nên có thể tối đa hóa nguồn tuyển dụng và thuê ngoài”, hay “dự án React trông đẹp trên CV” vẫn đang phát huy tác dụng
    • Thậm chí người ta còn bị buộc phải dùng React và Next.js. Nhiều nhà cung cấp SaaS hợp tác với Vercel và chỉ mở các điểm mở rộng về phía đó
      Nếu muốn dùng thứ khác thì bạn phải tự triển khai tích hợp, hoặc tìm một dự án mã nguồn mở đã làm sẵn, hoặc hỏi AI
      Làm cho dự án cá nhân thì còn được, chứ trong môi trường công việc thì rất khó tưởng tượng
    • Tôi không hiểu câu “không ai bị ép dùng React” nghĩa là gì. Không biết có nơi thế giới mới tuyệt vời nào mà bạn có thể đi học Lisp rồi dùng nó cho mọi thứ mình muốn, còn văn hóa doanh nghiệp thì hoàn toàn không ảnh hưởng đến lựa chọn công nghệ

  • Tôi thích React. Tôi cũng đã nghiêm túc thử cả phe HTMX/Hotwire
    Tôi từng muốn tạo một nút quay lại sao cho nếu đi từ hộp thư đến thì dùng Browser API để quay lại, còn nếu không thì chuyển tới liên kết hộp thư đến để giữ nguyên vị trí cuộn. Tôi đã phải nối hành vi trong HTML để gọi hàm quay lại, rồi trong controller xác định trang trước đó là gì, sau đó trả về hoặc là nút quay lại có JavaScript hoặc là một liên kết cứng. Logic bị rải ra trong 3 tệp
    Còn trong React, JavaScript bên trong component có thể xác định liệu trang trước có phải là hộp thư đến hay không, rồi dựa vào đó hiển thị JSX của nút quay lại hoặc một liên kết. Mọi thứ đều xong trong một tệp. Với tôi, chỉ cần mô hình hóa một thực thể khái niệm duy nhất, trong khi cách khác lại phải gượng ép nhét chức năng vào 3 thực thể khác nhau
    Nếu hỏi có chậm hơn không thì chắc chắn là chậm hơn. Nhưng nó vẫn khiến tôi thấy vui. Nếu bạn đang khổ sở với một codebase React bừa bộn ở công ty thì nên trách đồng nghiệp của mình. Nếu không có React, chắc chắn mọi thứ còn tệ hơn nhiều

    • Đó cũng là lý do tôi ghét các ứng dụng React single-page. Có vẻ như chúng luôn tìm ra những cách ngớ ngẩn để làm hỏng nút quay lại và nút điều hướng của trình duyệt
      Ngoại trừ đôi lúc chỉ cần cải thiện form, tôi lúc nào cũng sẽ ưu tiên htmx/server rendering và hành vi native
    • Tôi nghĩ HTMX chỉ nên dùng cho những việc liên quan đến trạng thái dữ liệu. Những thứ không phụ thuộc vào trạng thái tài nguyên, như nút quay lại thông minh, thì tốt hơn là đừng tính toán ở backend
      Theo cách dùng htmx được khuyến nghị, bạn chỉ cần nối nút onclick với JavaScript inline, hoặc nếu không thích thì gọi một hàm như goBackOrInbox là được
      function goBackOrInbox() { if (document.referrer) { const path = new URL(document.referrer).pathname; if (path.startsWith('/inbox')) { history.back(); return; } } window.location.href = '/inbox'; }
      Nếu dùng kiểu mẫu này nhiều, bạn chỉ cần tham số hóa nó bằng cách nhận đường dẫn cần chuyển đến làm đối số
    • Tôi nghĩ cách tốt nhất để giải quyết vấn đề nút quay lại là đừng làm mọi thứ quá phức tạp, mà hãy đảm bảo chỉ những gì thực sự muốn quay lại mới được đưa vào lịch sử trình duyệt. Bản thân cách đặt vấn đề dường như đang hét lên rằng “nếu cấu trúc tốt hơn thì đây sẽ là bài toán không cần giải”
    • Chắc chắn sẽ có những phần phức tạp ở đây ở đó, nhưng tôi nghĩ chẳng phải vẫn có thể làm được bằng Web Components sao

  • Tôi đã dùng React code trong một thời gian dài, còn giờ thì đang làm một dự án Vue lớn ở công ty. Trước đây ai cũng nói Vue là lựa chọn dễ hơn và dễ tiếp cận hơn trong hai bên, nhưng giờ tôi bắt đầu nhìn khác
    React thật thanh nhã ở chỗ component về bản chất chỉ là các hàm, ngoài ra không có nhiều thứ khác. Nếu tạm gác hệ sinh thái Next.js sang một bên, đây là thứ thanh nhã nhất tôi từng thấy trong phát triển frontend
    Ngược lại, Vue cho tôi cảm giác bị trộn lẫn. Nó mang dấu vết của việc được các backend developer không thực sự muốn học JavaScript tiếp nhận và ca ngợi, và kết quả là một hỗn hợp gượng gạo không khớp vào nhau một cách gọn gàng

    • Tôi chưa bao giờ hiểu được quan điểm này. React component không chỉ là hàm, mà là hàm có gắn ngữ cảnh được tiêm vào như phép thuật mà bạn truy cập thông qua hooks. Những hook này đòi hỏi đủ loại bảo đảm, và nếu không ý thức được điều đó thì rất dễ sinh ra kết quả khó debug. Theo tôi, nó còn xa mới gọi là thanh nhã
      Tôi đã dùng tất cả các framework lớn và hiện đang xây một ứng dụng web Angular lớn. Trong Angular, component được biểu diễn bằng class, template và style. Event listener nhìn chung sẽ gọi các method của class, còn state có thể đơn giản như các thuộc tính của class. Tự nhiên hơn nhiều và cũng có ít cạm bẫy hơn hẳn. Tất nhiên không phải là bằng 0
    • Tôi tò mò không biết bạn đã dùng Vue bao lâu rồi. Tôi cũng từng nhìn Vue từ nền tảng React vài năm trước và có suy nghĩ tương tự. Nhưng giờ tôi thích Vue hơn React, và trong cả dự án cá nhân lẫn dự án công việc, tôi đều chọn Vue trước
      Trải nghiệm sử dụng có hơi khác. Có việc dễ hơn trong React và cũng có việc dễ hơn trong Vue, nhưng việc Vue dùng signals là một ưu điểm lớn đối với tôi

  • Thay vì bản thân React, tôi quan tâm hơn đến câu hỏi nói chung là cách tốt nhất để viết UI bằng code là gì
    Tôi là fan của React và dùng React cho gần như mọi ứng dụng web mình làm, nhưng vấn đề lớn nhất và rõ ràng nhất là việc viết UI bằng React không mang lại cảm giác tự nhiên như khi dùng Go để viết công cụ dòng lệnh hay dùng Elixir để viết ứng dụng thời gian thực
    Có những ngôn ngữ cho cảm giác tự nhiên đến kinh ngạc và hầu như không có ma sát với một số loại công việc nhất định. Nhưng UI thì đến giờ vẫn chưa ai thật sự chinh phục được. Swift, JSX/HTML, Svelte, hay bất kỳ framework phổ biến nào cùng nhóm đó đều cho cảm giác như đang lách qua vấn đề ở một mức độ nào đó. Như thể đến một thời điểm nào đó, người thiết kế ngôn ngữ/framework đã phải thỏa hiệp và nhét vào thứ cú pháp lộn xộn, kỳ quặc hoặc gây đau đầu để đáp ứng yêu cầu
    Giao diện tự nhiên của UI là trực quan, nên các công cụ như Figma có thể là một phần quan trọng của lời giải. Nhưng tôi vẫn cảm thấy còn thiếu gì đó. Hẳn phải có cách trực giác hơn để biểu đạt thứ mang tính thị giác bằng code. Khó diễn tả chính xác, nhưng các giải pháp hiện tại lúc nào cũng có cảm giác hơi thiếu một chút ở đâu đó

    • Tôi cũng có cảm giác tương tự. Khi React mới ra mắt, nó thật sự có cảm giác hoàn hảo so với các lựa chọn thay thế lúc bấy giờ nên tôi rất thích
      Đến giờ tôi vẫn thích React hơn gần như mọi thứ khác, bao gồm Svelte, Vue và Solid. Nhưng gần đây tôi bắt đầu dùng Crank(https://crank.js.org/), và nó có vẻ gần hơn một bước với hướng mà tôi muốn đi. Dù vậy, đến nay tôi mới chỉ dùng nó cho các dự án thử nghiệm, nên khó nói nó sẽ mở rộng tốt đến đâu cả về hiệu năng lẫn trải nghiệm lập trình viên
    • Tôi cực kỳ đồng ý với ý “có những ngôn ngữ tự nhiên đến kinh ngạc và hầu như không có ma sát với một số công việc nhất định, nhưng UI thì vẫn chưa ai thật sự chinh phục được”. Nếu đọc những cuốn sách[1] bàn về vấn đề này từ đầu thập niên 90, bạn sẽ thấy chúng vẫn còn nguyên giá trị đến bây giờ
      Phân tích hay nhất tôi từng thấy nằm trong bài “Programs = Data + Algorithms + Architecture: consequences for interactive software engineering”[2] của Chatty. Hơi khó đọc nhưng hoàn toàn xứng đáng
      Tóm tắt ngắn gọn thì vấn đề là ở kiến trúc, cụ thể hơn là sự lệch nhau giữa ngôn ngữ và kiến trúc. Kiểu kiến trúc call/return mà các ngôn ngữ lập trình “mục đích chung” dẫn đến không phù hợp với kiến trúc mà giao diện người dùng cần, thậm chí còn xung đột với nó
      Tôi cũng đã viết về chủ đề này trong “Can Programmers Escape the Gentle Tyranny of call/return?”
      Cách tiếp cận hiện tại là trước tiên tạo ra Objective-Smalltalk[4], một ngôn ngữ lập trình có thể biểu đạt dễ dàng các kiểu kiến trúc thay thế
      Từ đó, tôi đang xây dựng một framework UI tên là interscript, đồng thời bao gồm HTMXNative và nhiều thành phần bổ sung khác
      Có vẻ mọi thứ đang tiến triển khá tốt
      [1] Ví dụ: “Languages for developing user interfaces” của Myers và cộng sự https://api.taylorfrancis.com/content/books/mono/download?id...
      [2] https://opendl.ifip-tc6.org/db/conf/ehci/ehci2007/Chatty07.p...
      [3] https://2020.programming-conference.org/details/salon-2020-p...
      [4] https://objective.st
    • Với tư cách kỹ sư, rất dễ nhìn mọi vấn đề và nghĩ rằng “chắc chắn có một lời giải hoàn hảo, chỉ là mình chưa tìm ra thôi”
      Nhưng theo thời gian, tôi dần chấp nhận những câu trả lời bớt lý tưởng hơn. Có lẽ lời giải như vậy không tồn tại. Có thể không gian vấn đề quá phức tạp nên không tồn tại một lời giải tổng quát khả thi về mặt con người có thể bao quát mọi dạng thức. Nếu có một lĩnh vực đúng như vậy thì có lẽ đó là UI

  • Đúng vậy. React là giao diện trực quan nhất, vượt trội hẳn, trong việc kết hợp thành công phong cách khai báo và mệnh lệnh. Xét trên mọi framework UI của mọi ngôn ngữ, tôi không thấy gì tiến gần JSX được

    • Nhiều nền tảng khác như Flutter, SwiftUI, Jetpack Compose đều đã triển khai React như thể đó là framework UI của riêng họ
    • Nếu nó trực quan đến vậy thì tôi không hiểu vì sao gần như mọi ứng dụng React đều có lỗi hiệu năng

  • Tôi thực sự rất thích Svelte, và dùng SvelteKit cho các ứng dụng phức tạp hơn
    Tôi cảm thấy đó là một cải tiến tốt hơn nhiều trong rất nhiều trường hợp mà trước đây tôi sẽ dùng React
    Svelte có vẻ dễ học hơn nhiều đối với những ai đã biết nền tảng web development, HTML, CSS và JavaScript. Nhưng dạo này tôi thường thấy mọi người bắt đầu web development bằng React, và thứ tự đó có vẻ hơi ngược
    Cá nhân tôi đang làm ứng dụng di động bằng SvelteKit + Capacitor, và đã viết cấu hình ở đây: https://bryanhogan.com/blog/web-to-app-sveltekit-capacitor
    Với các landing page đơn giản, tôi thích Astro hơn

    • Tôi cũng luôn chọn Svelte + SvelteKit trước tiên. Dùng Kit cho ứng dụng đơn giản có thể là hơi quá tay, nhưng sẽ rất tốt nếu có nó khi mọi thứ bất ngờ trở nên phức tạp
      Tôi đồng ý rằng việc mọi người ngày nay bắt đầu web development bằng React có cảm giác hơi ngược. Svelte xử lý HTML như tiếng mẹ đẻ nên giúp ngăn vấn đề này khá tốt. Nếu bắt đầu web development bằng Svelte(Kit), khả năng cao bạn sẽ học được nhiều nền tảng cơ bản hơn so với khi bắt đầu bằng React
    • Với tôi thì tổ hợp Svelte + Astro là phù hợp. Nó rất tốt cho các trang tài liệu và những trang chỉ có tương tác tùy chọn

  • Tôi có thiên kiến vì từng là một trong số những người góp phần làm cho React trở nên khả thi, nhưng tôi thực sự rất thích React. Trước đó, tôi đã thử đủ mọi thứ để sửa các vấn đề mình gặp ở frontend. Nhưng từ sau khi React xuất hiện, tôi không còn cần làm thế nữa, và có thể chỉ tập trung vào việc xây dựng

  • Một trong những bài thuyết trình tôi đánh giá rất cao là https://www.youtube.com/watch?v=h9SDuTSy7ps. Theo kinh nghiệm của tôi, kiến trúc của React thực sự rất tốt và khá phù hợp để xây dựng các ứng dụng lớn
    Đáng tiếc là vấn đề lớn nhất của React là nó buộc bạn phải bước vào hệ sinh thái JS/TS. Với tôi, JavaScript/TypeScript rõ ràng gần với mục tiêu biên dịch hơn là một hệ thống mà tôi muốn trực tiếp làm việc cùng
    Tôi hài lòng với Elm. Cộng đồng thực sự rất nhỏ, và đôi khi phải tự viết thư viện. TEA đôi lúc thấy không tự nhiên nếu đi từ React sang, nhưng tôi luôn hào hứng khi làm việc với Elm vì không phải lo về những trạng thái ngầm và khó lường như useEffect
    Hơn nữa, Claude dường như cũng trụ tốt hơn với Elm so với React, ít nhất là trong những codebase lớn và đáng sợ

    • Theo kinh nghiệm của tôi thì Elm trên thực tế gần như đã chết. Tốt hơn là dùng React và TypeScript, nơi có các thư viện vẫn tiếp tục hoạt động. Cũng từng có những nỗ lực nhằm biến TypeScript thành thứ có thể biên dịch native
    • Tôi thích TEA, nhưng chưa hoàn toàn hiểu nó mở rộng thế nào trong các ứng dụng có component tái sử dụng hoặc những trang đủ phức tạp. Tôi tò mò không biết có cách làm nào đã được cộng đồng đồng thuận cho việc này hay không
      State có vẻ như là một điều cấm kỵ lớn, nên cảm giác hơi mâu thuẫn. Tôi cũng tự hỏi liệu cuối cùng mọi ứng dụng Elm có trở thành một ứng dụng kiểu Redux + React toàn cục nhưng không có effect hay không. Tôi muốn biết chi tiết hơn điều gì khiến Elm thú vị và người ta làm việc với nó theo cách nào. Có link cũng được