Reactive vs Traditional web - Gap Analysis Document


The reactive web is taking its first steps, but right now it's not fully mature and doesn't have all the functionalities of the traditional web.

It would be great to have a gap analysis document which states what is now missing from Reactive compared with the Tradicional web. It would help to make the decision whenever a new application is going to be created. Should we go for Reactive or Tradicional?

Example: Lifetime analytics not fully working in Reactive. Translations are not yet ready in Reactive. Etc.

Created on 22 Nov 2019
Comments (10)

Hello Rui,

We are preparing documentation to help users who want to migrate an existing Traditional Web App to a Reactive Web App. It may answer some of the questions you have about the topic.  I am sharing here four documents, and I invite you and other users to provide feedback.

The most technical document:

There are also:

Please have a look and let us know:

  • Which parts might need more content
  • What sections are not clear
  • What other topics we could cover


These are the pending improvements:

  • OutSystems UI vs OutSystems UI Web reference
  • Information about HTTPRequestHandler
  • Send Email Tool and a workaround with a webservice
  • Adding more rationale to some sections, in particular for On Session Start
  • Creating custom JavaScript for functionalities such as string splitting
  • Links to (improved) documentation topics

Hi Romeo!

Thanks for providing such great content! 

But I think we're not quite really there. =)

The quick GAP analysis reference sheet is something that would be greatly appreciated. 

Hi Rui,

A quick note, not about documentation but about making a decision. Unless your app:

- is a public website without authentication where google ranking is critical (aka SEO)

- you will be needing a lot of custom UI components that are only available in traditional 

There is little reason to go with traditional. 

The secret here is that this is not a completely new stack, it’s the same mature underlying technology that powers mobile apps, some of them with millions of users. But without the headaches of plugins, offline synchronization or App Store certificates. Having someone on the team with mobile experience helps, but after the first couple of weeks you’ll probably never want to go back. We’ve been having great feedback, we were expecting a lot more “change aversion”.

Regarding analytics in particular, and while there is no out of the box solution, it should be trivial to get the screen logs and multiply time x frequency. Also, because you can check the server calls on google chrome inspector, performance bottlenecks should be a lot more straightforward to troubleshoot.

In any case let me assure you that we will continue to work actively in Reactive (and its docs) based on user feedback.

So thanks very much for it and keep it coming.


Tiago Simões

PS: Romeo, we should add a note about analytics, troubleshooting and SEO on docs. A GAP reference sheet sounds good.

Changed the category to Frontend

+ 1


GAP analysis document will be great.