Общаться с такими людьми не доводилось. Но за гос. организациями я подразумевал учебные заведения. И, соответственно, мне кажется, что это просто нехватка бюджетных средств для обновления ПО.
Объяснение такому феномену думаю довольно очевидное. Большинство юзеров IE8 это пользователи Windows XP (т.к там он впервые появился как браузер по умолчанию). Пользователей WinXP я встречаю до сих пор (как в гос. организациях так и в мелких частных компаниях). К тому же что говорить о IE8, если еще и IE6 живет
Если есть возможность компилировать несколько файлов в один, никто не мешает автоматизировать вам этот процесс. Например прописать настройки компиляции при билде в вашем проекте.
в данном случае 2 файла app.ts и hello.ts скомпилируются в 1 output.js
2. Приватные переменные только проверяются на стадии компиляции — но на самом деле они публичные и если предок и наследник имеют приватную переменную с одним и тем же именем — будет просто ошибка компиляции. Это как то не продумано.
Тут я с вами согласен. Это вызвано тем, что в JavaScript невозможно задать приватные поля. Они просто не предусмотрены спецификацией языка.
Спасибо за столь развернутый комментарий. Постараюсь ответить на Ваши вопросы:
Не все браузеры поддерживают отладку TypeScript в консоли без лишних настроек.
Действительно ли это доставляет проблем? Говорят, что сгенеренный JS обычно настолько прост, что вообще не составляет проблем его дебажить без всяких сорсмапов. Правда или врут? Если правда, то минус сугубо теоретический.
Согласен с вами, что в большинстве случаев хватает дебажить итоговый JS, но в крупных проектах, если у вас есть множество классов, контроллеров, вью моделей, то гораздо приятнее дебажить именно их. Сам сталкивался с такой проблемой, что без проблем получается отлаживать конечный код на ts только в браузере IE. Во всех остальных приходится делать манипуляции с .map файлами, дабавляя их в соответвующую директорию на сервере.
Множество нетривиальных классов. Чтобы писать код, опираясь на классы, приходится держать в голове какое свойство где находится. Например вместо одного класса Event существуют еще такие как MouseEvent, TouchEvent, KeyboardEvent и другие…
Это ж браузерные классы, а не тайпскриптовые. Или я чего-то не понял в этом минусе, или вы что-то не то говорите.
Лично сталкивался со случаем вида (event).keyCode, где keyCode нет в классе Event.
Неявная статическая типизация. Всегда можно описать тип как any, что по факту отключит приведение к конкретному типу этой переменной.
Опять же. Насколько это реальная практическая проблема? Действительно ли всякие ленивые люди это делают, и это доставляет какую-то боль?
Считаю это плохой практикой, т.к используя any вы лишаете себя основной возможности TypeScript — проверки типов. К примеру описав параметр функции как any, вы должны валидировать ее тип самостоятельно.
d.ts декларации поддерживаются сообществом DefinitelyTyped и часто не соответствуют текущей версии библиотеки. Либо не учитывают сложных вариантов (generic-функции, возвращаемые значения нескольких типов)
И опять же хотелось бы примеров — насколько часто такое встречается, и насколько много проблем доставляет.
Пример — knockoutjs сейчас имеет версию 3.4.0, а в DefinitelyTyped есть определения пока еще только для версии 3.2.0
Приходилось сталкиваться с подобной проблемой тоже. Решилось все использованием WinJS нативных байндингов. Подключаем вьюхи через data-win-control и подобный подобные проблемы с данамическим контентом исчезают
Насколько я понял автор старался подчеркнуть в своей статье значимость альтернативных источников получения информации отличных от обучающих программ, экспресс курсов и прочих интернет ресурсов.
работаю в Shopify не я, а автор статьи, которую я перевел. В оригинале статья получила достаточно одобрительных комментариев, поэтому я посчитал полезным перевести ее для хабра. В первую очередь статья должна мотивировать джуниоров, что собственно из заголовка статьи должно быть понятно
кстати уже есть пулл реквест который добавляет поддержку JSDoc
в данном случае 2 файла app.ts и hello.ts скомпилируются в 1 output.js
Тут я с вами согласен. Это вызвано тем, что в JavaScript невозможно задать приватные поля. Они просто не предусмотрены спецификацией языка.
Если вы запускаете проект в IE, то такая возможность по умолчанию есть.
Согласен с вами, что в большинстве случаев хватает дебажить итоговый JS, но в крупных проектах, если у вас есть множество классов, контроллеров, вью моделей, то гораздо приятнее дебажить именно их. Сам сталкивался с такой проблемой, что без проблем получается отлаживать конечный код на ts только в браузере IE. Во всех остальных приходится делать манипуляции с .map файлами, дабавляя их в соответвующую директорию на сервере.
Лично сталкивался со случаем вида (event).keyCode, где keyCode нет в классе Event.
Считаю это плохой практикой, т.к используя any вы лишаете себя основной возможности TypeScript — проверки типов. К примеру описав параметр функции как any, вы должны валидировать ее тип самостоятельно.
Пример — knockoutjs сейчас имеет версию 3.4.0, а в DefinitelyTyped есть определения пока еще только для версии 3.2.0
http://habrahabr.ru/post/258713/
http://habrahabr.ru/post/132558/
p.s. сам занимался этим, но на хабр постеснялся писать, по той же причине
Автор статьи призывает не только читать книги