Frontend development in 90 minutes

Summary

The course presents front-end development as a set of core browser and JavaScript concepts shared by modern frameworks. Its central message is that frameworks are useful abstractions, not magic: understanding HTML, CSS, JavaScript, browser behavior, and state updates makes it easier to use any framework and diagnose problems.

1. How a web application works

• A browser uses DNS to find a server, then sends it an HTTP request.
• Requests can include a URL, method, headers, and—when appropriate—a body. Responses include a status code, headers, and content such as HTML, JSON, JavaScript, CSS, or media.
• HTTPS adds encryption and server authentication through TLS, protecting data in transit.
• The browser parses HTML into the DOM and CSS into the CSSOM, combines them into a render tree, calculates layout, and paints the page. Large or complex DOMs can hurt performance.
• Resource loading affects rendering:
  • CSS can delay rendering while it is downloaded and parsed.
  • Default synchronous scripts pause HTML parsing while they download and run.
  • async scripts run when ready and can interrupt parsing; defer scripts wait until HTML parsing finishes.

2. Rendering strategies

• Multi-page applications (MPAs): The server returns a new HTML page for each navigation. This is straightforward, but full-page reloads and repeated server work can be inefficient for highly interactive sites.
• Single-page applications (SPAs): The browser receives an app shell, and JavaScript manages navigation and rendering. The app fetches data through APIs and updates the page without full reloads.
• Static site generation (SSG): Pages are generated at build time, making them fast to serve and suitable for relatively stable content. Client-side hydration can add interactivity after loading.
• Incremental static regeneration: Static pages can be regenerated after the initial build, balancing performance with fresher content.
• There is no universally best strategy; the choice depends on the application’s needs.

3. HTML and CSS fundamentals

• HTML provides structure; CSS controls appearance and layout.
• Prefer semantic HTML—such as header, nav, main, section, article, aside, and footer—over using only generic div and span elements. Semantic markup clarifies hierarchy and helps assistive technologies and search engines.
• Links support navigation; forms collect and submit user input. Links typically trigger GET requests, while forms can use methods such as GET or POST.
• Keep styling separate from content, generally in stylesheets rather than inline rules.
• CSS rules use selectors and declarations. Classes are useful for reusable styles; IDs can target specific elements. The cascade, inheritance, specificity, and importance determine which rule applies.
• Understand the box model: content, padding, border, and margin.
• Block elements generally occupy their own line; inline elements flow within text. CSS can change an element’s display behavior.
• Use Flexbox for one-dimensional layouts and Grid for two-dimensional layouts. Media queries and relative units help create responsive layouts.
• Maintainable CSS benefits from consistent naming conventions, organized stylesheets, and testing across screen sizes and browsers.

4. JavaScript and browser interaction

JavaScript adds behavior to web pages. The course demonstrates setting up a development environment with Node.js, npm, VS Code, and Vite, then building a counter and a to-do app.

Key practices and mechanisms include:

• Select DOM elements with methods such as querySelector and querySelectorAll.
• Attach event listeners and update the DOM in response to user actions.
• Use arrays and objects to represent application data, then render the interface from that data.
• Use event bubbling and event delegation to handle events from many child elements with a listener on a stable parent.
• Persist state in browser localStorage, or use fetch requests to store and retrieve it from a server.
• Avoid placing application variables in the global scope; use functions or ES modules to encapsulate code.
• Treat DOM elements and browser features as APIs, rather than assuming JavaScript itself provides every capability.

5. JavaScript concepts and runtime behavior

The deeper JavaScript section covers:

• Expressions and statements: Expressions produce values; statements perform operations.
• Equality and types: Prefer strict equality (===) to avoid unintended type coercion. JavaScript’s dynamic typing offers flexibility but requires care.
• Variables and scope: let allows reassignment, while const prevents reassignment of the binding, not mutation of an object’s properties. Scope can be global, function, or block-based.
• Hoisting and the temporal dead zone: Declarations are processed before execution, but accessing certain variables before their declaration can throw an error.
• this and arrow functions: A regular function’s this depends on how it is called; arrow functions inherit it from their surrounding lexical context.
• Language features: Object literals, destructuring, spread syntax, classes, prototypes, template literals, optional chaining, nullish coalescing, and collections such as Set and Map.
• Asynchronous code: Callbacks can become difficult to manage; promises and async/await make asynchronous flows easier to express. async/await does not make the underlying work synchronous.
• Functional programming: Functions are first-class values; higher-order functions, composition, currying, and closures enable flexible patterns.
• Runtime model: JavaScript execution uses a call stack, memory heap, runtime APIs, and an event loop. Long-running operations such as network requests can proceed without blocking the main execution thread. Promise callbacks and other microtasks are processed ahead of ordinary queued tasks.

