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 Mesopotamian’s, 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
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.
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.
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.
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:[html]
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:[js]
How many calendars were just initialized on the page? The answer; all of them.
The worst possible example might be the following:[js]
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.[html]