# DataCamp Light: Add Interactive R and Python Exercises to Any Site

> DataCamp Light is a TypeScript and JavaScript library that converts marked HTML elements into interactive R or Python exercises inside an existing website. It is suited to course publishers and educators who need DataCamp-style validation, but its hosted execution model and AGPL-3.0 repository license require review before embedding.

**datacamp/datacamp-light** — Convert any blog or website to an interactive learning platform for data science

- Repository: https://github.com/datacamp/datacamp-light
- Stars: 1,374 · Forks: 366
- Language: TypeScript
- License: AGPL-3.0
- Published: 2026-10-16 · Updated: 2026-10-16 · Language: en
- Canonical page: https://hysenlabs.com/projects/datacamp-datacamp-light

## Why DataCamp Light Exists in an Existing Page

DataCamp Light addresses a specific publishing problem: a blog or website may already have lessons, explanations, sample datasets, and exercises, but it may not include the code editor, language runtime, and submission validation needed for interactive data science instruction. The library lets a publisher keep those lessons on an existing site instead of reproducing an entire course application. Its target users are authors, course teams, and educators publishing R or Python instruction through ordinary web pages.

The integration model is deliberately narrow. The publisher adds a DataCamp Light script and marks exercise containers in HTML. DataCamp Light turns those containers into interactive exercises, while DataCamp's servers retain the R and Python sessions. This makes the project more than a syntax-highlighting widget, but it also makes the service dependent on an external execution and session infrastructure rather than a browser-only Python or R runtime.

The README also points to a separate DataCamp tutorial package for converting existing Markdown documents into an interactive course. That conversion tool and DataCamp Light are related, but they are not the same thing. DataCamp Light is the embeddable HTML exercise layer. It is the relevant component for a publisher who wants to place exercises inside a blog, documentation site, or application page.

## How DataCamp Light Processes Marked HTML

The data flow begins with the browser loading `dcl-react.js.gz` from DataCamp's CDN. The library then finds elements carrying `data-datacamp-exercise` and `data-lang`. The accepted language values are `r` and `python`. Nested elements identify pre-exercise code, starter code, the reference solution, correctness tests, and hints through their `data-type` attributes.

This is a markup-driven interface. The outer `<div>` declares that it is an exercise, while `<code>` or `<div>` elements inside it supply the lesson assets. The README says leading indentation in sample code is stripped, so authors do not need to align code precisely with the surrounding HTML. Exercise height can be set with `data-height`, either as a pixel value with a documented minimum of `300px`, or as `data-height="auto"` to size the exercise from the amount of sample code.

For pages that insert exercise markup after the initial load, the library exposes `initAddedDCLightExercises()`. The documented call matters for React applications and other dynamic pages because statically loaded markup and newly mounted markup have different initialization moments. Based on the documented API, the function asks DataCamp Light to process exercises added after its initial scan rather than requiring a full page reload.

The package metadata identifies the distributed entry point as `dist/dcl-react.js`. Its dependencies include React, Redux, Ace-related editor components, and RxJS, which is consistent with a browser application that manages exercise state and editor interaction. The package file describes the main package as TypeScript-oriented, while author-facing integration is through JavaScript and HTML.

## Embedding DataCamp Light and Publishing a First Exercise

The simplest installation is the CDN integration documented by the README. It does not require building the TypeScript package for an ordinary embedded exercise. Add the following script to the page that contains the lesson.

```html
<script type="text/javascript" src="//cdn.datacamp.com/dcl-react.js.gz"></script>
```

The page then needs an exercise container. This first example asks the learner to create and print a variable. The library supplies the interface, executes submissions on DataCamp's servers, and evaluates the embedded SCT.

```html
<div data-datacamp-exercise data-lang="r">
  <code data-type="sample-code">
    # Create a variable a, equal to 5
    # Print out a
  </code>
  <code data-type="solution">
    a <- 5
    print(a)
  </code>
  <code data-type="sct">
    test_object("a")
    test_function("print")
    success_msg("Great job!")
  </code>
</div>
```

After the page loads, the element should become an R exercise with editable code. The sample code is the learner's starting point, `solution` supplies the comparison code, and the SCT checks for the object and function call before displaying `Great job!`. A publisher can add a hint or pre-exercise code using the same `data-type` convention.

For a dynamically inserted exercise, call the documented initializer after the new element has been added to the page.

```js
initAddedDCLightExercises();
```

Calling it only once is consistent with the README's wording about exercises added after the initial page load. The README does not define a framework component or server-side rendering procedure for React, so this client-side call is the documented integration available here.

## R and Python Validation Through testwhat and pythonwhat

DataCamp Light does not treat a submission as correct merely because its output resembles the solution. The exercise author embeds a Submission Correctness Test, or SCT, and the library delegates that test to the language-specific DataCamp testing packages documented by the README. R exercises use `testwhat`, while Python exercises use `pythonwhat`.

This design gives authors more control than simple output matching. In the README's R example, `test_object("a")` checks that the learner created the expected object with the expected value relative to the solution. `test_function("print")` checks for use of `print`, and `success_msg("Great job!")` defines the success message. Those exact testing functions are shown for R, so they should not be copied unchanged into a Python exercise without consulting the Python package documentation.

The separate solution block matters because the SCT can compare learner behavior with the intended solution. Pre-exercise code can initialize variables, load packages, or prepare datasets before the learner works. That model supports lessons with shared state, but it also shifts responsibility to the author: incorrect setup code, an overly permissive SCT, or a test that checks the wrong learner behavior can produce a technically functioning exercise that teaches or grades incorrectly.

