OutSystems 11 supports two web app types: Reactive Web (Single Page App — client-side rendering with Ajax) and Traditional Web (server-rendered pages). Reactive Web is the current standard for all new O11 projects and the only option in ODC. Traditional Web is a legacy architecture maintained for existing apps. If you are starting a new project in 2026, choose Reactive Web.
Two Architectures Within the Same Platform
This guide compares two app architectures that exist within OutSystems 11. This is a separate decision from the O11 vs ODC choice — once you decide to use O11, you still choose the app architecture. Reactive Web and Traditional Web share the same IDE (Service Studio) and data layer (entities, aggregates) but differ fundamentally in how screens are rendered, how actions run, and which UI components are available. ODC eliminates this choice entirely: it supports only Reactive Web and Mobile.
Prerequisites
- Basic understanding of OutSystems concepts (entities, screens, actions)
- Familiarity with Service Studio interface (see Service Studio Interface Guide)
- No build steps required — this is a decision guide
Step-by-step guide
Understand the Reactive Web Execution Model
Understand the Reactive Web Execution Model
Reactive Web apps are Single Page Applications (SPAs). The architecture works as follows: 1. The browser downloads the app shell (JavaScript/CSS) once on first load 2. All screen transitions happen client-side — no full page reloads 3. **Client Actions** run directly in the browser (no server round-trip) 4. **Server Actions** are called via Ajax and return structured data 5. **Data Actions** fetch data asynchronously — screens render with loading states while data arrives 6. The OutSystems Runtime generates TypeScript/JavaScript that runs in the browser **Result:** Fast, fluid user experience. Navigation feels instantaneous. Offline-capable with local variables and client-side logic. Mobile app development uses the same Reactive architecture. **In Service Studio for Reactive apps:** - Right-click screen → 'Add Client Action' (runs in browser) - Logic tab → Server Actions (server-side) - Logic tab → Roles (authorization checks) - Interface tab → UI Flows (route containers) - Preparation actions do NOT exist — use Data Actions instead
Expected result: You understand that Reactive Web apps are SPAs where Client Actions run in the browser and Server Actions use Ajax calls — no full page reloads happen during navigation.
Understand the Traditional Web Execution Model
Understand the Traditional Web Execution Model
Traditional Web apps are classic server-rendered applications. The architecture works as follows: 1. Every screen navigation triggers a full round-trip to the server 2. The **Preparation action** (unique to Traditional Web) runs on every screen load, server-side, before the HTML is sent to the browser 3. All actions (Web Actions, Screen Actions) run server-side — there is no client-side action type 4. Screen state is maintained via Session Variables (stored in server memory per user session) 5. Web Blocks (equivalent to Reactive Blocks) run their own Preparation actions 6. The OutSystems Runtime generates server-side .NET code and HTML **Result:** Every user interaction that changes data requires a server round-trip. This is slower for interactive, data-heavy interfaces but simpler for developers familiar with classic web development. **In Service Studio for Traditional Web apps:** - Screens have a Preparation action (unique to Traditional Web — not present in Reactive) - Logic tab → Web Actions (instead of Client Actions) - Session Variables available (Data tab → Session Variables) - Ajax Refresh: update parts of screen without full reload (limited client-side capability) - Widgets: Ajax Submit button, Web Service Actions, OnChange server-side events
Expected result: You understand that Traditional Web apps render on the server, have a Preparation action instead of Data Actions, and use Session Variables for user state.
Compare Key Technical Differences Side by Side
Compare Key Technical Differences Side by Side
| Aspect | Reactive Web | Traditional Web | |---|---|---| | Rendering | Client-side (SPA) | Server-side | | Navigation | No page reload | Full page reload | | Client actions | Yes — run in browser | No — all actions are server-side | | Data loading | Data Actions (async) | Preparation action (sync, server) | | Session state | Client Variables (localStorage) | Session Variables (server memory) | | Offline capability | Yes (local variables, client logic) | No | | Mobile reuse | Yes — same architecture | No | | PDF generation | Needs Forge component | HTMLToPDFConverter built-in | | SOAP exposure | Both | Both | | Legacy widgets | No | Yes (Ajax Submit, etc.) | | ODC compatible | Yes | No — ODC does not support Traditional Web | **The critical PDF difference:** Traditional Web has a built-in `HTMLToPDFConverter` action that converts screen HTML to PDF server-side. This does not exist in Reactive Web — PDF generation in Reactive requires a Forge component (e.g., Ultimate PDF).
Expected result: You have a reference table showing every significant technical difference between the two architectures for use in your decision-making.
Apply the Decision Criteria for New Projects
Apply the Decision Criteria for New Projects
For any new OutSystems project in 2026, the decision should almost always be **Reactive Web**. Here is when to consider Traditional Web: **Choose Reactive Web (the default choice) when:** - Starting any new project - Building a mobile app (required) - The project may need to migrate to ODC in the future - The app requires offline capability - The team prioritizes responsive, fast UI/UX - You want to use OutSystems UI patterns library (full support) **Consider Traditional Web only when:** - Maintaining or extending existing Traditional Web applications - Your team is deep in Traditional Web patterns and migration cost is high - You need the built-in HTMLToPDFConverter and cannot use Forge components - Your app has heavy session-state requirements built on Session Variables - You are implementing a server-rendered app for SEO requirements (note: OutSystems Reactive apps have limited SEO compared to traditional server rendering) **OutSystems' official guidance (2026):** New development should use Reactive Web. Traditional Web is considered a legacy architecture. OutSystems invests new features only in Reactive Web and ODC.
Expected result: You have a clear decision. For almost all new projects, Reactive Web is the right choice. Traditional Web is justified only for maintenance of existing apps.
Understand the Conversion Path
Understand the Conversion Path
Converting an existing Traditional Web application to Reactive Web is a significant undertaking — OutSystems does not provide an automated conversion tool. The process involves: 1. **Audit Traditional-only features in use:** Preparation actions, Session Variables, Ajax Submit buttons, HTMLToPDFConverter, server-side event handlers (OnChange server) 2. **Remap data loading:** Each Preparation action becomes a Data Action (Reactive) or Aggregate directly on the screen 3. **Replace Session Variables:** Identify what data is stored in Session Variables and move it to Client Variables (browser localStorage) or pass it as screen input parameters 4. **Recreate UI:** Traditional Web screen widgets cannot be copy-pasted into Reactive screens — the widget types differ. Rebuild UI in Reactive using the OutSystems UI component library 5. **Replace PDF generation:** HTMLToPDFConverter usages must be replaced with a Forge component (Ultimate PDF is the most popular) 6. **Test thoroughly:** Traditional Web and Reactive have different event firing sequences — logic that worked in Traditional may behave differently in Reactive **Realistic timeline:** A 10-screen Traditional Web app with moderate complexity: 2-6 weeks for an experienced developer. **Alternative to conversion:** For very large Traditional Web apps, run them in parallel with new Reactive modules. Build new features in Reactive and leave the old Traditional code in place until business justification exists for rewriting it.
Expected result: You understand that Traditional-to-Reactive conversion is a manual rebuild, not an automated migration. You have a realistic scope estimate and a strategy for managing the transition.
Complete working example
1=== REACTIVE vs TRADITIONAL WEB REFERENCE ===23REACTIVE WEB (choose this for new projects):4 - SPA — no full page reloads on navigation5 - Client Actions run in browser6 - Data Actions load data asynchronously7 - Client Variables for client-side state (localStorage)8 - OutSystems UI patterns library — full support9 - Mobile app architecture — same codebase10 - ODC compatible11 - PDF: needs Forge component (Ultimate PDF)1213TRADITIONAL WEB (use only for existing apps):14 - Server-rendered — full page reload on navigation15 - Preparation action runs before HTML is sent16 - Session Variables for user session state17 - Web Actions / Screen Actions (all server-side)18 - Ajax Submit for partial page updates19 - HTMLToPDFConverter built-in20 - NOT compatible with ODC21 - O11 only2223SERVICE STUDIO DIFFERENCES:24 Reactive screen → right-click → Add Client Action25 Traditional screen → has Preparation node by default2627 Reactive data → Aggregate + Data Action28 Traditional data → Aggregate in Preparation action2930 Reactive state → Client Variable (localStorage)31 Traditional state → Session Variable (server memory)3233ODC NOTE:34 ODC supports ONLY Reactive Web and Mobile.35 Traditional Web is OutSystems 11 ONLY.36 All new ODC apps are Reactive Web by default.3738EXPRESSION EXAMPLES (same in both architectures):39 If(User.IsActive, "Active", "Inactive")40 FormatDate(CurrDate(), "yyyy-MM-dd")41 Length(Trim(EmailInput.Value)) > 0Common mistakes
Why it's a problem: Looking for Session Variables in a Reactive Web app
How to avoid: Session Variables do not exist in Reactive Web apps or ODC. Use Client Variables (Data tab → Client Variables) for data that should persist across screen navigations, or pass data as input parameters when navigating to a screen.
Why it's a problem: Looking for the Preparation action in a Reactive Web screen
How to avoid: Reactive Web screens do not have a Preparation action. Data loading happens in Aggregates placed directly on the screen or in Data Actions. Right-click the screen → 'Fetch Data from Database' to create a screen Aggregate, or right-click → 'Fetch Data from Other Sources' for a Data Action.
Why it's a problem: Using HTMLToPDFConverter in a Reactive Web app
How to avoid: HTMLToPDFConverter is a Traditional Web feature and is not available in Reactive Web or ODC. Install the Ultimate PDF component from the Forge (or equivalent) for PDF generation in Reactive apps.
Why it's a problem: Creating a new project as Traditional Web in 2026
How to avoid: Traditional Web is a legacy architecture. When creating a new application in Service Studio, always select 'Reactive Web App' or 'Mobile App'. Traditional Web is only appropriate when explicitly extending an existing Traditional Web module.
Best practices
- Always use Reactive Web for new OutSystems projects — it is the standard architecture and the only option in ODC
- In Reactive apps, use Data Actions for async data loading instead of putting all queries in a single synchronous action
- Never store sensitive data in Client Variables — they persist in browser localStorage and can be inspected
- In Traditional Web, minimize Session Variable usage — session memory is shared across all users and can cause scaling issues
- If you must build Traditional Web, keep the Preparation action lightweight — heavy queries in Preparation slow the initial page render
- Use the OutSystems UI patterns library in Reactive apps — it provides 70+ accessible, responsive components that replace most custom widget work
- When planning a Traditional-to-Reactive migration, audit Session Variable usage first — this is typically the most complex refactor
Still stuck?
Copy one of these prompts to get a personalized, step-by-step explanation.
I have an OutSystems 11 Traditional Web application with 25 screens, a Preparation action on every screen, 12 Session Variables storing user context, and 3 usages of HTMLToPDFConverter. I want to migrate this to Reactive Web. Walk me through the migration strategy step by step, including how to replace each of these Traditional-only features with their Reactive equivalents.
In my OutSystems Reactive Web app, I need to load customer data on screen load and display it in a table. In Traditional Web I would have put an Aggregate in the Preparation action. What is the correct Reactive Web approach? Should I use a screen Aggregate or a Data Action, and what is the difference in the action flow?
Frequently asked questions
Can I have both Reactive and Traditional Web screens in the same OutSystems application?
No. When you create an application in Service Studio and choose 'Reactive Web App', all screens in that application must be Reactive. When you choose 'Web App' (Traditional), all screens are Traditional. The two architecture types cannot be mixed within a single module. You can have separate modules — one Reactive and one Traditional — within the same Application in O11, but they cannot share UI components.
Does Reactive Web have any SEO disadvantages compared to Traditional Web?
Yes. Reactive Web apps are SPAs (client-side rendered). Search engine crawlers index server-rendered HTML more reliably than JavaScript-rendered content. OutSystems Reactive apps do not have built-in server-side rendering (SSR) for SEO. For most internal business applications this is not a concern, but for public-facing marketing pages or e-commerce, this is a real limitation. Traditional Web is better for SEO because it sends fully-rendered HTML from the server.
Can Traditional Web apps be deployed to ODC?
No. ODC does not support Traditional Web architecture at all. ODC supports only Reactive Web and Mobile apps. If you have Traditional Web apps that need to run in ODC, you must first migrate them to Reactive Web. This is one of the key reasons many enterprises with Traditional Web apps are not yet on ODC.
What is the OutSystems UI patterns library and does it work with Traditional Web?
The OutSystems UI patterns library is a collection of 70+ pre-built, accessible UI components (Accordion, Tabs, Cards, Gallery, Wizard, etc.) maintained by OutSystems. It is designed for Reactive Web and Mobile apps. A separate (older) Silk UI library covers Traditional Web, but it is in maintenance mode and OutSystems does not invest new components in it. Another reason to choose Reactive Web for new projects.
Talk to an Expert
Our team has built 600+ apps. Get personalized help with your project.
Book a free consultation