# YoptaScript compiles gopnik slang into plain JavaScript

> YoptaScript is a transpiler that turns a Russian slang dialect into plain JavaScript in the browser. Its dictionary is one file, its dialect rules are forgiving, and its documentation leaves several edges undocumented.

**samgozman/YoptaScript** — Joke programming language for 'gopniks' in Russia. Back from 2016!

- Repository: https://github.com/samgozman/YoptaScript
- Website: https://yopta.space
- Stars: 2,256 · Forks: 106
- Language: TypeScript
- License: MIT
- Published: 2026-10-14 · Updated: 2026-10-14 · Language: en
- Canonical page: https://hysenlabs.com/projects/samgozman-yoptascript

## A dictionary file decides what the parser accepts

Everything YoptaScript accepts comes down to one file. New words go into `src/dictionary/dictionary.ts`, and a prebuild step named `prepareArrayBeforeBuild.ts` turns that dictionary into an array before webpack bundles the language into `dist/yopta.js`, with declarations published beside it at `dist/index.d.ts`. The vocabulary is borrowed rather than invented for the joke: the project credits a lurkmore.to glossary and a copy of a street slang dictionary saved through web.archive.org, and it dates the origin to mid 2016, when Piter.TV reported on a category of programmers the README calls gopnik-programmers.

Editing that one table is the entire extension mechanism, which is rare and easy to audit. A contributor adds a word, the build rewrites the dictionary array, and the finished bundle carries the same table. There is no plugin system and no registry to query. The trade-off is that the language only knows what a single file knows.

## Load yopta.js after the script block it has to translate

The browser is the documented path, and it starts with the smallest possible case. Copy the built file next to your project, or pull it from a CDN, then load it at the very end of the page, after your markup and just before the closing `body` tag:

```html
<body>
    <script src="yopta.js"></script>
</body>
```

The next step decides whether anything runs at all. A script element carrying the attribute `language="YoptaScript"` has to sit in the page before that bundle is loaded, because the bundle is what converts the block. The README puts both halves on the page together:

```html
<body>
    ... ...
    <script language="YoptaScript">
        //ваш йоптакод
    </script>
    <!-- Пример с CDN -->
    <script src="https://cdn.jsdelivr.net/npm/yopta/dist/yopta.min.js"></script>
</body>
```

Order is a hard requirement in these instructions, and no fallback ordering is documented for a block placed after the bundle. You can also move the YoptaScript into a separate file and point at it through the src attribute rather than inlining the source. The first line worth trying is the sample the README itself prints:

```html
<script language="YoptaScript">
    ксива.малява(" Оно работает ") нах
</script>
```

Since the output is plain JavaScript, anything the browser can run stays reachable from inside a YoptaScript block, including the DOM and window.

## npm install yopta links a bundle, not a command

The NodeJS section is short. YoptaScript can be added to a project through the npm package manager:

```bash
npm install yopta
```

The next sentence offers a global form, `npm install -g yopta`, described as installing yopta globally. Read package.json and the promise shrinks. There is no bin field, so a global install leaves a library on disk and no command line entry behind it. The scripts block has no start, run or compile command either; the six entries are prebuild, build, demo, dev, test and test-local. That makes the package a browser bundle you link, not a tool you invoke.

Two more details from the same file. Exactly one runtime dependency is declared, globalthis, and the README never says where the transpiler uses it, even though one example file covers document and window. The declared licence is MIT, with the text kept in LICENSE.txt, while the published package is restricted to `dist/**/*`, so check what your bundler actually ships before you ship a page that depends on it. For local work the demo script serves the repository root on port 1488 through serve, which is how the repository and everything under demo/ are opened during development.

## One keyword carries several spellings, and no dialect flag

Synonyms replace flags. The true literal is reached through `трулио`, `чётко`, `четко` or `чотко`. The false literal has `нетрулио`, `пиздишь`, `нечётко`, `нечетко` and `нечотко`. Equality is `эквалио`, `ровно`, `однахуйня` or `типа`. A second layer sits on top of that: any word containing ё can be typed with е, and where ё may fall inside a word, о is accepted in its place.

The README states this in one line and then points at the dictionary file for more aliases, so the list above is a sample rather than the whole surface. No compiler option selects a preferred dialect in the documented scripts, and no linter configuration is offered for either spelling. The consequence is dull but real: two people writing the same condition can end up with files that read differently, and the only tie-breaker is the dictionary table itself.

## Five example files and a jest suite below them

The examples folder is the shortest guided tour. `vars.yopta` covers variables, functions and conditions, `loops.yopta` covers iteration, `document.yopta` covers the document and window objects, `math.yopta` covers the Math namespace, and `logical.yopta` covers logical operators. A complete page lives at demo/page/index.html, and demo/converter/index.html opens a converter that goes from JavaScript into YoptaScript in the browser.

