jQuery là gì, và tại sao người ta nói nó bị lãng quên?

jQuery in One Minute

jQuery là một thư viện JavaScript nhỏ giúp những tác vụ phổ biến trên trang web dễ dàng hơn — những việc như chọn phần tử, phản ứng với click, thay đổi văn bản, hiện/ẩn phần trang và gửi yêu cầu tới server.

Nếu bạn từng thấy mã như $("button").click(...), đó là jQuery. Ký hiệu $ chỉ là một phím tắt để “tìm thứ gì đó trên trang và làm gì đó với nó.”

What this article will cover

Bài hướng dẫn này mang tính thực tế và dễ hiểu: jQuery là gì, tại sao nó trở nên phổ biến, tại sao các dự án mới ít dùng nó hơn, và cách xử lý khi trang của bạn vẫn còn dùng jQuery. Nó có chủ ý dài hơn để đưa ra ví dụ rõ ràng và hướng dẫn thực tiễn thay vì ý kiến nhanh.

What people mean by “forgotten"

Khi người ta nói jQuery bị “lãng quên,” họ thường không có nghĩa là nó biến mất. Họ muốn nói:

• Nó ít được dùng hơn trong các dự án mới, vì trình duyệt hiện đại đã hỗ trợ nhiều tính năng mà jQuery từng cung cấp.
• Nó vẫn phổ biến trong các trang cũ (và một số plugin, theme, bảng quản trị) vì nó hoạt động, quen thuộc và việc thay thế tốn thời gian.

Vì vậy câu chuyện không phải “jQuery chết.” Nó giống như: jQuery chuyển từ công cụ mặc định cho công việc front-end thành một phụ thuộc kế thừa mà bạn có thể thừa hưởng — và thỉnh thoảng vẫn chọn dùng có chủ ý.

Why jQuery Was a Big Deal

Trước jQuery, công việc front-end thường là lặp lại những đoạn mã nhỏ khó chịu — rồi kiểm thử chúng trên nhiều trình duyệt và phát hiện hành vi khác nhau. Ngay cả mục tiêu đơn giản như “tìm phần tử này,” “gán handler click,” hoặc “gửi yêu cầu” cũng có thể biến thành một mớ các trường hợp đặc biệt.

What front-end development felt like before jQuery

Rất nhiều JavaScript thời kỳ đầu ít nói đến xây tính năng mà nhiều hơn là vật lộn với môi trường. Bạn viết mã chạy trong một trình duyệt, rồi thêm các nhánh để chạy trong trình duyệt khác. Các nhóm giữ lại “thư viện nhỏ” nội bộ các hàm trợ giúp chỉ để tồn tại với các thay đổi UI hàng ngày.

Kết quả: phát triển chậm hơn, nhiều bug hơn và luôn lo sợ một thay đổi nhỏ sẽ phá hỏng trình duyệt cũ mà người dùng vẫn còn dùng.

Browser differences and why they mattered

Các trình duyệt không đồng ý về nhiều chi tiết quan trọng. Phương thức chọn DOM, xử lý sự kiện, thậm chí cách lấy kích thước phần tử có thể khác nhau. Internet Explorer, đặc biệt, có API khác cho sự kiện và XMLHTTP request, nên mã “chuẩn” không phải lúc nào cũng portable.

Điều đó quan trọng vì trang web không được xây cho một trình duyệt duy nhất. Nếu form thanh toán, menu điều hướng, hoặc modal của bạn lỗi trên một trình duyệt phổ biến, đó là vấn đề kinh doanh thật sự.

The gap jQuery filled for everyday tasks

jQuery trở nên quan trọng vì nó cung cấp một API nhất quán, thân thiện, san phẳng những khác biệt đó.

Nó làm các tác vụ thông thường đơn giản rất nhiều:

• Chọn và thao tác phần tử DOM với bộ chọn kiểu CSS
• Xử lý sự kiện theo cách tương thích đa trình duyệt
• Hiệu ứng/animation mà không phải tự viết timer
• Yêu cầu Ajax với một giao diện nhất quán

Quan trọng không kém, phong cách “viết ít, làm nhiều” của jQuery giúp các nhóm ra hàng nhanh hơn với ít bất ngờ do trình duyệt — nhất là trong thời kỳ khi “API DOM hiện đại” chưa mạnh và phổ biến như bây giờ.

