Does outsystems have a challenge with .NET 5?

Recently Microsoft announced that its next release will be .NET 5  as a continuation of the .NET Core program. To avoid confusion wich .NET framework is the latest or applicable the .NET framework 4.7.2 or 4.8 will be the last version that will be released just as .NET Core 3.0 will be the last version.

As we all know Outsystems runs on the .NET Framework. The .NET Core variant does not support webforms just as .NET 5 will not support webforms.

Now don’t get me wrong. The .NET framework 4.7.2 is still supported  by Microsoft and is not being deprecated yet. But it won’t be developed actively anymore so we should not expect any new features on this framework.

Even though it isn’t deprecated and nothing has been said about that, we may assume it will be in the foreseeable future. This means that all webform outsystems applications are then no longer up to standard and working on a deprecated platform. This usually takes about 3 to 4 years. As an example the .Net 4.5.1 released in 2013 was deprecated in 2016.

So I was wondering how outsystems is going to solve this in the future. Maybe converting webform applications to MVC (if that would even be possible) or use the framework “React” in there webapplications interfacing it with the backend or maybe they just end the support and you may rebuild your work on a new platform. Outsystems 12 maybe? And wat about applications you are building right now in ousystems 11?

Would be nice to know the direction outsystems is taking.

Recources:         

https://devblogs.microsoft.com/dotnet/introducing-net-5/

https://en.wikipedia.org/wiki/.NET_Framework_version_history

Hi Danny,

We're currently modernizing our stack and working on the next generation of web apps. Stay tuned, because we'll have more news very soon.

Kind regards,

Ricardo Alves

Hi Danny,

One of the biggest advantages of using OutSystems is that you are not blocked by a technology, because the logic that is today converted into .net code can tomorrow be converted in something else.

So, I would be more worried about being stucked with a outdated technology if i had created the code myself on a non low code platform.


Hi Ricardo,


I'm sorry but I do not agree with you. The current stack where outsystems works on is going to be out of date / deprecated in the future. This means dat that your low code application is being converted into a outdated stack and that is a problem since security issues will also not be resolved by the stack provider. Outsystems can change the stack (That I do agree with you) but it is a challange becaus the webforms technologie is not available in the future .NET stack and there are no other technologie stacks that work on the same principle as webforms does.

If outsystems decides to convert it into a NodeJs or .net MVC or maybe even PHP it would be a challenge to convert already built applications, hence the question. 

Does outsystems have a challenge with .NET 5?

Hi Danny,

From what i have heard OS is moving towards React. The mobile applications are already based on it. 

I hope to hear more on Next Step, because i think it's a valid concern you have here. Will you be there as well?


Danny, your OutSystems applications are not web forms applications, neither are them .NET applications. You're developing applications in a higher layer, which by chance compiles down to a .NET application and web forms.

If necessary, OutSystems could simply compile your applications into a different stack, and you wouldn't even be aware of that underlying change. That was the case with a lot of customers that went from SQL to Oracle (or vice-versa), or that went from .NET to Java (or vice-versa). The same has been going on with native applications - Cordova gets upgraded transparently by OutSystems, and they manage the quality control of the upgrade.

There's really nothing to fear for you (other than, perhaps, OutSystems going out of business or being bought and extinguished by some big player). The low-code promise is that stack upgrades won't affect your applications.

There's a small caveat, though, if you're relying on C# code (or a forge component that uses it), chances might be that the code needs to be rewritten. However, that is a much smaller scope than rewriting an application on a different stack.


Indeed OutSystems is now moving to ReactJS. We're not sure yet what will happen to existing applications. But I am sure the same concept will apply - you won't be developing React applications either, and your OutSystems source code will remain stack independent.

Hi Leonardo and Stefano (old collaque),


Unfortunatly I'll be enjoying my vacation during the NextStep in amsterdam. However saying "OutSystems applications are not web forms applications" is not entirely true. 

  • Ajax refresh converts to webforms Updatepanel
  • Container coverts to webforms Contenttemplate
  • A theme is dome using webforms masterpage

It's a good thing there moving towards ReactJs. That way the application(backend) only needs to provide API's and makes it more independent of the stack it works on. However, current outsystems mobile applications work that same way. Current browserbased applications can not be converted to mobile in outsystems. probably becaus one is based on webforms and the other one on a ReactJs frontend and vice sersa.

Applications will always be able to run. Silverlight (if you remember) is depricated but still works if you open it in IE. That also includes every bug and security issue that is in the stack en will never be resolved.

Changing the database from SQL to Oracle is not a change of the application tachnologie stack. This is just a different implemantation of the translations used in the Object Relational Mapper that outsystems uses. Nhibernate, EntityFramework, Squalize stacks can all do that. 

From C# to Java is a bad example since Java it is no longer supported and people who created extentions had to rewrite them. Thats not realy supportive of outsystems...

