Software Architect at Genzeon Corporation in Malvern, Pennsylvania, Microsoft .NET MVP, Husband, Dad and Geek.
34133 stories

KendoReact: What Can It Do for You?

1 Share

In this first post in the Getting Started with KendoReact series, you'll learn what KendoReact can do for you, the React developer.

The Kendo UI team has been building component libraries for over 15 years and they have gained a lot of experience with user interface components in particular. They've built them for jQueryAngularVue, and now they're out with a true native component library built specifically for React.

A license holder of the React libraries also has access to the jQuery, Vue and Angular libraries as well. Not that anybody would ever stray from React or have different projects where they use different libraries . But, just in case, you have all of our JavaScript libraries at your disposal.

Why React?

We decided to build a library specifically for React, because React is cool . Okay, but more importantly, a lot of developers use it, including myself and probably you. The Kendo UI team wanted to build a library that would make React applications more efficient, faster, and easier to build. This is why we have a library that's specifically made with native React components. No funny business behind the scenes with wrappers and such, although we do have jQuery wrappers for React if that's what you prefer. But we advise those starting fresh to use our native component library for React instead.

What all does that mean for your React application? These React components are composable and precisely configurable to give you the ability to work with them just as you would any other React component. They support controlled and uncontrolled state - in both cases, we got you covered!

What Other Components are There?

To check out a list of all of the components (to date), just head over to the KendoReact page and explore. It's a long list, so feel free to take a minute before getting back to the article. I should also mention that we have a roadmap to see what's coming in the future.

To use these components, all you need to do is install them using npm, import them into your existing React project, add them to your JSX template, and that's it!

If you have a basic Create React App started we can try it with the following npm install command:

npm install @progress/kendo-react-ripple @progress/kendo-react-buttons @progress/kendo-theme-default

Then, in the App.js file, we would import the following:

import { Ripple } from '@progress/kendo-react-ripple';
import { Button } from '@progress/kendo-react-buttons';
import '@progress/kendo-theme-default/dist/all.css';

With the following component definition:

