ReactJS? Hiệu quả thực sự hay chỉ là trào lưu?
Đã có quá nhiều bài viết review về hiệu quả hay tốc độ tuyệt vời của reactjs, kèm theo đó là hàng đống dự án được thực hiện trên nó. Nhưng thực sự thì, reactjs hay cách làm của Facebook có thực sự là tốt nhất? Chúng ta hãy cùng xem qua ý kiến phản biện sau của Pandastrike: Phải công nhận một điều ...
Đã có quá nhiều bài viết review về hiệu quả hay tốc độ tuyệt vời của reactjs, kèm theo đó là hàng đống dự án được thực hiện trên nó. Nhưng thực sự thì, reactjs hay cách làm của Facebook có thực sự là tốt nhất? Chúng ta hãy cùng xem qua ý kiến phản biện sau của Pandastrike:
Phải công nhận một điều rằng: react đã khiến cả giới công nghệ phấn khích. Và nó dường như đã thay thế Angular để trở thành framework thời thượng nhất. Nhưng thực không may, vì cả hai framework đó đều không tốt! Nó thậm chí còn gây ảnh hưởng xấu đến toàn bộ nền công nghiệp phần mềm. Từ giờ trở đi, xin hãy sử dụng web components cho những dự án mới, vì một mục tiêu mọi thứ sẽ trở lên mở hơn.
Thiết kế của React tồi. Tôi có thể kể cho bạn rất nhiều vấn đề như - sự tách biệt của các vấn đề, gắn kết views với models, sự tập trung vào những cải tiến không cần thiết, tầm quan trọng của việc hỗ trợ các chuẩn mở - nhưng thay vào đó, tôi sẽ kể cho bạn một câu chuyện, về một startup có một sản phẩm thịnh hành và nhiều nguồn vốn đầu tư mạo hiểm. Startup này đã quyết định muốn biến sản phẩm của mình trở nên đặc biệt hơn. Họ muốn tạo ra thứ gì đó không chỉ là HTML và CSS.
The Wayward Startup
Mặc dù họ gặp khó khăn rất lớn khi sử dụng Canvas để xây dựng riêng rendering engine. Nhưng họ đã thành công. Tuy nhiên hóa ra chính các browsers cũng đang cố gắng giải quyết cùng vấn đề với công ty này. Thực tế, chỉ hai tuần sau khi công ty này tuyên bố những tính năng đặc biệt của rendering engine mới thì một browser lớn đã có giải pháp cho một trong những vấn đề đó.
Công ty startup này chính là Flipboard. Và với React-canvas, họ đã giải quyết được vấn đề lớn ở đây là cuộn trang mượt, tuy nhiên ngay sau đó thì Firefox đã có bản cập nhật. Thay vì đóng góp cùng với rất nhiều nỗ lực từ các công ty và tổ chức khác để tăng tốc việc rendering DOM, Flipboard quyết định viết riêng một rendering engine dựa trên Canvas. Nghe rất oách phải không? Nhưng nó có thực sự cần thiết? và khôn ngoan? Rõ ràng là không! Thay vì một giải pháp mà tất cả mọi người đều có thể hưởng lợi từ nó, chúng ta lại có một giải pháp dựa trên React. Thậm chí React có là một thiết kế tốt (thực sự thì không!), thì nó vô tình đã giới hạn lại tính khả dụng.
Dĩ nhiên chúng tôi, Panda Strike, không phải là những kẻ sùng bái mù quáng. Một vài người trong chúng tôi coi việc hỗ trợ hình động 60 FPS cho người dùng đọc báo, hay những nội dung tĩnh là ngu ngốc. Còn một vài người thì lại ủng hộ ý kiến của John Gruber, nên có tính phản hồi như trên IOS. Nhưng tất cả chúng tôi đều đồng ý rằng những kỹ sư ở Flipboard đều rất tài năng, và React Canvas có thể hữu dụng cho một vài lập trình viên. Nhưng nó sẽ tốt hơn nếu chỉ là một thư viện Canvas, mà không phải yêu cầu đi kèm với React.
Mọi sự cải tiến có thực là cải tiến?
Về bản chất thì React phụ thuộc vào Virtual DOM. So với browser DOM, các nodes của virtual DOM tương đối nhẹ. Bạn có thể tạo ra hàng ngàn nodes virtual DOM mà không làm giảm đi hiệu năng của chương trình. Không chỉ vậy, từ Virtual DOM, chúng ta có thể chỉ lấy những thay đổi và áp dụng vào browser DOM. Khá là tiện dụng. Nhưng vậy thì vai trò của nó là gì trong cái gọi là reactive programming? hay việc nhúng markup vào trong JavaScript?
Rõ ràng là không, và để chứng minh cho điều đó, bạn có thể tham khảo thư viện Virtual DOM này. Và đây là lý do tại sao Matt Esch và những người khác viết một phiên bản stand-alone:
Một thành phần quan trọng của phương thức virtual DOM là nó có một module và nó nên chỉ thực hiện tốt duy nhất một việc. Virtual DOM chỉ nên giải quyết việc mô tả virtual DOM. Những hàm diff, batch và patch chỉ nên liên quan đến những thuật toán cần thiết cho virtual DOM.
Virtual DOM không nên liên quan gì đến các sự kiện hay lưu trữ các trạng thái của ứng dụng. Ví dụ phía dưới chứng minh tính khả dụng của trạng thái với observ và các sự kiện với dom-delegator. Giống như việc sử dụng knockout hay backbone cho trạng thái và sử dụng jQuery hoặc component/events cho sự kiện.
Mục Đích Thực Sự của React
Thậm chí nếu Flipboard có dồn hết nguồn lực tài chính để cải tiến rendering engines của browsers, nó cũng không thể so sánh được với những gì Facebook có thể làm. Flipboard sai lầm khi đầu tư vào React canvas một thì Facebook phải trả giá mười, với React. Sẽ thế nào nếu thay vì đổ công sức vào một framework mà chỉ phục vụ cho một số lập trình viên, những nguồn lực đó được dùng để cải tiến chính những browsers?
Họ sẽ không làm vậy! vì đó không phải là điều họ quan tâm. Vào năm 2012, Mark Zuckerberg đã "thừa nhận" sai lầm lớn nhất khi đầu tư vào HTML5. Nhưng sau đó thì Sencha đã tạo ra một ứng dụng tương tự bằng HTML5, phản chứng lại những chỉ trích của Facebook về HTML5. Lợi nhuận của Google phần lớn phụ thuộc vào cỗ máy tìm kiếm, thực tế chính là phụ thuộc vào người dùng Web, tất cả mọi thứ. Trong khi đó, không giống Google, Facebook luôn chỉ thu được lợi tức từ hệ sinh thái riêng. Hay nói cách khác, Facebook chẳng quan tâm việc bạn có sử dụng web hay không, bạn có sử dụng Facebook hay không mới là vấn đề!
Vậy thì tại sao Facebook lại công khai hóa mã nguồn Web framework của họ? vì họ đang cạnh tranh với Google về mặt nhân sự. Như vậy, chúng ta đang có một cuộc chiến lớn, giữa hai công ty: môi trường làm việc ngầu nhất? làm thế nào để có lợi thế trong cuộc chiến này? đó là có Web framework thời thượng nhất!
Open Web Quan Trọng Hơn Bạn Tưởng
Trong khi đó, Web components đã được tích hợp trên Chrome và Firefox, đi kèm những hỗ trợ cho trình duyệt cũ. Nó chính là những thay đổi lớn nhất vì mục tiêu Open Web trong nhiều năm, và tại đây thì React đã trở nên hoàn toàn không cần thiết. (Nghiêm túc thì tại sao lại cần JSX và virtual DOM như là những thư viện độc lập? và với những thiết kế data flow đi cùng những thư viện đó, thì nó thậm chí chẳng có gì mới mẻ. Nó đã được sử dụng rộng rãi trong nhiều năm rồi.) Điều này thực sự không tốt, vì Open Web quan trọng, và mười năm trước, chúng ta gần như đã bỏ lỡ.
Có thể thấy, Microsoft giờ giống như một con bò lạc, lang thang qua những đồng bằng ở Sahara của những sản phẩm thất bại. Nhưng mười năm trước, họ đang ở vị trí là chủ cuộc chơi trên Web. Nếu bạn đã ở trong ngành công nghiệp này trên mười năm, thì mới nhận ra chúng ta đã từng gần như phải sống trong một thế giới mà, nếu muốn duyệt Web di động, bạn phải sắm cho mình một chiếc Window phone! bạn vẫn nghi ngờ ư? thì đây, Microsoft và vấn đề độc quyền, cho đến hiện tại thì nó vẫn phải giải quyết hậu quả của việc đó. Cho đến tận bây giờ, chúng ta vẫn cần đến sự hỗ trợ cho IE8, chỉ là một phiên bản của IE6, vô dụng, và đây lỗi. Chính những browsers đó đã kéo lùi sự phái triển của cả nền công nghiệp này trong gần một thập kỷ. Và lý do chính mà chúng ta có sự tự do đó là sự phát triển của Firefox và Webkit.
Chúng ta có được Open Web không phải tình cờ.
Vai Trò Của bạn
Chúng ta tùy ý phàn nàn về việc thời gian rendering của DOM quá "chậm" bời vì chúng ta không hiểu rằng một browser platform đang được cải tiến nhanh hơn cả việc chúng ta biết và sử dụng hết các chức năng mới của nó. Nó bao gồm cả những cải tiến lớn về việc rendering. Chúng ta sẽ đi thẳng vào vấn đề; chúng ta nên đầu tư vào việc làm cho những platform hiện thời tốt hơn. Và bạn chẳng cần phải biết C hay iOS, bạn chỉ cần là người sử dụng của những platform đó.
Quả thực, chỉ bằng việc sử dụng những cải tiến mới như Web components, thay vì dùng những thứ như React, bạn đang góp phần tạo ra Open Web. Khi nó được chấp nhận rộng rãi trong cộng đồng, thì nó sẽ trở thành một hệ sinh thái. Trong hai năm, thậm chí chúng ta có thể có một hệ sinh thái của những Web components có thể được tái sử dụng.
Cái được lớn nhất là bạn không phải thỏa hiệp để có thể có được những lợi ích từ Web components. Vì chúng thực sự là những tư tưởng tốt hơn rất nhiều để xây dựng giao tiếp người máy, so với React hay Angular. Cái mà nhiều người không nhận ra là những components đó bản chất đã theo mô hình MVC khi nó được xây dựng. Vì thế nó sẽ không giới hạn chúng ta khi sử dụng Web components. Thậm chí ngược lại, Web components còn đại diện cho một lựa chọn tuyệt vời hơn.
Hãy Sử Dụng Web Components
Một framework tốt sẽ hỗ trợ việc tách bạch các vấn đề. Web components không đưa ra một cách nào để thể hiện views hay kết nối các event handlers hay rendering thành DOM. Một framework tồi gắn kết nhiều thứ với nhau, nhiều thứ phải song hành. Đó chính là những gì React đang làm.
Chắc chắn bạn có thể sử dụng JSX nếu bạn muốn, nhưng đó lại chính là thứ tệ nhất của React. JSX muốn gắn kết view, model và controller. Ý kiến tồi. Đừng làm vậy. Virtual DOM thì tuyệt nếu cần nó, nhưng bạn có thể chẳng cần đâu, như thế này. React không phải là một framework tốt. Và Web components thì thậm chí chẳng phải framework, nó chính là những thứ mà các browsers đang sử dụng vậy. Một cách tổng quát hơn thì components là tất cả những gì mà Web đã được đầu tư và phát triển trong nhiều thập kỷ.
Cách giải quyết cho những vấn đề trên web sẽ không bao giờ là việc gắn chặt các thành phần hiển thị, dữ liệu và cách xử lý với nhau. Nếu không, cuối cùng thì những chương trình của bạn sẽ chỉ là những mớ bòng bong không thể bảo trì. Giải pháp sẽ là những Web browsers tốt hơn, cùng với các components có thể tái sử dụng. Nói cách khác, chúng sẽ được xây dựng trên những kinh nghiệm đã được phát triển qua hàng thập kỷ tiến hóa của nền công nghiệp phần mềm. Trong khi đó, cách tốt nhất cho bạn là hãy tập trung vào những vấn đề bạn có thể giải quyết.
Nguồn: https://www.pandastrike.com/posts/20150311-react-bad-idea