Re: Moving forward with function decorators

I don't see any mention of class/object shorthand methods; would these be trivial, do you think? ``` class FooClass { @dec1 @dec2 bar () { } } const fooObj = { @dec1 @dec2 bar () { } } ``` -- Dammit babies, you've got to be kind. On Wed, 4 Sep 2019 at 11:49,

Fwd: Moving forward with function decorators

Here I described my thoughts about this topic https://github.com/finom/function-decorators-proposal. The main idea of moving forward with function decorators is to make them behave like there were defined and wrapped by another function, not more, and get rid of any hoisting when they're used.

Re: Moving forward with function decorators

Class member decorators are there: https://github.com/tc39/proposal-decorators Object method decorators: of course they do make sense but honesty I don't know do they need to be also included as a part of "function decorators proposal"? They look and behave very similar to class members. In other

persisting large wasm-sqlite3 datasets in browser (beyond kv-storage)

at work, we have browser-app that load-and-persist ~100MB (500k rows) csv-files into wasm-sqlite3 [1], (ingestion-time is ~15s for 100MB csv). we wish to go bigger, but chrome's indexeddb has a hard-limit of 125MB per key-value object (on windows). i don't have anything actionable. just want

Re: persisting large wasm-sqlite3 datasets in browser (beyond kv-storage)

Not sure this pertains to the ECMAScript spec in any way. You may have better luck with WICG, because they are who deal with those specs - those are specific to the web, while JS is used in places where those might not even make sense (like IoT sensors). - Isiah Meadows