Core Things jQuery Helps You Do

Sức mạnh thực sự của jQuery không phải vì nó giới thiệu ý tưởng mới mà là nó làm cho các tác vụ trình duyệt thông thường trở nên nhất quán và dễ dàng trên nhiều trình duyệt. Nếu bạn đọc mã front-end cũ, bạn thường thấy jQuery được dùng cho bốn nhiệm vụ hàng ngày.

1) DOM selection and traversal (the $ function idea)

Hàm $() cho phép bạn “lấy” phần tử bằng bộ chọn kiểu CSS và sau đó thao tác với chúng như một nhóm.

Thay vì loay hoay với quirks trình duyệt và API dài dòng, bạn có thể chọn tất cả các item, tìm phần tử con, hoặc leo lên phần tử cha bằng các gọi chuỗi ngắn gọn.

2) Events: click/submit/ready patterns

jQuery làm cho việc phản hồi hành động người dùng đơn giản hơn:

• click cho nút và link
• submit cho form
• ready để chạy mã khi trang đã tải xong

Nó cũng san phẳng sự khác biệt về đối tượng event và cách binding, điều rất quan trọng khi hỗ trợ trình duyệt không đồng nhất.

3) AJAX basics (loading data without a refresh)

Trước khi fetch() trở thành chuẩn, $.ajax(), $.get() và $.post() của jQuery là cách thẳng thắn để yêu cầu dữ liệu từ server và cập nhật trang mà không reload.

Điều này mở ra các mẫu giờ đã trở nên bình thường — tìm kiếm trực tiếp, nút “tải thêm”, cập nhật một phần trang — bằng một API quen thuộc.

4) Effects/animations and simple UI helpers

jQuery phổ biến các hiệu ứng UI nhanh như hide(), show(), fadeIn(), slideToggle() và animate(). Chúng tiện cho menu, thông báo và chuyển tiếp cơ bản — đặc biệt khi hỗ trợ CSS kém ổn định.

