Reactive Web: The Next Generation of Web Apps

We’re proud to announce a whole new way of building highly performant and scalable applications. 

Using client-side development and a single codebase, you can create rich and engaging interfaces with a new type of web application that consolidates the development experience across mobile and web.

A revolutionary way of creating web applications

Reactive web apps give you the best of mobile apps with improvements that make creating web and mobile apps a lot easier. We’ll go into these them further ahead, but first here’s what we’ve brought from mobile to web.

Performance improvements

All UI elements in reactive web apps update immediately when the data they are bound to changes, instantly changing the interface. No more need to use Ajax Refresh; the apps are smart enough to understand what needs to be changed.

Client-side logic

In reactive web apps, all client-side logic can be visually modeled. Hard-to-maintain JavaScript will be a thing of the past. You can use the same logic construct across client and server actions. You have the full flexibility to create any kind of business logic. For client actions in the browser, calling server-side logic is just a drag-and-drop away. OutSystems generates and secures REST APIs behind the scenes to support communication between browser and server, using only the minimum network bandwidth required for the actual data transfer.


Asynchronism in server communication keeps your apps always responsive. For example, while an app is executing a server-side action, it continues to run and respond to user input in the browser.


OutSystems warns you whenever you accidentally create some scalability anti-pattern. For example, when you call a server action inside a loop, do something that might delay screen rendering, or sequentially call server actions, OutSystems suggests alternatives for the best performance of your apps.

A state-of-the-art runtime architecture

Reactive web apps use a modern runtime architecture built on industry standards and best practices taken to the limit. Most code and resources are cached in the browser, eliminating the communication overhead for the majority of user interactions. The UI is rendered in the client-side. All screens, blocks, and widgets are generated as reusable React components. Secure and fast REST APIs to handle communication are automatically generated from the actions defined in the IDE.

Data fetching

Instead of using Preparation, you’ll find screen data directly below the screen. Screen data is composed of aggregates, data actions, and variables. Aggregates provide easy access to entities’ data, while data actions can be used for more advanced cases, like fetching data from external services. All these are executed asynchronously and in parallel. This will improve your app’s UX, since there is no need to wait for all data to arrive before starting to display the page.

New capabilities introduced with Reactive Web

A Unified OutSystems UI framework

OutSystems UI Mobile is now called OutSystems UI. This is a big update to support the development of reactive web and mobile applications, a single UI framework for all your apps!

See more about the new framework in the OutSystems UI website.

Screen Aggregates and Data Actions scope improvements

We made data fetching straightforward to use in mobile and reactive web apps. Screen Aggregates and Data Actions are now available in the scope of other Screen Aggregates and Data Actions. For example, dropdowns that depend on other dropdowns’ selected values? No problem! Now you will be able to filter any aggregate using the results of another one. The platform will automatically understand the order in which these requests need to be done.

Fetch on Demand

We also added the Fetch property with On Start and On Demand options to Screen Aggregates and Data Actions. Now you can implement patterns such as master/detail with an excellent performance and user experience.

Client Variables

Create Client Variables in Mobile and Reactive Apps. Yes, that’s right. This will be useful to store interface state like a filter or to cache user information that you don’t want to fetch from the server all the time.

Default Buttons

Button widgets in mobile and reactive web apps now have the Is Form Default property, which you can set to Yes and have the App submit the data from the related form when the end-user presses the Enter key.

Table widget with simple Sorting

A new Table Widget comes with an accelerator: drag an Entity to it to create a table with sorting and pagination. Use tables to show data in cells distributed in rows and columns.

Start Index in Screen Aggregates for Pagination

Use the server-side pagination feature of the Screen Aggregates to build faster apps that need to handle large data sets. Enter the Start Index and fetch the number of records you define in Max Records.

Native Dropdown widget

The Dropdown Widget has a new property Options Content, which you can set to Text Only or Custom. Text Only gives a native look and feel of the dropdown lists in your reactive we and mobile apps. Set Options Content property to Custom to build a dropdown with a list of images or other widgets.

Download files

You can drag a Download Tool logic node to your Flow and create a node which, when executed, sends a file for download to the end-user.

New Library module type

Start building great applications with a solid architecture, right from the very start. Take advantage of the new Library module, that guides you through the process of laying down the building blocks of your application. Libraries can be used in both reactive and mobile apps.

Reactive in the Forge

In the Forge, you’ll have a new filter for the type of component “Reactive”. These share most of the same underlying technology as the mobile ones so, if you find a mobile component (not requiring native capabilities) that you would like to use in your apps, it is possible to convert it to a reactive component. With the help of the community, we expect the list of available reactive components to grow pretty fast.

Optimized Network Payloads

We improved the efficiency of the data exchange between the server and client-side for reactive web apps, by ensuring the client-side receives only the data it really needs. This is another step in making reactive web apps that focus on client-side development paradigm, even faster and snappier.

Reuse Logic and Data

If you have existing traditional web applications you’ll be able to reuse their entities and server actions. All your backend logic, data, and services can be leveraged across all channels.

Create awesome experiences for your users

It all boils down to what can you do for your users. You have to experience these new apps to understand how users delight in smooth transitions and fast response times. And all of this without JavaScript, only with easy-to-change visual low-code.

This is quite a revolution, and there is a lot more we intend to do with Reactive Web, but your help is crucial.

Please share your feedback by replying to this post. The good and the bad alike. We’re here to learn and evolve with you.

Rank: #160

Great news, let's dig in and start learning how to do it.

Rank: #75

I've been waiting for this one! Can't wait to build my first reactive web app!

I also cannot wait.  I hope there will be a guided path for it or replaced the current guided paths 

