HackerReposA FIELD GUIDE TO OPEN SOURCE
ProSponsor the shelf♧ 0
← Back to top all-time
tc39
proposal-decorators
OPEN SOURCE2016–2025
tc39 / proposal-decorators

proposal-decorators

Decorators for ES6 classes

Explore on GitHubRead Hacker News discussions
22Distinct people
22Mentions
0Explicit recommenders
3KGitHub stars
REPOSITORY AT A GLANCE

What to know before exploring

What it is

Decorators for ES6 classes

GitHub

Where it is used

No documented product use was verified in the last source check.

What people are saying

No recommendation phrase was found in the indexed comments.

No classified warning is attached to this page. Read the discussions before treating silence as approval.

Also in these discussions

No other repository is repeatedly linked in the same discussions.

This week on Hacker News

Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 3:03:16 PM UTC.

No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.

Mentions over time

HN mentions by year22 dated mentions

Observed mentions: 2016-07-11 18:20:15 UTC to 2025-05-16 06:31:55 UTC.

012342016-01-01 00:00:00 UTC to 2017-01-01 00:00:00 UTC (exclusive): 2 mentions; 0 submissions, 2 comments20162017-01-01 00:00:00 UTC to 2018-01-01 00:00:00 UTC (exclusive): 2 mentions; 0 submissions, 2 comments2018-01-01 00:00:00 UTC to 2019-01-01 00:00:00 UTC (exclusive): 2 mentions; 0 submissions, 2 comments2019-01-01 00:00:00 UTC to 2020-01-01 00:00:00 UTC (exclusive): 4 mentions; 0 submissions, 4 comments2020-01-01 00:00:00 UTC to 2021-01-01 00:00:00 UTC (exclusive): 3 mentions; 2 submissions, 1 comments20202021-01-01 00:00:00 UTC to 2022-01-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2022-01-01 00:00:00 UTC to 2023-01-01 00:00:00 UTC (exclusive): 4 mentions; 1 submissions, 3 comments2023-01-01 00:00:00 UTC to 2024-01-01 00:00:00 UTC (exclusive): 3 mentions; 1 submissions, 2 comments2024-01-01 00:00:00 UTC to 2025-01-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2025-01-01 00:00:00 UTC to 2026-01-01 00:00:00 UTC (exclusive): 2 mentions; 0 submissions, 2 comments2025

Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.

View mention counts and date ranges
UTC ranges include their start and exclude their end. Select a period to filter the source evidence.
PeriodStart (UTC)End (exclusive, UTC)MentionsSubmissionsComments
20162016-01-01 00:00:00 UTC2017-01-01 00:00:00 UTC202
20172017-01-01 00:00:00 UTC2018-01-01 00:00:00 UTC202
20182018-01-01 00:00:00 UTC2019-01-01 00:00:00 UTC202
20192019-01-01 00:00:00 UTC2020-01-01 00:00:00 UTC404
20202020-01-01 00:00:00 UTC2021-01-01 00:00:00 UTC321
20212021-01-01 00:00:00 UTC2022-01-01 00:00:00 UTC000
20222022-01-01 00:00:00 UTC2023-01-01 00:00:00 UTC413
20232023-01-01 00:00:00 UTC2024-01-01 00:00:00 UTC312
20242024-01-01 00:00:00 UTC2025-01-01 00:00:00 UTC000
20252025-01-01 00:00:00 UTC2026-01-01 00:00:00 UTC202

What Hacker News says