Gộp lại, những tiện ích này giải thích vì sao mã JavaScript cũ thường bắt đầu bằng $( và vì sao jQuery từng là công cụ mặc định lâu dài.

A Simple Example: jQuery vs Modern JavaScript

Danh tiếng của jQuery phần lớn đến từ việc cần rất ít mã để làm các tác vụ UI phổ biến — nhất là khi khác biệt trình duyệt còn đau đầu. So sánh nhanh cho thấy điều đó.

Selecting an element and handling a click

jQuery

// Select a button and run code when it's clicked
$('#save').on('click', function (e) {
  e.preventDefault();
  $('.status').text('Saved!');
});

Modern (vanilla) JavaScript

// Select a button and run code when it's clicked
const saveButton = document.querySelector('#save');
const status = document.querySelector('.status');

saveButton?.addEventListener('click', (e) => {
  e.preventDefault();
  if (status) status.textContent = 'Saved!';
});

Readability: fewer lines vs clearer APIs

Lúc đầu, phiên bản jQuery có cảm giác “gọn hơn”: một chuỗi chọn phần tử, gán handler, và cập nhật văn bản. Sự ngắn gọn đó là điểm bán hàng chính.

JavaScript hiện đại hơi dài hơn, nhưng rõ ràng hơn:

• querySelector và addEventListener nói rõ điều đang xảy ra.
• textContent là thuộc tính DOM chuẩn (không qua thư viện).
• Optional chaining (?.) và kiểm tra null làm rõ điều gì xảy ra nếu phần tử không tồn tại.

Which is “better”?

Tùy ngữ cảnh. Nếu bạn duy trì codebase cũ đã dùng jQuery khắp nơi, đoạn jQuery có thể nhất quán và dễ thao tác hơn. Nếu viết mã mới, API DOM hiện đại được hỗ trợ rộng rãi, giảm phụ thuộc và dễ tích hợp với tooling/framework ngày nay.

Native JavaScript Caught Up

Trong một thời gian dài, lợi thế lớn nhất của jQuery là tính dự đoán. Bạn có thể viết một cách để chọn phần tử, gắn sự kiện, hoặc chạy Ajax — và nó chạy ở hầu hết nơi.

Qua năm tháng, trình duyệt tiêu chuẩn hóa và cải thiện. Nhiều tiện lợi mà jQuery gói gọn giờ đã có sẵn trong JavaScript, nên bạn thường không cần thư viện ngoài chỉ để làm những thao tác cơ bản.

DOM APIs became simpler and more consistent

Các phương thức DOM hiện đại bao phủ hầu hết mẫu jQuery phổ biến:

• document.querySelector() / document.querySelectorAll() thay cho $(...) trong nhiều trường hợp
• element.classList.add() / .remove() / .toggle() cho thao tác class
• element.addEventListener() thay cho wrapper sự kiện của jQuery trong hầu hết trường hợp

Thay vì nhớ các helper đặc thù jQuery, bạn có thể dựa vào API chuẩn hoạt động trên trình duyệt hiện đại.

Network requests moved to fetch

Nơi $.ajax() từng là lựa chọn, fetch() nay xử lý nhiều yêu cầu hàng ngày với ít nghi thức hơn, nhất là khi kết hợp với JSON:

const res = await fetch('/api/items');
const data = await res.json();

Bạn vẫn cần xử lý lỗi và timeout rõ ràng, nhưng ý tưởng lõi — gửi yêu cầu mà không cần plugin — giờ là native.

Better structure with Promises, async/await, and modules

jQuery giới thiệu nhiều người với lập trình bất đồng bộ qua callback và $.Deferred. Ngày nay, Promise và async/await làm luồng async dễ đọc hơn, và ES modules làm rõ cách tổ chức mã.

Sự kết hợp đó — API DOM hiện đại + fetch + ngôn ngữ hiện đại — đã loại bỏ nhiều lý do ban đầu khiến các nhóm mặc định chọn jQuery.

Frameworks Changed How UIs Are Built

jQuery lớn lên trong thời kỳ “website nhiều trang”: server render HTML, trình duyệt tải trang, và bạn rắc hành vi — handler click, animation, AJAX — lên markup hiện có.

Framework front-end hiện đại đảo ngược mô hình đó. Thay vì chỉ “enhance” trang, ứng dụng thường sinh phần lớn UI trong trình duyệt và giữ nó đồng bộ với dữ liệu.

Single-page apps and component-based UI

React, Vue, và Angular phổ biến ý tưởng xây UI từ các component — các phần nhỏ, tái dùng, sở hữu markup, hành vi và state riêng.

Trong mô hình này, framework muốn là nguồn chân lý cho thứ đang hiển thị. Nó theo dõi state, render lại UI khi state thay đổi, và mong bạn diễn tả thay đổi theo hướng tuyên bố (“khi X đúng thì hiển thị Y”).

jQuery thì khuyến khích thao tác DOM mang tính mệnh lệnh (“tìm phần tử này, thay văn bản, ẩn nó”). Điều đó có thể xung đột với chu kỳ render của framework. Nếu bạn thay đổi DOM thủ công mà component kiểm soát, lần render tiếp theo có thể ghi đè thay đổi của bạn — hoặc bạn có thể mất thời gian debug sự không nhất quán.

Build tools and bundlers changed how code is shipped

Khi SPA phổ biến, các nhóm dùng build tool và bundler (Webpack, Rollup, Vite). Thay vì thả vài thẻ script vào trang, bạn import module, bundle chỉ thứ cần và tối ưu hiệu suất.

Sự chuyển đổi này cũng khiến người ta nhạy cảm hơn với phụ thuộc và kích thước bundle. Kéo vào jQuery “phòng khi cần” ít hợp lý hơn khi mỗi kilobyte và cập nhật bên thứ ba đều nằm trong pipeline.

Why jQuery can feel awkward in component apps

Bạn có thể dùng jQuery trong framework, nhưng nó thường trở thành một “hòn đảo” đặc biệt — khó test, khó lý giải và dễ vỡ khi refactor. Vì vậy nhiều nhóm chọn cách dùng các mẫu native framework thay vì script kiểu jQuery.

Bundle Size and Maintenance Pressure

jQuery bản thân không “to” lắm, nhưng nó thường đến cùng với gánh nặng. Nhiều dự án dùng jQuery dần tích tụ plugin (slider, date picker, modal, validation), mỗi cái thêm mã bên thứ ba phải tải và parse. Theo thời gian, một trang có thể gửi nhiều tiện ích chồng chéo — nhất là khi tính năng được thêm nhanh và ít khi được rà soát lại.

Bigger downloads, more work for the browser

Nhiều JavaScript hơn nghĩa là trình duyệt phải tải về, parse và thực thi nhiều hơn trước khi trang cảm thấy phản hồi. Ảnh hưởng này dễ thấy hơn trên di động, mạng chậm và phần cứng cũ. Dù người dùng cuối cùng có trải nghiệm mượt, “thời gian để sử dụng” có thể bị ảnh hưởng khi trang chờ các script thừa.

The hidden cost: mixed styles and mental overhead

Một pattern phổ biến trên các trang chạy lâu là codebase “hỗn hợp”: vài tính năng viết bằng jQuery, phần mới bằng framework (React, Vue, Angular), và vài đoạn JS thuần rải rác. Sự pha trộn này gây rối:

• Hai cách chọn phần tử và cập nhật DOM\n- Mô hình sự kiện và lifecycle khác nhau\n- Các giải pháp quản lý state cạnh tranh (DOM làm state vs state component)

Khi nhiều phong cách cùng tồn tại, thay đổi nhỏ trở nên rủi ro hơn. Developer cập nhật component, nhưng một script jQuery cũ vẫn can thiệp vào cùng markup và gây bug khó tái hiện.

Maintenance pressure adds up

Các nhóm dần rời xa jQuery không phải vì nó “ngừng hoạt động”, mà vì dự án hiện đại tối ưu cho bundle nhỏ hơn và rõ ràng việc sở hữu hành vi UI. Khi site lớn lên, giảm mã bên thứ ba và chuẩn hóa cách làm thường giúp tối ưu hiệu suất, debug và onboarding dễ hơn.

Why You Still See jQuery in Older Sites

jQuery không chỉ phổ biến — nó trở thành mặc định. Nhiều năm liền, đó là cách dễ nhất để làm trang tương tác hoạt động trên nhiều trình duyệt, nên nó chìm sâu trong template, snippet, tutorial và mã copy‑paste.

Khi đã như vậy, jQuery khó tránh: ngay cả khi site chỉ dùng một tính năng nhỏ, nó thường load cả thư viện vì mọi thứ giả định jQuery có mặt.

It’s baked into older plugins and themes

Lý do lớn khiến jQuery còn xuất hiện là vì thành công của nó khiến nó “có mặt ở khắp nơi” trong mã bên thứ ba. Các widget UI cũ, slider, lightbox, validator và script theme thường viết dưới dạng plugin jQuery. Nếu site phụ thuộc vào một trong các thành phần đó, loại bỏ jQuery có thể cần viết lại hoặc thay thế dependency chứ không chỉ sửa vài dòng.

WordPress inherited it (and kept it)

WordPress là nguồn lớn của “jQuery kế thừa.” Nhiều theme và plugin — đặc biệt những cái tạo ra từ nhiều năm trước — dùng jQuery cho hành vi front-end, và lịch sử các màn hình admin của WordPress cũng hay dựa vào nó. Dù phiên bản mới dần chuyển sang JavaScript hiện đại, đuôi dài các extension cũ giữ jQuery xuất hiện trên nhiều cài đặt.

Legacy systems value stability over change

Các site cũ thường ưu tiên “đừng phá những gì đang hoạt động.” Giữ jQuery có thể là an toàn nhất khi:\n

• site ổn định và quan trọng với doanh thu\n- thời gian hạn chế và kiểm thử hồi quy tốn kém\n- codebase có hàng năm sửa lỗi nhỏ mà không ai muốn rà soát lại

Tóm lại, jQuery không phải luôn bị “lãng quên” — nó thường là một phần nền tảng của site, và nền tảng hiếm khi bị thay thế nhẹ nhàng.

When jQuery Still Makes Sense

jQuery không phải phần mềm tồi — chỉ là ít cần thiết hơn trước. Vẫn có tình huống thực tế mà giữ hoặc thêm một chút jQuery là lựa chọn thực dụng, nhất là khi bạn tối ưu cho thời gian, tương thích hoặc ổn định hơn là tính tinh gọn kiến trúc.

You must support legacy browsers

Nếu bạn có yêu cầu bao gồm trình duyệt cũ (đặc biệt IE cũ), jQuery vẫn đơn giản hóa việc chọn DOM, xử lý sự kiện và AJAX theo cách mà API native có thể không khớp nếu không dùng thêm polyfill.

Câu hỏi then chốt là chi phí: hỗ trợ trình duyệt cũ thường tức là bạn phải gửi thêm mã. Trong bối cảnh đó, jQuery có thể nằm trong gói tương thích chấp nhận được.

You need quick fixes in an existing jQuery codebase

Nếu site đã xây quanh jQuery, sửa UI nhỏ thường nhanh và an toàn khi làm theo cùng phong cách. Trộn cách có thể gây rối (hai pattern cho sự kiện, hai cách thao tác DOM), làm bảo trì khó hơn.

Một quy tắc hợp lý: nếu bạn chỉ chạm vào một hai màn hình và app ổn định, vá bằng jQuery là ổn — chỉ tránh mở rộng jQuery vào hệ thống mới mà sau này phải gỡ.

Small sites without a build step

Với một trang marketing đơn giản hoặc công cụ nội bộ — không bundler, không transpiler, không framework component — jQuery vẫn là tiện lợi với một thẻ script duy nhất. Nó hữu ích khi bạn chỉ cần vài tương tác (toggle menu, hành vi form đơn giản) và không muốn thêm pipeline build.

You’re using an older plugin that depends on it

Nhiều plugin trưởng thành (date picker, table, lightbox) xây trên jQuery. Nếu plugin cũ là quan trọng và ổn định, giữ jQuery có thể là lựa chọn ít rủi ro nhất.\n\nTrước khi quyết, kiểm tra xem có alternative không còn duy trì hoặc việc nâng cấp plugin có buộc phải viết lại rộng hơn dự án có thể chi trả không.

How to Move Away from jQuery Safely

Di chuyển khỏi jQuery ít là về một lần rewrite lớn mà nhiều hơn là giảm phụ thuộc mà không phá vỡ hành vi. Cách an toàn nhất là từng bước: giữ trang hoạt động trong khi thay dần các phần bên dưới.

1) Audit what you actually use

