Liệu cái framework đó có bỏ vào mồm nhai, nuốt được?
Có nên dùng framework nhưng đừng bị lệ thuộc vào framework là được.
Dùng phải hiểu thật rõ nó nữa, không là ăn bug ngập mặt.
Biết là đứng trên vai người khổng lồ mà nhiều anh em quá thần thánh hoá nó quá.
Bug thường là vấn đề của người lập trình.
Không hiểu rõ cái mình làm thì dùng cái gì cũng ăn bug kể cả cái xử lý đơn giản nhất.
Để giảm bug chỉ có học nhiều, làm nhiều, dùng công cụ xịn.
Trong một project sẽ có nhiều phần và trong những phần đó có những cái cần thiết, bắt buộc, tốn tài nguyên nhân lực và thời gian nhưng lại không có nhiều giá trị. Những phần đó ưu tiên giải quyết nhanh bằng dùng lib, framework.
Hiệu quả công việc là cái rất quan trọng.
Đồng ý, nhưng mình đã gặp trường hợp phải đục nát framework chỉ để custom và vá lỗi của một framework sau khi đọc hầu hết các tài liệu và diễn đàn cho issue đó. Nên mình nghĩ phần lớn là vấn đề của người lập trình thôi, chứ không có nghĩa là framework không lỗi.
Thế mới có nhiều phiên bản của một framework và mình thường chọn phiên bản LTS để gặp ít lỗi nhất có thể.
Còn vấn đề ưu tiên giải quyết nhanh như bạn đề cập thì cũng không hoàn toàn đúng, vì có thể nhanh trước mắt nhưng càng về sau khi đối mặt mới nhiều thay đổi của requirement thì cái giá phải trả rất đắt. Thậm chí là đập hết đi, lúc đó tài nguyên và nhân lực còn tốn hơn.
Dù sao cái mình nêu ra chỉ là 2 mặt của một vấn đề, mình vẫn đang dùng framework nhưng mình không có nghĩ nó là bất tử 
Việc đập đi xây lại là do quá trình phân tích trước khi triển khai không chính xác đầy đủ.
Nên không định hình được sự phát triển trong tương lai dẫn đến vấn đề không tương thích khi phát triển, mở rộng thêm.
Nó phụ thuộc vào tầm nhìn, trình độ của cả team.
Còn framework tất nhiên nó được sinh ra thì cũng có thể nó sẽ chết hoặc phát triển liên tục dựa vào lợi ích nó mang lại. Không phủ nhận là lợi ích nó mang lại rất lớn.
Có cả framework là xương sống, là bắt buộc như NET.
Không hẳn, nếu bạn làm outsource bạn sẽ hiểu, tại thời điểm lựa chọn và quyết định chỉ làm sao cho đáp ứng được tốt nhất có thể tại thời điểm hiện tại và có thể thích ứng tốt nhất trong tương lai ngắn, tương lai thì không thể biết trước, yêu cầu mới sẽ phát sinh khiến cho phải đắp vá, thậm chí là xây lại để thích ứng và thay thế dần dần.
Nếu nói là tầm nhìn và trình độ của team thì có thể team yếu thật nhưng không hoàn toàn là lỗi do họ, không lý nào đổ thừa cho team trong khi công nghệ phát triển mỗi ngày.
Tán thành điều này. Lập trình các phần mềm (mà không vì lý do lịch sử đã có mã nguồn từ lâu) chạy trên Windows dám không dùng .NET thì quá là dũng cảm.
Chữ framework dùng cho nhiều thứ quá, nên đề cập thì liệt kê ra cái cần nói hoặc nhóm framework đó luôn để vấn đề hẹp lại.
Có những thứ người dùng dù muốn né Framework như né hủi nhưng rồi phải dùng thôi. Làm việc với Machine Learning mà không xài mấy cái như PyTorch, Tensorflow e rằng không biết đến đời nào viết xong cái gì đó để cho nó chạy được.
Linux Kernel cũng là một framework đấy
Quan điểm của mình là rất ghét những chủ đề đặt vấn đề nên hay không nên, vì cái gì tồn tại cũng có lý do/ mục đích của nó. Mình thích đặt vấn đề kiểu “liệu cái framework đó có bỏ vào mồm nhai, nuốt được?”. Hôm nào có anh em nào giỏi làm giúp cái web framework đặt tên Bánh tráng trộn , mình cảm thấy thèm ăn vặt sẽ lấy ăn.
Hợp lý, mình đề cập đến lợi và hại thôi chứ mình không có thiên về bên nào cả. Mình cũng đang dùng framework mà
Đổi tên theo ý bạn cho đỡ nặng nề.
Úi trời, bạn cũng thật là hài hước. Mình chỉ nói mang tính vui vui sau khi đọc bài blog của bạn, chứ hổng có ý gì căng đâu.
Mình thường hướng tới quan điểm nêu ra ưu và nhược điểm cho một thứ gì đó vì với mình chẳng có thứ gì luôn tốt và chẳng có cái gì chắc chắn xấu.
Quan trọng là cách lựa chọn, thời điểm, chi phí, và đáp ứng được nhu cầu.
Có những thứ cần phải tiếp thu những ý kiến khác nhau và mình vẫn open việc đó.
Đổi tên theo ý bạn để kích thích thêm trí tưởng tượng cũng hay hay 
Có thể do ngại học cái mới nên mình thường lo sợ mỗi khi có framework mới ra đời 
nếu framework mới ra đời giống như 1 bước đột phá khi phát minh ra xe máy trong khi toàn nhân loại đều đi xe đạp thì không sao. Chứ mỗi framework đều same same nhau cũng hơi ngại học. Mình có sở thích hơi dị là thỉnh thoảng xem các biểu đồ thống kê lượt download của các libray, framework trên npm như trader xem bảng điện tử chứng khoán. Browser mình luôn cài wappalyzer extenstion để xem những web mình truy cập có đang dùng framework yêu thính của mình không và cũng hơi buồn vì nó dùng framework khác mình kỳ vọng 
Cách học framework (mà không lạm dụng) là build một cái tương tự, nhưng mức đơn giản thôi.
Sử dụng API mà không viết nổi API mới là điều đáng lo.
mình nghĩ lợi ích to lớn của framework mang lại chính là thời gian, và cũng chính vì cái này làm cho mọi người dần nghĩ đó là điều dĩ nhiên, ví dụ ko có framework đó thì cả team phải ngồi build , test, vận hành, fix lỗi , đôi khi để viết 1 trang web mất vài tháng hoặc vài năm, nhưng có framework vào thì chỉ cần 1,2 tháng, nên lâu dần mọi người quên đi rằng cái sự phức tạp mà framework nó ẩn chứa bên trong, mọi người coi thường nó, coi thường quá trình tìm hiểu nó, dẫn đến bug, để tránh bug do việc hiểu chưa thấu đáo framework thì chỉ có cách là bỏ thời gian để tìm hiểu nó thôi, và mình nghĩ tổng thời gian mà mình bỏ ra để tìm hiểu nó chắc chắn ít hơn thời gian build lên 1 framework tốt tương đương
và 1 điều vô cùng oái oăm là khách hàng họ chả hiểu điều này, họ chỉ nói à cái này dùng framework này bỏ vào cái chỉnh cái này cái là xong làm gì mà mất thời gian ghê vậy
Vấn đề của sự trăm hoa đua nở framework dẫn đến 2 hoặc nhiều xu hướng. Quan điểm mình thấy có 2 xu hướng chính:
- Bỏ qua nhiều thứ, chỉ tập trung sâu vào một số thứ quan trọng (tuy gọi là ít nhưng cũng lên đến hàng tá) và cố gắng tận dụng hết mức. Vài “tên tuổi”: Wikipedia, PornHub, Khan Academy, Stack Exchange, Envato, Automatic, JetBrains, Twitter.
- Có gì hay ho cứ dùng nấy, framework lẫn các thư viện lên đến hàng trăm cái. Vài “thực thể” theo xu hướng này Mozilla, Google, Apache, Facebook.
Chú ý: ở trên không có đề cập mấy tổ chức/ công ty ưu tiên mã nguồn đóng hơn nguồn mở vì những thứ đó không được công bố hoặc nguồn đóng nhưng công bố stack behind.
Mình ko nắm nó thì nó nắm mình thôi.
Mấy ai chịu đọc sách về fw mình dùng. Toàn bộ fw được viết ra để giải quyết một bài toán chung nào đó, dựa trên một nguyên tắc cơ bản nào đó. Hiểu mấy cái cơ bản đó thì đi nhanh và it lỗi thôi. Đa phần dev search tutorial rồi làm theo thôi. Ít đào sâu.
Công ty đi theo hướng tech-driven thì có thế nghiên cứu làm mọi thứ từ đầu như google, fb.
Công ty đi theo hướng biz-driven/startup thì phải ra thị trường càng nhanh càng tốt (market early). Nên dùng fw để build nhanh làm bình thường. Right tool for right job trước rồi sau mới đến Best tool for right job 
Framework là “cái gì đó” rất quy mô, rất nhiều chất xám. Nguyên nhân nó ra đời là do lượng yêu cầu đông đảo và tồn tại được do đáp ứng đa phần yêu cầu ở mức tốt và có hiệu quả, lợi ích rõ rệt. Tất nhiên không hoàn hảo vì không thể sống cho vừa lòng toàn thiên hạ.
Nhưng không thể lập luận kiểu : Tôi dính bug, sản phẩm của tôi không tốt do tôi dùng fw nó hỗ trợ nhiều quá tôi không biết cmg. Đấy là kiểu “đái dầm đổ tại con ch*m”.
Thực tế thì dev cũng rất nhiều kiểu dev và có mục tiêu và cách làm việc khác nhau.
Có những ông dev luôn muốn phát triển, muốn code chất lượng nên luôn đọc doc, tip và học được rất nhiều từ framework và cộng đồng. Tất nhiên họ tránh được nhiều lỗi, bug, sản phẩm ngon.
Bên cạnh đó thì nhiều ông có tiêu chí “thà máy mệt chứ mình không mệt”, “chạy được là được”, “không nên phát minh lại bánh xe”, “đứng trên vai người khổng lồ”, Bản thân họ chỉ muốn nhàn đầu và giải quyết được vấn đề chứ không có nhu cầu tìm hiểu thì dĩ nhiên là nguy cơ cao hơn. Kiểu dev này thì có fw hay không nó vẫn dính bug thôi.
Còn không dùng fw, cũng được thôi vì không ai bắt cả. Rồi trải nghiệm thử vào project thực tế thấy “đái ra máo” là biết liền có nên hay không.
Giờ dùng C# không dùng NET. Dùng C++ không dùng mấy cái như QT, MFC, xWidgets, boost… mà toàn chơi std với OS API xem có khóc tiếng Miên không 
@Duong_Act Library là tập hợp code native và library khác. Framework là tập hợp nhiều library và code native. Vậy cho em hỏi có framework nào mà module của nó gồm nhiều framework khác nữa không? CMS bên trong nó là framework hay code chay toàn bộ? Lớn hơn CMS là gì ạ?
83% thành viên diễn đàn không hỏi bài tập, còn bạn thì sao?