22 sources
_benton·Mar 10, 2025
Yeah it works fine with the latest sveltekit. You do need to set { esbuild: target: "es2022" } in the vite config to enable JS decorators but that isn't specific to svelte. These aren't TS decorators, they're ecmascript decorators (https://github.com/tc39/proposal-decorators) which are at stage 3 and being adopted by JS runtimes. Under the hood the class is just creating a hidden property with $state({}) and the accessors are reading/writing to that property. Since $state() creates a deeply reactive object it acts the same as marking individual fields with $state().
In Svelte5: A Less Favorable Vue3
swyx·Mar 16, 2023
> How? There are a few notable improvements we’d like to give more details on in the future. But we won’t make you wait for that blog post. the typescript project continues to set the bar extremely high in terms of changelog and clear communication. love you so much, drosenwasser and co!! > Decorators are an upcoming ECMAScript feature that allow us to customize classes and their members in a reusable way. huh. i thought this was a bit early to do this but i checked (https://github.com/tc39/proposal-decorators) and looks like they've moved to stage 3. curious how this is going to change library/api design in the long term.
In TypeScript 5.0
lioeters·Feb 13, 2023
Decorators in TypeScript is still an experimental feature which may change depending on if/how it's implemented in JavaScript. > To enable experimental support for decorators, you must enable the experimentalDecorators compiler option either on the command line or in your tsconfig.json https://www.typescriptlang.org/docs/handbook/decorators.html > ..the current decorators proposal, which is a work in progress https://github.com/tc39/proposal-decorators Oh, but I see that the proposal is now at Stage 3, which means the specs and syntax are stable ("completely described") and ready for browsers to implement. On further digging, it seems decorators will be a standard feature included in TypeScript 5.0 planned for release on March 14th. TypeScript 5.0 Iteration Plan - https://github.com/microsoft/TypeScript/issues/51362
In <3 Deno
jitl·Feb 16, 2022
Note that the decorators standard has changed substantially, and the experimental decorators implementation in Typescript now varies greatly from the existing proposals. The current feature has not been updated in years. I would not use this feature in my code, especially for critical facilities, or build a framework around it. For what it’s worth, it seems like the proposal may move towards stage 3 soon - another round of review is going on here: https://github.com/tc39/proposal-decorators/issues/442 So, beware libraries or frameworks that rely on this toolset.
In Deep introduction to class decorators in TypeScript
lstamour·May 30, 2020
The explanation I heard was that E4X died at the time because (a) JSON developed by the early/mid 2000s to compete with XML and (b) XHTML would so easily break in strict browsers that the web was pushed in the direction of HTML5 instead of XHTML. In short, there was a rather large backlash against “enterprise” technologies like XML, WS-* and Flash (in some circles) in favour of HTML Microformats, REST and JSON. This is roughly around the same time when AJAX moved from shipping XML (2003-4) to shipping bits of HTML (PJAX) or using JSON APIs via AJAX or JSONP. The thinking of the day was if XHTML 2.0 was dead on arrival, then we should probably back out the E4X changes as “from another era.” CORS is a great example, the original CORS was “Authorizing Read Access to XML Content Using the <?access-control?> Processing Instruction 1.0” from 20
Read the rest
05: https://www.w3.org/TR/2005/NOTE-access-control-20050613/ which in 2007 became a header, then several headers, then the CORS specs we’re a bit more familiar with by 2009 as Chrome was introduced. Worth noting that compiling new syntax to old is also not new — anybody remember CoffeeScript? I’d say if there’s a new part, it’s the prevalence of implementations of standards and of polyfills for them in both TypeScript and core-js via Babel such that you can confidently write code in new syntax knowing you wouldn’t have to rewrite it later. Nobody remembers CoffeeScript or sees it today because it was generally all converted to JS long ago — it wasn’t a syntax we could build on top of. Arguably, if it was, you’d still see projects using it today, but it’s hard to modify syntax in an unambiguous way (for parsers I mean) while also simplifying the syntax as CoffeeScript did. Implementing standards are safer, though until implemented and shipped in multiple browsers, anything could still change. There are a few places where TypeScript has to be changed or will be changed due to changes in the JS standard... To illustrate how messed up standards can still be though, I’d present “decorators” —- seemingly a solved problem in Babel or TS but apparently very hard to implement as a standard: https://github.com/tc39/proposal-decorators I’m beginning to think JSX will ship in browsers before decorators do ;-) That said if there’s something the web community learned from ECMAScript 4 and XHTML2 it’s that usage, what people want to use and working code, always wins out over arbitrary standards. If two options are good enough, the one folks implement and use will win when it comes to standards. To this end, I’m pretty sure future standards required 2 independent implementations to actually graduate and become standards instead of remaining proposals. Not sure how that will change if Chrome ever becomes a larger monoculture than it already is... maybe web developers will have to vote with their codebases as standards bodies write and distribute polyfills to encourage their spec to “win”.
In ECMAScript 4: The Missing Version
paulddraper·Nov 6, 2019
I had actually listed decorators as a rare counterexample, but then removed it from my comment for brevity. 1. Decorators are currently TC39 Stage 2. [1] 2. Because of its unusual status, TypeScript lists decorators as "experimental, subject to change". Once the EcmaScript proposal advances, TS will ensure it is compatible with the ES standard and then remove the experimental sticker. 3. If it doesn't affect runtime, then you shouldn't expect JS to have the feature. TS private members are no different than public members at runtime; there is no need for JS to have that feature. (Note that TypeScript deliberately chooses not to name-mangle members.) 4. Sure call it a "feature and syntactic superset", but that doesn't make TS any less beholden to JS. Dedicated adherence to that property commits them to support every feature and syntax that
Read the rest
JS adds; future-proofing means they can't really add anything that JS doesn't have or is going to have. 5. Note that TS abandoned having a standard long ago. The behavior and validity of TypeScript program is determined by "whatever tsc does" and the ES standard. 6. Again, if you need convincing that TS effectively only implements JS features, refer the linked pipeline issue, locked as "waiting for TC39." [1] https://github.com/tc39/proposal-decorators
In TypeScript 3.7
no_wizard·Sep 13, 2019
These are all amazing features I am really hoping for private properties and compiler support of class properties (it supports the syntax, I think, but doesn't compile them down from what I understand). I also hope they update their decorator support to be in line with https://github.com/tc39/proposal-decorators I know its stage 2 (and it was stage 3, I think) but I think the reasoning behind the major(ish) changes are solid ones. Thats pretty much it. Now tc39 just needs to acceept Reflect.metadata :)
In TypeScript 3.7: The Biggest Features and How to Use Them

Showing the 15 most recent of 22 sources. Enable JavaScript to search and browse every indexed mention.

MAKE YOURSELF AT HOME

A few shortcuts

/
Search the collection
?
Open this guide
Esc
Close dialogs and navigation

Your saved repositories and interests stay in this browser.