Completing lessons shows exposure. Demonstrating skill requires working code, tests, review, and an explanation of decisions. Use this rubric after each phase project and again after the capstone.
You can:
- Explain values, types, coercion, scope, functions, errors, arrays, and objects with your own examples.
- Write small pure functions and test normal and boundary inputs.
- Transform a data set with clear collection methods.
- Identify accidental mutation and choose an appropriate data structure.
- Use browser developer tools to inspect values and a stack trace.
Evidence: Projects 01–03, with code and test notes.
You can:
- Build DOM content with safe node creation and textContent.
- Handle forms, events, delegation, timers, and cleanup.
- Keep application state consistent with rendered UI.
- Load JSON with distinct loading, empty, success, and error states.
- Cancel stale work or prevent late results from overwriting current choices.
- Use URL and storage state deliberately, without placing secrets in browser storage.
Evidence: Projects 04–05, keyboard checks, and failure-state demonstrations.
You can:
- Split code into modules with understandable dependencies.
- Test pure logic and one browser interaction.
- Diagnose a bug using a stack trace, breakpoint, or network evidence.
- Review dynamic accessibility state and untrusted DOM insertion.
- Measure a performance issue before changing code.
- Publish an app and smoke-test its public behavior.
Evidence: Projects 06–07, test results, an audit log, and a deployed app.
You can:
- Explain when an advanced tool such as a worker, iterator, or binary buffer is justified.
- Design component and state contracts that include errors and accessibility.
- Prioritize issues by user impact and evidence.
- Make a change, measure or test it, and communicate the tradeoff.
- Review another implementation constructively and incorporate feedback.
- Document limitations without overstating security, accessibility, or performance.
- Explain prototype behavior, weak references, async iteration, and stream backpressure.
- Choose browser persistence, worker, service-worker, or messaging APIs based on requirements.
- Apply security policy, internationalization, diagnostics, and performance tools with awareness of browser limits.
Evidence: Projects 08–10, a public application, meaningful tests, a review log, and a case study.
You can trace state ownership and asynchronous lifecycles, identify risks by user impact, and write review findings with reproducible evidence and a testable next step.
Evidence: A reviewed capstone, prioritized findings, reproduction steps, follow-up fixes, and a written explanation of tradeoffs.
Mark each area demonstrated, needs improvement, or not tested, and include evidence.
| Area | Demonstrated when |
|---|---|
| Language reasoning | The author can explain types, scope, promises, modules, and mutation in the project. |
| State consistency | Controls, URL, stored data, and rendered content agree after actions and navigation. |
| Async behavior | Loading, empty, error, and stale-result cases are handled. |
| Safe DOM | User or external text is inserted as data, and links are controlled. |
| Accessibility | Keyboard tasks, focus, labels, and dynamic messages have been checked. |
| Tests | Pure logic has normal, boundary, and invalid-input tests. |
| Performance | A relevant bottleneck was measured before and after a change. |
| Maintainability | Module boundaries and component responsibilities are clear. |
| Deployment | Public files, data, navigation, and errors were smoke-tested. |
| Communication | The case study explains choices, tradeoffs, feedback, fixes, and limits. |
An untested area is not complete. Fix the most important gap and review it again.