class App extends React.Component {
  render() {
    return (
      <div className="example-wrapper">
          <p>Ripple on Buttons</p>
          <Button>Primary Button</Button>

Here is the output we will get:

Ripple on Buttons example 

It's pretty easy, and one of my favorite things about using KendoReact is that styling is done for you when using our Sass themes. We know CSS isn't easy for everyone, and even if it is easy for you, it's still nice to have a theme to work with. For this reason we have created several of them, including our Kendo Default theme, Material theme, and a Bootstrap theme. With these, all you need to do is install the theme with npm and then import it into your project. As we did in the example above, the theme is one npm install and an import:

npm install @progress/kendo-theme-default
import '@progress/kendo-theme-default/dist/all.css';

With minimal effort, the themes give you lovely styled components that are consistent across your application, across components, and across projects. You don't have to touch the CSS files unless you want to provide overrides or additional customization. You also get different interactions and animations with these style libraries.


Support for accessibility is very important to us, we want everyone using your applications to feel comfortable. It can take time and effort to meet standard accessibility guidelines, but for our components, again, we got you covered. When you use the Kendo UI components we give you a lot of accessibility right out of the box. This includes Section 508 compliance, W3C web content accessibility guidelines, WCAG 2.1, WAI-ARIA and keyword navigation. This relieves you from having to put major development hours into custom-built components of your own. Instead, just use KendoReact because accessibility comes with the components.


We also provide standard internationalization support if using dates (or numbers like date input) as well as grids, numeric text boxes, etc.

Support When You Need it

At some point, everybody needs a little help! In those cases where you may hit some bumps in the road or you may not understand something, for our license holders, we offer different sources of help and support. This includes three support options for rapid help from the developers who make the product, as well as an option for 24-7 human support for tailor-made projects. You can also visit community forums where other people who are using the Kendo UI library and actual Kendo UI team members are there to help you answer questions, have discussions, and talk about different strategies they using our components.

Demos, Tutorials and Examples

There are more resources like interactive demos that you can explore. We also have example projectswebinarsblog posts, and tutorials that will give you more resources to help you. A little extra to help guide you beyond the documentation that we already have for each component.

Stay tuned for the upcoming Second Post of the series (not yet live, look out for this soon!)

Read the whole story
9 hours ago
West Grove, PA
Share this story

A Year of Q#

1 Share

The Quantum Architecture and Computation group launched Q#, our quantum computing programming language, a year ago on December 11th, 2017.

Q# 0.1 was the result of a lot of hard work from a small, dedicated team of developers, researchers, and program managers. We had made the decision to build a domain-specific language for quantum computing about six months before we launched, so we were on a very tight schedule. We were lucky to have a great team of people who all pitched in and did what needed to be done so that we could meet our extremely aggressive timetable.


Inside the team, we speculated on what level of interest Q# would attract. We hoped that we might receive a few hundred downloads, but we were blown away when we crossed 1,000 users by about 9 hours after launch. That said, with so many users installing the Quantum Development Kit and trying to write simple programs in it, bugs started popping up. In order to deliver the best experience for our users, we released a patch in January that addressed issues like floating-point literals that were handled incorrectly in certain locales, and allowed the simulator to run on older machines without vector instructions support.

We also addressed portability feature requests in our 0.2 release in February 2018, which saw us move from the .NET Framework to the open-source, cross-platform .NET Core. This allowed us to easily support macOS and Linux as well as Windows for building and running Q# code. We also added support for VS Code on all platforms (the 0.1 release was limited to Visual Studio on Windows). As part of the 0.2 release, we were able to make the majority of our libraries and samples available under an MIT license.

Long Hot Summer

We decided to take advantage of one of our team members’ expertise in organizing coding competitions and run a Q# coding competition to engage non-quantum developers with Q# and quantum computing. After a couple of months of preparation, we ran the Q# Coding Contest in early July. Again, the results exceeded our expectations: 514 participants in the warmup round, and 389 in the actual contest. 100 participants solved all the problems, and a lot of them even asked for more challenging ones!

To help make Q# and quantum computing more accessible to the public, we also launched self-paced programming tutorials: the Quantum Katas. We’re up to 10 katas already, and more are coming!

Spring, Summer, Autumn

We started planning the next major release in the spring of 2018, after shipping our 0.2 release: we wanted to rebuild our compiler to work as a language server, to give Q# developers the same interactive error checking and IntelliSense features they’re used to for languages like C# and F#. We knew this would be a huge amount of work and would require a significant re-architecture of the compiler in order to work incrementally. We didn’t want to wait longer to do this work, though, because we wanted to give our users the kind of modern programming environment they’re used to.

We spent the spring and summer re-architecting and rewriting the Q# compiler and shipped the new Q# compiler as our 0.3 release at the end of October.

The 0.3 release also includes a new, open source quantum chemistry library. This library integrates with NWChem, a powerful and popular open source computational chemistry package. The integration is based on the open source Broombridge schema.

Whatever Next

What’s next for Q#? No spoilers (yet!).

The last blog post of the calendar, scheduled for December 24th, will look at some of the things we’re considering for Q# in the coming year.

Until then, enjoy the holidays!

Congratulations to everyone who can figure out what the section titles have in common…

Alan Geller, Software Architect, Quantum Software and Applications

Alan Geller is a software architect in the Quantum Architectures and Computation group at Microsoft. He is responsible for the overall software architecture for Q# and the Microsoft Quantum Development Kit, as well as other aspects of the Microsoft Quantum software program.
Read the whole story
9 hours ago
West Grove, PA
Share this story

Prototypes and production

1 Share

There’s an interesting distinction that Jeremy Keith defines between prototype code and production code in this post and I’ve been thinking about it all week:

...every so often, we use the materials of front-end development—HTML, CSS, and JavaScript—to produce something that isn’t intended for production. I’m talking about prototyping.

What’s interesting is that—when it comes to prototyping—our usual front-end priorities can and should go out the window. The priority now is speed. If that means sacrificing semantics or performance, then so be it. If I’m building a prototype and I find myself thinking “now, what’s the right class name for this component?”, then I know I’m in the wrong mindset. That question might be valid for production code, but it’s a waste of time for prototypes.

I love the way that Jeremy phrases all of this and how he describes that these two environments require entirely separate mindsets. When prototyping, for instance, we can probably overlook optimizing for accessibility or performance and even let our CSS standards slip in order to get something in the browser and test it as quickly as possible.

Earlier this year, I echoed some of the same thoughts when I wrote a little bit about prototyping in the browser:

I reckon that the first time a designer and/or front-end developer writes code, it should never be in a production environment. Having the leeway and freedom to go crazy with the code in a safe environment focuses your attention on the design and making it compatible with a browser’s constraints. After this, you can think about grooming the code from a hot, steaming heap of garbage into lovely, squeaky-clean, production-ready poetry. Translating the static mockups into an interactive prototype is the first step, but it’s vital to have a next step to enforce your code standards.

Direct Link to ArticlePermalink

The post Prototypes and production appeared first on CSS-Tricks.

Read the whole story
9 hours ago
West Grove, PA
Share this story

Rust 2019: Think Bigger

1 Share

Rust shines when we find ways to have our cake and eat it too: memory safety without runtime garbage collection, abstraction without overhead, threading without data races. We must find new ways to continue this tradition for Rust 2019 and beyond.

On a day-to-day basis, I am dedicated to small, incremental progress. If a pull request is an improvement over the status quo, merge it now! Don’t wait for the pull request to be perfectly pristine or the feature to be 100% complete. Each day we drag reality inch by inch towards the ideal.

However, when planning on the scale of years, our vision must not be weighed down by discussion of incremental improvements: we must rise and collectively define the lofty ideals we aim for. It requires avoiding local maxima. Nick Cameron’s Rust in 2022 post, where he starts with what we might want in a Rust 2022 edition and then works backwards from there, is a great example.

With that out of the way, I will make a couple suggestions for the Rust 2019 roadmap. I will leave my thoughts for the Rust and WebAssembly domain working group’s 2019 roadmap for a future post.

Speed Up Compilation

Tired: make rustc faster.

Wired: integrate distributed compilation and artifact caching into cargo and

Of course we should continue identifying and implementing performance wins in rustc itself. We should even invest in larger scale rearchitecting like adding finer-grained parallelism in with rayon (I won’t go into too many specifics here because I’m largely ignorant of them!)

But we should also be thinking bigger.

The fastest compilation is the one that you didn’t have to do. If we integrate something like sccache into cargo and, then individuals can download pre-built artifacts for common dependencies from a shared cache and save big on local CPU time. In comparison, a 5% speedup to trait resolution is peanuts. This is an opportunity that is not available to most language ecosystems! Most languages don’t have a compiler toolchain, build system, and package manager that are widely used together and well integrated.

First-Class, Domain-Specific Workflows

Tired: make wasm-pack really good.

Wired: make wasm-pack unnecessary by building generic task hooks into cargo itself.

Different domains have different workflows that extend past cargo build. With WebAssembly, we must also generate JavaScript bindings, run tools like wasm-opt, create a package.json to integrate with NPM and JavaScript tooling, etc… For embedded development, you need to at minimum flash your built program into your microcontroller’s persistent memory.

To perform these tasks today, we typically write whole new tools that wrap cargo (like wasm-pack), invoke external tools manually (like using openocd by hand), or write a cargo-mytask package to add the cargo mytask subcommand. These solutions suffer from either repetition and a lack of automation, or they wrap cargo but fail to expose all the wonderful features that cargo supports (for example, you can’t use the --feature flag yet with wasm-pack). We should not write these tools that wrap cargo, we should write generic build tasks, which are invoked automatically by cargo itself.

cargo should not just grow a hook, its build tasks and dependencies between tasks and artifacts should become fully extensible. I should be able to depend on wasm build tasks in my Cargo.toml, and then after that cargo build should just Do The Right Thing. I shouldn’t have to compile these wasm build tasks for every project I use them with. cargo and should handle transparently distributing the wasm task binaries to me.

Growing Working Groups

Tired: the Rust project should start a working group for $PROJECT_OR_DOMAIN.

Wired: the Rust project should have a working group template, and system of mentorship for new (and old!) working group leads.

The more we collaborate and work together, the better we can tackle problems that are larger than any one of us. The primary way we’ve been organizing technical efforts in the Rust project has been working groups. But starting a new working group is hard, and leading a working group is hard.

We should have a template for new working groups that comes with cookie-cutter steps to follow to help build an open community, articulate working group vision, and collectively organize. Of course these steps will need to evolve for each particular working group’s needs, but having something to help new working groups hit the ground running is incredibly valuable. It would have been so useful for me when we were kicking off the WebAssembly domain working group last year. A lot of things that are obvious in retrospect were not at the time: hold weekly meetings, adopt an RFC process, communicate(!!), create room for contributors to own sub-goals, etc…

Additionally, every working group lead should have a mentor who is in a leadership position within the Rust project: someone who is a member of the Rust core team or a lead of another working group or team. Someone to rubber duck with and seek guidance from in the context of leadership and organization.

Instead of enabling Rust users to ask Rust leadership for a working group for X, we should empower them to start the working group for X themselves, and we should continuously follow up to ensure that they succeed. To have our cake and eat it too, Rust development must be a positive-sum game.


Whatever we end up with in the 2019 roadmap, I have faith that what we choose will be worthy. We don’t suffer from a lack of good options.

I hope we never stop dreaming big and being ambitious.

Read the whole story
9 hours ago
West Grove, PA
Share this story

Organisation-wide teams in Microsoft Teams: what and how

1 Share
Will organisation-wide teams in Microsoft Teams be one of the final nails in Yammer’s coffin? Maybe, maybe not. The answer is: “it depends”. There are some reasons why you would choose one over the other. Some are technical limitations or features, others are around being fit for purpose. In my latest piece for AvePoint I […]
Read the whole story
9 hours ago
West Grove, PA
Share this story

Splitting widgets to methods is a performance antipattern

1 Share
Action asphalt originally published on

Originally published at on December 11, 2018.

It has been almost 6 months since I wrote an article on cleaning up Flutter UI code.

The article had several tips on how to organize your Flutter UI code for less clutter and more readability. And it’s still a quite popular article. However, there was this one tip there that advocated doing something that turned out to be a not that good thing to do.

To escape the Lisp-y bracket hell, I advocated for splitting long build methods into multiple separate smaller methods. The following code sample is entirely nonsensical, but we’ll pretend that this is a snippet that does something really useful.

So, for example, if we have a widget that looks something like this:

Looking at the code, you might get a sense that the nesting level gets a little crazy.

And they do. It would be awesome to reduce the indentation level a little bit. Since widgets can be a little boilerplatey, the first solution that comes into mind is to split the nesting part into a separate method.

Our first intuition might end us having something that looks like this:

Problem solved, right? Time to call it a day and go home!

Well, not quite.

The problem with splitting widgets into methods

At first glance, splitting long build methods into small functions makes perfect sense. And you can certainly see this pattern used in the wild a lot. It’s also in heavy use in our codebase at Reflectly — and believe me, we have a bunch of UI code.

Now, 6 months later after my initial article, I’m here to tell you that you shouldn’t do this. If you picked up this bad habit after reading my article, you might be a little pissed at me right now. And you’re welcome. This is what friends do for each other. I’m very sorry.

The issue with this was first brought to my attention by Wm Leler in the comment section of the aforementioned article.

Wm Leler’s comment explaining how splitting widgets to functions is a performance antipattern.

Wm Leler’s comment explaining how splitting widgets to functions is a performance antipattern.

For those that don’t already know, Wm is a developer advocate for Flutter.

Some of you that read Wm’s comment will have an a-ha moment right now. However, some of you, including me initially, won’t. And that’s fine — we’ll learn what is going on here.

So what’s the problem, really?

Whenever the value of _counter changes, the framework calls the build method. This triggers our widget to rebuild itself. The problem is that _buildNonsenseWidget() gets called every time the value of _counter changes - which ends up rebuilding the widget tree over and over again.

Rebuilding for nothing

In this case, there’s no reason to rebuild that particular widget tree.

The widget tree returned by _buildNonsenseWidget() is stateless by nature - we only need to build it once. Sadly, because the widget tree is built by the _buildNonsenseWidget() method, the Flutter framework rebuilds it every time when the parent widget rebuilds.

Essentially, we’re wasting precious CPU cycles in rebuilding something that doesn’t need to be rebuilt. This happens because from the framework’s perspective, there’s no difference between a long-ass build method and a build method split into multiple smaller methods. Mind you, this is only a simple example — this has a more significant impact on more complex apps.

Splitting long build methods — revisited

The solution for this one is relatively simple, although it results in a couple of extra lines of code. Instead of splitting build methods into smaller methods, we split them into widgets — StatelessWidgets, that is.

When we refactor the previous example, we’ll end up with this:

While it’s a little more code, this is much better.

Now the _NonsenseWidget is built only once and all of the unnecessary rebuilds are gone. The parent widget can rebuild itself multiple times, but the _NonsenseWidget doesn’t care - it’s built once and once only.

You might be thinking that the above was a really simple example and it doesn’t represent the complexity of a real app.

And you’d be right. I recently updated the open source inKino app to follow the advice on this article. For example, I think this is a good sample of splitting widgets into smaller StatelessWidgets in a bigger app.


Instead of splitting you build methods into multiple smaller methods, split them into StatelessWidgets. This way, you won’t be rebuilding your static widget trees multiple times for nothing but wasted CPU cycles. When it comes to optimizing performance of Flutter apps, this is probably one of the lowest hanging fruits.

If you really prefer building your widget trees with methods, you might want to take a look at a package called functional_widget by Remi Rousselet. It alleviates the problems that come with building widget trees with methods by using code generation.

Originally published at on December 11, 2018.

Flutter Community (@FlutterComm) | Twitter

Splitting widgets to methods is a performance antipattern was originally published in Flutter Community on Medium, where people are continuing the conversation by highlighting and responding to this story.

Read the whole story
9 hours ago
West Grove, PA
Share this story
Next Page of Stories