The README does not document offline SCT execution, custom execution backends, or an option to replace DataCamp's session service. Authors who need to constrain exactly which libraries or network operations learners may use would need information beyond what this repository documentation provides.

## Repository Development Commands and Upgrade Exposure

Embedding exercises through the CDN does not expose every contributor command in `package.json`, but the repository file does define its local development surface. The top-level entries include `src/`, `webpack.config.js`, `tsconfig.json`, `package-lock.json`, `.nvmrc`, lint configurations, and CircleCI configuration. This indicates a source repository built with webpack rather than a package designed only for manual HTML embedding.

The documented package scripts provide specific commands for serving, building, testing, and linting. A contributor working from the repository would use the command that matches the intended task rather than assuming the CDN page is the only development mode.

```bash
npm run serve
```

That command starts `webpack-dev-server --open --env=serve`. Production output is produced by the following script.

```bash
npm run build:prod
```

It sets `NODE_CI=TRUE` and runs webpack with the production environment. The repository also defines `npm test`, `npm run lint:ts`, and `npm run prettier` for its respective test, TSLint, and formatting workflows. The `package.json` does not include a complete Node installation guide, so it does not justify asserting a particular Node version despite the presence of `.nvmrc`.

Upgrade planning has two separate tracks. A site using the CDN script may receive server-side or library changes without changing its page markup, although the repository does not state a CDN versioning or pinning policy. A site that builds and serves `dist/dcl-react.js` takes responsibility for dependency and artifact upgrades. The lockfile supports reproducible dependency resolution, but old pinned dependencies can also require dedicated compatibility work. The last repository push was on 2026-09-10, while the newest listed release is `v3.0.0-beta.7` from 2025-03-27. The beta designation is a concrete adoption boundary for teams that require a stable release channel.

## Licensing and Operational Boundaries

The repository is identified as AGPL-3.0, and a root `LICENSE` file is present. Its `package.json`, however, records `"license": "GPL-3.0"`. That discrepancy must be resolved before embedding or redistributing a modified build. This review does not provide legal advice, but the metadata conflict is a fact visible in the project files rather than an inferred compliance issue.

Operationally, the clearest boundary is DataCamp server dependence. The README states that sessions are maintained on DataCamp's servers. That architecture can remove the need to host language runtimes, but it introduces external availability, network, and account-policy questions that an offline exercise library would not have. It also means the publisher is not shipping a complete R or Python execution environment inside the website.

DataCamp Light is therefore the wrong tool when lessons must run without a connection to DataCamp's infrastructure, when course authors need direct control over the execution host, or when organizational policy prohibits sending exercise interactions to an external service. It is also a poor fit for a static documentation page that only needs syntax examples, because the library introduces an editor, session lifecycle, SCT authoring, and hosted execution where none are required.

## DataCamp Light Compared with DataCamp Tutorial Courses

The most relevant alternative named by the README is DataCamp's tutorial package. The approaches differ in where the course model lives. DataCamp Light embeds individual exercise components into an HTML page through `data-datacamp-exercise` containers and a JavaScript tag. Its author controls the surrounding blog or application, while DataCamp Light supplies the interactive exercise layer.

The tutorial package is presented as the route for converting existing Markdown documents into an interactive course. That workflow starts from course source documents rather than exercise markup embedded in a web page. It is more appropriate when the goal is to produce a structured DataCamp course from Markdown, and less appropriate when the requirement is to add exercises inside an existing independently designed website.

A browser-only code playground would be another conceptual alternative for basic editing and execution, but no specific browser-only playground is named in the repository documentation. The direct documented comparison is therefore DataCamp Light for embedded HTML exercises versus the tutorial package for Markdown-to-course conversion. Both belong to the wider DataCamp course ecosystem, but their input formats and publishing outcomes differ.

## Conclusion

DataCamp Light fits publishers that want to add DataCamp-style R or Python exercises without building an editor, validator, or remote session service. It is a poor fit for an offline tutorial, an environment that cannot contact DataCamp services, or a project that cannot accept the repository's AGPL-3.0 terms. Before adoption, verify remote session availability in the intended deployment region, confirm that `testwhat` or `pythonwhat` tests match the expected learner behavior, and reconcile the AGPL-3.0 repository license with the GPL-3.0 value recorded in `package.json`.

## FAQ

### How do I add DataCamp Light to a website?

Add `//cdn.datacamp.com/dcl-react.js.gz` as a script in the page, then mark exercise containers with `data-datacamp-exercise` and a language such as `data-lang="r"` or `data-lang="python"`.

### How are DataCamp Light submissions checked?

Each exercise can include an SCT in a `<code>` element with `data-type="sct"`. The README associates R checks with `testwhat` and Python checks with `pythonwhat`.

### Does DataCamp Light run R and Python on my website server?

The README states that sessions are maintained on DataCamp's servers. It does not document an offline mode or a custom local execution backend.

### How do I initialize exercises added by a React application?

After exercises are added following the initial page load, call `initAddedDCLightExercises()` as documented by the README.

## Sources

- [datacamp/datacamp-light on GitHub](https://github.com/datacamp/datacamp-light)
- [Issues](https://github.com/datacamp/datacamp-light/issues)
- [License: AGPL-3.0](https://github.com/datacamp/datacamp-light/blob/master/LICENSE)
- [README](https://github.com/datacamp/datacamp-light/blob/master/README.md)
- [Releases](https://github.com/datacamp/datacamp-light/releases)

---

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