Migrating Client RIA Business Applications to Web with Vaadin

The lights are going out on all plugin-based Rich Internet Applications (RIA) with the end of Adobe Flash on December 31 2020, and the end of Microsoft Silverlight on October 12 2021. Lately, a few companies have been in touch with us regarding migration from these technologies to Vaadin. Not many large business applications were built as RIAs, but some were and are still used today. 

Companies still on these stacks in 2020 have found a way to keep their applications running by working around severe browser limitations. These include using IE11 or specially forked versions of other open-source browsers. These companies are investigating migration as an option, but they often delay the move to get as much value from their existing code as they can.

In this post, we compare Vaadin with Flash and Silverlight, and explore how Vaadin can be a good fit for migrating Flash and Silverlight workloads.

What Vaadin has in common with Flash and Silverlight

There are similarities between Flash and Silverlight, and Vaadin, but there are also important differences. The similarities lie primarily in the developer experience. The differences, on the other hand, lie in the runtime architecture—the most important is that Vaadin applications run natively in the browser, without plugins. 

For the developer, all three frameworks combine the convenience and simplicity of desktop-style single-page development, with the ability to run in a browser. Furthermore, they do this while empowering the developer with not one but two programming paradigms at the same time: one declarative and the other procedural. 

For Silverlight and Flash, declarative means strictly declarative, with no language support for loops and conditions. Vaadin adds to the declarative experience with the conditional and repeating Web Components-based templating of Polymer and lit-html. 

With no loops and conditions, declarative programming in Silverlight and Flash was most suited for static views only. Using the declarative model, you could declare, name, instantiate, and layout your static compositions in a compactly readable format. This format was as easy for developers to maintain as it was for WYSIWYG visual editors. 

Flash, Silverlight, and Vaadin all have object-oriented language counterparts to the declaratives, in which you can define classes, methods, and as many loops and conditions inside the methods as needed.

It’s only when you compare how each framework has integrated their declarative and procedural counterparts that you start to see the many different ways they can be combined.

Mapping declarative/procedural integration to Vaadin

A key part of getting the declarative and procedural working together is to make names defined in one visible in the other. Let’s take a look at a simple UI in Silverlight. It’s got a Label, a TextBox, a ListBox, and a Button. When you click the Button, the text in the TextBox is added to the ListBox as a new ListBoxItem, and when you click on an item from the ListBox, the Label updates with the index. Our view could look like this:

In code, our XAML file (simplified with layouting and boilerplate removed) would look like this:

File MainPage.xaml:

<UserControl x:Class="SilverlightApplication1.MainPage">
    <Grid x:Name="LayoutRoot">
        <sdk:Label x:Name="label">Label</sdk:Label>
        <ListBox x:Name="listBox" SelectionChanged="listBox_SelectionChanged"/>
        <TextBox x:Name="textBox" Text="TextBox"/>
        <Button x:Name="button" Content="Button" Click="button_Click"/>
    </Grid>
</UserControl>

And our C# would look like this:

File MainPage.xaml.cs

namespace SilverlightApplication1
{
    public partial class MainPage : UserControl
    {
        public MainPage()
        {
            InitializeComponent();
            listBox.Items.Add("Tempest");
            listBox.Items.Add("Squall");
            listBox.Items.Add("Cyclone");
            listBox.Items.Add("Hurricane");
            listBox.Items.Add("Typhoon");
        }
        private void listBox_SelectionChanged(object sender, SelectionChangedEventArgs e)
        {
            this.label.Content = listBox.SelectedIndex;
        }


        private void button_Click(object sender, RoutedEventArgs e)
        {
            ListBoxItem li = new ListBoxItem();
            li.Content = textBox.Text;
            listBox.Items.Add(li);
        }
    }
}

Through C#’s notion of partial classes, the type defined in a C# compilation unit can be extended by other compilation units. The XAML file in the example defines five names that can be accessed from code in the C# file without needing to be redeclared. Each is defined in XAML in a “x:Name” attribute. The C# file defines two names in methods. 

To share names across source files in Vaadin, you have to bear in mind that the name and type are both missing in the other file, and the name will have to be redeclared or resolved dynamically. 

Let’s recreate this Silverlight demo in Vaadin, while preserving the number of components, their names, and the names of their event handlers. The following examples show the integration using Polymer templating. At the time of writing, final touches were being put on a newer templating framework in Vaadin called lit-html. The integration possibilities and mechanisms for declarative and procedural will however be similar in both Polymer and lit-html, so much of what is stated here still holds for the future.

class MainPage extends PolymerElement {
  static get template() {
    return html`
      <span id="label">0</span>
      <vaadin-list-box id="listBox" 
        on-selected-changed="listBox_SelectionChanged">
      </vaadin-list-box>
      <vaadin-text-field id="textBox"></vaadin-text-field>
      <vaadin-button id="button" on-click="button_Click">Button</vaadin-button>
    `;
  }
}

The concrete components that make up the view have comparable counterparts in the migration target: 

• Label becomes span
• ListBox becomes vaadin-list-box
• TextBox becomes vaadin-text-field
• Button becomes vaadin-button

The components are named using the “id” attribute instead of the x:Name attribute, and the listeners named for the events, with the name of the event being the name of another attribute. Silverlight’s SelectionChanged event and attribute for ListBox become on-selected-changed in Vaadin, and Click becomes on-click. Otherwise, line by line they correspond.

On the procedural side, in Vaadin the most fitting replacement for the polymorphism of C# would be Java (TypeScript is now an option as well). Java doesn’t have partial classes, and even if it did, these would be defining classes running on the server and not in the browser. We have to redeclare any name we declared in the browser here to get the class to compile. The four components we gave “id” labels to in our template, we will declare and link in Java using the @Id annotation.

Similarly, event handlers, which we named in the declarative, can be made accessible to the declarative through an @EventHandler annotation.

@JsModule("./src/views/main-page.js")
public class MainPage extends PolymerTemplate<TemplateModel> {

    ArrayList<Object> listBoxItems = new ArrayList<>();

    @Id
    private Span label;


    @Id
    private ListBox listBox;


    @Id
    private TextField textBox;


    @Id
    private Button button;



    public MainPage() {
        listBoxItems.add("Tempest");
        listBoxItems.add("Squall");
        listBoxItems.add("Cyclone");
        listBoxItems.add("Hurricane");
        listBoxItems.add("Typhoon");
        listBox.setItems(listBoxItems);
    }

    @EventHandler
    private void listBox_SelectionChanged() {
        label.getElement().setProperty("innerHTML",
            listBox.getElement().getProperty("selected"));
    }


    @EventHandler
    private void button_Click() {
        listBoxItems.add(textBox.getValue());
        listBox.setItems(listBoxItems);
    }
}

Conclusion

With a bit of creativity, you can get much closer to a line by line equivalence of client RIA applications in Vaadin than you might realize. Some companies have dabbled with their own tooling on top of the Flash and .NET SDKS, to partially automate the transformation of their RIA legacy, but avoid the error-prone chore of writing the parsers from scratch. This holds not just for the easily parsed declaratives, but also for their procedural artifacts.

Most of the documentation, samples and tutorials about Vaadin and its upcoming versions emphasize associating event handlers with components as an exclusively procedural affair. However, just because the recommended examples lean toward this particular pattern, doesn’t mean managing the association in the declarative is invalid. If you are looking to unlock your RIA legacy from browser plugins at minimal cost, and your application associates handlers in the declarative, you’ve a valid reason to do the same in Vaadin.