Review so sánh Java Spring vs Kotlin Spring, Deno vs Node (Nest JS) vs Dart, C#

#1

Chào mọi người ạ,

Em phân vân giữa việc chọn công nghệ cho sản phẩm product cá nhân cỡ vừa cho nhiều nền tảng ứng dụng, có tích hợp quản lý và thanh toán, hiện em cân nhắc các nhóm sau cho phía server

  • JS runtime: Node và Deno thì các web app lớn mọi người đều dùng NestJS để code có cấu trúc hơn và sử dụng Typescript nhiều hơn, Deno thì hỗ trợ Typescript mặc định và bảo mật hơn, quản lý gói tối ưu, em nghĩ phù hợp hơn cho ứng dụng doanh nghiệp nhưng tuổi đời chưa nhiều

  • Dart: cú pháp hiện đại, khá giống phiên bản JavaLite và có thể build ứng dụng trên nhiều nền tảng ứng dụng lẫn server, tái sử dụng code rất tốt và nhất quán, tuy nhiên cộng đồng phía server chưa nhiều

  • JVM: Kotlin vs Java thì Java khá phụ thuộc vào IDE, cấu trúc project và cú pháp cồng kềnh nhưng lâu đời, hiệu suất và được nhiều doanh nghiệp ưa chuộng. Tuy nhiên, Kotlin mới hơn nhưng cú pháp hiện đại, kế thừa nhiều từ Java cũng như tương tích tốt, tương tự như Dart thì Kotlin code được cả Web/MobileApp/DesktopApp tuy ít tuổi hơn Dart

  • C#: Có thâm niên không thua kém nhiều Java, liên tục và phát triển, hiện nay cũng build được mọi nền tảng với .NET MAUI và Blazor

Em không ngại học 1 trong 4 nhóm này, nhưng vẫn thấy rất phân vân, mong được các bác tư vấn và so sánh giúp em Java vs Kotlin và Deno vs Node ạ. Em cảm ơn

#2

Bạn biết ngôn ngữ nào thì làm ngôn ngữ đó.

Project lớn hay không là tuỳ thuộc bạn làm được hay không thôi.
Java làm được project lớn vì cộng đồng có nhân lực quản lý project lớn.

2 Likes
#3

Em đang tiếp cận chưa đúng. Những cái mà em liệt kê ra nó không có ý nghĩa gì khi chưa xác định được bối cảnh của Product.

Em có thể cân nhắc trả lời các câu hỏi sau:

  1. Sản phẩm em làm là gì? dành cho đối tượng người sử dụng nào?. Nếu là đối tượng đặc thù ngành nghề thì các yêu cầu tối thiểu của ngành nghề đó là như thế nào?
  2. Kinh phí em có thể chi cho cơ sở hạ tầng hàng tháng là bao nhiêu? ( 10$, 50$, 100$ hay 1000$ !?)
  3. Sản phẩm của em cần sử dụng các công cụ gì? Có phải mua license hoặc trả phí duy trì không?
  4. Em dự kiến tốc độ thay đổi hoặc ra chức năng mới của Product là nhanh hay chậm? Tức thay đổi mỗi ngày, mỗi tuần, mỗi tháng hay nửa năm mới đổi một lần?
  5. Nếu giả sử sản phẩm thành công, và em muốn tuyển dụng lao động để làm, thì chi phí (lương) để trả cho lao động ở mảng công nghệ đó là bao nhiêu? có dễ tuyển dụng không?
  6. v.v…

Vậy sau khi em trả lời được các câu hỏi trên, em hãy đặt từng công cụ ( hay ngôn ngữ ) mà em liệt kê ban đầu vào, xem nó có thoả mãn không. Em sẽ tự có câu trả lời

5 Likes
#4

những gì bạn viết/phân tích ở trên về những ngôn ngữ, framework từ đâu mà ra? là cop nhặt ở đâu đó trên mạng hay do bạn tự trải nghiệm?
riêng mình đọc vào thấy những “kiến thức” đó khá sáo rỗng, không giúp ích gì cho việc lựa chọn cả
nói khó nghe thì là chỉ loè newbie để tỏ ra hiểu biết thôi

