Web developers love inheritance, don’t you? Who would have thought you can inherit something so basic as an HTML element and extend it! Now you can do this using the new Web Components specifications.
With HTML5 came the introduction of semantic tags. Content could now be wrapped within much more appropriately named tags such as:
Kendo UI is more than just interface-candy. There is an elegant, underlying framework at play that makes things work. Is it easy to extend though? YES – Kendo is also framework-candy!
Wouldn’t it be great if you can specify different styles per page all from the stylesheet? For example, your home page may have a larger header section than the rest of your pages. The solution would be to add a different class on each page so you can do something like this.
Cross-browser compatibility can be a major pain. The philosophy for most web developers is to code against a standard-complaint browser (Chrome), then apply CSS hacks later for other browsers that need to play catch up (Internet Explorer). In other words, it is better to make your code forward-compatible and apply backward-compatible hacks instead of the other way around.
If you are a big believer in Kendo UI, then you will be glad to know there is a built-in template engine as well. The problem was that you have to load the entire kendo.web.min.js file just to render a simple template (~0.5MB). Kendo is now AMD-complaint and can be used with RequireJS! I can now use Kendo UI’s as my new favorite template engine. Why not if I plan to use other parts of the Kendo suite later or on other pages.
When working with existing sites or content management systems, you have little say on where and when jQuery is loaded. To complicate matters, some pages may have jQuery auto-loaded, and others may not (yay for performance boosts, nay for client-side plugins). Do you bite the bullet and write unmanageable scripts? Or do you believe in RequireJS and dodge the bullet matrix-style?