Why Paid UI Components Aren’t Evil

Rate this content
Bookmark

In this talk I’m going to convince you that paid UI components will solve all your problems, and that you should immediately give me all of your money. Maybe. Or perhaps I’ll draw on my experience working both on free and open source tools (jQuery, jQuery UI, NativeScript), as well as paid tools (Kendo UI, KendoReact), and discuss which type of tool makes sense depending on your team and needs. In any case the talk will go fast because lightning is in the title.

This talk has been presented at React Summit 2020, check out the latest edition of this React Conference.

FAQ

Paid UI components offer guaranteed support, long-term reliability, solutions to complex problems, adherence to accessibility standards, and a more sustainable financial model for developers.

Paid UI components, such as those from Kendo React, often come with guaranteed support services like dedicated response times. For instance, with all Kendo React licenses, you are assured a 24-hour response time for any issues.

Paid UI components provide long-term peace of mind as there's a financial incentive for the authors to continue updating and maintaining the software, unlike free UI tools that may become outdated if the creators lose interest.

Paid UI components are often designed to address more complex and specific requirements, such as creating advanced Gantt charts or comprehensive scheduling systems like an Outlook calendar for web applications.

Developers of paid UI components, like Kendo React, dedicate resources to ensure their products meet various accessibility standards and support globalization, which may be inconsistent with free alternatives.

Paid UI components have a direct financial model where users pay for the software, ensuring developers are compensated for their work. This contrasts with free tools that might rely on uncertain funding through donations or sponsorships.

Yes, paid UI components such as those from Kendo UI are continually maintained and updated with new features, even years after their initial release, ensuring they remain relevant and useful in the long term.

Paid UI components can save time by reducing the need for extensive troubleshooting and by providing out-of-the-box solutions for complex functionalities, which accelerates the development process and reduces time to market.

TJ VanToll
TJ VanToll
8 min
17 Jun, 2021

Comments

Sign in or register to post your comment.
Video Summary and Transcription
Paid UI components offer guaranteed support and long-term peace of mind. Unlike free tools, paid components often come with dedicated 24-hour response times and ongoing updates. They solve harder problems and provide features like advanced Gantt charts or comprehensive scheduling systems. Paid components ensure better accessibility and globalization, making them a reliable choice for developers. They have a direct financial relationship with users, eliminating the need for uncertain funding models. This video also highlights that paid components save developers time by providing out-of-the-box solutions, reducing troubleshooting efforts, and ensuring long-term reliability.

1. Paid UI Components: Not Evil

Short description:

Today, I'm going to talk about why paid UI components are not evil. Free software lowers the barrier for newcomers, but there are benefits to paid components. The first reason is guaranteed support. With paid UI components, you often get dedicated 24-hour response times. The second reason is long-term peace of mind. Free tools may not be actively maintained. Paid components provide ongoing support and updates.

