LangGraph vs LangGraph.js
LangGraph exists in two versions: the original Python library and a TypeScript port called LangGraph.js. Both are maintained by the LangChain team. The core API is the same — StateGraph, nodes, edges, checkpointers — but the language-level details differ. This page covers what is shared, what is different, and when each version makes more sense.
At a glance
Both are MIT-licensed and actively maintained. The Python version launched in August 2023, the JS version followed in January 2024. Both reached 1.0 GA in October 2025. Numbers below are from early 2026.
LangGraph (Python)
- GitHub stars
- ~25,500
- Monthly downloads
- ~37M (PyPI)
- Contributors
- ~274
- Current version
- 1.0.x
LangGraph.js (TypeScript)
- GitHub stars
- ~2,600
- Monthly downloads
- ~6M (npm)
- Contributors
- ~100
- Current version
- 1.2.x
The Python version has roughly 10x the GitHub stars and 6x the downloads. This reflects Python's dominance in the AI/ML space and the 5-month head start, not a quality gap.
Same API, different syntax
The graph API is the same in both versions: StateGraph, addNode, addEdge, addConditionalEdges, compile. The prebuilt agent (createReactAgent) works the same way. Checkpointers, human-in-the-loop (interrupt()), and streaming modes are all equivalent. The differences are at the language level.
API differences in detail
State definition
Python uses TypedDict with Annotated type hints for reducer functions. This is idiomatic Python — the type system handles the state schema naturally.
TypeScript uses Annotation.Root() with explicit reducer functions. This exists because TypeScript's types are erased at runtime, so reducers must be defined as actual values. The result is slightly more verbose, but provides the same capabilities. MessagesAnnotation is a shortcut that covers the most common case (a list of messages with append semantics).
Tool definition
Python infers tool schemas automatically from function signatures, type hints, and docstrings. The @tool decorator is all you need. TypeScript requires explicit Zod schema objects passed to a tool() function. This is more verbose, but gives you runtime validation that Python's type hints do not provide.
Node functions
Python supports both synchronous (def) and asynchronous (async def) node functions. TypeScript nodes are almost always async since all LLM calls are promise-based. Python requires asyncio.run() or an async runner for async execution. JavaScript's event loop handles this natively.
Naming conventions
Python uses snake_case (create_react_agent, add_node, tools_condition). TypeScript uses camelCase (createReactAgent, addNode, toolsCondition). Functionally identical.
Feature parity
As of early 2026, both versions share all major features: StateGraph, prebuilt agents, checkpointers (MemorySaver, SQLite, Postgres, MongoDB, Redis), human-in-the-loop via interrupt(), five streaming modes, subgraphs, conditional edges, the Store API for cross-thread memory, multi-agent swarms, and LangGraph Platform deployment.
Where Python leads
- More extensive documentation and more how-to guides
- LangChain Academy courses are Python-only
- ~98 chat model provider integrations vs ~33 for JS
- More community tutorials, blog posts, and Stack Overflow answers
- LangGraph Studio support is stable (JS is in beta)
- Features typically land in Python first
Where TypeScript leads
- Runs on Node.js, Deno, Bun, Cloudflare Workers, Vercel Edge, browsers
- Zod tool schemas provide runtime type validation
- Fully type-safe
.stream()method with TypeScript generics - Resumable streams that survive page reloads
- Native non-blocking I/O without GIL limitations
- Faster cold starts for serverless deployments
Runtime support
Runtime support is where the two versions diverge most. Python runs in CPython environments (servers, containers, Lambda). LangGraph.js runs anywhere JavaScript runs.
| Runtime | Python | TypeScript |
|---|---|---|
| Node.js | — | Yes (primary) |
| Deno | — | Yes |
| Bun | — | Yes |
| Cloudflare Workers | — | Yes |
| Vercel Edge | — | Yes |
| Browser | — | Yes |
| Docker / bare metal | Yes | Yes |
| AWS Lambda | Yes | Yes |
If you need to run agent logic on the edge (low latency, close to users) or in the browser (demos, offline-capable apps), LangGraph.js is the only option.
Performance
Agent workflows spend most of their time waiting on LLM API calls, so framework overhead rarely matters. The bottleneck is the LLM provider's response time, not your local code. That said, there are some practical differences.
Concurrency: Node.js handles concurrent I/O natively through its event loop. Python needs asyncio and is limited by the GIL for CPU-bound work. For agent workflows with multiple parallel LLM calls, JavaScript has a natural advantage. Community benchmarks show ~20-25% better end-to-end latency for I/O-heavy workflows.
Cold starts: Node.js and Bun have faster cold start times than Python, which matters for serverless and edge deployments.
ML ecosystem: Python has access to NumPy, Pandas, scikit-learn, PyTorch, and other libraries for local data processing. This is less relevant for typical agent workflows (which call external APIs) but matters if your agents do heavy computation locally.
Side-by-side comparison
| LangGraph (Python) | LangGraph.js (TypeScript) | |
|---|---|---|
Language | Python | TypeScript / JavaScript |
State definition | TypedDict + Annotated | Annotation.Root() + explicit reducers |
Tool schemas | @tool decorator, schema from type hints + docstrings | tool() function, schema from Zod objects |
Node functions | def or async def | async function (always async) |
Runtimes | CPython only | Node.js, Deno, Bun, Cloudflare Workers, Vercel Edge, browsers |
Checkpointers | MemorySaver, SQLite, Postgres, MongoDB, Redis | MemorySaver, SQLite, Postgres, MongoDB, Redis |
Streaming | 5 modes (sync + async) | 5 modes (async only) |
LLM integrations | ~98 chat model providers | ~33 chat model providers |
Community size | ~274 contributors, 25.5k stars | ~100 contributors, 2.6k stars |
License | MIT | MIT |
When to use which
Pick LangGraph (Python) when
- Your team is Python-first or comes from data science / ML
- You need the broadest possible model provider integrations
- You want access to the Python ML ecosystem (NumPy, PyTorch, etc.)
- You want the most documentation and community resources
- You are following LangChain Academy courses
- Your deployment target is a traditional server or container
Pick LangGraph.js when
- Your team is TypeScript/JavaScript-first
- You want one language across frontend and backend
- You need edge deployment (Cloudflare Workers, Vercel Edge, Deno Deploy)
- You need browser-based agent execution
- You are building a Next.js, Nuxt, or SvelteKit app
- Fast cold starts matter (serverless / edge functions)
The choice usually comes down to your team's primary language. If you write Python, choose Python. If you write TypeScript, choose TypeScript. The capabilities are the same. Crewship supports both, so your deployment infrastructure stays the same either way.
Deployment
LangGraph Platform (now called LangSmith Deployment) supports both Python and TypeScript across all deployment options: Cloud SaaS, self-hosted Lite, bring your own cloud, and self-hosted Enterprise. Both languages have a CLI and SDK package.
Crewship supports both versions too. Set framework = "langgraph" or framework = "langgraphjs" in your crewship.toml. You get the same Runs API, Threads API, versioning, and Slack integration regardless of language.
FAQ
Common questions
Deploy either version with Crewship
Same Runs API, Threads API, versioning, and Slack integration — whether you choose Python or TypeScript.