Developer Story: How it all started

“Real developers don’t use frameworks,” they told me

…and I kind of agree. Real developers build them.

My web developer background started with PHP and ASP long time ago. There were not many ready-made frameworks at the time, and many things were implemented from scratch. I cannot count how many data-grids with paging, sorting and filtering I have written in my early PHP projects. Very soon, I have created my own “library” to make my life easier in the following projects.

When ASP.NET 2.0 came out in 2005, I was really impressed. So many things I had to do in my library, was present there right away, ready to use. I still have the large box with all the CDs required to install Visual Studio and a complete distribution of the MSDN library, and there was also a book which described how to build web applications in ASP.NET.

Of course, ASP.NET Web Forms had a lot of flaws, like the viewstate field, or unpredictable HTML with inline styles and other nasty things. But still, it was a revolution in the way how web applications were built at that time.

I have built many applications in ASP.NET Web Forms. Soon enough, I built many custom controls in order to extend the framework and make my life easier. The component-based approach, the extensibility of the entire ASP.NET platform and reusability of controls was the things I loved and it helped me and my company to deliver the web applications to our customers quickly.

Somewhere about 2012, when more and more interactive web applications emerged, the Web Forms started being inefficient and too heavy. By that time, I wasn’t a freelancer any more. In 2011, I have founded my own company called RIGANTI.

Soon enough, we started experimenting with Knockout JS and Angular JS in our customer projects. We ended with Knockout JS for some time, mostly because it was really easy to use and learn.

However, building a real line of business application with Knockout JS required to build a lot of additional infrastructure. We were using ASP.NET Web API and Swagger to do the client-server communication. We had to implement some mechanisms to handle complex validation logic that was present in some of our applications. Simple validations could be done on the client side, but there were many validation rules which could be done only on the server side.

We found a lot of issues with date and number formatting because of a different formatting logic in JavaScript and .NET environments. Localization was also difficult to do — there were plenty of JavaScript libraries for localization, but we needed to share the localized resources between the server side and the client side, so we had to create our own solution to extract localized texts from the .NET resource files and serve them to the client using a REST API.

The Craziest Idea I Ever Had

In November 2014, I was attending MVP Summit, a conference which takes place in Microsoft Campus in Redmond. I was sitting in Building 33 and listening to Scott Hanselman, Scott Hunter and other guys from the ASP.NET team about the future of ASP.NET. They were sharing their visions about “restarting the platform” and there was an intense feeling ASP.NET will change a lot in the upcoming years.

In 2014, most of the ASP.NET-based web applications were still using ASP.NET Web Forms. Even today, there is a lot of them running out in the world. During the sessions on the MVP Summit, the guys mentioned that ASP.NET Web Forms was not going to get any significant new features in the future. It would be maintained for some time and get some improvements, but all major investments would go into other ASP.NET technologies.

At that time, I got an idea to build something like Web Forms, but using technologies and approaches from the year of 2015, not from the year of 2002. In most of line of business web applications with many data grids, complicated forms with hundreds of fields with various dependencies, the biggest challenge for a developer is to maintain the state of the page. Any framework which can help to do the state management easily, is a huge benefit. But the implementation of ASP.NET Web Forms just didn’t get an advantage of the modern web browsers and JavaScript frameworks that emerged.

I was also wondering, how to get rid of the things which Web Forms were criticized for. The biggest issue was the viewstate — a cryptic hidden field which contained the entire state of the web page. It was the year 2002 solution that allowed to build stateful web apps on top of the stateless HTTP environment. This form field caused many flame wars and divided the .NET community to two parts — the first one hated it, and the second one didn’t find it yet.

The guys from the ASP.NET team made a lot of improvements to keep the viewstate field smaller in every new version of .NET Framework, and to be honest, most of the viewstate issues was caused by inexperienced developers who didn’t understand how Web Forms work and did things they shouldn’t. Many of the Web Forms applications were slow because of too much data was transferred on each postback, but on the other hand, there were a lot of cases where it didn’t matter so much, the intranet applications for example.