cái cốt lõi nhất của product/ứng dụng là business, là thiết kế chứ không phải là ngôn ngữ
chọn thì chọn cái quen tay thôi chứ đi tạo mấy topic này y như đẽo cày giữa đường
không có khả năng tiếp nhận, xác nhận được những gì người khác comment thì lợi bất cập hại

4 Likes
#5

Deno và Node không có gì để phân vân. Vì đây là 2 runtime, mà dev lại dùng framework. VD expressJS mặc định dùng NodeJS nhưng vẫn có thể config chạy trên Deno. Theo như docs của deno thì deno đang beta.

2 Likes
#6

@nghuuquyen @kisuluoibieng

Cảm ơn các bác, em chủ yếu hỏi về khía cạnh kỹ thuật, phần nghiệp vụ đã thống nhất được rồi, hiện tại em khá là đơn lẻ lên cần xây dựng 1 base vững chắc cùng công nghệ phù hợp tốt cho xu hướng sau này.

Em xin tóm gọn lại ý em muốn nói là:

  • Công nghệ mới, trải nghiệm code rất tốt cho lập trình viên và đa nền tảng thì cộng đồng chưa lớn và cần thời gian thêm để chứng minh, không tránh khỏi 1 số hạn chế hay hệ sinh thái bao gồm các thư viện, tiện ích thiếu hụt, nhưng sau này người khác thay thế thì cũng không tốn quá nhiều thời gian để kế thừa và code lại nhất quán giữa 1 ngôn ngữ chính giữa các phần khác nhau trong dự án

  • Công nghệ cũ, có thâm niên và được nhiều doanh nghiệp sử dụng tất nhiên không sai khi chọn được nhưng code lâu và sau này tìm người thay thế cũng thường cần nhiều người hơn

  • Về chi phí thì chủ yếu dồn ở các dịch vụ lưu trữ, hosting hay vps, … và cả sức lao động của em thì nó là stack riêng và em không đề cập tới ạ

Về công nghệ kể trên là do em tự phân loại và trải nghiệm cũng như tìm hiểu được, có gì sai các bác cứ góp ý, nó sẽ giúp em chính xác hơn trong việc lựa chọn

#7

Nên dùng công nghệ mà bạn cho là “cũ”

Bạn mới trải nghiệm ở vấn đề code, chứ chưa trải nghiệm vấn đề của project. VD như test, deployment, integration…
Công nghệ mới có thể số lượng library hỗ trợ không nhiều và bạn phải code rất nhiều đặc biệt là các third-party như Authorization, Payment, SMS, OMS.

Không nên dùng 1 công nghệ cho tất cả

Qua cách bạn liệt kê, có vẻ như bạn đang muốn dùng 1 ngôn ngữ cho all platform backend, web frontend và mobile
Điều này không sai nhưng mỗi ngôn ngữ chỉ phù hợp cho 1 hoặc 1 số nền tảng.

Nó có thể build dc ứng dụng ở các platform khác, nhưng liệu các library có đủ dùng, có thể tích hợp được các third-party và khả năng mở rộng tới đâu.

Chỉ là công cụ

Khi bạn đã nắm rõ về các design pattern, cách khai thác thư viện, thì vấn đề công nghệ hay ngôn ngữ chỉ là công cụ thôi. rất nhanh để làm quen với công nghệ khác.

Khi sản phẩm của bạn phát triển ổn định, và công nghệ mới cũng phát triển đủ mạnh thì lúc đó có thể migrate lên công nghệ mới.

Trên đây là góp ý của mình. Mình không trả lời kiểu ba phải, nhưng việc lựa chọn vẫn là ở bạn

4 Likes
#8

Giờ có người nói xe SH 300cc là xe “rác”, bạn nghĩ sao về câu nhận định này?
bạn nghĩ sao thì cũng được, không quan trọng
mình đưa ra câu đó là để cho bạn biết là có rất nhiều thứ nó không có đúng sai, tuỳ vào ngữ cảnh cụ thể

