Компания Microsoft опубликовала (https://blogs.msdn.microsoft.com/typescript/2016/09/22/annou.../) релиз TypeScript 2.0 (http://typescriptlang.org/), языка для разработки web-приложений, расширяющего возможности JavaScript. Код компилятора, транслирующего код TypeScript в представление JavaScript, распространяется (https://github.com/Microsoft/TypeScript) под лицензией Apache 2.0, разработка ведётся в публичном репозитории через сервис GitHub. Спецификации (https://github.com/Microsoft/TypeScript/blob/master/doc/spec.md) языка открыты и опубликованы в рамках соглашения Open Web Foundation Specification Agreement (http://www.openwebfoundation.org/legal/the-owf-1-0-agreement...).TypeScript расширяет возможности JavaScript, оставаясь полностью обратно совместимым, что сводит к минимуму затраты на адаптацию существующих приложений. Основной принцип языка - весь существующий код на JavaScript совместим с TypeScript, т.е. в программах на TypeScript можно использовать стандартные JavaScript-библиотеки и ранее созданные наработки. Более того, можно оставить существующие JavaScript-проекты в неизменном виде, а данные о типизации разместить в виде аннотаций, которые можно поместить в отдельные файлы, которые не будут мешать разработке и прямому использованию проекта (например, подобный подход удобен при разработке JavaScript-библиотек). Итоговое приложение на TypeScript компилируется в обычный JavaScript, который можно выполнить в любом современном web-браузере или использовать c Node.js.
От JavaScript новый язык отличается средствами для явного определения типов, поддержкой использования полноценных классов, а также поддержкой подключения модулей. Статическая типизация позволяет избежать многих ошибок в процессе разработки, даёт возможность задействовать дополнительные техники оптимизации, упрощает отладку и делает код более читаемым и простым для доработки и поддержки сторонними разработчиками. Кроме аннотаций данные о типах могут быть определены с использованием "generic", что позволяет вводить специальные дополнительные параметры типов, которые дают возможность выявлять ошибки в реализации классов, интерфейсов и методов без дополнительных аннотаций типов (например, генерик для функции map позволяет считать, что переменные создаваемые конструкциями в которых используется map можно рассматривать как числовые).
Основные новшества (https://github.com/Microsoft/TypeScript/wiki/What's-new-in-TypeScript) TypeScript 2.0:
- Упрощена операция установки файлов ".d.ts" с информацией о типах для существующих библиотек. Например, для установки данных о типах библиотеки lodash теперь достаточно выполнить команду "npm install -s @types/lodash" и загруженные данные о типах будут автоматически использованы при импорте библиотеки lodash в любой части приложения без необходимости применения дополнительных инструментов для управления зависимостями;
- Возможность определения типов, не допускающих пустые (null) и неопределённые значения (undefined), а также отдельные типы Null и Undefined, которые позволяют разработчику явно контролировать ситуации в которых допустимо использование значений null и undefined. Так как изменение в обработке null/undefined нарушает обратную совместимость для включения проверки добавлен отдельный режим "--strictNullChecks";
- Расширение средств для оценки применимости типов на основе анализа потока выполнения программы, позволяющих, например, выявлять ситуации использования неинициализированных значений из-за несрабатывания условного оператора, которые не определяются статическим анализатором и возникают в зависимости от хода выполнения программы;
- Добавлен модификатор "readonly", позволяющий определять свойства, доступные только для чтения.
URL: https://blogs.msdn.microsoft.com/typescript/2016/09/22/annou.../
Новость: https://www.opennet.ru/opennews/art.shtml?num=45201
Тайпскрип - это как бабель, только от Майкрософта, я правильно понял?
Не-а. Это попытка причесать нетипизированный ужоснах ванильного JS. Удачная, между прочим, хоть и не без своих косяков.
Почему ужас?
Потому что без этого в проектах крупнее hello world начинают суммировать буханки хлеба с троллейбусами. И даже получают какой-то результат.
Это чтобы рукожопы из типизированного мира не слишком лажали с JS.
Вы абсолютно правы, пишите дальше на js.
> Это чтобы рукожопы из типизированного мира не слишком лажали с JS.Не подскажете, почему основная масса взломов серверов нынче происходит через вебню без жесткой типизации? :)
> Не подскажете, почему основная масса взломов серверов нынче происходит через вебню без жесткой типизации?Секурные флеш и жаба апплеты на Безопасных Типизированных Языках(ТМ) наше всё.
> Секурные флеш и жаба апплеты на Безопасных Типизированных Языках(ТМ) наше всё.Вспомнить именно случаи взлома флеш-апплетов ... ну наверное так возможно, но вы приведете навскидку хотя-бы пару примеров?
Секурнейший ActiveX забыли )
> Не подскажете, почему основная масса взломов серверов нынче происходит через вебню без жесткой типизации? :)А где статистику посмотреть можно?
> А где статистику посмотреть можно?А вот прямо здесь в новостях. Или в списке CVE, чтобы более прицельно.
Нет, бабель - просто транспайлер. Тайпскрипт - синтаксический сахар + синтаксический анализатор + транспайлер.
TS - это просто даже ms понял что по ходу лучше на нем писать чем на c#...
> TS - это просто даже ms понял что по ходу лучше на
> нем писать чем на c#...Сразу видно специалиста по C#. Да и по JS тоже.
фактическим создателем TS является программист Андерс Хейлсберг, так же известный как создатель таких языков как Delphi, C#.Вам стоит научиться разделять c# и .net.
> таких языков как DelphiСразу видно крупного специалиста по ЯП ;)
Delphi, к Вашему сведению, сэ-э-эр, - это среда быстрой разработки (RAD) для языка Object Pascal (ну, точнее, одного из его диалектов - Turbo Pascal от Borland (не путать со средой разработки Turbo Pascal на базе Turbo Vision), позже переименованный в Borland Pascal). Правда, Borland решили по примеру МелкоМягких ввести своих пользователей в заблуждение и в некоторых документах пытались обзывать его "языком программирования Delphi" - ведь нужно же что-нибудь выдавать за "инновации", чтоб за это кто-нибудь деньги заплатил. А "новый" ЯП - это ж круто... Хотя, по факту, это все тот же старый добрый диалект Object Pascal. Такое впечатление, что Borland пытается скрыть корни языка из Apple. К стати, как и идея Turbo Vision - слизана с MacApp.
Да будет вам известно, что delphi это не только среда, а как-раз таки язык, диалект Object Pascal'а.
Все эти ваши Flow и прочие надстройки — полумеры. Вот TypeScript загоняет разработчиков в типизированный загончик, и это правильно. Может там когда-нибудь дорастут потом до вменяемых инструментов для фронта, как вот Elm или PureScript.
Мозгов не хватет. С JS кое-как справляются
> расширяющего возможности JavaScript«Обними, расширь и уничтожь»:
https://ru.wikipedia.org/wiki/Embrace,_Extend,_and_Extinguish
пока оно строго компилируется в js, волноваться не стоит.
Да и не жалко будет, если честно.
> Да и не жалко будет, если честно.Даже не знаю, чем VBScript (внеднение которого МСовцами таки не прокатило) с activeXами в браузерах были бы лучше JS ;-)
Уничтожать Javascript будут скорее через Webasssembly. Впрочем, к нему Microsoft тоже приложила руку. С технической же точки зрения, оба начинания верны.
> приложила руку. С технической же точки зрения, оба начинания верны.Они и к AV1 формально приложили руку. Но как-то совсем уж формально - участвуют в фоундэйшне. Нет, код они не пишут от слова вообще. Вкалывает на 70-80% гугл, 10-20% мозилла, по мелочи циска докидывает. Майкрософт оказывает моральную поддержку. Их наверное все должны будут благодарить что они в своих недобраузерах вообще этот кодек реализуют.
Так, на подумать: Edge и IE - единственный выводок браузеров где нельзя например сделать server push сколь-нибудь просто и эффективно. И из-за этого куска индусского кода с 5% рынка - возни больше чем со всем остальным вместе взятым.
>> расширяющего возможности JavaScript
> «Обними, расширь и уничтожь»:
> https://ru.wikipedia.org/wiki/Embrace,_Extend,_and_ExtinguishТут, как и с остальными новоявленными чудесами "открытий" от Биллисофта не надо даже заглядывать внутрь -- [U] Микроскам зарелизил очередной Микрошлак [/U].
+++Автор приносит свои благодарности http://www.urbandictionary.com/tags.php?tag=microsoft+nicknames за х[U] Microsludge, Microscam и Billysoft [/U]. Не пропустите страницы два http://www.urbandictionary.com/tags.php?tag=microsoft+nickna... и тры http://www.urbandictionary.com/tags.php?tag=microsoft+nickna... ! ---"Микрочлен"?
> Упрощена операция установки файлов ".d.ts" с информацией о типах для существующих библиотекПрям какая-то мегаачивка. Вообще-то они просто ручками репы понаделали, для относительно небольшого количества пакетов. И не очень понятно кто там будет поддерживать актуальность.
Неужели лучше ставить весь существующий хлам d.ts из одного пакета? Я, честно говоря, порадовался альтернативе в виде typings-менеджера
Приятная новость, но... это всё же джаваскрипт и веб-приложения.
> Приятная новость, но... это всё же джаваскрипт и веб-приложения.Не вижу принципиальных преград для унификации скрипто-прикладного программирования и использования единого синтаксиса аля-JavaScript (возможно ECMAScript) вместо безмерно расплодившихся VBScript, VB, Delphi, PHP, Phyton, Ruby и прочих скриптовых поделок, включая PERL. Все они могут делать очень схожие вещи, все пишут враперы, плодят свои библиотеки и прочую экосистему. Уйма времени уходит на дублирование/перенос функционала вместо повышения качества реализации исполняемой среды, трансляторов-во-всё-что-хочешь и кода библиотек.
>> Приятная новость, но... это всё же джаваскрипт и веб-приложения.
> Не вижу принципиальных преград для унификации скрипто-прикладного программирования и использования единого синтаксиса аля-JavaScript (возможно ECMAScript) вместо безмерно расплодившихся VBScript, VB, Delphi, PHP, Phyton, Ruby и прочих скриптовых поделок, включая PERL. Все они могут делать очень схожие вещи, все пишут враперы, плодят свои библиотеки и прочую экосистему. Уйма времени уходит на дублирование/перенос функционала вместо повышения качества реализации исполняемой среды, трансляторов-во-всё-что-хочешь и кода библиотек.А уж сколько времени уходит на изучение всего этого скриптового борделя с ихними религиозными различиями в использовании скобочек, кавычек и точек-с-запятой...
Изучение структуры библиотек съедает ещё больше времени.
Пока сидишь в одном тёплом болоте PHP/HTML/JS, Java или C#, то всё вроде бы и ничего..., но как только в юникс-вейном-стиле начинаешь комбинировать различные софтины, написанные на разных языках, то со временем возникает вопрос: а нафига столько языков, если делают они практически одно и то же?!
Да и про bash/sh/... вспоминается... Нет, конечно есть вещи и более извращённые - то же самый PowerShell -, но нафига в принципе нужно издеваться над скриптописателями?!
Вот написал более или менее сложный скрипт, отладил, а через полгода надо что-то добавить/изменить... И нужно заново вспоминать, как там if() оформляется, какие есть умолчания, как строки соединяются, каким синтаксисом ПРАВИЛЬНО пользовать переменные (потому что есть НЕСКОЛЬКО способов даже для такой фигни!!!), как запускать фоновые/конвейерные задачи с нужным перенаправлением потоков ввода/вывода и как не ошибиться с именем переменной (контроля объявлений же нету!!!)...
Ещё для примера посмотрите на количество CMS и языков, на которых эти CMS-ки написаны. Их как грязи! Задачи CMS-ками решаются одни и те же, но явного преимущества для этих задач не даёт ни один из применяемых языков программирования. Всякие фреймворки и тулкиты - та же беда!
Назрела, ой как назрела потребность в унификации в деле прикладного скриптописательства.
Всё очень просто. Если ты пишешь для себя скрипты (т.е. какая-то локальная автоматизация) - ты пишешь их на чём-то одном. И никакой проблемы нет.Если же ты пишешь продукт - там, вообще говоря, скриптовым языкам (т.е. рассчитанным на "бысто и несложно написать") делать нечего. Вот что назрело - так это внятное разделение скриптовых и production языков.
> Всё очень просто. Если ты пишешь для себя скрипты (т.е. какая-то локальная
> автоматизация) - ты пишешь их на чём-то одном. И никакой проблемы
> нет.
> Если же ты пишешь продукт - там, вообще говоря, скриптовым языкам (т.е.
> рассчитанным на "бысто и несложно написать") делать нечего. Вот что назрело
> - так это внятное разделение скриптовых и production языков.На мой взгляд, скрипты хороши для склеивания разрозненных бинарных модулей. Собственно так мы адаптируем применение систем в конкретных условиях. Я не сторонник подменять скриптами языки программирования общего назначения.
> Если же ты пишешь продукт - там, вообще говоря, скриптовым языкам (т.е.
> Вот что назрело
> - так это внятное разделение скриптовых и production языков.Кстати, да, согласен. Вроде как JavaScript уже и не скрипт вовсе, а скорее становится языком программирования общего (универсального) назначения.
> использования единого синтаксиса аля-JavaScript (возможно ECMAScript) вместо безмерно
> расплодившихся VBScript, VB, Delphi, PHP, Phyton, Ruby и прочих скриптовых поделок,И все б ничего если б JS не имел кучи своих проблем. Поэтому его наверное постепенно прибьют в пользу webassembly. А дальше кому на чем удобно тот на том и будет писать. Если кому удобно на Ruby писать - то наверное это его дело, не?
>> использования единого синтаксиса аля-JavaScript (возможно ECMAScript) вместо безмерно
>> расплодившихся VBScript, VB, Delphi, PHP, Phyton, Ruby и прочих скриптовых поделок,
> И все б ничего если б JS не имел кучи своих проблем.
> Поэтому его наверное постепенно прибьют в пользу webassembly. А дальше кому
> на чем удобно тот на том и будет писать.Да у всех языков есть свои неудобства и недостатки, но синтаксис в большинстве случаев уже можно было бы и унифицировать.
> Если кому
> удобно на Ruby писать - то наверное это его дело, не?Таки да.
А ещё бывают полиглоты. Им вообще пофиг сколько языков учить.
Не, вы, друзья, как ни садитесь... Жабоскрипт убог by design, и припарки тут не помогут, только живительная эвтаназия.
> обоссаный javascriptтут вы правы
Припарки нужны пока не заработает в полную силу Webassembly.
Webassembly выплевывает ЖабоАсам
> Webassembly выплевывает ЖабоАсамЕго выплевывают всем - он ЯП не навязывает. На чем хочешь на том и пиши. А то когда промежуточное представление делают из JS как всякие emscripten, получается кошмар на улице вязов.
Согласно описания, это дополнительная возможность, а не обязанность>WebAssembly describes a memory-safe, sandboxed execution environment
>that may even be implemented inside existing JavaScript virtual machines.
По аналогии как C++ это С с классами,
TypeScript это Javascript с типамипоскольку js убог, то Scala.js наше все
А почему не Clojurescript?
О да, заменить одно извращение на другое - самое оно.
Я за Дарт. Гораздо более правильная разработка, а не этот обрезок.
Теперь бы еще браузеры научить понимать этот TypeScript без перевода в JS
P.S.
тем более, если он обратно совместим с JS, страницы не поломаются.
Браузерам не надо уметь typescript. Пишете на TS, дальше всё компилируется и собирается в js файл/файлы, которые отлично работают на странице в браузере. Angular2 тому живая иллюстрация для примера.
И js файлы сохраняют информацию о типах? Или как после применяются все эти оптимизации?
Вся типизация работает на уровне статического анализа. Соответственно т.к. результат написания программ TS всегда JS, итоговый код ничего не знает о типах в runtime. Но поверьте, имея статический анализ типов, описания интерфейсов и типов, нормальные стрелочный функции, которые в классе за вас сделают замыкание, фичи типа async-await, декораторы на уровне языка и прочее, прочее, прочее, что дальше идёт в ES6, ES7 (и надеюсь и далее будет развиваться), так вот всё это сильно улучшает как front-end разработку, так и бекенд на nodejs.
> бекенд на nodejs.Мне сразу представляется банковский счет, на котором лежит NaN рублей.
И вы туда перечисляете undefined рублей.
Для каждой задачи выбирается свой набор инструментов, а не наоборот. Возможно у вас как-то иначе, поэтому NaN рублей пополняется на Undefined рублей.
Ничего не сохраняется. Никаких реальных оптимизаций не применяется.
На счёт оптимизаций всё почти так, кроме некоторых моментов, связанных с опциями компиляции, например возможности указать какую версию ES вы хотите видеть в итоговом файле. Например ES5 для фронта, потому что больше браузеры сейчас массово не умеют, или ES6 для бекенда, если у вас nodejs 6х, например, и вы хотите всякие @decorator, @proxy, async/await и прочее в нативной форме использовать или в принципе использовать.
И как эту скомпилированную кучу добра потом отлаживать?
sourcemaps
Благодаря типизации код пишется сразу без багов.
Отладка поддерживается браузером по на основе sourcemap файлов по TS файлу. Процесс прозрачный и не требует дополнительных телодвижений. Не хочется отлаживать TS через sourcemap - можно заниматься отладкой js, там тоже особо страшного ничего нет, это не бинарный или обфусцированный код, по дефолту там даже форматирование человекочитаемое. Разумеется в этой ситуации необходимо быть в курсе в общих чертах, "что такое JS" чуть глубже, чем "hello world": языковые конструкции классов, приватных членов, обращений к this внутри методов и т.п. неизбежно обретают при компиляции полноразмерную JS реализацию в соответствии с общеизвестными паттернами и возможностями/ограничениями языка конкретной версии ES,под которую компилировался код.
Спасибо.