Расширяемость
Ковырялся я тут на досуге во внутренностях react.js, и вот что я хочу сказать вам о JavaScript вообще.
Я познакомился с JS когда это был вполне себе простой и понятный язык. Раз: любому объекту в любой момент можно добавить любое свойство, и два: один объект может иметь прототипом второй, тогда свойства ищутся по цепочке. Всё. Конечно, эта кажущаяся простота нелегко давалась разработчикам компилятора, но нам-то, пользователям, было хорошо. Просто и гениально. Я как-то недостаточно наблюдал восторгов по поводу красоты концепции.
Реализация кое-где хромала, конечно. Свойство prototype, к примеру - не путать с идеей прототипов - настоящий бред. Если бы его быстренько - ну, в ES3 там, или раньше - зафиксили, народ бы не ныл и не просил классов. Ну или использование объектов как структуры данных-словаря, до сих пор эпичнейшие баги всплывают, типа того что на npm нельзя создать библиотеку с именем constructor. Мне кажется, именно из-за этого JS-программистов и следом вообще всю frontend-разработку не считают за «настоящее» программирование.
Но реализация - дело наживное. Главное, что языку больше ничего и не надо. Можно стандартную библиотеку доделать, добавить массивы и словари настоящие, и можно вполне писать. Питон как-то так и работает, и много что на нем можно сделать.
Я веду к тому, что в таком состоянии у языка появляется очень важное свойство - безумная, просто неконтролируемая расширяемость, какая даже рубистам не снилась. Настоящая расширяемость, модифицируемость - это не когда вам дали два гнезда и вы можете воткнуть в одно - функцию, раскрашивающую вывод, а во вторую константу, отвечающую за размер буфера. Расширяемость, в том виде в каком к ней надо стремиться - это возможность взять вещь, посмотреть как она устроена, разобрать, что-то вынуть, что-то поставить свое. Утиная типизация, подсовывание своего объекта вместо чужого, все ручки на виду и перезаписываемые. При проектировании под расширяемость надо учитывать ровно одну вещь - что ты понятия не имеешь, кто и что с твоей библиотекой захочет сделать.
Ведь почему мы так любим Кложу? Потому что в ней принято делать открытые системы (с подачи Рича, конечно). Первое - библиотеки гоняют данные, и на вход, и на выход, и внутри. Данные, понятно, открыты, это не классы, их легко распечатать, легко поменять, сгенерировать в нужном виде - короче, библиотека никак не диктует, что и как вам делать с данными. Второе - протоколы, протоколом прикинуться легко. Третье - открытые неймспейсы, куда можно при необходимости залезть, посмотреть, поменять что-то. Позволяет, например, тестировать даже то, что для тестирования не предназначалось.
Это приводит к тому, что почти всегда библиотеку на Кложе можно понять и можно заставить делать то, что нужно. Очень трудно загнать пользователя в угол, если только специально не прилагать усилий. Это важно, и я рад, что Кложе-сообщество подхватило этот тренд.
Но куда идет общественное мнение? Общественное мнение склоняется к тому, что разработчику библиотеки виднее, что выставлять наружу, а что нет. Приватные свойства, закрытые лексические скоупы, захваченные через замыкание функции и свойства без постоянного имени, проверка конкретного типа вместо протокола или утиной типизации. Все это потихоньку втаскивается в JS как зарекомендовавшие себя практики из «большого» программирования, но это и убивает всю прозрачность JS.
Не надо так.