Not a great comparison, likely AI generated fluff. No mention of advancements like RSPack and other options (Parcel). While there's lip service to "developer performance" and similar, there are no hard numbers or references in the article. No sources or citations either.
Total aside... I've been thinking it would be nice to build a CSV parsing library that uses iterable and async iterable options... effectively bubbling a character at a time, wrapped in an iterable bubbling a field at a time... then another for a row at a time... then a final inerrable for optionally transforming string[] for each row to object of key/values for each row.
My only issue is that I'd like to bubble each "character" as a set for joined utf-8 characters represented from the read stream. And I can't help but think that logic itself would be the most complex... effectively understanding unicode/utf8 well enough to peak/pop each "character" as a set. Then the wrapper would take field delimiters (quptes, commas) for bubbling.
So you could use the sync interface for "very fast" ETL to line separated json, for example... and async for data ingestion ETL to a queue or FaaS intake.
Been thinking of similar for a few different languages... but I think JS/TS generators would be particularly useful for this.
I got 20... that was rough AF. This just reaffirms my disdain for most DateTime parsing and libraries. Not just in JS, where it's *VERY* flexible, almost too much so. I really wish normies would get used to ISO-style YYYY-MM-DD format for dates, at the very least. Though I did once work on a project where early on a Jr dev had made the mistake of using YYYY-DD-MM, which is used nowhere on earth as a standard and was "too far along to fix"... Pissed me off to no end.
Yeah, Rust has a really good path to WASM for use in the JS ecosystem. I did similar with an html sanitization library a couple years ago and it ran about 5x the speed of a similar JS library at the time.
Source is obfuscated without sourcemaps, only the interface is mentioned, no link to docs in MozDev for the specs or API methods used by the example.
It's cool to show that something *can* be done, it'd be nice if it went the half a step further to guide to how it is done.
As pointed out in the article, the scope, arguments and 'name' properties are different for arrow functions.
One point not made, is it makes it easier to use tiered functions to make functional constructs and pipelines...
For example...
const takeWhile = (predicate) => (arr) => {...}
Can be used as a function that returns a function which takes the final argument... this can be used to build new functions that can be reused and passed around. It's often used as part of middleware patterns in various frameworks to handle various stages of middleware processing or not.
As pointed out in the article, the scope, arguments and 'name' properties are different for arrow functions. One point not made, is it makes it easier to use tiered functions to make functional constructs and pipelines... For example... const takeWhile = (predicate) => (arr) => {...} Can be used as a function that returns a function which takes the final argument... this can be used to build new functions that can be reused and passed around. It's often used as part of middleware patterns in various frameworks to handle various stages of middleware processing or not.