The second issue Web Forms were criticized for, was the HTML code being produced by Web Forms. Many controls in Web Forms rendered HTML that was compatible with really old browsers, like Netscape Navigator. This was perfectly OK at the time when Web Forms appeared, but it caused a lot of issues later, and it also caused a lot of nightmares to the ASP.NET team which had to keep the backwards compatibility. There was an option in the web.config to make the controls produce the same HTML as in the older versions of .NET Framework, so the developers could upgrade their applications to the newer .NET and didn’t have to worry about breaking the web pages because of the different HTML being rendered in a new framework version. However, it must have been a nightmare for the ASP.NET team because these compatibility switches required a lot of compatibility code in the controls and made Web Forms difficult to maintain.

Additionally, Web Forms were designed to allow desktop developers to switch to the web development easily. That’s why Web Forms controls contained properties like FontSize or BackColor. It was easy to use for the developers without the knowledge of CSS, but it rendered inline styles which was considered as a bad practice.

Many amateur developers were using the Designer view in the Visual Studio and created their application using the designer, which didn’t produce nice markup at all. But it was easy and discoverable. You were able to render a grid with data from your database without writing almost any code, which was great for the beginners. They could start quickly, create a simple page, look at the generated code and learn how things work. I have seen many non-developer users who started playing with ASP.NET Web Forms and created simple web sites. These sites were far from being perfect, but worked and did the job somehow.

The third issue of Web Forms was the lack of testability. It was very difficult, if not impossible, to write integration tests for the code-behind files of the pages. You would need to mock the HttpContext and all the other properties, avoid using static methods and so on. You couldn’t use dependency injection in the code-behind files easily, because the core of ASP.NET Web Forms was tightly integrated with the IIS request pipeline and there was no extensibility point to instantiate the code behind class.

Here Came Redwood

I liked Knockout JS, but I didn’t like writing Knockout JS viewmodels. Most of the code that was in the viewmodel just took the data, unwrapped them from the Knockout observable objects, and passed them to the REST API, got the result and applied it to the viewmodel. That required a lot of code to be written and it was really boring. I had to write similar classes in C# anyway to use them in the REST API, and then use Knockout Mapping to map the JavaScript objects to Knockout observables and back. So many steps for such a trivial thing like filling the grid with data.

There was really not too much invention in the JavaScript code — almost same things on every page. What if the viewmodels are written in C#, with IntelliSense and strong typing, and the JavaScript implementation was just generated? And when I have this, what about a concept of server controls that could encapsulate some functionality and be reused in multiple projects?

I have succeeded to build a simple prototype of the framework during the MVP Summit. The original name for the framework was Redwood. I wasn’t sure that the design I had in my mind, would work, and I also had to fine-tune the syntax so it was easy and practical.

The prototype allowed me to write viewmodels in C# and design the views using HTML-based syntax with server controls, that produced quite clean HTML with Knockout JS data-bind expressions. Together with the page, a JSON-serialized viewmodel was posted, so the user got the HTML including the data in a single HTTP request.

The state was persisted in the viewmodel, which was a C# class and the developer had precise control over what information was part of the state — it was his own class. When the client needed to call a method on the server, the client-side viewmodel was serialized, sent to the server where the action was executed, and the changes made to the viewmodel came back as JSON to the client where the Knockout viewmodel was updated. To avoid sending the entire viewmodel to the server and back, there were also attributes that governed which parts of the viewmodel needs to be transferred and which do not.

Because of the MVVM, the viewmodels were testable, and all the server controls were designed to produce the simplest HTML possible, that could be styled using CSS. This became the core of DotVVM, which is a current name of the framework. These are the principles on which DotVVM stands. It is still quite friendly for Web Forms developers, because many things are similar (control and property names, for example). At first, I didn’t expect that it would be usable, so I have placed the project on GitHub, maybe someone will finish it. After a few months where I have found the potential in the project, I have decided to keep it open source. In order to make a product out of it, I have started planning commercial extensions and support scenarios.