Two gaps show up immediately. No example exercises JSX, and no example runs outside a browser page. Underneath, the project keeps a `__tests__` directory with jest pinned at `^27.0.4`, where test runs jest and test-local rebuilds the bundle first and then watches, so transpiler regressions are caught before anything is published. The demo tree also carries demo/import, and the README never explains what that third route does, which leaves it as the one directory in the tree with no documented purpose.

## JSX arrived in 2.0.6 with nothing documenting it

The recent version list holds three entries after a long quiet stretch: 2.0.4 on 2022-08-20, which moved yopta.space onto gh pages, 2.0.5 on 2025-07-11 with a batch of fixes, and 2.0.6 on 2025-07-14, whose note is JSX syntax support. package.json is pinned to 2.0.6, so the source tree and the newest published build agree on the number.

The timing tells its own story. Nearly three years separate 2.0.4 from the next entry, then two days separate 2.0.5 from 2.0.6, and the last push landed on 2026-07-01 with the repository not marked as archived. What 2.0.6 added is also the least visible part of the project. None of the five example files contains a JSX fragment, the browser section never mentions JSX, and no JSX key exists anywhere in package.json. Anyone who wants to write JSX with this transpiler has to read the source rather than the documentation, which is the opposite of what the version note invites.

## Keep your TypeScript and let an editor rewrite it

There is a second route that avoids typing a single keyword. The md-prettify extension for VS Code turns existing code into YoptaScript on the fly while the file on disk keeps the original source, and the README shows the single setting that switches it on:

```json
"mdPrettify.predefinedConfig": "typescript-to-yoptascript"
```

That is a different bargain from compiling by hand. Your editor stays on TypeScript, which is the language the transpiler itself is written in, and the YoptaScript form exists only in the rendered buffer. The same idea appears in demo/converter/index.html, which converts JavaScript into YoptaScript inside the browser.

Neither route is documented in reverse, and neither one documents what happens to constructs the dictionary has no word for. If the goal is to read the dialect, the converter is the cheaper path. If the goal is an executable artifact, you are still back to loading a bundle into a page.

## Page privileges, profanity, and no way back

Two constraints decide when this is the wrong tool. First, the output is plain JavaScript, so a YoptaScript block runs with the same authority as any inline script on the page. No sandbox, module boundary or permission model is written down anywhere, and the bundle itself arrives from a CDN in the README example. Code that reaches the page from outside your team runs with your page's access.

Second, the README opens with its own warning that the language contains a large amount of profanity. That is fine for a joke and awkward inside a repository that a linter, a review bot or an employer scans, and it applies to source files, not just to rendered output. Neither point is a defect; both follow from the design. Add one more gap: rollback and migration for teams that already have .yopta files in a repository are absent from the documentation, so the way out has to be designed before the way in.

## Conclusion

YoptaScript fits a tutorial page, a talk demo or a joke inside an existing project, and fits badly anywhere a linter, a reviewer or a security audit will read the file. Treat it as a transpiler, not a sandbox: the marked script block is handed to the browser as plain JavaScript with page authority, and the vocabulary carries profanity by the project's own admission. Before adopting it, confirm that your build can serve dist/yopta.js, that the JSX support added in 2.0.6 has an example you can read in the source, and that no workflow of yours needs to convert YoptaScript back into ordinary code.

## FAQ

### How do I run YoptaScript in a browser?

Load the built bundle at the end of the page, then place a script element with the attribute language="YoptaScript" before it. The bundle can be a local yopta.js file next to your project or the jsdelivr path dist/yopta.min.js from the yopta package.

### Does YoptaScript have a command line interface?

No command line interface is documented. The README offers npm install yopta for a project and npm install -g yopta for a global install, but package.json declares no bin field, so the package exposes no executable.

### How do I write true and equality in YoptaScript?

Each has several spellings: трулио, чётко, четко and чотко mean true, while нетрулио, пиздишь, нечётко, нечетко and нечотко mean false. Equality is эквалио, ровно, однахуйня or типа, and the letter ё can always be typed as е.

### How do I add a new word to YoptaScript?

Add the definition to src/dictionary/dictionary.ts, then rebuild. The prebuild step runs prepareArrayBeforeBuild.ts through ts-node before webpack bundles the language into dist/yopta.js.

### Can I convert JavaScript into YoptaScript and back again?

One direction is documented: demo/converter/index.html converts JavaScript into YoptaScript in the browser, and the typescript-to-yoptascript preset in md-prettify reformats a file while the original stays on disk. The reverse direction is not described anywhere in the README.

### Is YoptaScript suitable for production code?

The transpiler emits plain JavaScript, and no sandbox or module boundary is described for the marked script block. The README also warns that the language contains a large amount of profanity, which matters for scanned repositories.

## Sources

- [License: MIT](https://github.com/samgozman/YoptaScript/blob/master/LICENSE)
- [Project website](https://yopta.space)
- [README](https://github.com/samgozman/YoptaScript/blob/master/README.md)
- [Releases](https://github.com/samgozman/YoptaScript/releases)
- [samgozman/YoptaScript on GitHub](https://github.com/samgozman/YoptaScript)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/samgozman-yoptascript