SheetJS js-xlsx VS tup

ExcelJS and XLSX (SheetJS) are great libraries to work with XLSX files. The former I've found a bit easier to work with but less efficient in general.

Sure. I manipulate excel files programatically in the browser all the time. I don't really understand your exact workflow, but I use Javascript with xlsx and React.

Looking at the xlsx documentation, to parse files in the browser, rather than readFile, you use read, which is designed to parse binary data directly, rather than read from disk. There are a bunch of different formats if you go to the XLSX NPM page and scroll down to "Acquiring and Extracting Data". Importantly, it seems the data must already be serialized, so a Blob won't work, but we can work with that.

Last year, Bing and Edge erroneously flagged our website https://sheetjs.com/ as "dangerous": https://i.imgur.com/BvA3zrk.png

At the time, there was no "Safety Report" to indicate why Bing thought it was dangerous. The report page linked to https://www.bing.com/toolbox/bing-site-safety?url=https%3a%2... and it said "That web page doesn't exist"

To fix it, we had to register with "Bing Webmaster Tools" (https://www.bing.com/webmasters/about) and raise a support ticket.

Within a few days, the issue "resolved itself". It's possible that raising a ticket forced some automatic refresh of the indexed data for the domain.

xlsx.

SheetJS | https://sheetjs.com/ | Software Developer | Full time, Remote (US) | $165K - $240K

We're a bootstrapped company building open source solutions for spreadsheets and structured data. With over 1.5M unique monthly visitors, companies across the business world turn to us for challenging data processing problems. Over the last 10 years, we have pushed the boundaries of JavaScript and the web.

In this role, you will master new and established technologies while working on high-impact projects used by millions of people across the world. Balancing research and engineering, you will design and implement creative solutions that draw from your academic and professional experience.

https://sheetjs.com/careers/ more details

For more, you can visit xlsx documentation Link.

There are libraries like https://github.com/SheetJS/sheetjs to parse excel and https://www.chartjs.org/ for all kinds of charts/graphs. Not really much HTML involved here.. the markup gets generated by the chart library.

Whenever looking at one these, I think back to the obscure but interesting "tup":

“How is it so awesome? In a typical build system, the dependency arrows go down. Although this is the way they would naturally go due to gravity, it is unfortunately also where the enemy's gate is. This makes it very inefficient and unfriendly. In tup, the arrows go up.”

https://gittup.org/tup/

Once upon a time, you could roll your own of this using `tup` which might have my favorite "how it works" in the readme:

How is it so awesome?

In a typical build system, the dependency arrows go down. Although this is the way they would naturally go due to gravity, it is unfortunately also where the enemy's gate is. This makes it very inefficient and unfriendly. In tup, the arrows go up. This is obviously true because it rhymes. See how the dependencies differ in make and tup:

[ Make vs. Tup ]

See the difference? The arrows go up. This makes it very fast.

https://gittup.org/tup/

Also has a whitepaper: https://gittup.org/tup/build_system_rules_and_algorithms.pdf

Ten years ago, I used reStructuredText and its support for LaTeX math and syntax highlighting. I used tup (tup monitor -a -f) to take care of running rst2html on save.

I might be showing my ignorance here, but this just sounds like Tup? https://gittup.org/tup/

I agree. While I like the idea of tup (https://gittup.org/tup/ -- the first "forward" build system I remember hearing of), writing a makefile is easy enough that thinking about the problem upside-down doesn't offer a compelling reason to switch.

Ptrace is one option for tracing dependencies, but it comes with a performance hit. A low-level alternative would be ftrace (https://lwn.net/Articles/608497/) or dtrace (https://en.wikipedia.org/wiki/DTrace).

Tup uses LD_PRELOAD (or equivalent) to intercept calls to C file i/o functions. On OSX it looks DYLD_INSERT_LIBRARIES would be the equivalent.

* order-only prerequisites - X must happen before Y if it's happening but a change in X doesn't trigger Y

This is just a small selection and there are missing things (like how to handle rules that affect multiple targets).

It's all horrible and complex because like a lot of languages there's a manual listing the features but not much in the way of motivations for how or why you'd use them so you have to find that out by painful experience.

It's also very difficult to address the warts and problems in (GNU) make because it's so critical to the build systems of so many packages that any breaking change could end up being a disaster for 1000s of packages used in your favorite linux distribution or even bits of Android and so on.

So it's in a very constrained situation BECAUSE of it's "popularity".

Make is also not a good way to logically describe your build/work - something like Meson would be better - where you can describe on the one hand what a "program" model was as a kind of class or interface and on the other an implementation of the many nasty operating system specific details of how to build an item of that class or type.

Make has so many complex possible ways of operating (sometimes not all needed) that it can be hard to think about.

The things that Make can do end up slowing it down as a parser such that for large builds the time to parse the makefile becomes significant.

Make uses a dependency tree - when builds get large one starts to want an Inverted Dependency Tree. i.e. instead of working out what the aim of the build is and therefore what subcomponents need to be checked for changes we start with what changed and that gives us a list of actions that have to be taken. This sidesteps parsing of a huge makefile with a lot of build information in it that is mostly not relevant at all to the things that have changed. TUP is the first tool I know about that used this approach and having been burned hard by make and ninja when it comes to parsing huge makefiles (ninja is better but still slow) I think TUP's answer is the best https://gittup.org/tup/

You might enjoy Tup[1] if you've not checked it out before.

[1]: https://gittup.org/tup/