trở lại với câu chuyện kĩ thuật, mình sẽ đưa ra một số vấn đề để bạn thử suy nghĩ rồi tự đánh giá

  1. như mình có comment ở trên, làm product thì business thay đổi từng ngày, sản phẩm phải phát triển, khi đó, không có cái framework hay ngôn ngữ nào sẽ đi theo cái product đó mãi mãi đâu
    nếu bạn đã đi làm, chắc sẽ có lúc nghĩ: thành quả làm việc cả năm, giờ mà viết lại chắc chỉ 1 tháng là xong
    chuyện đổi ngôn ngữ hay framework hay rebuild lại, một phần hoặc toàn bộ cũng không phải hiếm
    vậy confuse làm chi mấy cái đó, làm product thì business và dealline mới là cái cần đưa lên hàng đầu
    nên chọn cái nào mà vừa quen tay để dev nhanh nhất có thể thôi
  2. chắc chắn tại thời điểm này thì có lẽ không ai bắt đầu product bằng java 1 hay net 2.0 hay node 4 nữa, vẫn là chọn current LTS mà thôi. Và hiện tại, việc dev cũng đã dễ dàng hơn trước rất nhiều rồi, nên vấn đề quyết định thành bại vẫn là business và thời gian ra mắt được sản phẩm mà thôi
  3. đừng nói là business hay framework thay đổi, cả bản thân cũng sẽ thay đổi từng ngày, thậm chí là nhìn code của bản thân mình viết hồi tháng trước cũng thấy ngứa mắt muốn sửa/viết lại, thậm chí là refactor lại cấu trúc nữa
    code xấu là chuyện bình thường, chỉ cần business thu hút user, và chạy ổn định là đủ, còn lại cũng chỉ là thứ yếu
  4. code mấy cái service cũng chỉ là một phần tech mà thôi, tech còn bao gồm kiến trúc, hạ tầng, cấu hình network, security các thứ
    chưa kể code xong rồi phải enhance performance bằng cách này hay cách khác nữa, enhance chỗ nào thì còn phải bắt bệnh mới bốc thuốc được, mà bốc thuốc thì cũng có nhiều loại thuốc cùng chữa được bệnh thì coi thuốc nào phù hợp nữa
  5. tỉ lệ product mà chạy được tới khi có doanh thu rất thấp, rất nhiêu product tạch từ trong trứng, nên cũng chưa chắc bạn đã đi dài hơi với nó, đó là khách quan
    còn chủ quan thì có khi bạn chán code xấu, chán team, chán áp lực deadline gì đó nữa

con đường của bạn còn dài lắm, bớt lo xa lại và xuất phát thôi
“thuyền đến đầu cầu tự nhiên thẳng”

4 Likes
#9

Gen Z bị hội chứng FOMO nên các bạn ở đây thông cảm. Họ cứ đứng ngoài đợi ai đó rì viu giúp, kể cả đi ăn uống. Kết quả người ta ăn xong, ị và xả bồn cầu rồi vẫn thấy đám đó đang còn hóng rì viu. Cách đó hoàn toàn khác với cách của 7X bọn mình. Cuối tuần vừa rồi, 5 gã trai tuổi gần 50, nắm tay nhau đi dung dăng dung dẻ dạo chơi thôn dã. Khi đi ngang qua rẫy kia thấy người ta trồng “cỏ” nuôi gà, mấy thằng 7X tụi mình vào đó bứt lá khô, sau đó 15 phút ra đường liên xã, ghé quán bia tự làm “thuốc lá” rồi phê với nhau. 2 thằng còn đang ở đồn công an :smiley: Trong khi đó sáng nay thì một thằng nói rằng lần đầu tiên nó viết một phần mềm nho nhỏ với Rust, nó thấy có vẻ Rust dễ hơn năm 1996 nó học C rất nhiều.

2 Likes
#10

Câu trả lời đơn giản.

Bạn và team của bạn rành tech nào nhất thì dùng tech đó mà phát triển. Một khi team bạn mạnh về ngôn ngữ nào đó, như Golang chẳng hạn, viết demo cũng được, viết kiểu startup ra product nhanh cũng được, hoặc phát triển hệ thống với đầy đủ kiến trúc và thiết kế cũng được.

Câu hỏi của bạn thiên về nguồn nhân lực hơn là kĩ thuật.

3 Likes
#11