If ReactJs is the future where every outsystems aplpication is built on.. Then Great!! but I doubt older webforms based applications will be or can be converted to the new technologie stack. That means that in time older applications will not have support by the stack provider, security issues will not be resolved and eventually have to be rebuild using the newer framework that outsystems implemented. That to me, would be a big disapointment.






Hi Danny,

"but I doubt older webforms based applications will be or can be converted to the new technologie stack."

Why can't they? In the end, what the browser is running it's HTML + CSS + javascript, right?

So, in my view, you'll just need to install the new version and recompile the full factory. That is already what we do when installing a new version.

The job to create the new compiler (that translates the OS logic to React) is not easy but why do you feel that it's not possible? Which things do you think they cannot do without the webforms?



 

I'm not saying its not possible. But since its not possible to convert current outsystems applications to mobile applications I doubt it will be implemented. If it doens't I'd rather know sooner then later..


I guess the only anser is.. Time wil tell

I think someone should ask Microsoft to stop bringing out new Frameworks. That will solve a lot of rewrite/migration issues...

Hanno wrote:

I think someone should ask Microsoft to stop bringing out new Frameworks. That will solve a lot of rewrite/migration issues...

I get what you're saying, but to be fair, if anything, Microsoft hasn't really been bringing out that many frameworks. 

Sure, they're now going for .NET 5 (formerly known as .NET Core) but realistically, the old .NET Framework was in dire need of a serious update. It has too much useless stuff that mostly isn't needed these days, so focusing on a smaller, leaner, framework, one that only has the, shall we say, the core parts, makes sense.

A good example is the WebForms. Yes, WebForms were a pretty neat solution to web applications way back when, when we didn't have nice things like, well, basically all the modern web funcionalities like Local Storage, Service Workers, Notifications, etc. And that's not no mention how even HTML and CSS weren't even standardized, we had different browsers and each did things differently.

These days even Microsoft has a Chromium based browser!

It's a different world, and it makes sense for the .NET Framework to keep up with the times.


This is real world:

"From C# to Java is a bad example since Java it is no longer supported and people who created extentions had to rewrite them. Thats not realy supportive of outsystems.."

We create BPT - Java Stack - for a client and as it is not supported again, my client is planning to move to Red Hat BPM.

How come OS introduce Java and then forget it after many clients use it?

regards

Financial Freedom wrote:

How come OS introduce Java and then forget it after many clients use it?

The same way Microsoft introduces web forms and then decides to forget it. It's a vendor decision, we have to adapt to it or switch vendor.

I just don't understand why you didn't move to .NET. As we've been discussing in this thread (keep in mind this thread is *not* to discuss why OutSystems+Java became unsupported, so please don't change the subject)... the fact that your application was compiled to Java is just an implementation detail. You should be able to compile the same application in .NET, and I'm sure it has a lower cost than rebuilding it in Red Hat BPM.

Thank you Leo,

The client said that they have no Microsoft technology in their history. So, they strict to non Microsoft.

regards

Danny Prager wrote:

  • Ajax refresh converts to webforms Updatepanel
  • Container coverts to webforms Contenttemplate
  • A theme is dome using webforms masterpage

That's not entirely true - all of these features are custom-built by OutSystems. For example, themes have nothing to do with master pages. You're trying to look at OutSystems simply as a thin abstraction layer on top of .NET Web Forms - it is not.

But even if these concepts mapped directly to the ones you've pointed out. Your argument doesn't hold for Java stack, or ReactJS stack. So do you still think OutSystems strictly depends on Web Forms, when it has already proven that it can adapt to JSF and ReactJS?


Changing the database from SQL to Oracle is not a change of the application tachnologie stack. This is just a different implemantation of the translations used in the Object Relational Mapper that outsystems uses. Nhibernate, EntityFramework, Squalize stacks can all do that.

Changing an enterprise application from SQL to Oracle (or vice-versa), even if you're using an ORM, has always been a big challenge - I'm sure you know about that. But in OutSystems, it isn't, because it fixes most interoperability problems. For example, Oracle is case sensitive, while SQL Server is not. Oracle stores an empty string as NULL value, while SQL Server stores it as a NOT-NULL value. The length of table names is restricted in Oracle (30 characters from what I recall), while in SQL server it's much larger.

So, yes, I consider this as a stack change. But even if you claim otherwise, the point is that your OutSystems application is independent of underlying technology. And will continue to do so as the industry evolves.

100% agree with Leonardo!

Agree or not agree.. Lets agree to disagree...

First up: I was asking a question: Does outsystems have a challenge with .NET 5?

You think they don't, I think they do, meaning rebuilds of current webform based applications. (Let's hope I'm wrong)

