JavaScript: где мы сейчас и куда двигаться

Да, я согласен с тем, что классы (как сущность в синтаксисе) нужны для того чтобы статическим анализаторам (системе типов) облегчать работу. То есть в данном случае это просто контракт типа, который говорит что «а вот у нас такие методы есть», и это сразу доступно сразу после разбора AST, без необходимости делать глубокий вывод типов, как это делают инструменты типа Tern. Документацию опять же генерить легче.

Аннотации типов (и их статический анализ) в JS сейчас уже вовсю появляются — в статье про это упомянуто (Flow). Так что это может быть внешним инструментом.

Мне вообще очень нравится на самом деле то как развивается JS. Новые расширения языка сначала появляются извне, как внешние инструменты. А потом уже стандартизуются, когда становится очевидно, что это работает и работает хорошо. Babel это лучшее что случилось с JS за последние годы — а вовсе не «костыль», как многим кажется. Потому что стандарты делаются для людей, а не люди для стандартов. И чтобы понять, что нужно стандартизовать — это сначала должно быть опробовано людьми (комьюнити) и зарекомендовать себя. Но такой фидбек луп был невозможен до Babel.

It’s the future

Спасибо, интересно очень именно про негативные стороны React узнать. Потому что все пишут про его положительные стороны, а вот недостатки обходят стороной. А ведь в них вся соль. Мне вот совершенно непонятно пока, как в реакте с его уровнем абстракции от DOM делать какие-то супер динамичные вещи.

К примеру, у меня есть проект WYSIWYG редактора, который юзает голый DOM (и именно это позволило сделать такой UI, а также кастомный undo/redo стек для DOM):

Я понятия не имею как подобное можно было бы реализовать в рамках модели React. Но очень интересно.

It’s the future

Посмотрите в сторону Flow.

JavaScript: где мы сейчас и куда двигаться

Брр, не подмножеством, конечно же, а вообще несовместимой с ним фигней, усложняющей язык.

JavaScript: где мы сейчас и куда двигаться

Классы это просто удобная декларативная форма конструирования прототипов, ничего плохого в этой абстракции нет per se. Плоха именно ES6 реализация, которая ломает идею «прототипы это тоже объекты» на уровне синтаксиса. То есть было:

Foo = $class ({ methodA: ..., methodB: ... })

стало:

Foo = class { methodA () { .. } methodB () { ... } }

Это даунгрейд по сравнению с ES5, по той причине, что прототип синтаксически перестал быть объектом, и я не могу переопределить реализацию class, добавив какой-нибудь препроцессинг этого. Для этого появился костыль в виде декораторов:

Foo = @decorate class { ... }

Но — ха-ха — это все равно даунгрейд, потому что внутри { ... } у нас не объект. Там другой синтаксис, который является подмножеством JSON — не позволяя делать key: value, а значит, теряя в выразительности.

Никакого смысла в ключевом слове class нет — оно не решает ни одну проблему, но создает кучу проблем. Все плюшки классового синтаксиса доступны и в объектах. Вот смотрите:

obj = {
    method () { },
    get prop () { },
    foo: bar
}

Видите? Я могу так же коротко записывать методы и акцессоры, но при этом я не теряю возможности сделать foo: bar. В ES6 достаточно было сделать лишь это, не было никакой нужды вводит ключевое слово class.

Проприетарные системы классов в JS просто выглядят так, как будто они пытаются имитировать классы. На деле они дают намного больше чем классы, и по факту являются просто абстракцией, позволяющей удобно описывать прототипы. И эти системы потому у каждого фреймворка свои, потому что у каждого решают какие-то свои задачи, специфичные для фреймворка. Скажем, где-то есть миксины, где-то нет. Ключевое слово class все ломает, запрещая разработчикам как-то встраиваться в механизм создания прототипа, фиксируя этот механизм, обрубая все замечательные возможности, которые появились в различных фреймворках.

Когда разработчики стандарта JS осознали, что же они натворили — бегом побежали делать декораторы, которые эту проблему немного позволяют решить. Но правильным шагом было бы исключить class из стандарта (сделать его deprecated), и развивать идею декораторов для объектов. Оставив задачу конструирования прототипов в userland. Потому что там нужна гибкость, и классы в ES6 эту гибкость уничтожили.

It’s the future

Нужны приватные поля? Вместо этого изобрели новый базовый тип Symbol, который сложно понять и всё равно можно обойти. Вместо потоков — веб-воркеры, без примитивов синхронизации и с урезанными возможностями взаимодействия. Вместо классического наследования — прототипное.

Тут я с вами очень сильно не соглашусь. Прототипное наследование намного мощнее вашего так называемого «классического». Классы это новая (лишняя) сущность по отношению к объектам — это blueprint'ы объектов — тогда как прототипы придерживаются самого настоящего классического ООП принципа «всё есть объект»: наши прототипы это тоже объекты. То есть, прототипное наследование на деле куда более «классическое», оно проще, оно фундаментальнее. Оно объектное.

Символы точно так же куда более общая концепция, чем приватные поля. Приватные поля — это атрибут «классов», они не имеют смысла в рамках модели, в которой классов нет (в JS классы это лишь сахар для настоящих объектных прототипов — для тех несчастных, кто не освоил их — чтобы сгладить переход из других языков).

Например, символы позволяют делать свойства без строкового имени вообще (анонимные), исключая конфликты с существующими полями:

field = Symbol () 
obj[field] = ...

