41–45 of 45 posts
Earlier quoted context omitted.
Yes, this is the point of that code. It's boilerplate to ensure the module loads in different environments.
UMD does _not_ support standard JS module imports. The UMD code won't detect `exports` or `define` and will write to globals instead of producing any exports.
I work on a data viz product and we've always struggled with a myriad of charting libraries. IMO Chart.js is one of the best tools for charting that has quickly surpassed existing libraries in aesthetics, ease of use, robust community, etc. Big thanks to the Chart.js team for their work! I wound up building an open-source web service for rendering Chart.js to images for embedding in static contexts without JS support…
I've been using Uber's graphing libraries, and they're nothing short of stunning.[1] It's easy to get started, and customizing or extending functionality is straightforward, with myriad example to help. And charting is rendering agnostic. SVG? Canvas? You choose. My only gripe is the lack of TypeScript support. I won't touch vanillaJS with a 20 foot pole if I can help, and the the missing type annotations can be pain…
Chart.js still uses the HTML Canvas element, so charts generated with it look blurred when printed or zoomed in. Nowadays I prefer Apexcharts.js, which renders to SVG. https://github.com/apexcharts/apexcharts.js (MIT License)
i'm working on a micro timeseries plotter that easily handles 150k+ datapoints. it uses canvas but accounts properly for display pixel density, so is as sharp as SVG. here is how it performs vs Chart.js: https://github.com/leeoniya/uPlot#performance i will add Apex charts to the bench list in a day or so i think the only practical way to get acceptable perf with SVG is to simplify the paths via something like https:/…
What do y'all recommend for frequently updating charts i.e. streaming data sources with histograms, etc?
It's a popular framework, so a lot of my questions were answered on Stack Overflow.
Earlier quoted context omitted.
UMD does _not_ support standard JS module imports. The UMD code won't detect `exports` or `define` and will write to globals instead of producing any exports.
I'm not sure what you mean. Obviously UMD cannot support native es6 modules since they're syntactical invalid for non-es6 applications.
> Yes, this is the point of that code. It's boilerplate to ensure the module loads in different environments.
but the UDM header does not allow the module to load in JS modules. So I'm not quite sure what you meant actually. The header does nothing for standard modules.