Синтаксический сахар или технический деготь: классы в JavaScript

ЕМНИП, get/set можно просто для методов в объектных литералах задавать, без классов

Ну что вы неудобные вопросы то задаете? Автор пост написал что бы за час получить плюсики от коллег и забыть, а что там с содержанием не так уж и важно))

Не знал что приватные поля уже давно имеют хорошую поддержку во всех браузерах!

Большинство в действительности пользуются TypeScript, а там есть красивое ключевое слово private

Как дмитрий обратил такое юное дарование в своего последователя?

Класс внутри себя ничего не хранит - это абстракция. Хранит физическая ячейка памяти располагаемая в условном массиве, который где-то на листе программиста размечен как класс. Класс может знать о том что он вообще существует, если его ID есть ячейка памяти. Класс может знать что у него есть методы, если есть таблица методов, располагаемых статически или как указатели на функции. Класс знает что он-часть иерархии, если есть таблица виртуальных функций и опять-таки его ID в ней как в линейном массиве или часть switch-case в зависимости от типа объекта при динамическом поведении.
В этом случае действительно разнести класс как спецификацию данных и бизнес-логику (оперирует состоянием автоматов и ), которая вообще может не знать какие объекты она использует а работает с их хешами, идентификаторами или правилами обработки типов данных. В этом случае под катом может быть любой язык программирования, так как это всё генерируется автоматически, тем же ИИ-агентом.
То что класс может быть в топе - то есть на вершине стека, можно над этим подумать, действительно, иерархия может быть обработана как стек при размещении туда наследуемых объектов.

Нет защищенных полей. Без них бывает туго, если приватное пле в базовом классе надо использовать в наследнике

Не согласен на счет «недоклассов».

В js, действительно, нет protected, но все же такое поведение можно получить, например так:

class A {
    #private = 1;
    
    get protected() {
        return this.#private;
    }
}

class B extends A {

}

console.log(new B().protected) // 1;

или еще такой вариант:

class A {
    #private = 1;
    
    static getProtectedValue(instance: A) {
        return instance.#private;
    }
    
    static setProtectedValue(instance: A, newValue: any) {
        instance.#private = newValue;
    }
}

class B extends A { };
const instance = new B();
console.log(A.getProtectedValue(instance)); // 1;

A.setProtectedValue(instance, 2);
console.log(A.getProtectedValue(instance)); // 2;

// Или так
class C extends A {
    doWork() {
        return A.getProtectedValue(this);
    }
}

console.log(new C().doWork()); // 1;

Более того, так как конструкторы также наследуют свойства, то можно и так:

// ... объявление класса А как и выше

class B extends A { };
const instance = new B();

// тут уже обращение через B
console.log(B.getProtectedValue(instance)); // 1;

B.setProtectedValue(instance, 2);
console.log(B.getProtectedValue(instance)); // 2;


class C extends A {
  doWork() {
    // а тут через C
    return C.getProtectedValue(this);
  }
}

console.log(new C().doWork()); // 1;

Там проблема была искусственная - это попытка прикрутить ООП к пакетной обработке данных, летящих к интерпретатору. Иерархия и классы - железобетонно прибиты идентификаторами к архитектуре. Веб-поведение динамично, объекты могут мутировать до состояния байта. Тем более это для поведения форм - полуфабрикат, который связывается дополнительно с разметкой документа (декларативное представление), которая как-то должна уживаться со спецификацией. Поэтому он ушёл в чисто поведенческую нишу ФП для разметки, фактически став знаком "=" в эксцеле.

Я Вам даже больше скажу, в нулевых на каждом втором проекте писали свой велосипед для наследования. Причем, не всегда эти велосипеды были более удобными, чем прототипы...

А с чего Вы решили, что классы стали маргинальными? На фонтенде да, их пожалуй почти выкосила тенденция небольших (или больших, это как кому нравится) функциональных компонент, так как там больше по визуальной части.

Но на бэкенде, особенно там, где сложная бизнес-логика, классам вполне подходящее место. Мне, например, с классами на бэкенде работать гораздо удобнее, чем без них. Код организовывать проще. А если взять такой фреймворк, как Nest.js, то там вообще все через классы.

Кстати... А где самое главное-то: Классы это дёготь или сахар? Синтаксис мы рассмотрели... И всё? А как должно быть? А как НЕ должно быть? Что плохого в классах, что хорошего? Какие решения были удачными, а какие лишь портят общую картину?