Released DotVVM 2.4

Today, we have released the version 2.4 of the DotVVM framework, Bootstrap for DotVVM and DotVVM Business Pack.

This version brings many bug fixes and enhancements, a support for .NET Core 3.0 and 3.1, and also two new experimental features: Server-Side ViewModel Caching and Lazy CSRF Tokens.

Server-Side ViewModel Caching

This feature can dramatically reduce data transferred between the server and the client.

To enable this feature, add the following code snippet in DotvvmStartup.cs:

config.ExperimentalFeatures.ServerSideViewModelCache.EnableForAllRoutes();

When the feature is enabled, the viewmodels are cached on the server. When the client needs to do a postback, DotVVM can send only the diff of the viewmodel instead of serializing and transmitting the entire object. Thanks to this, we can save a lot of network traffic – almost 100% in extreme cases. Imagine a page with a GridView and a Delete button in every row – when you click on the button, the viewmodel on the client hasn’t changed at all. Thus the diff will be empty and the postback will transfer only a tiny JSON object with an identification of the button that was clicked – no viewmodel data at all.

The viewmodels are stored in memory by default, but the mechanism is extensible so you can use any storage you need – just implement the IViewModelServerStore interface. They are also deduplicated – we are using a hash of the viewmodel as a cache key, so when you use this feature on a public facing site which has the same “static” viewmodel for many users, the viewmodel will be kept in memory only once. And if the item is not in the cache any more, DotVVM will signal it to the client which will immediately issue a new postback with a full viewmodel.

The feature can be enabled for all routes, or only for specific routes in the application. We recommend to enable it on less frequently used pages at first, and watch the memory consumption on the server – the cache should be cleaned up when the server gets low on memory, but still – we encourage to start using this feature carefully.

We are still working on providing diagnostic tools that will help you identify how much this feature actually helped - how much traffic it saved and how much memory on the server it consumed.

Lazy CSRF Tokens

We have been building a few Progressive Web Apps with DotVVM and got a few ideas on what to improve in DotVVM. One of the things we found is that the presence of CSRF tokens in the HTML generated by DotVVM prevents caching of the pages and embedding them in the mobile app. Thanks to the lazy CSRF tokens, this problem is eliminated – DotVVM page doesn’t contain the token and it will ask for it right before the first postback.

This also introduces a new scenario – if you only use REST API bindings in your DotVVM app, you can run it without a server runtime at all – just use the generated HTML files and host them on a CDN.

Better Type Checking in CheckBox, RadioButton and ComboBox controls

We have added extensive validation on CheckedItems, CheckedValue, SelectedValue and ItemValueBinding properties. Thanks to this, you’ll immediately see that the type specified in the SelectedValue doesn’t match the ItemValueBinding which previously let do inconsistent or unpredictable behavior.

Unfortunately, this feature may break some of your pages. For example, if your SelectedValue was a string property and the ItemValueBinding was enum, it worked with previous versions of DotVVM and now you’ll see the error page. We have decided to introduce this breaking change because most of the cases were working only under some circumstances and they weren’t reliable.

Also, when your ItemValueBinding was an object, the previous versions of DotVVM allowed this even though this wasn’t working well because there was no way how to compare objects in JavaScript. Beginning with DotVVM 2.4, ItemValueBinding can only be a primitive type.

Please make sure to use the Diagnostics Status Page package to make sure none of your pages is broken – just install the DotVVM.Diagnostics.StatusPage NuGet package and visit /_diagnostics/status in your app.

Full Release Notes

• DotVVM 2.4.0
• DotVVM 2.4.0 Preview 2
• DotVVM 2.4.0 Preview 1

What’s Next

As we mentioned earlier, the next version of DotVVM will be 3.0. We plan to finalize the experimental features and bring more enhancements – right now we focus on several areas:

• Better integration with a JavaScript world – the ability to issue postbacks from a JavaScript and to call JavaScript functions from DotVVM controls.
• Rewrite of the JavaScript part of DotVVM to use ES6 Modules – this will make the JS part maintainable and the pages may include only the modules they really need – for example the SPA-related functions don’t need to be on a non-SPA pages.
• Improvements for PWAs – an option to store parts of the viewmodel in the local storage and be able to use then while the app is offline, and more.
• Enhancements for public facing web apps – we have been thinking about auto-generating of amp.js versions of the pages, and we plan to introduce some improvements in the server-side rendering.
• We are also thinking of moving toward more abstract and high-level components – something we internally call “Application Blocks” – ready-made templated components that would handle functionality of entire pages, e.g. CRUD, login/registration form, multi-step wizards, surveys, comments and discussion, and so on. These “blocks” would be working with “unified data sources” that could be backed by a REST API, SQL database and so on. Right now, we don’t have any concrete plans for this feature, but we feel that this direction would be interesting to many developers.

We are also watching the growing interest in Blazor – it looks like the idea of writing web apps with just C# and HTML is really appealing for many .NET developers, and since this is the same idea that DotVVM stands on, we feel that the effort invested in the DotVVM ecosystem is worth it.

We are happy to provide an alternative framework to those developers who don’t want the overhead of the .NET in Web Assembly (which means downloading a hundreds of kilobytes or small megabytes even for a simple hello world app) or to those who just prefer the Model-View-ViewModel approach.

It was really an awesome year for all of us in the DotVVM team. We’ll be thrilled to hear your feedback on DotVVM 2.4, and we wish you all the best in 2020!