A Gatling suite is written in Java and maintained by a platform team while the product engineers write TypeScript, so how would you decide whether to move it onto Gatling's JavaScript and TypeScript SDK?
answer
- Same DSL, different package manager
- Ownership decides it, not syntax
- Audit for constructs with no equivalent
- Pilot one simulation before the suite
basics
~20 sDecide on ownership, not syntax. The DSL vocabulary and the engine are the same, so the move buys maintainability by the product engineers and costs a rewrite, an npm toolchain, and an audit for constructs the JavaScript SDK does not have.
solid answer
~40 sStart from what does not change: the DSL names, the load model and the engine underneath are the same, so nobody should expect different results or better performance from the move. What changes is everything around the code — dependencies come from npm as `@gatling.io/core`, `@gatling.io/http` and `@gatling.io/cli` rather than from a build tool, simulations are discovered by file name rather than by class, and the CLI fetches its own runtime bundle. Before committing, audit the existing simulations for constructs with no JavaScript equivalent: Gatling's own JavaScript samples render some regions as unsupported, simulation `before`/`after` hooks among them. Then decide the real question, which is who maintains and is accountable for the suite. Port one simulation first and let that pilot answer it.
go deeper
Be ready to say that Gatling's JavaScript and TypeScript SDK expresses the same DSL as the Java one, so choosing between them is not a question of what the tool can do.
Explain concretely what changes: npm packages instead of build-tool dependencies, file-based discovery instead of class names, and a runtime bundle the CLI fetches.
Show the audit step. Name the constructs to check for before promising a migration, and insist on a pilot simulation that a product engineer, not the migrator, modifies first.
Own the framing — this is an ownership and accountability decision, with a stopping rule agreed up front and an explicit answer to who is paged when the suite fails.
This is an ownership decision wearing a language decision's clothes. The honest way to run it is to separate the three things it actually turns on: what genuinely carries across, what the move costs, and who ends up holding the suite. ## What carries across unchanged Gatling is authored in five languages — Java, Kotlin, Scala, JavaScript and TypeScript — over two JVM binding layers plus one npm package family for JavaScript and TypeScript. The npm SDK is not a second product with a different vocabulary: - **The DSL names are the same.** A scenario is still `scenario(...)` composed with `exec(...)`, a population is still registered through one `setUp` call, and the injection step names are the ones the JVM SDKs use. - **The engine is the same.** Nothing about throughput, accuracy or the report changes because the source language changed. A team hoping the move makes their tests faster or their numbers better is hoping for the wrong thing. - **The verdict is the same.** A failed assertion is a failed assertion, and Gatling's failure exit code is unchanged by the SDK you author in. That is the strongest argument *for* the move: it is a change of authoring surface, not a change of tool. ## What changes around the code | concern | JVM SDK today | JavaScript / TypeScript SDK | |---|---|---| | dependencies | declared to a build tool | `@gatling.io/core`, `@gatling.io/http` in `package.json`, plus `@gatling.io/cli` as a dev dependency | | what a simulation is | a class extending `Simulation` | a module default-exporting a `simulation(...)` value | | how one is selected | by class name | by file: `*.gatling.js` / `*.gatling.ts` at the root of a sources folder | | the engine's provenance | on the JVM classpath | a runtime bundle the CLI downloads and caches | | library choice | anything on the JVM | no native binaries, no Node-specific APIs | None of these is hard, and all of them are new. They land on whoever runs the suite, which is exactly the group you are proposing to change. ## What may not port at all This is the step teams skip. Gatling's own JavaScript and TypeScript documentation samples mark some regions as **not supported** — simulation `before` and `after` hooks are one, deployment information about a distributed run is another. Before you promise the migration, sweep the existing simulations for: 1. **Lifecycle hooks** — any `before`/`after` setup or teardown, which needs somewhere else to live. 2. **JVM-only helpers** — anything reaching into Java libraries, custom feeder implementations, or JDBC and Redis data sources. 3. **Shared JVM code** — internal test-support artifacts your simulations depend on, which do not follow you to npm. 4. **Anything the JavaScript samples do not show at all** — absence in the docs is not proof it is missing, but it is the list to verify rather than assume. The output of this sweep, not the language preference, is what tells you whether the migration is a week or a quarter. ## The decision that actually matters Ask who is accountable for the suite **after** the move: - If the product engineers will genuinely own it — write the simulations, review each other's, and be the ones paged when a run gates a release — then removing the language barrier is a real reduction in handoffs, and the migration cost is worth paying. - If the platform team will still own it and the change is only meant to make the code *look* familiar to product engineers, the move buys nothing and costs a rewrite of working software. Familiar-looking code that nobody outside the owning team touches is the same code in a different syntax. - If the honest answer is "we hope they will", treat that as unproven and design an experiment rather than a migration. ## How to de-risk it - **Pilot one simulation**, ideally a mid-complexity one rather than the smallest, and have a product engineer — not the migrator — make the first change to it afterwards. That is the actual hypothesis under test. - **Run both for a period.** Two suites briefly is cheaper than a half-finished migration, and it gives you a comparison of results from the same engine. - **Do not mix per-file.** A repository half in Java and half in TypeScript inherits both toolchains permanently; choose per suite, not per simulation. - **Set a stopping rule up front** — what the pilot must show for the rest to follow, and what makes you keep the Java suite. Deciding that afterwards is how migrations become permanent hybrids. ## What would make you say no An audit that finds real unsupported constructs, a product team that will not take on-call for the suite, or a stable suite nobody is struggling to maintain. "Our engineers prefer TypeScript" is a legitimate input and a poor sole justification, because the cost falls on working software and the benefit is contingent on a behaviour change that has not happened yet.
- What would make you keep the Java suite instead?An audit that turns up constructs with no JavaScript equivalent, a product team unwilling to take real ownership including on-call, or simply a suite nobody is struggling to maintain. Rewriting working software needs a benefit that has actually been demonstrated, not one that is hoped for.
- Should the two suites ever be run side by side?Briefly, yes — during a pilot. Running the ported simulation and its original against the same target for a period gives you a like-for-like comparison from the same engine and a fallback if the pilot fails. What you should not do is settle into a permanent half-and-half repository carrying both toolchains.
saying these in an interview costs you the question
- Treating the move as a mechanical syntax translation
- Expecting different performance from a different Gatling SDK
- Assuming every JVM construct has a JavaScript equivalent
- Migrating without agreeing who owns the suite afterwards