Bắt đầu bằng trả lời ba câu thiết thực:\n

• Trang nào load jQuery?\n- Plugin nào phụ thuộc vào nó (slider, date picker, validator, v.v.)?\n- Những tính năng jQuery nào xuất hiện trong codebase (chọn DOM, sự kiện, AJAX, animation)?\n\nBản kiểm toán này giúp bạn tránh thay những thứ không cần và phát hiện dependency ẩn như plugin lặng lẽ dùng $.ajax().

2) Replace low-hanging fruit first

Phần lớn nhóm đạt thắng lợi nhanh bằng cách thay các pattern đơn giản phổ biến:\n

• Selector: $(".card") → document.querySelectorAll(".card")\n- Class: .addClass() / .removeClass() → classList.add() / classList.remove()\n- Events: .on("click", ...) → addEventListener("click", ...)\n Làm từng PR nhỏ để dễ review và rollback.

3) Plan your AJAX transition

Nếu bạn dùng $.ajax(), migrate những gọi đó sang fetch() (hoặc helper HTTP nhỏ) từng endpoint một. Giữ cấu trúc response giống trước để UI không cần thay ngay.

// jQuery
$.ajax({ url: "/api/items", method: "GET" }).done(renderItems);

// Modern JS
fetch("/api/items")
  .then(r => r.json())
  .then(renderItems);

