If you take away how this looks, and start digging into the project from a beginner's perspective, this project is awful. I find this with most of the supposed "UI frameworks" out there for HTML. With a few exceptions, they mostly lack:
1. Good documentation that doesn't just define the framework, but teaches you how to use it and get stuff done with it. Code already defines what it is, your docs should tell me why it's this way and how to use it. In Kendo UI they've got a list of dependencies for javascript projects they need, then a few code snippets with no explanation as to why or how they work.
2. Good sample code, in a full complete project you can download, with documentation on getting it up and running. Your first sample code is how everyone will write code using your project. If you've got bad samples, poor formatting, and weird file layouts (or none), then that's what everyone will write and that's what you'll be known for.
3. Examples that gradually increase in complexity. Start off with a simple hello world, graduate to a chat app or something simple, and get them to a full blown large application. In this Kendo example they've got a demo picture viewer, with no explanation for how it was built, and viewing the source it looks like a huge mess.
4. Humor. These kinds of documentation are boring as hell, especially if you're just defining everything. It doesn't have to be insanely hilarious, but at least throw a few little funny tidbits in the code. Even the great tech books of our time have tiny little jokes for the people who pay attention.
5. Finally, these frameworks rarely have a "theme". MVC is a theme. Convention over configuration is a theme. There's only one way to do it. There's more than one way to do it. Themes work to help people keep the script for why everything works the way it does in their head.
It's too bad because this looks really good, and it could be the most awesome thing on the planet. But if I can't figure it out even if I want to, then I'm never going to try.
Finally, none of what I wrote above applies if your project is for fun and not meant to be a "product".
I agree with your points. Tutorial-style documentation is a way to go.
The main problem this framework has isn't its reference-style documentation (if a framework looks good enough I'm willing to do some extra work figuring out how to use it). Kendo's real problem is its licence. Apart from seeing how "awesome" it is you can't do shit with it.
Read the FAQ, the beta version has a different license than the full release will:
Q: How is Kendo UI licensed? Is it open source?
Kendo UI is dual-licensed, Commercial and Open Source (GPLv3).
The Commercial license includes full source, professional support, access to the latest Kendo UI hotfix builds, and priority influence on the Kendo UI roadmap. During the Beta phase, the framework is licensed under a Beta license and no commercial license is available.
1. Grant. Telerik hereby grants to you, and you accept, a non–exclusive, non–transferable license to install and use the Software for evaluation purposes only, solely as authorized below. ....
I must admit that I haven't checked your list against the Kendo UI. However +1 for a nice description of how to present a framework to potential new users.
Good lineup. However, I think that #4 is only appropriate in beginner's guides—docs always should have some boring reference section with quick navigation. HTML5 boilerplate lacks that. Jokes get old fast.
Perhaps some good examples should be mentioned… I think, SproutCore handles points 1-3 very well (http://guides.sproutcore.com/), but lacks #5 a bit. Django's documentation seems to have most of these, too. (These aren't HTML UI frameworks, however.)
Sproutcore fails on another point though with making too much "improvements" on version 2.x. Why would anyone consider using sproutcore 1.x if it's already deprecated, and version 2.x is far from ready, as well as the docs. The sproutcore demos doesn't even work. You gotta have working demoes. There's no excuse for that - try getting your boss to accept a framework with no working demoes.
If you don't manage to get a home run with version 1.x just stick with it and fix the damn bugs, instead of doing the big rewrite, with the promise that it'll eventually work. It'll just work if you stick with it and fix the last 10%.
Hm.
If you look --> in the documentation <-- you find your first protest invalid. And in those docs you will find plenty of sample code, for your second protest, and examples (#3) to go with them (what is sample code if not an example?). #4 Protest too much? #5 Does a framework's theme need a template, too, or will a motif do?
And other pages that are just enumerations of things that are in the code, then you've just defined it, you haven't told me how to use it or why it works the way it does.
Instead, they'd need docs that lead the user through step-by-step breakdowns of where things are, why they are there, how to exactly build an app from nothing, and get it working. They've got none of that. Just a .zip with some crap in it and nothing that says what to do.
Then, your idea of "sample code" is a couple of blocks of js on an HTML page? Right, I need HTML, Js, server setups, everything needed to get it working. If I don't have that then you've skipped over a ton of shared knowledge I don't have and that you need to take out of your brain and lay down so I can follow along.
"Protest too much?" You're a dick. Seriously, I love you guys who come in talking all tough like you're so damn right and really you just pedantically split hairs then throw out ad hominem attacks while claiming you abhor them.
But, then again, like I give a fuck what you think. The people who will actually benefit from my comment will read it, and the guys like you will just go about your day writing down 5 paragraphs for your docs and wondering why people can't use your crap.
Note: You cannnot use this library on your web site. The licensing agreement forbids you from redistributing the library, whether or not it's minified. It further states, "You are not allowed to integrate the Software into end products or use it for any commercial or productive purpose." So private deployment is out too. It's strictly for your own evaluation and amusement.
After poking around on their website, I noticed that this library is being developed by Telerik (http://www.telerik.com/), which is a pretty big vendor for .net libraries.
The trouble is I don't think they have a library for MVC3-ish apps with a front-end focus. At my place of work, we are ditching the traditional asp.net development and porting our app to MVC3. In the switch our Telerik .net controls were no longer usable, and we switched to jQuery UI.
I'm sure this will just end up being their solution to jQuery UI, to the corporate types that already use their current offerings.
It's funny because Telerik's evangelist has been pushing HTML5 hard lately (http://www.telerikwatch.com/) and I found it curious because Telerik's current offerings are useless to anyone who wants to write an HTML5 solution on MVC (they do have a half hearted MVC project but it pales in comparison to the free solutions available for Javascript/JQuery development)
That link just takes me to an error page. The FAQ says "Kendo UI is dual-licensed, Commercial and Open Source (GPLv2)"—and furthermore, that "During the Beta phase, no commercial license is available."
[Edit: Updated link did work. Yeah, that license agreement is... not GPL-compatible. I'm guessing they duplicated the same boilerplate that they use for trial versions of their .NET libraries.]
Regarding the license - we are using a "beta" license that should protect people from using beta quality software in production. We'll move to the dual-licensing scheme once we are out of beta. We also updated the FAQ accordingly.
The question I am asking myself right now is how did this project make it to the top slot of HN. It seems to be a re-hash of some standard frameworks, some bad documentation, some buggy widgets and be backed by a largish vendor. I hate to say it, but it reeks of a voting ring.
Hey, don't shoot the messenger!
I am no related whatsoever with Kendo UI, I read about it on twitter and thought to submit it here to see what you guys think of it. I'm pretty sure there's no voting rings involved.
It just seemed kind of strange to me to have a pretty uneventful project hit the top slot. I appreciate your reply and it probably just generated a lot of conversation it just seemed unusual for HN.
Hate to jump on the negative bandwagon, but... I had a momentary hope for something truly novel, but found the usual aggregation of data-binding framework, templating language, and widget kit, where the widgets have various bugs/quirks that make them undesirable to use as is.
Using Chrome13 on Ubuntu, when I try to use the Drag&Drop Demo, the draggable element jumps to the lower right corner of the mouse cursor.
In the slider demo, rapidly clicking multiple times on the left or right arrow to increase/decrease the value fires a doubleclick event, highlighting most of the text on the site.
In the window demo, the mouse cursor does not change when I hover over the title bar, although the window is draggable.
It's these little details that scare me off. When I use a framework, I want it to take care of everything. If I have to add css classes for the mouse cursor or fix element positioning, I'd just build what I need myself.
I'd seriously consider using this, just because of the stagnancy of jQuery UI. It's a massive project with hundreds of long-open tickets (despite thousands of dollars spent on incentivizing developers over the summer through http://rewardjs.com/). 1.8 was released in March of 2010, and the last milestone release for 1.9 was back in May.
To be fair, a lot of jQuery UI's development headaches come from supporting IE6, while Kendo only touts its support for IE7+...
I would like to make a guess and say that the stagnancy of jQuery UI has a lot to do with jQuery Mobile (which if I'm not incorrect actually is a child-project of jQuery UI). I do however agree, jQuery UI is in many ways awesome, but needs to pick up speed.
Demo pages are completely broken for keyboard navigation (try tabbing or activating the accordion widget). Wake me up when the hard stuff is actually working (accessibility!)
I'm having a hard time nailing down what the killer features are here. For example, I saw that they advertise drag-and-drop with support for touch devices, but I couldn't even find the drag and drop demo on the site.
Thanks. I'll be checking this out, although I was hoping they would also have something equivalent to jQuery's Sortable (http://jqueryui.com/demos/sortable/).
I've learned from experience to run away from these kinds of UI kits. I always end up hacking around their shortcomings (e.g., tokenized inputs with autocomplete, etc.)
This one does seem to have a nice, compact, intelligible stylesheet, though – big improvement over jQuery UI there.
I couldn't say if jQuery UI is better or this is better, honestly seems they are just different. Even if Kendo UI is faster I have never had a speed issue with jQuery UI (not speaking for everyone, just, I personally have never had a speed issue).
jQuery UI is pretty sluggish under some of the iOS build-app-in-JS frameworks (e.g., PhoneGap) and for webapps because those don't use the new nitro engine (I understand that's coming in iOS 5). It's not nearly as bad under standalone Safari with a mobile web page. If someone wanted to test their performance claims, that might be a good thing to try.
The problem I have with this and JQueryUI is that both are still too stylized such that they don't lend themselves well to being integrated into an existing design. And the JqueryUI themeroller doesn't help much. YUI probably does the best job of being generic enough to utilize broadly.
For some reason, in Chrome 13 on OS X, some of the UI animations cause the browser view to go black for a second and redraw. Not sure if this is just a Chrome bug but it's really obnoxious and means I won't use it until it's smoother.
It can be seen as flicker in Windows and there are some reports of black flashes in OS X. Switching the 3D acceleration off seems to fix them, but unfortunately it can be done only with a command line switch. We may forfeit the CSS transition animations in Chrome in later releases if we can't find a fix for these issues.
This is a bit off the topic of your actual framework, but as far as branding, I love your logo. Do you mind sharing the person/company that designed it for you?
It looks pretty good. Good UX and well designed, and I see that it's based on jQuery. That's useful for many reasons, e.g. you can least pull jQuery from a CDN.
The .js file is coming in at 233.85 kb when pulled from the CDN, but that's the whole framework. I think it's highly likely that they will create a modular packaging system so you can get just what you need.
I apologize in advance if this opinion offends anyone, but every HTML UI kit that I've seen simply can't hold a candle to native kits such as WinForms, WPF or even Cocoa. I would really love a write-once browser based solution, but I just can't see that type of solution ever catching up to native tech.
How long do we have to wait before the browser can catch up? Do you think it will ever happen?
The closest thing that I've ever seen is Silverlight. With it I've been able to make some very excellent front-ends, with EASE, that look and behave identically between Mac and Windows. EDIT: The only challenge with Silverlight has been wheel-scrolling, which works fine on Windows but only works in Out-Of-Browser on the Mac.
I am working on a UI lib which is written in Javascript and completely painted on HTML5 canvas. I know, crazy idea... I got rid of the incompatibilities of the browsers, I got rid of DOM: I defined my own event system, component graph, etc... This will be someting like a traditional desktop component based UI, just in javascript, in the browser. Styling will be far more advanced than CSS: you can even inject a custom paint method into a component from a stylesheet. (stylesheets will be javascript classes). Also it will have advanced dynamic layout. (min/max/preferred sizes, weights, gridpanel with colspan, rowspan, etc...)
I am doing it in my free time (at nights), because I have no funding: it is a quite huge undertaking: I am ready with 5300 lines of code, but I still need a couple of weeks just to release a very early demo. My secret aim is to make it a flash/flex killer in the long term. In the very long term:)
But won't using the canvas for this eliminate the compatability in older browsers? Which not caring for older browsers would help resolve a lot of the pains of working with the front end in browsers...
In my experience it's going to be very hard to make moving elements around performant, unless you're using multiple canvases (which is basically just using the DOM) or you use WebGL. How are you going to solve this problem?
At styling and layout I use dirty flag managment, so that branches of the component tree is restyled or layed out only if needed. This kind of dirty-management makes stuff a bit more complicated than otherwise, but this is a tradeoff. At painting I did not implement caching (painting to a memory buffer) and dirty flag management yet, but here I will also do optimizations in the future. This is a bit tricky, as painted components can have alpha/trasparency.
The most serious bottleneck will be probably painting (everything else can be addressed with algorithmic optimizations).
At the beginning of the project I've looked at canvas painting benchmarks, and I decided canvas performance is already quite good. The slowest is drawing texts, but even that is not that terribly slow. I expect that canvas performance will improve in the browsers in the future so time works for me.
Currently my samples' performance feels acceptable, although I did not do serious performance tests yet (and as I mentioned I did not implement the most agressive optimizations regarding painting yet.)
TL;DR: Making this fast is quite challenging, but not undoable I think.
Why don't you just write a Canvas backend for an existing toolkit like gtk or qt? You'll never be able to implement all the details of a sufficiently wide range of controls on a one-man (or even 10) part time basis.
The biggest fun of the project was that I was completely free to design the system from the ground up (except the canvas drawing functions).
Regarding the amount of work I have to be strategical.
I try to concentrate on a relatively small core system: get the philosophy right, tune the performance as much as possible. The components which are 'ready' right now: Window, Button, ScrollBar, ScrollPanel, GridPanel, TextEditor, StaticDoc. (StaticDoc is a read-only RichText component, kind of the original HTML.)
The other absolute necessary things needed in the near future: TabPanel, DataTable, CheckBox, ComboBox.
To go further I will certainly need outside help (either other programmers or funding or third party component creators). I cannot create a huge component lib myself. But 10 people can do lots of things I think.
I completely agree and I am very sad that a lot of people can't be rational about this. The vision of HTML5 may be towards that direction, but when I do a simple test with SVG and found ugly issues on Google Chrome (I move a specific object but it left a trail behind) then I understand that we are far from there, may be 2 years in development and business terms?
Also the development side, something like the criticized old Visual Basic, an IDE where you can quickly design a rich UI with a lot of controls. It will be an irony if the best IDE for HTML5 came from Microsoft on Visual Studio >= 2012? http://webcache.googleusercontent.com/search?q=cache:zNKE5vp... Macromedia, Google et al have opportunities but they move slowly in this direction.
Cappuccino is the best implementation out there, because the most important thing we strive for is conformance with Cocoa behavior. Cappuccino is certainly at par with Cocoa with most things.
I'm in the same boat. The problem I keep finding with a lot of these UI libs is that they don't have layout managers. We settled on dojo because we wanted an open source option with a layout manager, but it's got other headaches we need to deal with.
I'm the last one to hold his breath for fear of vaporware, but I have high hopes for a new Sproutcore UI kit. I want robust client-side UI elements that bind easily to a REST API. I feel like we're right on the cusp of that revolution.
Sencha isn't even remotely cross-platform, with support restricted to the latest webkit-based browsers with decent CSS3 support. Sencha's UI is pretty bad on any other device but an iPhone.
Yes, it is very convenient to work with if you're used to programming desktop UIs. I found that ExtJS is great for (admin) backends especially now that it integrates charting.
It appears to be more oriented toward enterprises, who'd be happy to license this just for internal web apps. You've got Grid and Chart widgets (must-haves for internal sites that show business data), but no Datepicker (a must-have for consumer-facing sites).
I'm not sure I buy that. I've been looking at moving some of our antiquated Access reports to an intranet web form, and the first thing I needed was a datepicker.
1. Good documentation that doesn't just define the framework, but teaches you how to use it and get stuff done with it. Code already defines what it is, your docs should tell me why it's this way and how to use it. In Kendo UI they've got a list of dependencies for javascript projects they need, then a few code snippets with no explanation as to why or how they work.
2. Good sample code, in a full complete project you can download, with documentation on getting it up and running. Your first sample code is how everyone will write code using your project. If you've got bad samples, poor formatting, and weird file layouts (or none), then that's what everyone will write and that's what you'll be known for.
3. Examples that gradually increase in complexity. Start off with a simple hello world, graduate to a chat app or something simple, and get them to a full blown large application. In this Kendo example they've got a demo picture viewer, with no explanation for how it was built, and viewing the source it looks like a huge mess.
4. Humor. These kinds of documentation are boring as hell, especially if you're just defining everything. It doesn't have to be insanely hilarious, but at least throw a few little funny tidbits in the code. Even the great tech books of our time have tiny little jokes for the people who pay attention.
5. Finally, these frameworks rarely have a "theme". MVC is a theme. Convention over configuration is a theme. There's only one way to do it. There's more than one way to do it. Themes work to help people keep the script for why everything works the way it does in their head.
It's too bad because this looks really good, and it could be the most awesome thing on the planet. But if I can't figure it out even if I want to, then I'm never going to try.
Finally, none of what I wrote above applies if your project is for fun and not meant to be a "product".