The Many Influences of Kendo UI Core

Every good idea is usually a combination of an existing idea and a new one. This is how we make things better.

The Arch building structure is still used today. It dates back as far as the Mesopotamians, but first saw heavy use in multiple structures by the Romans. Arches are incredible things due to their ability to span large distances while supporting insanely heavy loads by distributing the force down the base which then pushes outward into the ground.

“BNSF Railroad Three Arch Bridge over Bullinger Creek, Sealy, Texas 1112111435BW” by Patrick Feller

Arches have the ability to reduce the materials required for construction, increase stability, and maximize available space by providing room to move both on top of and beneath the structure.

Much of our architecture today contains arches. We’ve taken what we know works, and we continue to apply it to our ever evolving designs. Software shares so much commonality with physical architecture. Just as mechanical and civil engineers continue to build on past influences, software is always evolving based on what we’ve learned and those ideas that have influenced and inspired us most.

Kendo UI Core

Kendo UI Core is an HTML5 framework for web and mobile that is built on strong influences of frameworks past and present. I’ve watched those influences take hold in Kendo UI as it grew from an idea into the most complete open source JavaScript library available today. It’s important to know what those influences are to understand how we got where we are today.

jQuery

jQuery is the “arch” of software. It’s brilliant, easy to use, and prolific by any definition. It has perservered through the baseless performance and anti-framework outcries, and continues to serve as the backbone for 69% of the top 10K sites on the Internet today.

When the idea of an HTML5 framework was born at Telerik, we had the opportunity to start fresh. Telerik had been building UI components for over a decade, but this was different. This was the first product that would be far more than just a set of UI widgets. The browser was rising as the virtual machine of choice, and whatever we built would need to meet the ever expanding needs of front-end developers.

We also wanted to bring HTML5 to developers everywhere, not just those developing for the newest “evergreen” browsers. We wanted to do all of this while delivering the most performant JavaScript framework available. This is why we decided from the start to build Kendo UI on top of jQuery.

jQuery is not an optional piece of Kendo UI. It is baked into the very core of the framework, and is the rails on which Kendo UI rides. Kendo UI uses virtually every piece of the jQuery library from DOM manipulation to utility methods to event delegation. In retrospect, this is one of the best decisions we ever made.