4) Reduce risk with tests and staged rollouts

Trước khi gỡ jQuery, bổ sung coverage chỗ quan trọng: luồng người dùng chính, submit form và UI động. Ngay cả kiểm tra nhẹ (smoke tests bằng Cypress hoặc checklist QA) cũng phát hiện lỗi sớm. Triển khai thay đổi sau feature flag khi có thể và theo dõi analytics/lỗi.

Nếu muốn an toàn hơn khi refactor, dùng tooling hỗ trợ snapshot và rollback. Nhiều nhóm hiện đại hóa front end legacy thường prototype thay thế trên Koder.ai (một nền tảng tạo web app qua chat) và dùng workflow snapshot/rollback để lặp lại mà không mất bản “known-good”.

Nếu cần giúp tổ chức kế hoạch tổng thể, xem bài blog jquery-vs-vanilla-js để lấy baseline so sánh dùng trong refactor.

Common Migration Pitfalls

Di chuyển khỏi jQuery thường ít liên quan đến “thay cú pháp” mà nhiều đến tháo gỡ giả định nhiều năm. Đây là những bẫy làm chậm đội — và cách tránh.

Trying to rewrite everything at once

Việc viết lại toàn bộ nghe có vẻ sạch sẽ, nhưng thường tạo nhánh kéo dài, nhiều regressions và áp lực ra hàng mã chưa hoàn chỉnh. Cách an toàn hơn là từng phần: thay một tính năng hoặc một trang, giữ hành vi giống hệt và thêm test quanh phần bạn chạm tới.