Cảm ơn bác. Dù không ai review em vẫn sẽ làm ạ, nhưng mà em nghĩ rằng một số tiền bối cho rằng chọn công nghệ là một khâu không quan trọng lắm thì em không đồng ý. Cụ thể là đây là ngôn ngữ và framework cho ứng dụng và server, các câu hỏi này cộng đồng trên stackoverflow hay reddit và quora hỏi rất nhiều. Dành ra 1 vài tiếng để tìm hiểu công nghệ có thể tiết kiệm nhiều thời gian tính theo tuần / tháng ở sau này nên tìm tòi, lựa chọn công nghệ là đáng giá.

Em đồng ý là công nghệ như ngôn ngữ nào hiếm khi là nút thắt cổ chai, nhưng em mang lên bàn cân để lựa chọn, làm phép so sánh thì đã coi những yếu tố khác như độ thành thạo hay quen thuộc của team là như nhau rồi, và có nhiều lựa chọn thì chắc chắn có sự cho sánh, không cho cá nhân em thì cũng cho những độc giả khác.

@hungaya Bác Hùng thì em cũng cảm ơn và xin phản hồi rằng cái gì cũng cần kỹ thuật và ở đây là kỹ thuật cá nhân để triển khai những dòng code và tiếp tới là kỹ thuật quản lý dự án với yêu cầu nghiệp vụ đã được phân tích trước.

Còn câu chuyện của các thế hệ thì em không dám đại diện cho 1 thế hệ, về tâm lý của việc lựa chọn thì có lẽ những cuốn như “Phi Lý Trí” hay “Nghịch Lý Của Sự Lựa Chọn”, … sẽ phân tích chuyên sâu đúng chuyên môn và sẽ giúp em nhiều

1 Like
#12

Nói chung là em cứ giữ quan điểm của mình rồi triển khai làm đi. Triển khai nhanh, đo đạt hiệu suất rồi hiệu chỉnh nếu cần ( Agile / Scrum )

Những cái các đàn anh nói em phải có đủ “trải nghiệm” mới hiểu được. Vì có những anh đã làm nghề hơn 10 năm rồi, thăng trầm có đủ.

Anh mong trong thời gian tới, 6 tháng hoặc 1 năm em có thể viết bài mới Review lại chính công nghệ em chọn và quá trình làm dự án của em trên diễn đàn này.

Chúc em thành công!!

4 Likes
#13

Bạn quan niệm công nghệ là gì mình không rõ nên rất khó để nói gì thêm. Mình chỉ chia sẻ về những gì mình thấy như một góc nhìn, không có đúng, có sai gì. Mình quan sát thấy ở cuộc đời, chủ yếu là cứ đi rồi sẽ có đường, còn nếu đứng đó và thầm nghĩ “chọn lựa quan trọng hơn nỗ lực” (slogan thần thánh của dân bán hàng MLM) thì có khi lạc nhịp.

Bỏ thời gian để xem công nghệ nào quan trọng để theo đuổi không phải là việc làm “chuẩn chỉnh” của dân mới ti toe vào nghề. Chọn cái nào cũng như nhau, ăn thua bắt tay vào làm. Một ví dụ cụ thể luôn: lúc mình mới đi làm về CNTT, ngồi chung team với .NET, vài gã Java nhưng ngoài giờ thì mình vọc Perl. Mấy anh em nghe trố mắt lên chẳng biết gã này học cái của quái gì ngu ngốc vậy, “công nghệ” cổ lổ sỉ (???). Một ngày kia dự án đấu thầu cần có người biết Perl. Lúc đó, sếp hỏi các team xem có ai biết Perl không? Haha, lúc đó các team toàn chỉ vào mình. Kết quả: công ty mình thắng thầu dự án đó bởi các cty đối thủ trong thời gian ngắn không tuyển đâu ra người biết Perl.

Công nghệ theo mình hiểu, giống như mắt kính ở câu chuyện sau:

2023-08-21-15-12
2023-08-21-15-12651×510 46.4 KB

“Công nghệ” Emacs, Vim rất xịn nhưng mỗi ngày mình vẫn gõ nano trên Linux vì nói thật là không biết cách thoát khỏi Vim :smiley: . Có đồng nghiệp sử dụng Vim rất thần thánh, mình cũng chỉ biết bái phục chứ vẫn chưa thể học theo được.

