Our great sponsors
-
proposal-record-tuple
ECMAScript proposal for the Record and Tuple value types. | Stage 2: it will change!
-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
-
proposal-asset-references
Proposal to ECMAScript to add first-class location references relative to a module
-
proposal-change-array-by-copy
Provides additional methods on Array.prototype and TypedArray.prototype to enable changes on the array by returning a new copy of it with the change.
-
WorkOS
The modern identity platform for B2B SaaS. The APIs are flexible and easy-to-use, supporting authentication, user identity, and complex enterprise features like SSO and SCIM provisioning.
-
proposal-import-assertions
Discontinued Proposal for syntax to import ES modules with assertions [Moved to: https://github.com/tc39/proposal-import-attributes]
-
simpatico
Simpatico is an umbrella term for several data-structures and algorithms written in JavaScript
-
ecmascript-types
ECMAScript Optional Static Typing Proposal http://sirisian.github.io/ecmascript-types/
-
SaaSHub
SaaSHub - Software Alternatives and Reviews. SaaSHub helps you find the best software and product alternatives
Immutable data structures are on the agenda over in https://github.com/tc39/proposal-record-tuple and I would vote for that in Deno while I have the chance.
I often miss map, reduce and filter on iterators, though this is already a stage 2 proposal: https://github.com/tc39/proposal-iterator-helpers.
TS design goals and non-goals [1]
It's very much designed to be a layer of abstraction over JS.
I am as much a fan of TS, however, it's not likely ever going to be the thing that it's really close to being.
[1] https://github.com/Microsoft/TypeScript/wiki/TypeScript-Desi...
No no, this is about things like importing WASM through the `import` keyword, or referencing assets statically through syntax:
Asset References: https://github.com/tc39/proposal-asset-references
Alternative module reflections (wasm imports): https://github.com/tc39/proposal-import-reflection
Currently in stage 2 as `Array.prototype.toReversed`: https://github.com/tc39/proposal-change-array-by-copy
I think they are great! Especially in combination with pattern matching (https://github.com/tc39/proposal-pattern-matching), or when using JSX.
Things like https://github.com/tc39/proposal-explicit-resource-managemen.... Essentially better language level support for objects which represent some IO resource that should be reliably closed when a user is done with it. Something like the `defer` statement in Go is really missing from JS.
Things like https://github.com/tc39/proposal-explicit-resource-managemen.... Essentially better language level support for objects which represent some IO resource that should be reliably closed when a user is done with it. Something like the `defer` statement in Go is really missing from JS.
This is a great news! Good luck, Luca!
> Better support for explicit resource management
+1
Since everyone is making feature requests, I'd like to point out `ArrayBuffer.transfer`[1] -- ability to effectively move data without copying would do wonders for low-level/high-performance code in JS.
Please have someone on your team take a good hard look at the current proposal-pipeline-operator: https://github.com/tc39/proposal-pipeline-operator
It started as a Function Composition proposal (using the pipe operator :>) but after a chage of leadership it has changed into something much different. We might need another perspective on the current trajectory of this proposal, as in its current form it seems it might take JS in the wrong direction.
Thanks!
There's an issue for that to be added as aprt of import assertions https://github.com/tc39/proposal-import-assertions/issues/11...
*>...use types [at] runtime..."
Two things. First, TS conceives of itself as having no runtime component. If it did, I think people (including the TS devs) would be more confused.
Second, I'd say rather we need a runtime type system. In fact I've tried my hand at writing one in the most minimalist way possible, and have been working on it recently [1]. The type system is explicit in that a type is a JSON like object, similar to JSON schema, but 100x less code.
[1] https://github.com/javajosh/simpatico/blob/master/friendly.h... This is effectively the test harness for the module.