Mixing jQuery with a component framework in the same UI area

Nếu bạn thêm React/Vue/Svelte (hoặc hệ thống component nhẹ) trong khi jQuery vẫn thao tác trực tiếp cùng DOM nodes, bạn có thể gặp “kéo co UI”: framework render lại ghi đè thay đổi jQuery, trong khi jQuery cập nhật phần tử mà framework nghĩ mình sở hữu.

Quy tắc: chọn ranh giới rõ ràng. hoặc:\n

• Giữ jQuery trong một container legacy và mount framework ở nơi khác, hoặc\n- Migrate toàn bộ widget đó như một đơn vị trước khi thêm hành vi mới.

Event delegation differences

Nhiều mã cũ dựa vào delegated events như:

$(document).on('click', '.btn', handler)

DOM thuần có thể làm điều này, nhưng việc ghép khớp và kỳ vọng this/event.target có thể khác. Lỗi thường gặp là handler chạy cho phần tử sai (do icon/span lồng nhau) hoặc không chạy cho phần tử thêm động vì listener gắn lên ancestor sai. Khi thay delegated events, xác nhận:\n

• Phần tử nào được coi là “nút được click” (closest() thường cần)\n- Liệu sự kiện có từng được namespaced (jQuery hỗ trợ; native cần chiến lược khác)

Accessibility regressions when replacing effects

Hiệu ứng UI và animation tự viết đôi khi vô tình che lấp vấn đề truy cập — hoặc sinh ra chúng. Khi thay fade/slide/toggle, kiểm tra lại:\n

• Quản lý focus\n- Trạng thái ARIA (aria-expanded)\n- prefers-reduced-motion

Phát hiện sớm những vấn đề này giúp migration nhanh hơn và UI ổn định hơn — ngay cả trước khi xóa hết $().

Key Takeaways and Next Steps

jQuery không “xấu.” Nó giải quyết vấn đề thực tế — nhất là khi trình duyệt khác nhau và xây trang tương tác có nghĩa là viết nhiều mã DOM lặp. Điều thay đổi là bạn thường không cần nó nữa cho dự án mới.

Why jQuery Declined

Một vài lực lượng đẩy nó từ “lựa chọn mặc định” thành “phụ thuộc legacy”:\n

• API DOM hiện đại cải thiện: chọn phần tử, thay class và xử lý sự kiện đều đơn giản bằng JavaScript chuẩn.\n- Trình duyệt đồng nhất hơn: ít quirks hơn nghĩa là lớp tương thích ít giá trị hơn.\n- Frameworks thay đổi cách nghĩ: React/Vue/Angular khuyến khích UI component và render theo state, nơi thao tác DOM trực tiếp ít được dùng.\n- Áp lực hiệu suất và bảo trì: các nhóm quan tâm đến kích thước bundle, cập nhật phụ thuộc và giảm “mã bí ẩn” trong ứng dụng lớn.

Practical next steps

Nếu bạn duy trì site cũ, jQuery vẫn là công cụ hợp lý cho sửa nhỏ, plugin ổn định hoặc trang không đáng để rebuild. Nếu xây tính năng mới, ưu tiên JavaScript thuần trước và chỉ giữ jQuery khi nó thực sự tiết kiệm thời gian.

Để tiếp tục học theo hướng gắn với công việc thực tế, xem:

• DOM fundamentals and common patterns: blog/vanilla-js-dom-basics\n- Replacing older AJAX patterns with modern requests: blog/fetch-api-beginners

Nếu bạn đánh giá cách hiện đại hóa nhanh hơn, cân nhắc công cụ giúp prototype và ship dần. Koder.ai có thể hữu ích: bạn mô tả hành vi muốn bằng chat, tạo UI React và backend Go/PostgreSQL khi cần, và xuất mã nguồn khi sẵn sàng tích hợp vào codebase.

Nếu bạn đang đánh giá tooling hoặc gói hỗ trợ, review options here: pricing