It’s a moment every developer lives over and over again: the company wants to move forward on a brand-new feature and hidden among the requirements is some fairly complex component — a fancy dashboard to display information on a website or a calendar widget so users can sign up for an event in any online calendar that’s ever existed.
In most cases, there are three ways to put these features into production:
Build it yourself. If this component is completely new, then you might not have much of a choice. Additionally, if it’s fairly straightforward and simple to code (like yet another polling widget), it might be easier to build internally.
However, for any component that’s even marginally complex, the amount of support, maintenance, and just plain attention often isn’t worth the effort.
Find an open-source version. Chances are that you’re not the first person to need a feature, so the tool likely already exists as one of many open-source projects in GitHub. This is the most cost-effective solution upfront.
However, with so many options and so many factors to consider, it can be difficult to find the right fit. Plus, depending on the requirements and use cases, there are often hidden costs later on.
Buy a commercial version. While this might seem to be a more costly solution, depending on the use case, having a company support team behind the product often saves you a great deal of time and effort.
There’s no one right answer. Finding the best possible solution means considering your requirements along with the open-source and commercial products available.
This means wading through the large number of products currently on the market — some enterprise-level components with tons of extras, and fairly complex APIs, others open-source tools built for a specific purpose or framework.
If you’re deciding which web component is the best solution for your project, this article may help you whittle down the myriad options available. Let’s explore the important factors to consider when selecting an open-source component and discuss when a commercial product may be a better fit.
Product Support
One of the most important factors when selecting an open-source project is ensuring there is an active community behind it. Often, a developer creates an open-source project to solve an issue, but at some point — maybe because of lack of time, or because they’ve moved on to other projects — they abandon the repository.
Choosing a project without significant updates may mean it no longer works with certain browsers, is not compatible with new features, or, at worst, contains unpatched security vulnerabilities.
Any time you’re evaluating whether to use an open-source product, it’s essential to look at the repository and check the dates of the last commits. If there hasn’t been any activity in months, that’s a good indication that the project isn’t supported in any significant way.
It’s also worth examining the approved pull requests and closed issues for the project, to ensure fixes are properly addressed.
It’s also useful to check how long the project has been around. In some cases, if the technology is quite new, this won’t be a factor (there aren’t a ton of WebAssembly open-source projects that are 10 years old).
However, for something like a JavaScript-based spreadsheet or charting library, it’s helpful to see that the project has been around for a while and has adapted to changes in web technologies.
Another factor to consider is whether the open-source project has any sponsorship. The level of support can be a major determinant of whether the project is sustainable.
Let’s face it: there’s nothing worse than waking up one day and finding that a major piece of your front-end ecosystem has been abandoned after the contributors ran out of time and resources.
GitHub’s Insight tab provides even more detailed information about the health of the project — how many contributors there are, frequency of commits, and even the number of forks. This helps you determine if the product is active and supported.
Documentation
Another challenge that comes up frequently with open-source projects is the lack of documentation. For many developers, tooth extraction is preferable to writing up documentation, so as a result, important setup instructions or API guidelines are often missing or out of date.
This is occasionally true of commercial products as well, but generally any company selling a product puts extra work into ensuring the developer documents are correct and up to date.
Checking in advance for documentation — and documentation dates — may help you determine if the open-source solution has the support you need.
Integration
Open-source software doesn’t generally have any upfront cost, although it’s important to consider the amount of labor needed to integrate the product into your overall solution. For a spreadsheet, for instance, you might have to retrieve and save information to an underlying data store.
That means someone needs to ensure the backend is set up to query and serialize the data in a format the tool expects, requiring significant time and effort.
Ten years ago, adding a JavaScript control might have meant simply including a reference to jQuery and configuring the control on the page. However, the complexity of front-end development, the wide variety of frameworks (including Angular, Blazor, Vue, ASP.NET, MVC, and React), and even the advent of transpiled languages like TypeScript, means that tools need to integrate into the frontend as well.
When considering open-source tools, look at how well they integrate with your application.
Support
Scenario: everything seems to be going well with your component, and suddenly, without warning, customers start complaining that it’s suddenly not working in their favorite web browser. Who do you call?
This is probably the main reason for a development team to choose a paid product: at the end of the day, there is a customer support system — by email, chat, or phone — that can, and is often contractually obligated to, address your issue. Of course, commercial products have varying levels of paid support, so when purchasing a product, it’s equally important to find out the response times and communication methods.
With open-source software, however, unless you’re willing to fix the problem yourself, you generally need to wait until a contributor looks at the issue. If the project is big enough, there might be a significant online community to help — a project like jQuery can boast thousands of answered questions on sites like Stack Overflow — but that’s generally not the case for a small component library.
Before committing to an open-source solution, make sure you are informed about and comfortable with its level of support. One way to figure out the response you can expect is to check the issues tab in the repository. Note the time difference between when each issue was opened and when it was closed.
UI
Some developers are more than happy to have all their sites look like a Craigslist clone. Fortunately for all, most developers recognize how a polished and well-designed user interface (UI) makes a product enticing to customers.
Many (though certainly not all) open-source components have a fairly standard look out of the box. They often include a few basic styles, methods for integrating custom design, and in some cases, an array of plug-in themes, but that’s pretty much it.
To create a compelling UI, or to integrate a tool into your application’s existing style, look for tools offering a broad range of designs.
Features
At the outset of a project, it’s worth considering what type of additional functionality might be required in the future. This is particularly important with open-source projects, which depend on often unpaid contributors whose greatest priority is to ensure that the core functionality is working correctly.
If the feature is likely to increase in complexity, and require much more advanced functionality, it may be better to select a more feature-rich commercial product. It’s also worth keeping in mind how much easier it is to integrate a component into a project right at the beginning, instead of having to retrofit it once the feature is already in production.
The Hunt for the Right Solution
Let’s imagine your product team comes up with an exciting new feature: an embedded spreadsheet on the company website that helps determine how well a person sleeps over a given week.
For each day of the week, the user enters a date from a dropdown menu, then provides both the number of hours in bed and the number of hours they slept that night. A formula in the following cell indicates how good their sleep was, on a scale of 0 to 100. And the product team wants the project done in two sprints.
The first method to scratch off the list is building it yourself: Only the most foolhardy developers would consider building a JavaScript-based spreadsheet product from scratch, let alone in such a short period. That leaves either an open-source or commercial product.
A quick online search reveals a large assortment of choices. Some options, like SheetJS, you can discard quickly because of the large number of open issues, and the lack of recent commits. Other products, such as Smart-Grid, have more recent contributions, but don’t offer integrations into many frameworks. However, a few open-source candidates stand out, specificallyJspreadsheet CE, and LuckySheet, which provide solid documentation with strong functionality and integration.
After a few hours of comparing the available tools, it comes down to two candidates: the open-source Jspreadsheet or a commercial product, SpreadJS from GrapeCity.
Jspreadsheet
Unlike many open-source projects, Jspreadsheet’s website and GitHub documentation is quite thorough and comprehensive. It provides basic setup and data structures, then delves into more advanced features, such as formulas, events, and custom stylings. A full range of examples showcase the code for different use cases.
Additionally, Jspreadsheet has many front-end integrations, from older libraries like jQuery to the more modern trio of React, Vue, and Angular. We can quickly integrate their component into our project by running a simple npm install jexcel command (jexcel being the product’s former name), then adding the component on the view page, as well as a reference to it in TypeScript codebehind:
//this adds the Jspreadsheet Element
@ViewChild('spreadsheet') spreadsheet: ElementRef;
<!--Jspreadsheet component markup-->
<div #spreadsheet></div>
Additionally, adding data is straightforward. The first step is to define the spreadsheet contents, which means first creating arrays to hold the days of the week and the data.
public daysOfTheWeek=['Monday','Tuesday','Wednesday','Thursday','Friday','Saturday','Sunday'];
public JSpreadsheetData=[];
Next, we create our data by iterating through the date array and adding default values for each of the properties in the spreadsheet:
//set up the data arrays for each, day and add the default date,
// hours in bed and hours slept
this.daysOfTheWeek.forEach((day:string,index:number)=>{
this.JSpreadsheetData.push(
[day,'01/01/2021',0,0]
);
});
We can then instantiate the spreadsheet by defining our rows, passing in the data, and running the jexcel function. The syntax uses a simple declarative JSON format and provides options for formatting the data (the calendar option for our date provides an out-of-the-box datepicker element), as well as some styling, demonstrated by the max dimension property.
jexcel(this.spreadsheet.nativeElement, {
data: this.JSpreadsheetData,
columns: [
{ title: 'Day', width: 300 },
{ title: 'Date', width: 300, type: 'calendar', options: { format:'DD/MM/YYYY', time:0 } },
{ title: 'HoursInBed', width: 80,type: 'numeric' },
{ title: 'HoursAsleep', width: 100,type: 'numeric' },
],
minDimensions: [10, 10]
});
The last step is to add a formula to calculate the ‘sleep efficiency’, using the calculation (Hours Asleep/Hours In Bed) * 100. We can easily implement this by adding another entry into the column array:
{ title:'Sleep Efficiency', type: 'text', width:'100' }
and then adding the formula to our data array using an Excel-like formula syntax:
[day,'01/01/2021',0,0,`=(D${index+1}/C${index+1})*100`]
The resulting spreadsheet looks fairly good, although the main adjective that comes to mind is functional — it does what it’s designed to do, but looks more like an internal administrative tool than a feature on a front-facing website. Of course, a talented designer can easily remedy that problem, assuming they have the time and resources to spare.
One missing feature is out-of-the box Excel style functions. For example, the formula above displays a divide-by-zero error — we prefer an ERRORIF function that displays a default value. Although Jspreadsheet does enable you to create your own functions, there was nothing like this error function available.
Without question, though, assuming all the project requires is a fairly straightforward embedded spreadsheet, Jspreadsheet is an excellent choice.
SpreadJS
The SpreadJS implementation is a bit more involved, but the documentation is robust, containing several helpful video tutorials and interactive demos.
SpeadJS additionally integrates with many front-end libraries and frameworks. One of the nice touches is the library-specific demo section, which contains an actual code example of a feature in the given integration (in our case, Angular). This makes adding dropdowns and formulas much easier to implement. Again, the first step is running npm to install the libraries.
Building the data structure is fairly similar to Jspreadsheet, and involves creating an array with objects for each day of the week:
this.daysOfTheWeek.forEach((day:string,index:number)=>{
this.SpreadJsData.push(
{
Day: day,
HoursInBed:0,
HoursAsleep:0,
}
);
});
However, at this point, the two libraries diverge: SpreadJS offers many more design and functional options. For example, while adding the date picker was not as simple as in Jspreadsheet (where it appeared simply by declaring a column as a calendar type), SpreadJS provided additional customizations for how the calendar looks, and which element (such as time) should appear.
let style = new GC.Spread.Sheets.Style();
style.cellButtons = [
{
imageType: GC.Spread.Sheets.ButtonImageType.dropdown,
command: "openDateTimePicker",
useButtonStyle: true,
}
];
style.dropDowns = [
{
type: GC.Spread.Sheets.DropDownType.dateTimePicker,
option: {
showTime: true,
}
}
];
spread.commandManager().execute({ cmd: "openDateTimePicker", row: i, col: 1, sheetName: "Sheet1" });
Additionally, the wider variety of functions means that we can easily add more advanced formulas, such as ERRORIF, to the spreadsheet.
sheet.setFormula(i,4,`=IFERROR(((D${i+1}/C${i+1})*100),0)`)
For any application needing more advanced features — anywhere from this type of built-in function all the way up to Excel-style use cases — having a library with such a large number of options saves a lot of time (and developer headaches).
A commercial product such as SpreadJS also has a distinct advantage in its user interface. A basic version ‘looks’ like a commercial spreadsheet product with no additional styling, meaning that if you need something that looks professional, and don’t want to spend additional time on styling, a commercial product is definitely the way to go.
You can find this project’s full code on GitHub.
Next Steps
In the end, the choice between open-source and commercial components isn’t always easy. It’s important to consider the requirements, the audience, any possible feature development plans, and, of course, your budget.
In many cases, the robust functionality, superior UI, and reliable support of commercial products is worth the cost. However, with all the excellent open-source software available these days, it’s always worth at least checking and comparing open-source options before making your final choice.
Now that you see how to integrate both an open-source and a commercial spreadsheet into your application, and some considerations when deciding between an open-source and a commercial component, you can decide what is best for your next project. Learn more about SpreadJS or download a free trial to experiment with its powerful capabilities for your next great app.
Kevin Ashley