English:Web Application Development
Web Application Development
Introduction
Web applications are software systems that you use through a web browser. They range from simple interactive tools to learning platforms, online shops, social networks, dashboards, and collaborative applications. Building them requires more than writing code: you need to understand how browsers, servers, networks, interfaces, data, security, accessibility, testing, and teamwork fit together.
This aiMOOC is designed for Grades 11–13. It assumes that you can use files and folders confidently and that you have some experience with logical problem solving. Previous programming experience is helpful but not required. By the end of the course, you should be able to explain the architecture of a web application, create a small front end, connect it conceptually to a back end and data store, test your work, and justify design decisions involving usability, accessibility, performance, security, and maintainability.
The image above shows a typical client–server exchange during web browsing. A browser sends a request to a server, and the server returns a response. Real web applications extend this basic pattern with databases, APIs, authentication, caching, background services, and many other components.
Learning Goals
After working through this course, you should be able to explain the difference between front-end and back-end development; describe the roles of HTML, CSS, JavaScript, HTTP, DNS, APIs, servers, and databases; build semantic page structures; style responsive layouts; add browser-side interaction; reason about data flow between client and server; use developer tools and version control; apply basic accessibility and security principles; test a web application systematically; and plan a small project from requirements to deployment.
A strong web developer does not only ask, “Does it run?” You also ask, “Is it understandable, usable, accessible, secure, maintainable, efficient, and appropriate for the people who will use it?”
How a Web Application Works
Client, Server, Request, and Response
A client is software that requests a resource or service. In ordinary web use, the client is usually a browser. A server is a program running on a computer that listens for requests and returns responses. The client–server model separates the user-facing part of an application from services and data that may run elsewhere.
When you enter a web address, several steps may occur. The browser identifies the host name, obtains a network address through the Domain Name System, establishes a connection, sends an HTTP request, receives an HTTP response, interprets the returned resources, and renders the interface. Modern sites often request additional resources after the first page has loaded.
DNS and Web Addresses
The Domain Name System (DNS) maps human-readable domain names to information needed to locate services on networks. It is hierarchical: names are resolved through a distributed system rather than one central global list. A URL can also identify a scheme such as HTTPS, a host, a path, and optional query information.
For example, in a conceptual address such as https://example.org/catalog?item=42, HTTPS describes how the browser communicates securely, example.org identifies the host, /catalog identifies a path, and the query string provides extra information to the application.
HTTP and HTTPS
HTTP is the application-layer protocol commonly used for communication between web clients and servers. A request includes a method, target, headers, and sometimes a body. A response includes a status code, headers, and sometimes a body. Common methods include GET for retrieving representations and POST for submitting data or requesting processing.
HTTPS is HTTP carried over a cryptographically protected connection using TLS. It helps protect confidentiality and integrity while data moves between endpoints and helps the client authenticate the server through certificates. HTTPS does not automatically make application logic secure; developers must still handle authentication, authorization, input, output, sessions, dependencies, and stored data carefully.
Static and Dynamic Content
A static resource can be served in essentially the same form whenever it is requested. A dynamic response is generated or modified using application logic, user state, database content, time, permissions, or other inputs. Many real systems combine both: static images and style sheets may be served directly, while account pages or search results are generated dynamically.
Think of a school portal. The logo may be a static file, but your timetable is dynamic because it depends on your identity and current data.
Front-End Development
The front end is the part of a web application that runs in or is rendered by the browser and that users directly perceive and operate. The core technologies are HTML for structure and meaning, CSS for presentation and layout, and JavaScript for behavior and application logic in the browser.
HTML: Structure and Meaning
HTML describes the structure and semantics of web content. Good HTML identifies headings, paragraphs, navigation, forms, buttons, images, tables, and other content according to meaning rather than appearance alone. Semantic structure improves maintainability and often supports accessibility technologies.
A small semantic fragment could look like this:
<main>
<article>
<h1>School Event Planner</h1>
<p>Choose an event and view its details.</p>
</article>
</main>Notice that the elements describe roles in the document. Visual appearance should normally be controlled with CSS rather than by choosing HTML elements only because of how they happen to look.
CSS: Presentation, Layout, and Responsive Design
CSS controls presentation: colors, spacing, typography, borders, alignment, animation, and layout. Modern CSS includes powerful layout systems such as Flexbox and Grid. A well-designed style system uses reusable rules and avoids unnecessary duplication.
Responsive web design adapts an interface to different viewport sizes and device capabilities. It does not mean shrinking a desktop layout until it barely fits. Instead, content, spacing, navigation, and layout should reflow so that the interface remains usable.
A mobile-first approach starts with a simple layout for constrained screens and progressively enhances it when more space is available. Relative units, flexible layouts, appropriate breakpoints, and responsive media are common techniques.
JavaScript: Behavior and Interaction
JavaScript is the main programming language executed by web browsers. It can respond to events, validate inputs, update the interface, request data, manipulate objects, and coordinate application state.
A simple browser-side interaction can select an element and react to a user action:
const button = document.querySelector("#show-message");
const output = document.querySelector("#message");
button.addEventListener("click", () => {
output.textContent = "The interface changed without reloading the whole page.";
});JavaScript is powerful, so structure matters. Use clear names, small functions, consistent formatting, and separation of concerns. Avoid putting unrelated logic into one large block.
The Document Object Model
When a browser parses HTML, it creates a structured representation called the Document Object Model (DOM). JavaScript can read and modify this tree. Changing the DOM can change what a user sees and how the page behaves.
DOM manipulation is central to interactive front ends. However, developers should avoid unnecessary updates, preserve accessibility information, and ensure that keyboard and assistive-technology users can still operate dynamic controls.
Back-End Development and Data
The back end is server-side application logic and infrastructure. It can process requests, apply business rules, authenticate users, authorize actions, communicate with databases and other services, generate responses, and record events. Back ends can be written in many programming languages and frameworks; the important concepts are largely transferable.
Routes, Endpoints, and APIs
A server usually maps incoming requests to application logic. A route describes a pattern that the application recognizes, while an endpoint is an address through which a client can interact with a service. An API is an interface that defines how software components communicate.
Web APIs often exchange structured data. JSON is a common text-based data format because it maps naturally to objects, arrays, strings, numbers, Boolean values, and null. An API contract should clearly define expected inputs, outputs, error behavior, and authorization requirements.
For example, a client might request a list of school events. The server could verify permissions, read records from a database, transform them into a suitable representation, and return JSON. The browser would then render the data into the interface.
Databases and Persistence
A database stores information that should remain available beyond a single page load or process. Relational databases organize data into tables connected through keys, while other database models use documents, key–value structures, graphs, or other representations.
Good data modeling identifies entities, relationships, constraints, and valid states. In a school event system, possible entities include users, events, rooms, and registrations. A database should enforce important constraints where appropriate rather than relying only on the interface.
Application code should use safe parameterized database operations instead of constructing commands by combining untrusted input into query strings.
State, Sessions, and Authentication
HTTP interactions are independent unless an application introduces a way to associate requests with state. Applications may use cookies, server-side sessions, signed tokens, or other mechanisms to maintain a user's authenticated context.
Authentication answers, “Who are you?” Authorization answers, “What are you allowed to do?” These are different. A user may be correctly authenticated but still lack permission to edit another user's account or access an administrator function.
Sensitive session identifiers should be protected, renewed appropriately, and invalidated when necessary. Applications should minimize the amount of personal information they collect and should define why each data item is needed.
Architecture and Separation of Concerns
A maintainable application separates responsibilities. The browser should not be trusted to enforce security-critical rules because users can modify client-side code and requests. The server should validate important assumptions independently.
A simple architecture might contain a presentation layer, application or service layer, and data-access layer. Larger systems may divide responsibilities into multiple services. More services do not automatically mean better architecture; additional components create operational and communication complexity.
Useful architectural questions include: Where is state stored? Which component owns a rule? What happens if a dependency is unavailable? How are errors represented? Which actions require authorization? How will the system be tested and monitored?
Accessibility and Inclusive Design
Web accessibility means designing and developing websites and web applications so that people with disabilities can perceive, understand, navigate, interact with, and contribute to the web. Accessibility also often improves usability for people on small screens, with temporary limitations, in noisy environments, or with slow connections.
Use semantic HTML before adding custom behavior. Associate labels with form controls. Provide meaningful alternative text for informative images. Ensure that interactive elements can be operated by keyboard. Preserve a logical focus order. Use sufficient contrast. Do not communicate essential information through color alone. Provide captions or transcripts when needed.
Accessibility should be considered from the beginning of a project rather than treated as a final repair step.
When you test an interface, use automated checks as helpers, not as substitutes for human evaluation. Try keyboard-only navigation, zoom, different viewport sizes, and where possible screen-reader testing. Ask whether the task can be completed, not merely whether the page passes a scanner.
Security and Privacy by Design
Web applications receive untrusted input from users, browsers, files, APIs, and networks. Treat all externally supplied data as potentially malformed or malicious until it has been validated for the specific context.
Important security practices include using HTTPS; applying authentication and authorization on the server; validating input; encoding output appropriately; using parameterized database operations; protecting sessions; limiting privileges; storing secrets outside public source code; keeping dependencies updated; logging security-relevant events; and handling errors without exposing sensitive implementation details.
Security also includes design choices. If a feature does not need sensitive data, do not collect it. If an account does not need administrator privileges, do not grant them. If an operation is destructive, make the user's intention clear and consider recovery.
A common mistake is to confuse client-side validation with security. Browser validation improves user experience, but a malicious client can bypass it. Server-side validation is still necessary.
Testing and Debugging
Testing answers different questions at different levels. A unit test checks a small piece of logic in isolation. An integration test checks whether components work together. An end-to-end test exercises a user flow through a larger part of the system. Manual exploratory testing helps reveal unexpected behavior that scripted tests may miss.
Browser developer tools help you inspect the DOM, CSS rules, network requests, console messages, storage, performance, and accessibility information. When debugging, first make the problem reproducible. Then reduce the problem, form a hypothesis, gather evidence, test one change at a time, and verify that the fix does not create a new problem.
A useful bug report states the environment, exact steps to reproduce the problem, expected behavior, actual behavior, and relevant evidence such as error messages or network responses.
Version Control and Collaboration
Version control records changes to source files so that teams can review history, compare versions, work on separate branches, and integrate changes. Git is a widely used distributed version-control system.
A good commit is focused and explains a meaningful change. Teams often use branches and pull or merge requests to review work before integrating it. Code review is not only about finding mistakes; it also spreads knowledge and improves consistency.
Never commit passwords, private keys, access tokens, or other secrets into a repository. Removing a secret from the latest version may not remove it from repository history, so exposed credentials generally need to be revoked or rotated.
Performance, Reliability, and Deployment
A web application should deliver useful content efficiently. Large images, unnecessary scripts, repeated network calls, expensive database operations, and excessive client-side work can slow an application.
Performance is not only a technical score. It affects whether users can complete tasks, especially on older devices or limited networks. Optimize the resources that matter to the actual user journey. Measure before and after changes.
Deployment is the process of making an application available in a target environment. A professional workflow usually distinguishes development, testing, and production concerns. Configuration such as database addresses or service credentials should be handled through environment-specific mechanisms rather than hard-coded into source files.
Reliability requires thinking about failure. What should happen if the database is temporarily unavailable? What if a request times out? What if invalid data reaches the server? Good systems fail predictably, communicate useful errors to users without exposing secrets, and record enough information for developers to diagnose problems.
A Practical Development Workflow
A manageable school project can follow an iterative workflow. Begin with a concrete user need. Write a small set of requirements and acceptance criteria. Sketch the interface and data flow. Build a minimal version. Test it with realistic tasks. Improve accessibility and error handling. Add automated tests for important logic. Review security assumptions. Use version control throughout. Deploy a working version. Then reflect on what should change in the next iteration.
For a project such as a school event planner, a first release might allow users to view events. A later iteration could add filtering, registration, organizer roles, capacity limits, accessible forms, and notifications. Each addition should have a reason, a testable requirement, and a clear owner in the architecture.
Careers and Transferable Skills
Web application development connects Computer science, Software engineering, User experience design, Database, Computer network, Cybersecurity, Web accessibility, and Project management. Relevant roles include front-end developer, back-end developer, full-stack developer, software tester, DevOps engineer, UX engineer, accessibility specialist, security engineer, data engineer, and technical product roles.
The most transferable skill is not memorizing a framework. It is learning how to decompose problems, read documentation, test assumptions, communicate decisions, and learn new tools while preserving sound principles.
Interactive Tasks
Quiz: Test Your Knowledge
Which technology primarily gives web content its semantic structure? (HTML) (!CSS) (!DNS) (!SQL)
What is the main role of CSS in a web application? (Presentation and layout) (!Resolving domain names) (!Storing database records) (!Authenticating servers)
What does the browser build from parsed HTML so that scripts can access page elements? (Document Object Model) (!Domain Name System) (!Transport Layer Security) (!Database schema)
Which statement best describes HTTPS? (HTTP over a TLS protected connection) (!A database query language) (!A JavaScript testing framework) (!A replacement for DNS)
What is authentication mainly used to establish? (The identity of a user) (!The visual layout of a page) (!The size of a database) (!The order of CSS rules)
Why must important input validation also occur on the server? (Client checks can be bypassed) (!Servers cannot receive text) (!CSS prevents invalid requests) (!DNS validates form fields)
What is a common purpose of a web API? (Communication between software components) (!Choosing a font family) (!Drawing a page border) (!Compressing an image manually)
What is a key goal of responsive web design? (Usable layouts across different viewport sizes) (!Identical pixel dimensions on every device) (!Removing all images from mobile pages) (!Keeping navigation fixed to desktop width)
What does version control help a development team manage? (Changes to source files over time) (!Only browser bookmarks) (!Only production passwords) (!Only database passwords)
Which testing level checks a complete user flow through much of an application? (End to end testing) (!Color testing) (!DNS testing) (!Markup naming)
Memory Game
| Client | Software that sends requests for resources or services |
| Server | Software that receives requests and returns responses |
| DOM | Browser representation of a parsed document as objects |
| API | Defined interface for communication between software components |
| DNS | Distributed system that resolves domain names |
| Repository | Version-controlled storage for project files and history |
| Endpoint | Address through which a client can access a service |
Drag and Drop
| Match the correct terms. | Topic |
|---|---|
| Semantic HTML | Meaningful page structure |
| Responsive CSS | Adaptive visual layout |
| JavaScript events | Browser interaction handling |
| Server authorization | Permission enforcement |
| Automated tests | Repeatable behavior checking |
...
Crossword Puzzle
| Browser | Which program usually acts as the client that renders a web interface? |
| Server | Which system receives web requests and returns responses? |
| Stylesheet | What kind of file commonly contains CSS presentation rules? |
| JavaScript | Which browser language commonly handles interactive behavior? |
| Database | What stores persistent structured application information? |
| Responsive | Which adjective describes a layout that adapts to viewport size? |
LearningApps
Cloze Text
Open-Ended Tasks
Easy
- Interface inventory: Choose a web application you use regularly and identify at least six visible interface elements. For each one, explain whether HTML structure, CSS presentation, JavaScript behavior, or a combination is probably involved.
- Semantic page sketch: Draw or digitally create a wireframe for a school club page and label the major semantic regions you would represent in HTML.
- Responsive observation: Open one public website at desktop and narrow mobile widths. Record three layout changes and explain why each change may improve usability.
- Developer interview: Interview a student, teacher, or professional who has built a website. Ask about tools, debugging, collaboration, and one mistake from which they learned.
Standard
- Accessible form prototype: Create a small form for event registration with clear labels, instructions, keyboard operation, useful error messages, and a short accessibility test report.
- Network request investigation: Use browser developer tools on a site you are allowed to inspect. Select several requests, classify their resource types, compare status codes, and explain what the evidence shows about page loading.
- API data prototype: Build a small interface that reads a local JSON file or a safe public learning API, presents selected fields, handles an error state, and documents the data flow from source to interface.
- Version control mini-project: Create a small repository for a web page, make several focused commits, use a branch for one feature, merge it, and write a reflection explaining what version control contributed.
Advanced
- Full-stack design brief: Design the architecture for a school event application with users, events, registrations, and roles. Produce a diagram, data model, API sketch, security assumptions, and test strategy.
- Usability study: Build a prototype, recruit several voluntary test users, give them realistic tasks, observe difficulties without coaching them through the interface, and turn the findings into prioritized design changes.
- Security review: Analyze a fictional or self-built web application for risks involving authentication, authorization, input handling, sessions, secrets, and data exposure. Propose mitigations and explain their limits without attempting to attack systems you do not own or have permission to test.
- Web development field study: Visit a local web agency, school IT department, digital lab, university computing unit, or comparable workplace, or conduct a remote interview. Create a short video or illustrated report comparing professional workflow with your school project workflow.
Learning Assessment
- Architecture explanation: Given a diagram of a browser, server, API, and database, explain the complete data flow for a user action and identify where validation and authorization should occur.
- Front-end transfer task: Transform a fixed-width page concept into a responsive and accessible design, then justify your HTML and CSS decisions with reference to user needs.
- Debugging case: Investigate a deliberately faulty web application, collect evidence from developer tools, identify the cause, implement a repair, and explain why the repair works.
- Data and API reasoning: Given a small API specification and data model, design two client requests and expected responses, including one error case and one authorization rule.
- Security and privacy review: Evaluate a proposed feature that collects user data, identify unnecessary data collection and security risks, and redesign the feature using data minimization and least privilege.
- Project defense: Present a working web application and defend key choices about architecture, accessibility, testing, performance, version control, and deployment in a short technical interview.
Evidence of Learning
Evidence of learning should show both what you know and what you can do.
| Area | Strong evidence |
|---|---|
| Knowledge | Accurate explanations of client–server communication, HTML, CSS, JavaScript, DOM, HTTP, DNS, APIs, databases, authentication, authorization, testing, and deployment |
| Technical skills | A working prototype with semantic structure, responsive presentation, interactive behavior, error handling, and an understandable project organization |
| Accessibility | Keyboard testing, meaningful labels and structure, appropriate text alternatives, readable content, and documented accessibility checks |
| Security reasoning | Clear identification of trust boundaries, server-side validation needs, authorization rules, session concerns, secrets handling, and data-minimization choices |
| Engineering process | Version-control history, focused commits, test evidence, reproducible bug reports, code review notes, and documented design decisions |
| Product evidence | Wireframes, architecture diagrams, data models, API sketches, source files, test reports, deployment notes, and a demonstration of the finished application |
| Transfer | Ability to apply the same principles to a new problem, unfamiliar framework, different device context, or changed user requirement |
OERs on the Topic
For additional open learning, explore Web application, Front-end web development, Web development tools, Hypertext Transfer Protocol, Domain Name System, Application programming interface, Database, Web accessibility, Computer security, Git, and Software testing.
Linked Learning Areas
Web application development links classroom learning with computing, design, communication, mathematics, ethics, and project work. You use abstraction when separating components, logic when defining program behavior, data modeling when designing persistence, communication skills when documenting and reviewing work, and ethical reasoning when handling user data and inclusive access.
aiMOOC Projects
_-_en.png){kind=link}
MOOCwiki · Deutsch
Nach dem Lernen ist vor dem Lernen
Entdecke direkt den nächsten Lernkurs. Weitere Inhalte erscheinen, wenn Du weiter nach unten scrollst.
Zur MOOCwiki-HauptseiteMediathek
Mediathek
Mediathek wird aus dem Wiki geladen ...
Keine passenden Inhalte gefunden. Bitte ändere Suche oder Filter.