Bạn sẽ thấy rằng sớm “bập vào” cái công nghệ nào đó mà chưa vững về ngôn ngữ, cách tư duy giải quyết vấn đề thì rất dễ có ngày dính vào cái mớ lùng nhùng, cấu hình được cho môi trường chạy thôi là đã vượt quá khả năng. Rồi bạn loay hoay suốt cả tuần, tắc tịt nằm ở đó, phải thuê chuyên gia về gỡ rối giúp (mình từng gỡ ca khá hài hước: trong thư mục Cha không thể đặt được thư mục Con trên Windows, team cãi nhau ỏm tỏi). Chứng kiến 1 chuyên gia khác, cô ấy đã “gõ búa” một phát lấy vài trăm Mỹ kim, hóa ra nhóm lập trình viên chưa bao giờ vọc umask vì không chịu học về hệ điều hành *nix.

3 Likes
#14

bữa comment xong, nghĩ là mình đã viết đủ nên bữa giờ không có vô lại topic
nay vô đọc, thì có vẻ như vẫn còn cái để comment tiếp

thực tế, bạn có đọc trăm review, thì cũng không thể nào bằng được bạn tự trải nghiệm, nên khỏi phải chờ review

ở đây hình như mọi người không nói như thế, có vẻ bạn tự hiểu như thế
việc lựa chọn mà bạn đưa ra là “không quan trọng” -> đúng là nhiều người có ý đó
nhưng ở đây, bạn đang đưa ra cái gọi là “công nghệ”, mà cái đó theo như ý của bạn, thì nó chỉ là ngôn ngữ/framework
-> nên “không quan trọng” ở đây là mọi người đang nói với cái title của bạn

Danh sách mà bạn list ra, đều có ưu điểm và nhược điểm
Để lựa chọn, thì bạn phải list ra được, bạn cần “cái gì”,
ví dụ như ngôn ngữ 1, có ưu điểm cho feature A, nhưng nhược điểm khi phải xử lý feature B,
ngược lại với ngôn ngữ 2 thì xử lý B rất tốt, nhưng làm feature A hơi tốn thời gian, ít support gì đó
và cái product của bạn, cần A hay cần B hay cần cả 2, cần “nhanh” hay cần “tin cậy”…

ở đây, có là chữ “công nghệ” nó không có ý nghĩa gì cả,
cá nhân mình cũng không có khái niệm công nghệ c#, hay công nghệ .net hay công nghệ sql server
nghe nó cứ chói chói sao sao ấy

gọi nó là solution thì chắc nghe hợp hơn, “giải pháp” cho nhu cầu của bạn/product của bạn
mà thôi, bạn thích thì bạn gọi đó là cái bàn cũng được, bỏ qua những cái khái niệm đó
còn câu mình viết thì mình tự tạm lấy chữ solution vậy

có những vấn đề khác, đáng thắc mắc, phân tích hơn

  • database: sql hay nosql? sql nào? nosql nào? serial hay random string cho field id…
  • hạ tầng: cloud service hay vps hay server vật lý
  • proxy, web server: nginx hay apache?
  • application management: systemd, pm2, docker, bash/shell
  • giao tiếp nội bộ: http hay grpc hay tcp?
  • load balancing: cloud service hay rabbit hay kafka
  • event: rabbit hay redis hay kafka?
  • log: elk?
  • redis: sentinel hay cluster?
  • job schedule: build service tự schedule hay dùng cron + service (chỉ làm job)
  • work-flow/git-flow như nào, team chia nhiệm vụ như nào, quản lý dự án ra sao
    -feature, ngoài những feature public đến user, thì chắc chắn sẽ phát sinh feature nội bộ, hoặc tool, phân tích, report, chống gian lận, spam các thứ

nếu có ngôn ngữ, chắc sẽ xếp chót hoặc áp chót
ngôn ngữ chọn sai, thì có thể chọn lại, tách service/feature rồi migrate từ từ, apply A/B testing hoặc replace trực tiếp là được
những cái khác chọn sai, thì bạn tự đánh giá

học hỏi là tốt, nhưng cũng không cần vội vàng, từ từ mà trải nghiệm

-> chốt lại như câu quote đầu tiên, bạn cứ tự trải nghiệm từ từ là được, bạn sẽ tự trưởng thành cùng với project của bạn

5 Likes
83% thành viên diễn đàn không hỏi bài tập, còn bạn thì sao?