Leonardo is wrong saying that I "qoute": (You're trying to look at OutSystems simply as a thin abstraction layer on top of .NET Web Forms). Abstraction facilitates platform independence, among other things. So if anyone is assuming it is an abstraction layer.. its you..and is incorrect in my opinion

Second "qoute": (So do you still think OutSystems strictly depends on Web Forms, when it has already proven that it can adapt to JSF and ReactJS?) Java extentions are no longer supported in Outsystems 11 and how is it then that I'm not able to convert a web application into a mobile application?




1. Everything goes obsolete some day. That's the very nature of our business. You'll always have to rebuilt at some point.

2. Porting a web application directly to a native mobile app? That's like porting games from console to pc. The result would be aweful. Those are just 2 completely different types of applications. While not entirely impossible to create some kind of converter, there would not really be a point because the result would be bad anyway.

As for .NET 5 being a challenge. Yes, probably, but it is nothing they haven't faced before. You think adapting OutSystems to produce native mobile apps was a walk in the park? I'm confident they'll manage. Us not having to worry about this is one of the greatest adavantages of OutSystems. Let them worry. 

Danny Prager wrote:

Agree or not agree.. Lets agree to disagree...

First up: I was asking a question: Does outsystems have a challenge with .NET 5?

You think they don't, I think they do, meaning rebuilds of current webform based applications. (Let's hope I'm wrong)

Leonardo is wrong saying that I "qoute": (You're trying to look at OutSystems simply as a thin abstraction layer on top of .NET Web Forms). Abstraction facilitates platform independence, among other things. So if anyone is assuming it is an abstraction layer.. its you..and is incorrect in my opinion

Second "qoute": (So do you still think OutSystems strictly depends on Web Forms, when it has already proven that it can adapt to JSF and ReactJS?) Java extentions are no longer supported in Outsystems 11 and how is it then that I'm not able to convert a web application into a mobile application?




Hi Danny,

Great read so far, answering your main concern, we are actively working on overcoming any challenges regarding  .NET Core or .NET5. We’ll continue to evolve our underlying stack as needed choosing the appropriate technologies. OutSystems development language is mostly independent of the generated code and will also evolve to provide the best possible developer experience. Regarding a hypothetical conversion between a web application and a mobile application, the main challenge would clearly be on the OutSystems language and not on the underlying stack. Have you ever felt that need? And if so did you convert manually? And what was the experience and end-result?

Best,


leonardo.f

But even if these concepts mapped directly to the ones you've pointed out. Your argument doesn't hold for Java stack, or ReactJS stack. So do you still think OutSystems strictly depends on Web Forms, when it has already proven that it can adapt to JSF and ReactJS?

The adapt analogy is off base, changing colors is a more accurate one.  

  1. OutSystems could not upgrade existing Web applications to Mobile applications.
  2. OutSystems could not migrate SilkUI applications to OutSystemsUIWeb applications.

Those would be examples of how OutSystems could have adapted; instead they changed colors / retooled.

OutSystems needs to adapt however, because when the cost of upgrading software to the currently platform version becomes too expensive, existing software switches from an upgrade to rewrite and more than likely this rewrite is on a entirely different platform by a different vendor.

  • How many Visual Basic 6 applications were ported to VisualBasic.Net vs being rewritten into Web Application (Microsoft, Java, PHP, etc)?
  • How many WinForm applications were ported to WPF vs being rewritten into Web Application?
  • How many WebForm applications were ported to MVC vs being rewriten into Web JS framework?

It is my understanding the some of the original OutSystems customers at some point in time said enough to the OutSystems version upgrade process and its lack of adapting.  The best ROI for these companies was to continue to license and run a legacy version of platform that was two more versions behind the current major release with new software being developed on a different platform..

If the ReactJs Web Stack is coming, should I be developing/investing in OutSystems Web applications (particularly with OutSystemUIWeb) since its days are already numbered?  Should I be developing on a platform where staying current in the platform requires a major rewrite every major release?

ReactJs is also also getting long in the tooth, by the time OutSystems combines their Web and Mobile ecosystems together, the software industry will have moved on past ReactJs.  OutSystems should be be investing in future, and the future of Web and Mobile applications is pointing to technologies like WebAssembly and svelte.js.


Erik, I don't know what you mean by changing colors. The differences between SilkUI and OutSystemsUI go well beyond changing colors.

Yes, there is no direct migration path from SilkUI to OutSystemsUI. Why should there be? There's no migration path from WebForms to MVC, no direct path from Angular 1 to Angular 2, no direct path from React Redux to React Hooks.

Besides, SilkUI is still fully supported. You are not forced to upgrade. Your idea that OutSystems is forcing you to spend effort keeping up with the latest and greatest is wrong.


If the ReactJs Web Stack is coming, should I be developing/investing in OutSystems Web applications (particularly with OutSystemUIWeb) since its days are already numbered?  Should I be developing on a platform where staying current in the platform requires a major rewrite every major release?

Again, OutSystems does not "require a major rewrite". If you started with SilkUI, keep using SilkUI and you'll be fine.

Regarding whether you should be investing in a technology that has days "already numbered". If you can afford to wait, then yes, do wait until Next Step when you'll have a good idea of the direction OutSystems is going. If you can't afford to wait and have to deliver something tomorrow, use the best tool your current self has in hands.


ReactJs is also also getting long in the tooth, by the time OutSystems combines their Web and Mobile ecosystems together, the software industry will have moved on past ReactJs.  OutSystems should be be investing in future, and the future of Web and Mobile applications is pointing to technologies like WebAssembly and svelte.js.

Whenever (and if) that happens, OutSystems will adapt to the pressures of the market.

leonardo.fernandes wrote:

Yes, there is no direct migration path from SilkUI to OutSystemsUI. Why should there be?

Every version upgrade that does not upgrade the previous written software to the latest core framework is bad software platform. It also indicates that no new features or enhancements are coming to the now dead previous release. When you perform a database platform, your databases are all upgraded to the latest version with exposure to the latest features. Some existing features might work differently (aka break stuff) and documented with migration options. Worst case scenario is running in backwards compatibility mode. At NextSteps 2017, it was hinted 11 would be .NetCore using React UI. I suspect half of this will be announced at NextSteps 2019. For the life of me I see no reason why OutSystemUI was developed at all without these two features when SilkUI already existed. Was SilkUI architected in such way that it could not support the new version 11 features of template selection, events, and CSS variables? Are we to expect that every major version of OutSystems will contain a new static non evolving UI Core?

leonardo.fernandes wrote:

 There's no migration path from WebForms to MVC, no direct path from Angular 1 to Angular 2, no direct path from React Redux to React Hooks.

Because there was no upgrade path organizations moved off the platform for all new development. When there was an upgrade path, organizations stayed on the platform and actively developed on it.

leonardo.fernandes wrote:

Besides, SilkUI is still fully supported. You are not forced to upgrade. Your idea that OutSystems is forcing you to spend effort keeping up with the latest and greatest is wrong.

Yes OutSystems is forcing applications to upgrade and be rewritten to uses the latest championed OutSystems toolset. 

The last release of Webforms was 2010 and was probably dead then as Asp.net MVC 3 had before the defacto MS web platform. The official writing on the wall was the with ASP.NET 5 in 2014 when it was stated Webforms were not supported. JavaScript based UI rending kicked in 2013. OutSystems mobile efforts were a great accomplishment, but at the expense of web platform. With their current funding I am expecting a unified web mobile platform that is current(technology and library versions) and future orientated.

This death of web forms along with no direct major platform upgrade path has their #1 potential suitor (who already has their own mobile platform) have less and less interest in acquiring.

Well (the bullet is through the church) dutch saying..

It seems OutSystems does not have a challenge with .NET 5 instead, we seem to have a challenge now. According to below post the switch will be made to React webpages.

https://www.outsystems.com/blog/posts/reactive-web-applications/

There is however no possibility to transform current web applications to the newer reactive versions. So when the .NET Framework 4.8 is deprecated by Microsoft in the future probably by 10/10/2023, we will have to have rewritten all our current applications to the newer Reactive versions.

“.NET Framework is a component of the Windows OS. Components receive the same support as their parent product or platform. For more information, please visit the .NET Framework Lifecycle FAQ.

Or maybe I’m just jumping to stupid conclusions

Hi Danny,

I already have converted a few small applications from Web to Reactive it's really not a big deal. If you architectured your application well you only need to "rewrite" the end-user interface part since all magic happens here but you can copy/past almost everything. And then the only things that you really need to pay attention to is the Preparation fase since this has been replaced by direct Aggregates or Server Actions along with a OnAfterFetch action. Then you need to bind all the widgets to the correct incoming data and your done for 90% of the work. And this is easier to do then you probably think.

The only caveat could be the module in which the Entities reside but I'm sure that a solution will be given should the Traditional Web ever be removed (if ever)

Hi Vincent,


Your right, Only the frontend needs replacing. (still a lot of work in my opninion). And I do not see a problem with the current Core layer migrating to the newer Reactive web version. Have not tried it yet since we haven't upgraded the platform that supports reactive web.

Outsystem did not implement the scaffolding option (basicly what made it a Rapid Dev platform). So thats a bummer.

And yes, traditional web is not going anywhere for now.. and may probably still work for decades to come but.. It wil not be supported since the framework it's built up on will be deprecated. Meaning issues will not be solved en security will not be up to date. So you can't realy use it anymore in the future. Kinda like Silverlight (it still works) but you can't and shouldn't use it anymore.