Можно поинтересоваться чем это обусловлено? (не сарказм)
Полагаю что ответ кроется в том что вы просто на клиенте js используете что бы производить простые манипуляции с DOM?
Т.к. в случае работы над большими приложениями обойтись без более серьезных инструментов (вроде vue, react и т.д.) просто не получится (а с ними в ваш проект приходит и использование babel).
А к вопросу по typescript - он ведь приносит не только синтаксический сахар (который сейчас конечно и в es6 завезли), но и хоть какую-то типизацию. Когда в вашем приложении очень много структур различных типов данных - вам нужно их как-то описывать (typescript как раз с этим очень неплохо выручает).
Если же все ваши задачи на клиенте сводятся к тому что бы императивным способом обновить часть DOM на странице, то разумеется тянуть в приложеие все описанное выше будет overhead. Но не стоит же в таком случае говорить что "что ES6 + JSDoc ничуть не хуже TS" т.к. TS дает все же больше чем Вам от него требуется и он просто конкретно Вам не нужен, для решения конкретно Ваших задач. По этому не стоит приводить личный в виде объективной оценки. Для разных задач - требуются разные инструменты.
Мне кажется, что empty гораздо удобнее и логичнее использовать в различных ситуациях. Да и просто приятнее написать (!empty($foo)), нежели ($foo !== null || $foo != ""), хотя делают оба варианта одно и тоже.
Так же само мне приятнее использовать (!empty($array)) при работе с массивами, нежели получать количество его элементов, для сравнения, вроде (count($array) == 0).
empty — это возможность понять, есть ли в переменной, что-то важное и если нет — не обращать на нее внимания. Тогда, как прямое сравнение — это возможность убедится что переменная не является null (хотя по прежнему может быть «ненужной», например содержать пустую строку или 0 (если это целое число)).
Я хочу сказать что нужно действовать по ситуации, если переменная может быть равна пустой строке (если это допускается приложением), но не может быть равна null — Вам необходима прямое сравнение, если необходимо проверить наличие в переменной данных, для дальнейшего использования — я не вижу смысла писать условие, в котором перечислены все возможные исключающие ситуации, а проще воспользоватся функцией которая именно для этого предназначена.
Лаконичнее же, данное решение, мне кажется из-за естественности написания. Вы ведь согласитесь, что «если массив не пустой то...» выглядит куда более естественно, нежели «если количество элементов в массиве равно нулю» уже как-то не очень.
Использовать можно и тот и другой вариант, по поводу же стайл-гайдов, то я не думаю, что есть хоть одна группа разработчиков, запрещающая использовать функцию empty (как нативный инструмент языка), своим программистам — это (использования тех или иных функций), собственно, на мой взгляд вообще не должно входить в стайл-гайды.
Не хотелось бы начинать комментарий с критики, поэтому сначала, скажу что согласен с Вами. Использовать манипуляции DOM в 2016 году глупо.
Однако, а теперь критика, подбор фреймворка, в большей мере (лично для меня, а не общепринятый факт), это выбор инструмента для описания бизнес логики самого приложения. Вы же описали View компонент, который к бизнес логике отношения никакого не имеет. Более того, никогда не чувствовал проблем с интеграцией в backbone стороннего View, более того сам фреймворк это поддерживает, как говорится «из коробки».
PS: Мне кажется что заголовок и некоторые выдержки из статьи сильно громкие — Вы громко кричите, но не о том, что хотите сказать на самом деле.
Думаю, что начиная от заголовка Вы описываете не сове мнение, либо его искажаете. Но, блин, Вы делаете это так громко!
>> А заказ большой, включает в себя далеко не только верстку и качать права — дохлый номер.
потом
>>… и приходится потом долбаться с шимами или переверстывать сайт/громоздить костыли.
Получается Вы беретесь за проект, только потому что за него платят больше чем обычно, но нужно мучатся с поддержкой устаревших браузеров, а после жалуетесь, что времени на него тоже уходит больше чем обычно? Тогда у меня вопрос почему бы не взяться за нормальный проект без «извращений», чувствую, что соотношение объем работы и оплаты за нее, получатся такие же как и с приведенным примером, но нервы Вы себе сохраните.
Можно поинтересоваться чем это обусловлено? (не сарказм)
Полагаю что ответ кроется в том что вы просто на клиенте js используете что бы производить простые манипуляции с DOM?
Т.к. в случае работы над большими приложениями обойтись без более серьезных инструментов (вроде vue, react и т.д.) просто не получится (а с ними в ваш проект приходит и использование babel).
А к вопросу по typescript - он ведь приносит не только синтаксический сахар (который сейчас конечно и в es6 завезли), но и хоть какую-то типизацию.
Когда в вашем приложении очень много структур различных типов данных - вам нужно их как-то описывать (typescript как раз с этим очень неплохо выручает).
Если же все ваши задачи на клиенте сводятся к тому что бы императивным способом обновить часть DOM на странице, то разумеется тянуть в приложеие все описанное выше будет overhead.
Но не стоит же в таком случае говорить что "что ES6 + JSDoc ничуть не хуже TS" т.к. TS дает все же больше чем Вам от него требуется и он просто конкретно Вам не нужен, для решения конкретно Ваших задач.
По этому не стоит приводить личный в виде объективной оценки. Для разных задач - требуются разные инструменты.
Так же само мне приятнее использовать (!empty($array)) при работе с массивами, нежели получать количество его элементов, для сравнения, вроде (count($array) == 0).
empty — это возможность понять, есть ли в переменной, что-то важное и если нет — не обращать на нее внимания. Тогда, как прямое сравнение — это возможность убедится что переменная не является null (хотя по прежнему может быть «ненужной», например содержать пустую строку или 0 (если это целое число)).
Я хочу сказать что нужно действовать по ситуации, если переменная может быть равна пустой строке (если это допускается приложением), но не может быть равна null — Вам необходима прямое сравнение, если необходимо проверить наличие в переменной данных, для дальнейшего использования — я не вижу смысла писать условие, в котором перечислены все возможные исключающие ситуации, а проще воспользоватся функцией которая именно для этого предназначена.
Лаконичнее же, данное решение, мне кажется из-за естественности написания. Вы ведь согласитесь, что «если массив не пустой то...» выглядит куда более естественно, нежели «если количество элементов в массиве равно нулю» уже как-то не очень.
Использовать можно и тот и другой вариант, по поводу же стайл-гайдов, то я не думаю, что есть хоть одна группа разработчиков, запрещающая использовать функцию empty (как нативный инструмент языка), своим программистам — это (использования тех или иных функций), собственно, на мой взгляд вообще не должно входить в стайл-гайды.
Однако, а теперь критика, подбор фреймворка, в большей мере (лично для меня, а не общепринятый факт), это выбор инструмента для описания бизнес логики самого приложения. Вы же описали View компонент, который к бизнес логике отношения никакого не имеет. Более того, никогда не чувствовал проблем с интеграцией в backbone стороннего View, более того сам фреймворк это поддерживает, как говорится «из коробки».
PS: Мне кажется что заголовок и некоторые выдержки из статьи сильно громкие — Вы громко кричите, но не о том, что хотите сказать на самом деле.
Думаю, что начиная от заголовка Вы описываете не сове мнение, либо его искажаете. Но, блин, Вы делаете это так громко!
потом
>>… и приходится потом долбаться с шимами или переверстывать сайт/громоздить костыли.
Получается Вы беретесь за проект, только потому что за него платят больше чем обычно, но нужно мучатся с поддержкой устаревших браузеров, а после жалуетесь, что времени на него тоже уходит больше чем обычно? Тогда у меня вопрос почему бы не взяться за нормальный проект без «извращений», чувствую, что соотношение объем работы и оплаты за нее, получатся такие же как и с приведенным примером, но нервы Вы себе сохраните.