Что позволяет расширять объекты мета-информацией, доступной только тем, кто в ней заинтересован, не вступающей в конфликт с чем-то еще. Скажем, вместо метода .toString () у объектов, процедуры распечатки объектов могли бы экспортировать соответствующий символ. Вот как это сделано в библиотеке string.ify например:

Boolean.prototype[Symbol.for ('String.ify')] = function () {
                                                   return this ? 'yes' : 'no' }

String.ify ({ a: { b: true }, c: false })
//         '{ a: { b: yes }, c: no }'

It’s the future

Насчет идеологов это вы зря. Как раз-таки многие идеологи ECMAScript против классов. К примеру, Дуглас Крокфорд вообще не использует классы (btw, благодаря нему в JS появился `Object.create`).

Вот список статей, обосновывающих, почему классы в ES6 это кривой костыль, создающий проблемы, а не решающий их: Not Awesome: ES6 Classes

Или вот: How to Use Classes and Sleep at Night

JavaScript: где мы сейчас и куда двигаться

Мне чтобы для себя ответить на эти вопросы, пришлось много лет делать свой фреймворк. Я об этом не жалею, потому что это позволило мне разобраться в JavaScript вплоть до самых его кишок. Но именно поэтому я не осуждаю людей, которые не знают что такое .prototype или зачем нужен Object.create — потому что понимаю, сколько надо потратить личного времени, чтобы в этих деталях разобраться. У большинства людей на работе просто нет задач, которые это требуют.

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

Зачем нам jQuery?

Я в одном из своих проектов отказался от jQuery именно по той причине, что он «проглатывал» ошибки доступа. Это только для спагетти-проектов подходит.

То есть, если я вижу в коде, что if (h2) — это подразумевает, что возможна такая ситуация, когда h2 не будет. И стоит задаться вопросом — почему. На самом деле, это исключение, а не правило. JQuery же возводит в абсолют такой паттерн — подразумевая, что элемента, с которым мы работаем, может не быть.

Это так же неправильно, как если бы язык программирования не выбрасывал null pointer exception при доступе к несуществующему свойству, а молча это проглатывал. Вы бы тогда охренели отлаживать код, потому что совершенно непонятно было бы, почему он не работает — хотя делает вид что работает.

JavaScript: где мы сейчас и куда двигаться

Мой друг как-то рассказывал мне историю про своего кореша, который ушел из Яндекса по той причине, что опыт, полученный в Яндексе был применим только в самом Яндексе.

JavaScript: где мы сейчас и куда двигаться

Я про него не забыл, просто у нас в проекте как раз подобная абстракция используется для событийной модели и асинхронного dataflow — но для меня было совершенной загадкой, как React'у удается быстро обновлять DOM при изменениях в данных без использования подобной абстракции. Для меня это было инсайтом — как и то, как тесно это связано с иммутабельностью и функциональной чистотой.

JavaScript: где мы сейчас и куда двигаться

Я просто думаю что правила типографики из текстов на естественных языках применимы и к коду — ведь текстовое представление кода именно на естественных языках и базируется. То есть если вы в английском или русском языке перед скобками ставите пробел, то почему бы и в коде так не делать? Это очень естественно.

Убивать вообще никого не надо, агрессия нынче не в моде.

It’s the future

Слишком много оверхеда. Просто возьми бумагу и карандаш.

It’s the future

Для слоупоков от мира веб-разработки — написал статью, которая мб кому-то поможет разобраться лучше с проиходящим: JavaScript: где мы сейчас и куда двигаться.

It’s the future

Для больших и сложных приложений его стали только в последние годы использовать. Отсюда и взрыв технологий и интереса к языку, и проблем сопутствующих. В 95 году это был просто встраиваемый скриптовый язык, по типу bash. Никто не предполагал, что это будет основой будущей «операционной системы интернета».

It’s the future

Ну ничего страшного, статья-то замечательная :) Не грех и еще раз посмеяться. Тут как раз соседний топик «Зачем нам JQuery?», так что весьма ситуативно получилось.

Чем меньше, тем лучше — о возможностях языков программирования

Why is Haskell used so little in the industry?

И вот еще забавная статья, развенчивающая миф о простоте Хаскелла, на примере реализации quicksort:

Parallel generic quicksort in Haskell

Почему теория струн не является научной теорией

Вы исходите из странного предположения, что математика это наука. Есть разница между словом «наука» в бытовом смысле (т.е. это то, чему научают — в школе, в институте). И формальным его смыслом. В формальном смысле математика не является наукой.

Научный метод

Просто в русском языке так уж повелось, называть все подряд наукой. Это трудности перевода. В англоязычной среде math и science это совершенно разные понятия. Math !== science.

Альтруизм, эгоизм, инстаграм. Взгляд физиолога на поведение в социальных сетях

> Жертвуя большую сумму денег на благотворительность, помогая бездомным и больным, мы демонстрируем альтруистическое поведение как средство повышения собственной репутации и статуса.

Кто «мы»? Говорите за себя ;) Истинно альтруистические поступки не совершаются с целью демонстрации чего-либо. В ином случае это имитация альтруизма — или карго-культ. К примеру, известно, что альфа особям присуще альтруистичное поведение. Можно имитировать поведение (пикаперы занимаются подобным) — но это всегда останется лишь имитацией. Разница в искренности.

Гамбит Яровой

Эта машина уже не может остановиться. Они делают то единственное, что умеют делать — запрещать, ограничивать, уничтожать, пресекать, подавлять, манипулировать, etc etc. Им недоступно творчество и созидание — их этому не учили в институтах КГБ.