6. TypeScript

TypeScript adds static checking and tooling to JavaScript, but browsers run the JavaScript output, not TypeScript directly.

A typical workflow is:

1. Write TypeScript files.
2. Compile or transpile them to JavaScript.
3. Run the generated JavaScript in the browser.

Main lessons:

• Add types to variables, parameters, and return values when useful; TypeScript can also infer many types.
• Use union types when a value may have several valid forms, and use type guards to narrow uncertain values.
• Avoid any because it disables type checking; prefer unknown when a value’s shape is not yet known.
• Keep type definitions readable. Avoid unnecessary nesting and overly complex unions, intersections, mapped types, or conditional types.
• Enable strict checking where practical.
• Use interfaces primarily for object shapes and class contracts; use type aliases for more flexible or complex types. Be consistent within a project.
• Types and interfaces are compile-time constructs; they do not exist as runtime objects.
• TypeScript also supports modules and can help produce JavaScript compatible with older environments.

7. Frameworks and their trade-offs

Frameworks help coordinate components, state, DOM updates, events, routing, and rendering. They reduce repetitive work, but their abstractions are easier to use when the underlying browser concepts are understood.

The course groups tools into established frameworks, newer approaches, meta-frameworks, and lightweight tools that add interactivity to mostly traditional pages.

• React: Large ecosystem and job market, but relatively unopinionated. Its rendering, hooks, side effects, and memoization can be confusing if its model is not understood.
• Vue: Approachable syntax, strong documentation, and a more guided approach; its job market is smaller than React’s in some areas.
• Angular: Comprehensive, TypeScript-oriented, and structured for large applications, but more complex and verbose.
• Svelte: Compiles components into direct DOM updates, often with concise code; its ecosystem and job market are smaller than those of established options.
• Solid: Uses fine-grained reactivity and avoids virtual-DOM diffing; it is performant but has a smaller ecosystem.
• Qwik: Focuses on resumability and loading code only when needed; it offers a different mental model and has a younger ecosystem.
• Astro: A meta-framework that can combine server-rendered or static pages with selected interactive components.
• Alpine, HTMX, and petite-vue: Lightweight options for adding interaction to existing HTML without adopting a full client-rendered SPA model.

The course’s practical recommendation is not to overfocus on choosing a “best” framework: the right choice depends on the project, team, and available opportunities.

8. Practical project: Astro and Solid bookstore

The demonstration builds a bookstore using Astro for page and server functionality and Solid for interactive components.

• Astro’s file structure maps page files to routes. Its front matter runs on the server and can prepare data or import components.
• A shared layout provides consistent structure and uses slots for page-specific content.
• Astro can render pages statically or dynamically. Its client directives hydrate selected components, creating “islands” of interactivity rather than shipping JavaScript for the whole page.
• Solid signals hold interactive state. Resources handle asynchronous data, and lifecycle hooks run code when components load.
• The bookstore loads books, displays cards, tracks borrowed books and cart state, and shows loading or empty states.
• Astro API endpoints handle actions such as borrowing or checkout, connecting front-end interactions to server logic.
• The cart fetches book details, calculates a total, and supports removal and checkout.

9. Building a tiny framework

The final exercise builds a small framework to show how common framework behavior can be implemented with ordinary JavaScript.

Its requirements and implementation are:

1. Reactive state: Create signal-like values that notify dependent work when state changes.
2. Dependency tracking: Use a proxy to intercept reads and writes, recording which rendered expressions depend on which state values.
3. Declarative bindings: Traverse the DOM for custom attributes, evaluate their expressions against state, and update text, HTML, or other attributes when dependencies change.
4. Event handling: Use event delegation from a common parent rather than attaching a separate listener to every element.
5. Server interaction: Allow event attributes to trigger fetch calls and update a selected part of the DOM from the response.
6. Lifecycle support: Include a simple load event when an element is first processed.
7. Encapsulation: Wrap the implementation in a function or module to avoid polluting the global scope.

The exercise demonstrates that frameworks differ in syntax and implementation, but they address recurring problems: tracking state, responding to events, updating the DOM, and coordinating client-server work.

Speakers and sources featured

• Speaker: One unnamed course instructor/narrator; no guest speakers are featured.
• Named technologies and frameworks discussed: HTML, CSS, JavaScript, TypeScript, Node.js, npm, Vite, VS Code, Astro, Solid, React, Vue, Angular, Svelte, Qwik, Alpine, HTMX, petite-vue, and browser APIs such as the DOM, fetch, and localStorage.