The ActiveReports product family consists of ActiveReports.NET (from now on AR.NET) and ActiveReportsJS (from now on ARJS). Suppose you want to integrate a reporting solution into a .NET desktop application, such as WPF or Windows Forms, or build a long-running service application that distributes reports on schedule.
In that case, AR.NET is the clear choice. However, if you build a web application that offers reporting features, both AR.NET and ARJS could be suitable for that purpose. This article compares these two products by multiple factors that should be considered when deciding which product to use.
Want to Check Them Out for Yourself? Download ActiveReports.NET and ActiveReportsJS Today!
Architecture
AR.NET is written on C# and runs against .NET runtime. Reports are initialized, processed, and exported on the server-side of a web application. While the frontend web designer and web viewer components are fully JavaScript-based and platform-agnostic, AR.NET can only be used within a web application if it can interface with a .NET backend service. Here is a simple sequence diagram of a typical AR.NET based application
ARJS is written in TypeScript, compiled to JavaScript, and runs on the client-side of a web application in the browser. Thus, ARJS is back-end-agnostic and can be used with a wide variety of back-end solutions - node.js, PHP, etc. The sequence diagram:
Both products include the report designer that lets developers build report templates. AR.NET offers the Visual Studio-integrated report designer that you can use to add and modify reports within your .NET web application's structure, while ARJS offers a Visual Studio Code plugin that you can add to your IDE to build and save reports.
Also, AR.NET offers the standalone designer application for Windows that you can utilize to create, modify, and save report templates as external files. It could be practical if you use the IDE other than Visual Studio, for example, Visual Studio Code. ARJS provides a cross-platform standalone designer application that you can run on Windows, Mac OS, and Linux operating systems.
In addition, AR.NET installation includes the standalone Report Viewer application, Theme Editor, and Import Tool.
Data Sources
ARJS supports connection to either a JSON or CSV data source at design time. The data provider offers many options that allow you to easily set up the connection to a REST API, OData, or GraphQL end-point supplying query parameters and HTTP headers. Developers can also supply the array of JavaScript objects to be used as the data source at runtime.
AR.NET supports connection to MS SQL Server, SQLite, ODBC, OLE DB, XML, CSV, and JSON data sources at design time. At runtime, the code can supply the collection objects or DataSet/DataTable/DataView instance to be used as the data source. Also, AR.NET supports custom data provider implementation that you can use to bind a report to a database of your choice.
Report Types
ARJS supports Continous Page and Fixed Page Reports, Pageless Reports, and Dashboard Reports, which are saved as an RDLX-JSON report file.
AR.NET includes RDLX Continuous Page reports, RDLX Pixel Perfect Page reports, RDLX Dashboard reports, traditional Banded List Section reports, and fully Code-Based Section reports.
Report Items
AR.NET and ARJS report items for Page and RDLX/RDLX-JSON reports are the same, with the only differences being that ARJS does not support the Map control, and instead of using the FormattedText control, ARJS makes use of the RichText control.
AR.NET also supports custom report items, allowing you to implement custom visualizers, such as chart controls.
Web Components
Both AR.NET and ARJS include JavaScript-based Report Viewer and Report Designer components that you can integrate into a web application. The Report Viewer allows users to preview and export reports, and with the Web Designer, users can modify existing or create new report templates.
AR.NET Viewer and Designer components must communicate with the .NET server-side to save, load, pull the output, and export reports. ARJS components do not depend on the server-side, and thus they are more flexible and backend-agnostic than AR.NET components.
Exports
AR.NET supports the report’s data export to CSV and JSON and export the report's layout to BMP, GIF, JPEG, TIFF, PNG images, PDF, Word, HTML, and Excel documents. Besides, AR.NET supports custom export implementation.
ARJS only supports export to PDF, HTML, Tabular Data (CSV), and XLSX documents.
Licensing and Pricing
AR.NET licenses are developer-based, so you will need one license per each developer working on the project, but a single license is applicable for an unlimited number of deployments. Most Report Viewer and Report Designer components are part of the Professional Edition. Visit our AR.NET pricing page for more information.
ARJS licenses do not limit the number of developers that can work with the library; it is licensed based on runtime deployment for each hostname. It offers competitive pricing per hostname, domain, or unlimited domains. Visit the ARJS pricing page for more information.
Cross-Compatability Limitations
AR.NET uses RDLX files which are essentially an e(x)tension of the original RDL XML-based format, while ARJS uses RDLX-JSON, which, as you may have guessed, is a JSON-based adaptation of RDLX. It is technically possible to convert a report definition file from RDLX to RDLX-JSON by opening an RDLX file in the ARJS designer, but it is not a perfect one-to-one conversion, and it is not possible to go the other way, from RDLX-JSON to RDLX.
They are not designed to be used in conjunction, and for these reasons, we do not suggest using AR.NET and ARJS together in the same project unless you intend to have two completely parallel reporting solutions.
Conclusion
