X-ray a codebase and learn to code in Novus Learn

Open /code and point it at a JavaScript codebase. What you get back is structural: how the project is organised, what depends on what, and where the meaningful boundaries sit. This is the map you would otherwise build by reading entry points and following imports for an afternoon.

Read it as orientation rather than as ground truth about behaviour. Structure tells you where to look; it does not tell you what a function does under load, and no static view of a codebase ever will.

The two most useful things in any unfamiliar project are where execution starts and where the project stops being itself. Entry points tell you the order things happen in; boundaries — the module edges, the interfaces to external systems — tell you where a change is safe and where it is going to ripple.

Prioritise those over reading files top to bottom. A codebase is a graph, and reading it alphabetically is a choice that makes the graph invisible.

When the code uses something you do not know, the coding paths at /languages are where to go. They cite official language documentation, which matters more here than in most subjects: JavaScript accumulates confidently-wrong folklore faster than almost any other language, and a lot of what circulates as explanation is years out of date.

The same extractive rule applies. A path shows you what the documentation says, not a rewritten version of it, so the semantics you learn are the specified ones rather than someone's recollection of them.

Reading about a language feature and using it are different kinds of knowing. The JavaScript scratchpad at /playground closes that gap — write the snippet, run it, and find out whether your mental model survives contact with the interpreter.

This is especially worth doing for the parts of JavaScript that behave counter-intuitively: coercion, scoping, asynchronous ordering, and anything involving `this`. Five minutes in a scratchpad settles arguments that documentation alone tends to leave open.

A code project produces the same study artifacts as any other source: notes, flashcards, a quiz, a concept map. For a codebase the concept map is usually the keeper — it is the structural view in a form you can come back to when you have forgotten which module owns what.

For the language material, flashcards genuinely help. API surfaces and semantics are recall problems, and recall problems are what cards are for.

The /code surface analyses JavaScript. It is not a general-purpose static analyser, not a linter, and not a security scanner, and it will not tell you whether the code is correct — only how it is arranged and what the language underneath it specifies.

That boundary is worth respecting. Use it for orientation and for learning, then use the actual tooling — tests, types, profilers, review — for the questions those tools exist to answer.