[♪ music playing ♪ Hey, everyone. Today, I'm going to talk to you about why paid UI components are not evil. And the reason I want to give this talk is that almost all the software that we use on the front end today, so think about React and all the different React tools and components that we use, they're basically all free, which is kind of awesome, actually, mostly because it greatly lowers the barrier for newcomers to get started in the industry.

Now, back when I was getting started on software and also apparently nine feet tall, I wanted to use what the cool kids at the time were using, which were tools like Flash and Java. But the problem is, these things cost money and poor high school, college TJ couldn't afford them. So instead I moved over to the web because the tooling there was something that was completely free. And really, this is how my career got started and the reason that I'm here today. I went on to work for the jQuery project I spent two years working on jQuery UI. So if you're building apps with jQuery UI 10ish or so years ago, you might've used components and controls that I helped build and maintain.

For the last few years though, I've worked for a company called Progress and on a UI component suite called Kendra React. And importantly for this talk, we charge money for the controls that we make. And having worked now on both sides of the equation for both free and paid UI components, it's given me a whole different perspective. For example, you might assume that our biggest competitors for Kendra React would be other paid UI component suites. But actually what we find is we mostly fight against developers' sort of expectations, especially front end and React developers, that all controls and all software for this world are free. So you'll see things like free in search terms and on lists of components and such in recommendations. So today I want to give you four reasons to at least consider paid UI components. And this a lightning talk, so we're going to make these four lightning reasons and go through these kind of quickly.

So the first reason is guaranteed support. With free UI controls, the help that you receive is largely dependent on how willing the community is to devote their time, which sometimes can work out great. But other times it can mean you're digging through long stack overflow threads or huge GitHub issue lists to try to find help that you need. With paid UI components, one thing you often get is some form of guaranteed support. So for example, with all Kendo React licenses, you get dedicated 24 hour response times. Essentially, you have an issue, you create a ticket with us, we're guaranteed to get back with you and help you out within 24 hours. Reason number two is long-term peace of mind. So another problem with free UI tools is that there's no real incentive for the authors to continue working on their project after their sort of initial motivation to create the thing occurs. And because of this, there is no shortage of sort of projects that haven't been touched in a long time on GitHub and throughout the web. And to be clear, I'm not blaming the authors for this in any way. After all, they're putting their work out there for free. But rather, as sort of Ben Lesch, who's the author of RxJS said, anyone that thinks they want to be the owner of a popular open-source project is a fool, which is something I can commiserate with from my time on jQuery. I got a lot of benefit out of working out of the jQuery project, but I also had to deal with some of the worst of the worst on the internet from people that wanted to know why their date picker didn't work in their super complex application.

2. Benefits of Paid UI Components

Short description:

When you pay for software, you have a direct financial relationship that isn't so dependent on the author's goodwill and motivation. Paid UI components often solve harder problems and provide features and guarantees that aren't necessarily a given with free controls. With paid UI controls, you get more of a same funding model, eliminating the need for weird sponsorship or donation models. Paid UI components offer benefits such as guaranteed support, long-term peace of mind, solving harder problems, and having a more direct financial relationship with the authors.

When you pay for software, you have a direct financial relationship that isn't so dependent on the author's goodwill and motivation. And that makes the project much more likely to stick around. So for example, with Kendo UI, we launched back in 2011. And if you used our series of jQuery plug-ins on day one, those are jQuery plug-ins that we're actually still maintaining in 2020. We're actually still adding features to those components as well. So we've been around for the long run.

Reason number three is paid UI components often solve harder problems. There are a lot of developers out there trying to make the world's best React date picker, and you can find lots of great free ones out there. There are fewer developers out there trying to create the world's best React Gantt chart, which is something that we ship as part of Kendo React, or the best scheduler, basically creating like an Outlook calendar in your browser, which is also something we ship as part of Kendo React as well. Paid UI components also tend to ship features and guarantees that aren't necessarily a given with free controls. So for example, on Kendo React, we spend a lot of time making sure all of our components adhere to numerous accessibility standards and provide globalization support, which again, with free controls, can be hit or miss, especially if you're trying to piece together a number of different free controls and make them work well together.

And finally, last on my list is with paid UI controls, you get more of a same funding model. And I include this because in our front-end world today, the value of this software that we use, again, think of the different React's tools and components that you use in your day-to-day job, is in no way equal to the actual amount of financial value that these developers are actually compensated with, which has some frankly kind of bizarre consequences. For example, we now see things like NPM install logs containing advertisements, which is something that somebody tried to do. And if you write React, you've probably seen a core.js person asking for jobs, which is something that happens as well. There's a sort of weird set of foundations out there with some very nebulous funding models. There are things like Patreon and GitHub sponsors, which are things you probably feel like you should contribute to for some tools you use, but you probably also aren't either. When you pay for software, you don't have to worry about how the developers behind the software are getting paid because the relationship is way more direct. For example, at Kendo React, we make a suite of 80 plus React UI components and you pay us money if you want to use them. There's no weird sponsorship or donation model.

Now to be clear, I'm not saying that paid UI components are a panacea. We're not going to solve every problem that you have for your applications. Instead, I'd encourage you to do just a bit of a time benefit analysis because front-end developer's time isn't cheap and there are some real cost in time savings to be had from having things like guaranteed support from knowing you're going to hear back on issues that you have within 24 hours, from having a bit more long-term peace of mind that the code and the tools you use are going to be around for two, three, five years to come, from solving harder problems, from knowing things like accessibility is something that's going to be taken care of for you, and from having that more direct financial relationship with the authors of the tools that you build. So the next time a new app comes up, you're starting a new project, a new initiative, I'd encourage you to at least consider paid UI solutions. Have us on the list of things that you're going to test out. And if you're interested in trying Kendo React, you can learn more about kendoreact.com. And if you have any questions, you can ask them to me throughout this event, and I'm also at TGEventHole on Twitter. So thanks.

Check out more articles and videos

We constantly think of articles and videos that might spark Git people interest / skill us up or help building a stellar career

Design Systems: Walking the Line Between Flexibility and Consistency
React Advanced 2021React Advanced 2021
47 min
Design Systems: Walking the Line Between Flexibility and Consistency
Top Content
The Talk discusses the balance between flexibility and consistency in design systems. It explores the API design of the ActionList component and the customization options it offers. The use of component-based APIs and composability is emphasized for flexibility and customization. The Talk also touches on the ActionMenu component and the concept of building for people. The Q&A session covers topics such as component inclusion in design systems, API complexity, and the decision between creating a custom design system or using a component library.
Towards a Standard Library for JavaScript Runtimes
Node Congress 2022Node Congress 2022
34 min
Towards a Standard Library for JavaScript Runtimes
Top Content
There is a need for a standard library of APIs for JavaScript runtimes, as there are currently multiple ways to perform fundamental tasks like base64 encoding. JavaScript runtimes have historically lacked a standard library, causing friction and difficulty for developers. The idea of a small core has both benefits and drawbacks, with some runtimes abusing it to limit innovation. There is a misalignment between Node and web browsers in terms of functionality and API standards. The proposal is to involve browser developers in conversations about API standardization and to create a common standard library for JavaScript runtimes.
Composition vs Configuration: How to Build Flexible, Resilient and Future-proof Components
React Summit 2022React Summit 2022
17 min
Composition vs Configuration: How to Build Flexible, Resilient and Future-proof Components
Top Content
Today's Talk discusses building flexible, resilient, and future-proof React components using composition and configuration approaches. The composition approach allows for flexibility without excessive conditional logic by using multiple components and passing props. The context API can be used for variant styling, allowing for appropriate styling and class specification. Adding variants and icons is made easy by consuming the variant context. The composition and configuration approaches can be combined for the best of both worlds.
Building Cross-Platform Component Libraries for Web and Native with React
React Advanced 2021React Advanced 2021
21 min
Building Cross-Platform Component Libraries for Web and Native with React
Top Content
This Talk discusses building cross-platform component libraries for React and React Native, based on a successful project with a large government-owned news organization. It covers the requirements for React Native knowledge, building cross-platform components, platform-specific components, styling, and the tools used. The Talk also highlights the challenges of implementing responsive design in React Native.
Walking the Line Between Flexibility and Consistency in Component Libraries
React Summit 2022React Summit 2022
27 min
Walking the Line Between Flexibility and Consistency in Component Libraries
This Talk discusses the comparison between Polaris and Material UI component libraries in terms of consistency and flexibility. It highlights the use of the action list pattern and the customization options available for the action list component. The Talk also emphasizes the introduction of a composite component to improve API flexibility. Additionally, it mentions the importance of finding the right balance between flexibility and consistency and the use of types to enforce specific child components.
Find Out If Your Design System Is Better Than Nothing
React Summit 2022React Summit 2022
20 min
Find Out If Your Design System Is Better Than Nothing
Building a design system without adoption is a waste of time. Grafana UI's adoption is growing consistently over time. The factors affecting design system adoption include the source mix changing, displacement of Homebrew components by Grafana UI, and the limitations of Grafana UI's current state. Measuring adoption is important to determine the success of a design system. The analysis of code through static code analysis tools is valuable in detecting and tracking component usage.

Workshops on related topic

Build a Data-Rich Beautiful Dashboard With MUI X's Data Grid and Joy UI
React Summit 2023React Summit 2023
137 min
Build a Data-Rich Beautiful Dashboard With MUI X's Data Grid and Joy UI
Top Content
WorkshopFree
Sam Sycamore
Siriwat (Jun) Kunaporn
2 authors
Learn how to put MUI’s complete ecosystem to use to build a beautiful and sophisticated project management dashboard in a fraction of the time that it would take to construct it from scratch. In particular, we’ll see how to integrate the MUI X Data Grid with Joy UI, our newest component library and sibling to the industry-standard Material UI.
Table of contents:- Introducing our project and tools- App setup and package installation- Constructing the dashboard- Prototyping, styling, and themes - Joy UI features- Filtering, sorting, editing - Data Grid features- Conclusion, final thoughts, Q&A
Should we have business logic in the UI?
JSNation 2022JSNation 2022
148 min
Should we have business logic in the UI?
WorkshopFree
Samuel Pinto
Samuel Pinto
How many times did you say or hear “this is business logic, it should not be here”?In this workshop, we will create a modern frontend application using old patterns and you will learn how to build apps that have decoupled UI and services.We will start with a React application that has its whole logic in the UI. Then step by step we will extract the rules and operations to hit that sweet spot of independence.
Learn To Use Composables: The Swiss Army Knife Of Vue Developers
Vue.js Live 2024Vue.js Live 2024
163 min
Learn To Use Composables: The Swiss Army Knife Of Vue Developers
Workshop
Juan Andrés Núñez Charro
Juan Andrés Núñez Charro
Composables (composition functions) are stateful/stateless functions that can leverage Vue's reactivity API, decoupling it from components.This shift in perspective opens the possibility for tackling common scenarios in a new and creative way. In this workshop, you will learn how to solve typical problems every Vue developer faces, using composables:
- Data store;- Component cross-communication;- Utility functions (DOM, API, etc);And more.