The first version of the framework included only few controls. The DOTHTML (at that time, it was RWHTML actually) parser was pretty naïve and many parts of the framework were later rewritten to be more robust.

When I tried to implement the postback mechanism, I realized how well architected Web Forms actually was. At first, I was thinking that the page lifecycle of Web Forms was too complicated and nobody really understood it. It tried to remove some stages from the lifecycle, but when I tried to implement the postbacks and execute methods in the viewmodel, I quickly found out that it could not be simplified much — it would just not work for complicated controls like the GridView. The Init, Load and PreRender phases stayed in the framework, and I decided to keep the naming so the Web Forms developers didn’t have to learn anything new.

Few months later, I had shown a short demo of Redwood at the end of my friend’s session at one .NET conference, and the next day, I got a pull request from someone called @exyi. I contacted him and soon enough, he started working for RIGANTI. Now, he is the most important person behind the framework development and has made far more commits to the repo than me.

The Path to Production

We tested DotVVM on several smaller projects and when we got to the version 0.7, we started building several large web applications with it. The feedback from these projects was used to constantly improve the framework, and in June 2016, we have published the first stable version 1.0. Since then, we have built more than 50 of projects using DotVVM. At the same time, we have started building the Visual Studio extension for DotVVM. It was (and still is) a very difficult job to do. The HTML editor in Visual Studio is extensible in many ways and is designed quite well, but there is no documentation, which made us spend hundreds of hours by decompiling Visual Studio assemblies and discovering, how things work and where could we hook in.

Delivering the IntelliSense in data-binding expressions was the biggest challenge, but we have been successful and in my opinion, it is one of the greatest things DotVVM can offers — full IntelliSense everywhere and detecting errors in real-time when you write the markup. The accurateness of the IntelliSense in the commercial version of DotVVM for Visual Studio is one of the key features and maybe the greatest reason to give DotVVM a try. Name anything and we can do the IntelliSense for it — names of controls, properties, expressions in data-bindings, route and route parameter names, resource names…

We have also started building commercial controls. Bootstrap for DotVVMcontrols were quite easy as they are simple wrappers over Bootstrap widgets. Business Pack was a great challenge for us and we have discovered and created many patterns and best practices on how to develop DotVVM controls. Many controls in this library was redesigned several times until we found the best way how to implement them properly and keep them maintainable.

.NET Core

One of the big challenges for us was the support for .NET Core. When I started writing DotVVM, nobody knew about .NET Core, and OWIN was the new shiny way to build frameworks. I knew that the ASP.NET will change a lot, so I tried to avoid of using anything from the old pipeline, and kept using OWIN infrastructure.

That allowed us to port the framework to .NET Core quite easily, when the platform became stable enough. We tried it for the first time when .NET Core was in Beta 5, but there were so many changes since then that we really started working on the support after the 1.0 RTM was out. Supporting .NET Core required some breaking changes in the framework, but considering how many things we needed to change inside the framework, the upgrade process to DotVVM 1.1 was not so bad and almost all the changes concerned the application startup, not the individual pages and the viewmodels.

The constant changes in the tooling complicated the entire process — we have migrated our projects to project.json, then to a new CSPROJ. Every update to .NET Core tooling (which was in Beta months after the RTM version of the platform was released) broke something and I cannot count how many times we needed to change something in the CI process because of the changes. But after months, we have shipped the new version which supports both old and new platform.

Breaking MVVM Wall

I have always liked design patterns and software architecture — these are one of my favorite topics to talk and read about. However, I have seen many scenarios and applications where breaking the rules was the only way to solve the problem. The most frequent reason for this was performance — doing the things properly can be slow.

That’s why DotVVM doesn’t push the MVVM way everywhere and allows to avoid it when you need performance. For many operations, you don’t need to do a full postback — there is a concept of static commands that allows to call a method on the server without transferring the viewmodel at all. In the current version of DotVVM, the static commands are still quite weak and cannot be used everywhere.

