proposal-private-fields VS proposal-decorators

Compare proposal-private-fields vs proposal-decorators and see what are their differences.

proposal-private-fields

A Private Fields Proposal for ECMAScript (by tc39)
Our great sponsors
  • InfluxDB - Power Real-Time Data Analytics at Scale
  • WorkOS - The modern identity platform for B2B SaaS
  • SaaSHub - Software Alternatives and Reviews
proposal-private-fields proposal-decorators
7 64
320 2,626
- 1.3%
0.0 4.2
about 2 years ago 28 days ago
HTML
- -
The number of mentions indicates the total number of mentions that we've tracked plus the number of user suggested alternatives.
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.

proposal-private-fields

Posts with mentions or reviews of proposal-private-fields. We have used some of these posts to build our list of alternatives and similar projects. The last one was on 2023-03-09.

proposal-decorators

Posts with mentions or reviews of proposal-decorators. We have used some of these posts to build our list of alternatives and similar projects. The last one was on 2024-01-21.
  • Making Web Component properties behave closer to the platform
    9 projects | dev.to | 21 Jan 2024
    Because many rules are common to many attributes (the coerceType operation is defined by WebIDL, or using similar rules, and the HTML specification defines a handful of microsyntaxes for the parseValue and stringifyValue operations), those could be packaged up in a helper library. And with decorators coming to ECMAScript (and already available in TypeScript), those could be greatly simplified:
  • JavaScript Naming Conventions are Important
    5 projects | dev.to | 14 Nov 2023
    JavaScript was created a long time ago, and at the time of its inception, the authors decided not to use affirmative prefixes for boolean names. Now, they do their best by continuing to follow their convention, even if it goes against the community's opinion. Even if the authors wanted to introduce new naming conventions in the specification, they could not do it, at least not coherently. Old code cannot be renamed because JavaScript must remain backward-compatible. And starting to write new code using new approaches is not a great idea either, as there would be two ways to do the same thing, which is also undesirable.
  • ECMAScript Decorators. The Ones That are Real
    6 projects | dev.to | 24 Oct 2023
    2016-07 – Stage 2. After the decorators proposal reached stage 2, its API began to undergo significant changes. Furthermore, at one point the proposal was referred to as "ESnext class features for JavaScript." During its development, there were numerous ideas about how decorators could be structured. To get a comprehensive view of the entire history of changes, I recommend reviewing the commits in the proposal's repository. Here is an example of what the decorators API used to look like:
  • Strawberry - Zero-Dependency, Build-Free JavaScript Framework
    2 projects | /r/javascript | 2 Jun 2023
    The example you've given isn't valid JavaScript, JS doesn't have decorators. (Although there is a stage 3 tc39 for it, afaik no browser has implemented it)
  • Updates from the 96th TC39 meeting
    5 projects | /r/javascript | 19 May 2023
    There was a decorators issue brought up in the meeting (issue 508) and decorators metadata, as noted in the article, is now at stage 3. So there's still active work being done on decorators. If I had to guess, I'd say they'd be a likely candidate for ES2024.
    5 projects | /r/javascript | 19 May 2023
  • The Lightweight Alternative to GraphQL, Resolvers Instead of Endpoints
    2 projects | dev.to | 2 May 2023
    As per the proposal, decorators can be used with Classes and their elements such as fields, methods, and accessors. To leverage this feature, we need to ensure that our resolvers provider is an instance of a Class. Therefore, we will modify the code in src/api/users/users-resolvers.js to the following:
  • Using modern decorators in TypeScript
    4 projects | dev.to | 2 May 2023
    The modern version of decorators, which will be officially rolled out in TypeScript 5.0, no longer requires a compiler flag and follows the official ECMAScript Stage-3 proposal. Alongside a stable implementation that follows ECMAScript standards, decorators now work seamlessly with the TypeScript type system, enabling more enhanced functionality than the original version.
  • What should I do after react js
    2 projects | /r/developersIndia | 28 Apr 2023
    100% this. Going in depth of libraries will make you so much better developer than learning newest and coolest frameworks in JS ecosystem. Learn to create your own React, Promises, or anything you like in JS. It will give you immense perspective about these libraries. Once you start understanding them you will feel like they are not that complex and you can do it too. Go read TC39 proposals and issues people point out in them. You will see how JS is borrowing features from other languages.
  • TypeScript 5.0
    12 projects | news.ycombinator.com | 16 Mar 2023
    > 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.

What are some alternatives?

When comparing proposal-private-fields and proposal-decorators you can also consider the following projects:

TypeORM - ORM for TypeScript and JavaScript. Supports MySQL, PostgreSQL, MariaDB, SQLite, MS SQL Server, Oracle, SAP Hana, WebSQL databases. Works in NodeJS, Browser, Ionic, Cordova and Electron platforms.

proposal-decorator-metadata

remult - Full-stack CRUD, simplified, with SSOT TypeScript entities

proposals - Tracking ECMAScript Proposals

arktype - TypeScript's 1:1 validator, optimized from editor to runtime

openapi-typescript - Generate TypeScript types from OpenAPI 3 specs

reflex-metadata-SCKS

InversifyJS - A powerful and lightweight inversion of control container for JavaScript & Node.js apps powered by TypeScript.

lit-element - LEGACY REPO. This repository is for maintenance of the legacy LitElement library. The LitElement base class is now part of the Lit library, which is developed in the lit monorepo.

proposal-record-tuple - ECMAScript proposal for the Record and Tuple value types. | Stage 2: it will change!

nestjs-auth - Comprehensive handling of authentication and authorization for NestJS.

proposal-class-fields - Orthogonally-informed combination of public and private fields proposals