vega VS sucrase

Hi HN – Excited to share a beta for Minard, a new data visualization toolkit we've been working on that lets you generate publication-quality charts with simple natural language (throw away your matplotlib docs and rejoice!).

Upload or import CSVs, Excel, and JSON, give it a spin, and please let us know what you think! (Long format data works best for now)

For those curious, the stack is a simple Django app with HTMX/Alpine and all of the charts are specified and rendered as Vega (https://vega.github.io/vega/). Lots of LLM function calling under the hood as well.

I recently added support for plotting XGBoost models using Vega (https://vega.github.io/vega/) into the XGBoost Elixir API (https://github.com/acalejos/exgboost).

Since EXGBoost supports loading trained models across different APIs, you can even train using the Python API and then plot using this Elixir API if you prefer.

The Data Source is from devjobsscanner (I am basically the owner, so I have the data) an the tool used to make the chart is Vega

It’s based on Vega https://vega.github.io/vega/ which means it’s an already matured backend. Vega-lite is the Javascript package and Altair is the Python.

Site:: https://vega.github.io/vega/

Eh, I have no reason to, and not much interest in PHP anymore. Things like Vega seem really cool.

This chart is make with Vega (and also all the charts from the article). Data source is from devjobsscanner and contains about 10 Million dev jobs offers, which only a small subset contain salary information thought.

Not that I'm working on it, but I'd love to see a vega stack in rust.

Thanks. As for the code compilation, that can be tested and seen in https://sucrase.io/

The demo page is only to show how we can transpile JSX in browsers.

Thanks u/OutlandishnessKey953, the playground built with React, Docusaurus(https://docusaurus.io/), CodeMirror(https://codemirror.net/), Sucrase(https://sucrase.io/), etc.

Hi, Sucrase author here.

To be clear, the benchmark in the README does not allow JIT warm-up. The Sucrase numbers would be better if it did. From testing just now (add `warmUp: true` to `benchmarkJest`), Sucrase is a little over 3x faster than swc if you allow warm-up, but it seemed unfair to disregard warm-up for the comparison in the README.

It's certainly fair to debate whether 360k lines of code is a realistic codebase size for the benchmark; the higher-scale the test case, the better Sucrase looks.

> worse it disables esbuild and swc's multi-threading

At some point I'm hoping to update the README benchmark to run all tools in parallel, which should be more convincing despite the added variability: https://github.com/alangpierce/sucrase/issues/730 . In an ideal environment, the results are pretty much the same as a per-core benchmark, but I do expect that Node's parallelism overhead and the JIT warm-up cost across many cores would make Sucrase less competitive than the current numbers.

First, npm i -D sucrase to install sucrase. Now you can do node -r sucrase/register ./index.ts to run TypeScript code directly with Node.

As you might know there are a lot of Javascript bundlers out there, such as webpack, sucrase, parcel, rollup and etc. Bear in mind, not because they have thousands of stars on Github that means they're the best. sometimes new libs are as good as the popular ones but they're still building up their image/popularity in the community. what I bring today is a not sooooo, popular JS bundler called esbuild.

Sucrase JS was 2x the speed of esBuild and 50% faster than SWC last I checked.

Webpack does way more than esbuild, including running a typechecking compiler instead of just transpiling, running compilers able to downlevel emit to ES5 and providing a deep plugin architecture allowing you to hook into any bit you like. But yes, it hasn't been designed with speed in mind - it has been designed with maximum extensibility instead. Its the same reason why Babel is slow compared to sucrase (written in JS, currently faster than SWC and esbuild but doing somewhat less - https://github.com/alangpierce/sucrase)

tsc has in fact been designed with speed in mind (I've been following the project since before it ended up on GitHub). Going beyond 1 order of magnitude performance improvement is highly unlikely.