Not only has jQuery proven to be a rock solid framework that can stand the test of time, it also allowed us to modularize Kendo UI to meet developers where they are. If you need just a DatePicker, you can drop a Kendo UI DatePicker in, and your only commitment is $('#element).kendoDatePicker(). If you want to build an entire Single Page Application with Kendo UI complete with two way data binding, you can do that too. jQuery is what makes this all fundamentally possible.

jQuery UI

The jQuery UI project has been nothing short of ground breaking. This is the library that made building interfaces with jQuery so trivial. I know several of the folks who work on or have worked on the jQuery UI project, and I can assure you that these are some of the best minds in JavaScript.

We learned a lot from jQuery UI. We were downright inspired by jQuery UI. We realized that jQuery UI might be right for some, and some might want a framework that delivered some additional rather complex widgets. Learning from jQuery UI enabled us to see what worked well for the jQuery UI team, what roadblocks they faced, and what events shaped the API.

jQuery Mobile

Kendo UI is heavily influenced by jQuery Mobile as well, but not in the ways that you might think. While Kendo UI Core does include the Kendo UI Mobile framework, jQuery Mobile is actually the influence behind Kendo UIs declarative API.

Since we use Kendo UI internally to build other tools, we quickly discovered that imperative initialization of the interface can be very difficult to scale and maintain. Angular has brought popularity back to HTML, but the beauty of the declarative UI extends way beyond your ability to create custom HTML tags.

You may be familiar with creating a calendar using imperative initialization:

<div id="dob"></div>

<script>
  $('#dob').kendoCalendar();
</script>

This works wonderfully, and has been how we have initialized UI components with jQuery for years. The problem is that we have relieved HTML of having any part in describing our user interface and we replaced it with “div soup.” It gets even worse if we look at some other ways to initialize that same date picker:

$('.cal').kendoCalendar();

How many calendars were just initialized on the page? The answer; all of them.

The worst possible example might be the following:

$('<div>').kendoCalendar().appendTo('body');

At first glance, it looks dead sexy to be able to create a UI component on the fly and add it to the page. The reality is that this component does not exist anywhere in the HTML until runtime. That makes it incredibly difficult to find and change later. Even if you are the person who wrote that code, the chances are you won’t be able to remember that you did it even six months from now.

jQuery Mobile was the first library to handle this using data attributes. Data attributes are brilliant because they are valid HTML and you don’t have to worry about stepping on the toes of actual legit attributes. Using a role based selector like jQuery Mobile does, its possible to let HTML once again define what UI elements are and what their configuration is.

<div data-role="calendar"></div>

<script>
  kendo.bind('body');
</script>

Knockout

Two-way binding between HTML and JavaScript objects is all the rage these days, but it wasn’t always that way. Steve Sanderson was way ahead of his time when Knockout was released. This two-way binding that was previously available in Flex and Silverlight was being brought to JavaScript. As those same frameworks began to fade into obscurity, it was only natural that we would need to replace their robust application abilities with JavaScript rising to the task.

Knockout was the first to introduce the concept of having two-way binding between the JavaScript and the HTML. Furthermore, it was done using data-bind attributes which made it legal HTML.

We wanted to be able to add this seamless two-way integration between Kendo UI widgets and JavaScript. We wanted an MVVM pattern. We loved what Knockout was doing, but we were concerned about the logical operators that people seemed to like to put in the binding syntax. This caused Knockout projects to get unwieldy very very quickly.

We wanted to take the good parts about Knockout – like simple HTML binding – and make it work seamlessly with Kendo UI widgets. We decided to roll our own MVVM framework that would mimic the best parts of Knockout.

This was NOT an easy task. Furthermore, we had many people that were quite upset that we didn’t build Kendo UI fully on top of Knockout as many others were doing. The end result, though, was a wicked fast MVVM implementation that was light and very familiar for those who knew Knockout well, and easy to learn for those who were new to MVVM. We also avoided taking a dependency on a third party library that was out of our control. Dependencies translate directly into technical debt if you aren’t very careful.

Bootstrap

During the course of last year it became apparent that responsive web design was solidified as a legit mobile strategy, and we wanted all of our Kendo UI widgets to be responsive. We were then at a crossroads; create a layout system just for Kendo UI, or use an existing one.

The line between a framework that is complete and one that is bloated is extremely fine and at many times indistinguishable line. Whenever we consider adding features or capabilities, we have to first decide if someone else is already doing it quite well. If they are, and we can integrate with it without taking a dependency, then there is no point in adding to the already existing Cambrian Explosion of web tools. This is why we chose to add first class support for Bootstrap as our preferred layout framework for responsive apps.

We have long been huge fans of Bootstrap. When the framework reached version 2, we decided to add a “bootstrap” theme to Kendo UI so that the widgets would fit in with the Bootstrap look and feel. When we released responsive versions of all our widgets (adaptive grid/scheduler), we upped our bootstrap commitment and tightened our integration. There is no easier way to get up and running with a responsive application that to use Bootstrap, and it made more sense for us to make Kendo UI work with a layout framework that you already know instead of asking you to learn yet another.

Backbone

Backbone is largely considered by many to be the father of JavaScript frameworks. The original client side framework, there were some things that Backbone did exceptionally well – specifically routing and views. Kendo UI Mobile has always had a router, views, and view management baked into Kendo UI Mobile. We decided to decouple that part of the framework and expose it via the core as part of the new Kendo UI SPA framework.

Much of what the Kendo UI SPA is today was influenced heavily by Backbone and the Backbone Marionette project. It was happenstance that Derick Bailey (author of Marionette) was working for Kendo UI at the time and he was able to provide a lot of valuable insight around our implementation. What we have today is a very simple and easy to use SPA framework that will feel rather familiar to Backbone developers, and is easy to learn for those who found Backbone to be a bit daunting.

For instance, you declare a Backbone view this way:

var HomeView = backbone.View.extend({
  tagName: "li",
  className: "row",

  events: {
    "click .badge":         "open",
    "click .button.save"    "save"
  },

  initialize: function () {
    // some initialization code
  }

  render: function () {
    // draw the view to the container
  }
});

var homeView = new HomeView();

A Kendo UI view is abstracted a tad more, and allows you to attach a model to a view. The model is an observable object which will be bound to the view. This means that all bindings in the view template are honored, including Kendo UI widgets and their creation.

var template = '<div data-role="kendo.mobile.ui.NavBar">' +
                '<div data-role="viewTitle" data-bind="html: title">' +
                '</div>';

var headerModel = kendo.observable({
  title: 'Home'
});

var headerView = new kendo.View(template, {
  tagName: 'header',
  model: headerModel,
  init: function () {
    // some initialization code
  }
});

headerView.render('#app');

See the Pen Kendo UI SPA by SitePoint (@SitePoint) on CodePen.

When the view is rendered, Kendo UI binds the HTML to the view while initializing any widgets inside with declarative intialization. Kendo UI takes this concept a step further with the ‘Layout’ construct. This object is in charge of rendering, caching, destroying, and generally managing views and their content. This is similar to what Backbone Marionette does with its absraction on Backbone boilerplate.

var layoutTemplate = '<div data-role="kendo.mobile.ui.NavBar">' +
                      '<span data-role="viewTitle" data-bind="html: title"></span>' +
                      '</div>' +
                      '<div id="content"></div>';

var homeTemplate = '<h1>Home View</h1>';

var layoutModel = kendo.observable({
  title: 'Home'
});

var layout = new kendo.Layout(layoutTemplate, {
  tagName: 'header',
  model: layoutModel
});

var homeView = new kendo.View(homeTemplate);

// render layout container
layout.render('#app');

// show the view inside of the layout
layout.showIn('#content', homeView);

See the Pen Kendo UI SPA by SitePoint (@SitePoint) on CodePen.

Angular

Angular has enjoyed more widespread popularity than arguably any other framework in history. That’s quite a feat considering there are more JavaScript frameworks available than there are drink flavor combinations at Sonic. The interesting thing about Angular is that it is very opinionated – which is generally considered a bad thing in web frameworks. It’s adoption has proven that, in fact, many developers are looking for strong opinions on the subjects of application structure and concepts such as dependency injection and test driven development.

We have always tried to integrate Kendo UI well with other libraries. This effort was manifested in the creation of the Kendo UI Labs repo on GitHub. This is where we house integration projects for Knockout, Backbone, Breeze, and Angular amongst others. Some of the projects are worked on by Kendo UI engineers and some are worked on by community members from these various libraries.

The Angular labs project is unique in that it will be the first labs project to officially “graduate” into Kendo UI Core. That means that we will begin shipping Angular integrations for Kendo UI as part of the Kendo UI Project for the first time in July. This is unprecedented for us in terms of our writing code specifically for another framework, including it as part of the distribution, AND offering support for that framework to our Kendo UI Professional customers. Angular has inspired us to offer deeper integration with third party frameworks and continue to modularize and decouple Kendo UIs components to make it easier to use everywhere.

ReactJS

I saw a tweet from Brian Holt this morning that just about sums up how people feel about ReactJS…

@reactjs makes me feel like a wizard.

— Brian Holt (@holtbt) May 29, 2014

We feel the same way! The concept of a virtual DOM is one of the most groundbreaking discoveries in pure web technologies. We’re doing some very close investigation right now of the impact that virtual DOM has on Kendo UI widgets and their rendering speed. Specifically, we want to know if we can improve performance on those widgets which are often used to display massive amounts of data. This would be widgets such as the Grid, ListView, and others.

The guys working with Kendo UI over at Wingspan also point out that React is wonderful for mapping disparate models to widgets. Often data is stored in a way that isn’t well suited for display inside of applications. Additionally, developers may want to combine models to display the data in a coherent, unified interface. React’s props make this much easier than trying to create abstractions on models since you aren’t removing the interface from the single source of truth, which is the base model(s) for you data.

Check out the Wingspan’s blog post on the subject for more info on how they use ReactJS.

All Open Source Projects

Honestly, we are constantly in awe of the open source projects out there that are so well done. They are loved by the community who gives back to the project and everyone wins. Rising tides definitely float all boats and we were so excited to be able to open source Kendo UI Core to offer it completely free on GitHub.

If you’re interested in getting to know Kendo UI Core a little better, you can grab it from GitHub, or simply:

bower install kendo-ui-core

There are plenty of demos to help get rolling quickly.

Stay Inspired

We’re excited for the future of the web and the ground that is being broken every day. Anytime someone tells you “The web isn’t made for that”, that’s a pretty clear sign that someone somewhere is making the web do exactly that very thing at the exact moment that phrase was uttered. Don’t believe me? Check out the Famous project, Mithril, or D3. All of these projects have inspired us to continually innovate to make Kendo UI Core a complete, cutting-edge front-end framework; freely available for all.

Frequently Asked Questions about Kendo UI Core