Aurum
Download

Frontend Web Engineering

A frontend you can keep changing: a browser matrix and rendering choice, Core Web Vitals and accessibility baselines, error triage, bundle budgets, component upkeep and the skills behind fast, accessible interfaces.

Free · Mac (Apple silicon) and Windows · v1.0.0 · Other platforms

Then open the Marketplace in the app, search for Frontend Web Engineering, and click Install. It goes into your own files, and works offline from then on.

What it installs.

1

Pillar

1

Area

50

Projects

200

Starter tasks

⚙️ Software Engineering

Frontend Web Engineering

Building web interfaces with modern frameworks, managing state, performance, accessibility and browser quirks in a maintainable way.

  1. Supported browser and device matrix
  2. Rendering mode and framework decision
  3. Component and feature folder conventions
  4. TypeScript strict mode for the frontend
  5. Browser-safe environment and build config
  6. Design tokens wired into CSS
  7. Core Web Vitals baseline from field data
  8. Accessibility baseline audit of key pages
  9. Browser error reporting with source maps
  10. Weekly browser error triage
  11. Bundle size budget in pull requests
  12. Monthly Core Web Vitals review
  13. Browser release watch and quirk log
  14. Shared component library upkeep
  15. Accessibility spot check on new features
  16. Pre-release cross-browser pass
  17. Component stories as living documentation
  18. Frontend reading and experiment queue
  19. Semantic HTML and native form controls
  20. Modern CSS layout with grid and container queries
  21. Browser rendering pipeline fundamentals
  22. Event loop and async patterns in the browser
  23. Keyboard and screen reader testing practice
  24. Server state versus client state patterns
  25. Component tests that query like a user
  26. Profiling with browser developer tools
  27. Adopting a query cache for data fetching
  28. Choosing a styling approach
  29. Responsive image pipeline
  30. Route-based code splitting
  31. Accessible forms with clear validation
  32. Fixing layout shift and hydration mismatches
  33. Internationalisation and right-to-left readiness
  34. Third-party script audit and governance
  35. Redesign launch behind a feature flag
  36. Framework major version upgrade
  37. Accessibility conformance report for a customer
  38. Dropping support for an old browser
  39. Backend engineer's first quarter on the frontend
  40. Sole frontend engineer at an early-stage startup
  41. First frontend job after a bootcamp or degree
  42. Inheriting a jQuery or server-templated frontend
  43. Client marketing site build and handover
  44. Moving onto the design system team
  45. Micro-frontends fit assessment
  46. Offline-capable progressive web app
  47. Content Security Policy for the frontend
  48. Virtualised rendering for large lists and grids
  49. Real-time collaborative interface with optimistic updates
  50. Embeddable widget for third-party sites

Where it starts.

Each project arrives with its purpose, milestones and first tasks written out. Here is how the first three read.

Supported browser and device matrix

Arguments about whether a bug matters usually come down to nobody having written down which browsers and devices are supported. Pulling the real mix from your analytics, then agreeing a short matrix of browsers, versions, screen widths and one or two reference phones, turns every later quirk into a clear in or out call and feeds your build target settings.

First tasks

  • Export the last 90 days of browser and device share from analytics
  • Draft a matrix with versions, screen widths and two reference phones
  • Agree the support cut-off rule with the product owner
  • Update the build tool browser targets to match the matrix

Rendering mode and framework decision

Choosing between a client-rendered single-page app, server rendering, static generation or an islands approach decides your hosting, your SEO, your first-load speed and how hard data fetching will be for years. Writing the decision down with the trade-offs, before the codebase grows around a default, saves a painful rewrite when search traffic or slow first loads become a problem.

First tasks

  • List every page type and mark whether it must be indexable
  • Compare two or three rendering options on speed, SEO and hosting cost
  • Write the decision and its trade-offs as a short decision record
  • Deploy one proof of concept page with the chosen approach

Component and feature folder conventions

Frontend repositories drift into a components folder with four hundred files and three different ideas of where hooks, styles and tests live. Agreeing a feature-first folder layout, naming rules and a clear line between shared UI components and feature code makes the codebase navigable for the next engineer and keeps imports from tangling.

First tasks

  • Sketch the current folder tree and mark the confusing parts
  • Write a one-page layout guide for features and shared components
  • Configure import path aliases in the bundler and type checker
  • Move one feature into the new layout as the reference example

Make it yours.

Install Frontend Web Engineering, then tell Aurum the date you're aiming for. It checks whether the plan fits the weeks you actually have.

Free · Mac (Apple silicon) and Windows · v1.0.0 · Other platforms

Blueprints are general information to help you organise your own work. They are not medical, financial, legal or other professional advice. See the Terms.