DigitableCourses
Portal settings
Русский
Show me around

Local and account-free. No account, no sign-up: whatever you type into the tools stays in this browser's localStorage and never reaches a server.

Our own counter records page opens and finishes: the address leaves, plus one tenth-of-the-text figure. No cookies, no outside trackers, your IP is not stored, Do Not Track is honoured. How to check that

The portal's own repository is not published, so we do not call it open source. What is open:

Digit flang Agent gate tools-core IT Tools Chat digitwm blender-mcp Hugging Face Licences

The portal lives on donations, paid consultations and requested write-ups, and on Workbench sales.

Support Order a write-up Workbench

There are no plans to make the courses paid.

Career

Frontend developer

The interface in the browser: markup, state, performance, accessibility.

Roles and moves Self-assessment

Step 2 of 2 · Frontend developer

Which level inside the role?

Where people go from here: Mobile developer, Backend developer, Product manager, Team lead, tech lead, engineering manager

Not sure — open the whole role card Pick another role

  1. Junior
  2. Middle
  3. Senior
  4. Further on: a branching, not a rung

Junior

Straight to the self-check

Compared with studying, the ground under you changes: the mockup and the framework are temporary, while the browser and its rules stay.

Do now

  • I build a screen with no framework at all: markup, styles, eventsThe form submits on Enter, and a button is a button rather than a div with a handler.
  • I go through my screen from the keyboard without touching the mouseFocus is visible, and every action can be reached with Tab.
  • I work out what the bundle of the project is actually made ofI can fix a broken build instead of reinstalling dependencies at random.
  • I check the layout on a narrow screen and with long textNothing falls apart and nothing is cut off.

Where next

Middle

Sideways out of the role

What this step asks of you

  • I understand what the browser does between the load and the first frameI can explain why the page flickers and which part of that is my code's fault.
  • I write markup that works without styles and from the keyboardThe form submits on Enter, and a button is a button element, not a div with a handler.
  • I build a layout that does not fall apart on a phoneI understand flow, flexbox and grid, and I do not fix everything with absolute positioning.
  • I write components and understand where their state comes fromI tell component state from application state and do not duplicate the source of truth.
  • I can deal with the project build, not only with npm run devI understand what happens between the source and the bundle, and I can fix a broken build.

Common mistakes

  • Fixing a layout with absolute positioning: on another screen it falls apart again.
  • Learning the framework instead of the browser: when the fashion moves on, the knowledge resets to nothing.
  • Making buttons and links out of divs: the keyboard and the screen reader stop working, and it is not noticed straight away.

What to learn

  1. Junior
  2. Middle
  3. Senior
  4. Further on: a branching, not a rung

Middle

Straight to the self-check

What counts as a finished screen changes: not the markup assembled but the behaviour on a network error, on empty data and on a second tap.

Do now

  • I walk through my screen with the network switched off and with the server returning an errorThe person can see what happened, and what they typed is not lost.
  • I choose how to hold state to fit the problem and write down whyI can explain where component state is enough and where a cache of server data is needed.
  • I set the types up so that an impossible state does not compileThe compiler catches the mistake, not a test in production.
  • I hand the form to a screen reader before the releaseThe fields are named, errors are announced, and the traversal order matches what is on screen.

Where next

Senior

Sideways out of the role

What this step asks of you

  • I choose how to store state to fit the problem, not out of habitI can explain why useState is enough here and a cache of server data is needed there.
  • I build forms that behave honestly when the network and the validation failA double click does not create two records, and a server error does not wipe what was typed in.
  • I use types as a design tool, not as a formalityAn invalid state is inexpressible in my types rather than checked at runtime.
  • I test the behaviour of the interface, not implementation detailsThe test does not break when a class is renamed, but it does break when the scenario breaks.
  • I check accessibility before the release, not after a complaintI go through my own screen with a keyboard and a screen reader, and I know where aria is genuinely needed in it.

Common mistakes

  • Testing the details of the implementation: the tests go red when a class is renamed and stay silent on a broken scenario.
  • Keeping the same fact in two places: the two states diverge on the very first day.
  • Leaving accessibility to the end: fixing the semantics after a release costs more than getting it right on the mockup.

What to learn

  1. Junior
  2. Middle
  3. Senior
  4. Further on: a branching, not a rung

Senior

Straight to the self-check

The scale of a decision changes: a choice inside one screen now costs the whole client side — its modules, its contracts and its loading speed.

Do now

  • I describe the boundaries of the client modules and the rule for adding a screenA new developer puts a file in the right place without asking me.
  • I look at loading speed for real users rather than at a run on my own machineI work from field data and know for whom our site is slow.
  • I explain the price of a mockup to design through behaviour rather than through you cannot do thatThe argument ends with a different solution rather than with hurt feelings.
  • I go through with the team what we won and what we lost on the rendering model we choseThe choice is written down together with its price, and it can be revisited.

Where next

Further on: a branching, not a rung

Sideways out of the role

What this step asks of you

  • I hold the client architecture: module boundaries, shared contracts, other people's codeA new developer adds a screen without asking where to put the file.
  • I improve load metrics from measurements taken on real usersI work from field data, not from a lab run on my own laptop.
  • I choose the rendering model deliberately and understand its priceI can explain what we gained and what we lost by moving to server rendering.
  • I understand the client-side classes of attack and do not rely on checks in the browserI know what CSP is for, and I do not count validation on the client as protection.
  • I speak the same language as design and argue on the substanceI can say what is expensive in a mockup and what to replace it with, instead of just saying it cannot be done.

Common mistakes

  • Rewriting the whole architecture because the old one has become tiresome: the product stands still, and nobody remembers the reasons any more.
  • Trusting a lab measurement: people have other devices and another network.
  • Treating a check in the browser as protection: the client is visible to everyone, and data is validated on the server.

What to learn

  1. Junior
  2. Middle
  3. Senior
  4. Further on: a branching, not a rung

Further on: a branching, not a rung

Straight to the self-check

There is no rung upwards: what you choose is not a height but a kind of work — tooling for other teams, the product, or people.

Do now

  • I hand my shared component to other teams together with versions and a path for upgradingThe library has internal users, not only an author.
  • I move a rule of quality out of chat and into the pipelineThe check lives in CI, and it cannot be forgotten.
  • I take a vague problem that has no owner and carry it through to a solutionThe work is closed although nobody had written it down as a task.
  • I grow somebody next to me who will manage without me afterwardsThere are people who can say what they learned working next to me.

Where next

Not another step — a fork

Sideways out of the role

What this step asks of you

  • I build tools for other teams and answer for how convenient they areMy library has versioning, migrations and live users inside the company.
  • I set the quality practice for the whole frontend of the companyThe rules live in CI, not in message threads.
  • I pull along the work that has no ownerI took a vague problem, broke it down and carried it through to a solution.
  • I raise the level of the team, not only my ownThere are people who grew up next to me and can confirm it.

Common mistakes

  • Building a library with no users: it turns into a personal project at the company's expense.
  • Keeping a standard in words: a rule that is not in the pipeline is obeyed until the first emergency.
  • Going into management because of a ceiling on pay: the subject of the work changes completely, and there is a ceiling there too.

What to learn

IT Tools source · GPL-3.0 Digitable Chat source · GPL-2.0-or-later Legal documents