If you want to write a dynamic web application in 2019 then the chances are that you will reach out for a JavaScript solution, and that solution will probably be React. We compare React to Blazor, a new .NET framework allowing you to write in C# for the front and back ends.

Using Blazor, code written for the front-end has access to all the language features of C#. In particular, it may be useful to have a type hierarchy and make use of polymorphism. However, JSON objects have no explicit type, so how can we correctly deserialise a subtype?

One of the benefits of Blazor is that you can share C# objects between the server-side processing and the client-side processing. In this year’s Dev Camp we wanted to put this to the test with validation of dynamic forms.

In our Dev Camp this year we chose to experiment with Event Sourcing, using EventFlow for the solution. One task was to configure it to use an Azure Cosmos database instead of a SQL Server one. There were some hurdles to overcome. This post takes you through the attempts we made and the solution we found.

Our final day saw huge progress in the application's client and server sides coming together. This was really the focus of the day with everyone working together to solve the final challenges and get the client communicating with the server.

Development progresses on all fronts in day 4, with the client and server sides moving closer together thanks to new work on the shared classes and API.

By the end of day 3 we'd managed to get the Blazor application constructing a dynamic form based on an external set of defined fields and having those fields be validated dynamically on the client-side again based on externally defined validation rules. Here's what that looks like...

In day 2 the team continued making progress in each of their areas. The EventFlow project begins to come together, shared client and server validation plans are made, and getting Event Flow working with Cosmos DB causes frustration.

In day 1 we set up our client and server-side teams; identified useful resources and frameworks for the week; and began setting up the solution and its components.

At OCC, dev camps are a way for us to experiment with new technologies, create prototype products, and bring back recommendations to the wider company regarding the new tools and techniques we've been able to evaluate.

OCC DevCamp has been a great opportunity to put the day-job to one side and try out some new technologies. Here are some thoughts on how I got on with them. AngularJS AngularJS is Google’s offering in the JavaScript application building framework arena. Having previously used Knockout I wanted to use a different framework for comparison. I’ve felt that Knockout isn’t especially well suited to large applications, and it seems to struggle in terms of performance when handling a large[...]

HTML5 Canvas HTML5 canvas is a powerful little container for graphics which I only used the smallest set of features of. Other features to explore would be changing of line colours/styles, and of drawing shapes. There are also other algorithms for drawing lines (Bezier/Quadratic) that might lead to smoother lines. Problems arose due to different implementations between web-browsers; chrome seemed to fare the worst here, especially when reporting the position of events. Some of the other features of HTML5/CSS3 I[...]

My focus for DevCamp was building an Android app that would interact with the presentation web app in realtime. For that we made use of a toolkit called Xamarin, as well as the ASP.NET SignalR library, and Git for source control. Xamarin Xamarin is a toolkit that allows you to use C# to write code for native Android and iOS apps. I had a good experience with this overall. I hit a small bug where changing the namespace caused a[...]

I spent most of the DevCamp week working on the client applications: the presentation itself (minus the annotations and the graphs), the secondary screen and the audience view. So the new technologies I spent most of my time on were AngularJS and TypeScript, with a little time spent on SignalR. SignalR I didn’t spend much time delving into SignalR, mostly because I didn’t need to. The code to set up a connection between clients and server is very concise and[...]