DotVVM 2.0, our next planned version, will add a lot of new features to the static commands so they can be used in more scenarios. You will be able to inject services in the views and call methods on them.

We are also playing with an option to translate C# methods in viewmodels to JavaScript. That would allow to avoid the communication with the server completely in case you need to do a local change to the viewmodel without touching application dependencies (like the SQL database).

It might allow to generate HTML from DotVVM and host it on a CDN or any other cheap storage, without hosting the server runtime at all. The C# code would be converted to JavaScript, which would allow to call e.g. Azure Functions or some kind of REST API. These features might change the way how DotVVM applications are written today.

Modernizing Legacy Applications

Being a developer and a CEO of a small company together gave me an opportunity to see the same things from two sides. I have seen a lot of legacy systems and old web applications which are still running and which cannot be easily rewritten to run on new shiny platforms.

From the developer perspective, it must be a nightmare to work with these projects, and I admire all the brave guys who still have to use Visual Studio 2005 and maintain old apps their companies rely on. But if you build a single application for 10 years, there is usually no way to rewrite it completely in less than half of that time, and I also understand the business point of view — the application works, the company depends on it, rewriting it is very costly and imposes many risks on the business, and it’s difficult, but still possible to find developers who know the technology and are able to work with the code.

The fact that DotVVM still supports OWIN and classic .NET Framework opens a bunch of interesting integration scenarios. Even if you have a 10 years old Web Forms application, you can add DotVVM NuGet packages in the project easily and write new pages in DotVVM while keeping the old Web Forms pages functional.

You can implement single sign-on, use the same CSS so the users won’t recognize that the pages are created in two different technologies. You can connect the DotVVM pages to the same business layer and build the new parts of the application using MVVM.

After a few years, most of the Web Forms pages may be removed or replaced by the newer DotVVM ones, and you may end with an application that got rid of the Web Forms completely. At that time, you might be able to switch to .NET Core which is also supported by DotVVM.

DotVVM also doesn’t require to rearchitect the business layer so it could be exposed as a REST API, which would have to be done if you choose any client-side framework. Of course, if the business layer is monolithic, it might be a good idea to split it into smaller services and maybe containerize it, but you can do it while the application is still working, module by module. At RIGANTI, we have done several integrations like that and we are helping other companies to work with their legacy code and modernize it without the need to rewrite it from scratch.

Summary

Building DotVVM was fun and without any doubt, the last 3 years were the best years in my life. As a company, we gained a lot of experience that other software companies cannot have. It was also a huge mind-shift for RIGANTI and there are some new areas we have to grow in, especially marketing and sales. Few years ago, we didn’t have to care about these things — our customers found us themselves.

We are using DotVVM in all our current projects and it saves a lot of effort and costs. It doesn’t require learning dozens of JavaScript libraries and tools — the developers with .NET skills can learn DotVVM in a few weeks.

We have convinced a lot of companies that building web sites that DotVVM is a way to go, and new customers contact us every day. We are still dealing with the fact that RIGANTI is a small and unknown company. Especially the larger companies are sometimes afraid to use DotVVM and prefer to use frameworks backed by big names. On the other hand, every Silverlight developer can confirm

that even a large and well-known company can abandon its own framework suddenly, which is a thing we really don’t plan with DotVVM.

We have a lot of interesting features in our backlog and we are working hard to provide DotVVM 2.0 by the end of this year. This version will be interesting in many ways, mostly because of the integration with REST APIs that could be called directly from the views, to fill the GridView for example.

For the next years, we plan to get rid of Knockout JS internally and switch to virtual DOM while preserving full backwards compatibility. It will be an important change in the framework and also a great challenge and experience for us, but it will improve the client-side performance of the framework and help us get rid of Knockout observables which can be a pain sometimes.

My intent was to make building of web applications simple for everyone. That’s why I have built a framework.