Curious about our plans for Kendo UI for React? Read on for our update about the future of the suite.
Let's start with the great news. Thanks to the feedback received from you, we decided to resume the work on React UI suite, also known as Kendo UI for React. We recognize the platform as a prominent force that will shape web development in the near future. ThoughtWorks puts it in the "adopt quadrant." We love it.
"I believe React is the new jQuery." - Burke Holland, DevRel, @ProgressSW
You seem to like it, too. Our blog post from last October, Kendo UI for React—The Road Ahead, spurred a healthy discussion in the comments, plus some additional insights in my mailbox. Enough waiting, it’s time we get a move on!
Lessons We Learned from Angular
Kendo UI supports AngularJS 1.x through directives that wrap our jQuery widgets.
For Kendo UI for Angular 2, we started fresh with a pure implementation based entirely on the framework concepts.
#1 - The Wrappers Approach is a Compromise
While good enough for many, the Kendo UI AngularJS 1.x wrappers have to co-exist with our existing two-way binding implementation and data binding abstractions, and sometimes you just had to reach out to jQuery for certain scenarios.
Some of you welcomed that. Kendo UI was your known companion as you explored the unknowns of the AngularJS framework. As projects grew and matured, many recognized the wrappers approach as a bottleneck, an impediment, and a foreign citizen. At times, we could not keep up with the breaking changes introduced in the releases. Many of you were not happy with the insufficient amount of Angular-specific help topics and code samples.
The wrappers approach is not the first-class toolkit a major web framework deserves. They can be "good enough," on time and still bring a lot of value. But they won't bring the raving fans. Ultimately, will the very developers pushing React ever stand behind a wrapper approach?
#2 - The Pure Approach Feels Great, but Takes Time
Our Angular 2 UI suite does not suffer from the limitations and gotchas of the wrappers approach. It supports the platform features properly (at times being the only UI suite that does it) and it will automatically pick up any underlying performance improvements.
Ultimately, it's not just about getting a quick solution out there. Instead, we want to get everything right and deliver something that all React developers will want to use. Unfortunately, this presents a key downside: this approach ends up taking longer to deliver the final product.
"Thanks for answering. The problem is that my customer doesn't want to wait till you release Scheduler."
- Reply from a forum thread about the Scheduler for Angular 2 availability
Verdict: Wrappers vs. Pure
We can safely say that both the wrappers and the pure approach have their pros and cons. But which one should we pick for React?
Well, why not? The wrappers may be the short-term solution that can help you with something until the real thing becomes available.
The biggest challenge with the dual approach is the lack of compatibility between the wrappers and the pure implementation. How much is the migration going to hurt? We don't know yet, but we don't see a point in making the pure implementation backward compatible with the wrappers—this means backporting things that don't look right in the platform context.
Despite the challenge, doing both wrappers and pure implementation seems like the best thing we can do for you. Support for wrappers as a short-term solution while at the same time working on the pure implementation as the recommended, long-term solution.
While our engineering team is busy dusting off the Babel Webpack setup, let's talk. The feedback we received previously was very positive and helpful; it helped us to really understand where the platform fits in your priorities. Please help us again by letting us know how your React adoption os going. What do you need right now? Do you need more help with some short term wrapper solution or guidance on how to use the jQuery widgets in React?