Thanks,  I have to wait till my personal enviroment is upgraded so I opened a support case for it. 

Which page do you mean with the platform page ? 

Rank: #19
Rank: #4

Been waiting this for so long! Awesome job guys! 

Rank: #487

Finally!! :D 

Rank: #75

An important step towards bringing mobile and web app development closer together! Congrats guys!

Rank: #591

This is incredible, exciting news!

Rank: #400

Awesome! Great news!

Rank: #618

I am really impressed with Outsystems's evolution. This will really make things a lot easier for us developers, and help us provide a better experience for our clients.

Congrats for the Outsystems Developers Team, this is quite an advance. Keep up with the good work.

Rank: #223

Great news! Congrats! 

Congrats. Doing the guided paths right now and found no wierd things.

Rank: #376

Great, can't wait to play with these new tools

Rank: #260

I just finished the upgrade... 

I can't wait to do the course.

Anyone already trying stuff ?

I'd love to hear.

Rank: #19

It is like OutSystems Mobile, without local storage, without offfline support and a new concept called client parameters which is the client side equivelant of session parameters.

Rank: #51902

This was the expected roadmap. Great News.

Rank: #28361

Can we also create/add our own custom ReactJS component or existing npm ReactJS components?

Rank: #409

Hi Tiago,

By the way, what relation these Reactive Web Apps (RWAs) have with the hype around Progressive Web Apps (PWAs)?


Is this a starting point for OutSysytems to support full PWAs in the future?



Rank: #110

Wow... "Fetch on Demand". A very nice feature.

Cool features... This is clearly evident that how Outsystems is transforming to next gen development....

Rank: #693

Great news.


Rank: #751

It's a great improvement!! I can't wait to "reactive" my apps :D

So far I have made a short test in my personal enviroment, and, althougth it's a great advance, I see some little disadvantages regarding classic web apps:

- Locale is not persisted between calls to server actions (there is an idea submited for this: LINK), so, we should set locale in each call to server actions in which we retried some translated text (literals, static tables, etc)
- There is no multilingual resources like classic web apps. So I suppose we should translate apps like classic mobile apps (translating literales one by one, creating a json resources, and using multilingual component), which is much more complicated
- There is no server session properties. There is a new client side properties (what is great!) but in some scenarios are useful to have server side properties. And, with the new reactive apps, values are not preserved between calls (like locale set)
- The patterns are the same that mobile patterns. This is great, and has sense to have common components (the new "libraries"), but there are some "classic web" patterns missing, like editable tables, radio buttons, etc...
- I have no make several test, but seems there is no easy way to migrate classic web apps to reactive apps. I have test to copy things from classic web apps to reactive web apps, and nothing can by copied, not even one container. So I believe that we should recode full apps, shouldn't we?

In any case I think it is a great step to improve the classic web applications, which were already a bit outdated. Thanks for work guys!

Rank: #19

Hi Carlos,

Instead of session variables you have client variables  which you could also use to store the locale. You could do this in the OnApplicationReady Client system event.



Rank: #751

Hi Taigo and Danië, thanks for answers, really!! :D

 About persist locale, It does not work just by reading the client side properties on the server side (which would be helpful!). If you take a look the IDEA posted in outsystems forums (LINK), the problem is locale is not persisted (as they do other things like tenantId or UserId) between servers calls when you call from mobile side or reactive app. 

This is a big problem when you have a Core Module, that returns literals or have static tables and both have translations resources. Image a multilingual app, and a French user (for example): as the "locale" does not persist, you need to pass a parameter with the locale that you want (fr-Fr, or, in the future, read client side variable in server side, as you told) and make a "SetCurrentLocale" each time you need to call a server action (and this server action returns translatable things). 

And this is also a problem with an aggregate in client side window that join an static table that are in a core module and have translations, because you are not able to "set server side locale" before executed and always is return the "labels" in the default platform language; the only workarround I have found is tranform in fetch data and set locale first. 

All this it is better explained in the idea, even with a demo project... The usual case would be that when a user chose the language or logged in, if he set the language, you call to an server action to make a SetCurrentLocale and this persisted during the session between all calls to server side... I really hope that in the near future the locale that is set in a server action persists, as it does when perform a switch tenant, for example.

Anyway, as I said, this evolution in web applications with Reactive Apps is excinting, so thank you very much for that :-)

Rank: #20

Got it, you are right. I’ve changed the status of your idea to “on our radar”, so we can keep an eye on it. Thanks. 

Rank: #751

Regarding the new client side variables

I remember that it was a bad practice use a lot session variables (or populate with bigger content) because this was stored in datebase and loaded in each page load, will you use them or not.

Now, with the new client side variables, we should try not to abuse them like old session variables? or its use is much more optimal because are client side variables?

And, a question regarding the functionality you mentioned that will arrive shortly, that we would use the client variables on the server side: this means that are going to be send it in each call to server side? and this means that we should use them with caution because could impact in performance if we assign big data in them? Or may be they will have some kind of optimizations to avoid bad performance send in each call?



Very exciting! I am particularly interested in the removal of Ajax refresh. Can't wait to get my hands dirty...

Rank: #777

Great news, can't wait to try out!

Rank: #751

Really cool!

Another two questions about the Reactive apps:

- There is any reason to not have local storage in new libraries modules?Are they expected to be in the future?

- I have observed that there are no entry points in Reactive Apps. When I need to call from one end user module to page of another end-user module I use entry points with GetEntryURL to avoid coupling between modules (4 layers canvas rules, avoid calls between end-users modules)... What should be the mechanism now to do this without entry modules?

Again, thank you so much ;-)