Comments 197
Видите ли, для каждой портированной либы необходимо описать .d.ts файл, в котором и хранятся все возвращаемые типы и описание всех методов.
Можно просто тип any использовать
declare var $: any;
Верно, типизация в TypeScript опциональна и не причиняет больших не удобств, даже наоборот! )
Использовать часто any не совсем корректно. Обычно я быстренько описываю только используемые функции. Описания больших библиотек немного замедляют сборку, но все равно могут быть полезными в IDE.
TypeScript никак не конкурирует с JS, а развивает его, очень много крутых фишек, (которые возможно и были в спецификации!) быстрее реализовались в остальных компиляторах после того как были опробованы в TS.
Использовать часто any не совсем корректно. Обычно я быстренько описываю только используемые функции. Описания больших библиотек немного замедляют сборку, но все равно могут быть полезными в IDE.
TypeScript никак не конкурирует с JS, а развивает его, очень много крутых фишек, (которые возможно и были в спецификации!) быстрее реализовались в остальных компиляторах после того как были опробованы в TS.
Согласен, но если смотреть с этой точки зрения, то это полумера, так как все можно описать через any и использовать TS в некоторых частях кода, а не везде. Но я являюсь поклонником фразы: «Если используешь что-то, то используй это на 100%».
Можете глянуть — jQuery.d.ts, если будет интересно.
Но в целом — Вы правы.
Можете глянуть — jQuery.d.ts, если будет интересно.
Но в целом — Вы правы.
UFO just landed and posted this here
Стоит также взглянуть на flow
А еще на соответствующий плагин для Babel. Очень выручает с типами, тем более что Babel сейчас юзается повсеместно.
Это полумера, TypeScript больше чем просто типы. В любом случае на переход тратятся усилия, так лучше потратить их разумно чем хвататься за сомнительные поделки.
Так ведь сам TypeScript — это сомнительная поделка.
Да, есть удобство от типизиации, но в целом спроектирован TS криво.
Сейчас они вроде перешли на более-менее нормальный импорт зависимостей (из ES2015), а раньше у них импорт описывался через комментарии с xml тегом.
Да и в целом, они решили сделать велосипед, в то время, когда их нужды без проблем мог покрыть ActionScript3. Который уже на тот момент имел поддержку во многих IDE, который был известен очень большому количеству людей и был очень даже популярным.
Да, есть удобство от типизиации, но в целом спроектирован TS криво.
Сейчас они вроде перешли на более-менее нормальный импорт зависимостей (из ES2015), а раньше у них импорт описывался через комментарии с xml тегом.
Да и в целом, они решили сделать велосипед, в то время, когда их нужды без проблем мог покрыть ActionScript3. Который уже на тот момент имел поддержку во многих IDE, который был известен очень большому количеству людей и был очень даже популярным.
но в целом спроектирован TS криво
Выскажитесь по этому поводу подробнее, пожалуйста.
но в целом спроектирован TS криво.
Наоборот, он спроектирован очень хорошо. Синтаксис берётся из самых свежих спецификаций ES, плюс надстройка в виде описания типов. Т.е. в отличие от coffee- и clojure-скриптов, код на TS выглядит почти как js-код будущего.
раньше у них импорт описывался через комментарии с xml тегом.
Это был не импорт, а что-то типа #include из мира C/C++. Хотя можно было вообще не добавлять эти комментарии, а просто настроить компилятор и использовать модули / namespace'ы.
Самый сок в том, что пока не было примерно понятно, как в ES будет выглядеть импорт/экспорт, в TS не стали добавлять какой-то свой синтаксис импорта в сам язык, что позволило сейчас относительно безболезненно ввести этот самый синтаксис. Разве это пример плохо спроектированного языка? По-моему, как раз наоборот.
Как человек, попробовавший typescript и сейчас пробующий flow, скажу, что вы не правы. Оба инструмента имееют преимущества и недостатки. Например flow можно включать не для всех файлов, или даже не для всего файла. Он также умеет самостоятельно выводить типы, что прямо крутая фича для динамического языка.
Например flow можно включать не для всех файлов, или даже не для всего файла.
А в TS типизация не опциональна? Плюс теперь есть флаг «allowJs».
Что имеется ввиду под «выводить типы»?
Что имеется ввиду под «выводить типы»?
https://flowtype.org/try/#0PQKgBAAgZgNg9gdzCYAoVBjOA7AzgFzHwFMCwBeMACgEoKA+MAchIKYG51X9aA6fOADEAlgA9iAE1qcgA
test.ts
$ tsc test.ts:
Аналогичный результат можно получить здесь https://www.typescriptlang.org/play/
Также вот для ознакомления https://github.com/Microsoft/TypeScript/wiki/What's-new-in-TypeScript#typescript-20
const test = () => 'test';
test().toFixed();
$ tsc test.ts:
test.ts(3,8): error TS2339: Property 'toFixed' does not exist on type 'string'.
Аналогичный результат можно получить здесь https://www.typescriptlang.org/play/
Также вот для ознакомления https://github.com/Microsoft/TypeScript/wiki/What's-new-in-TypeScript#typescript-20
Typescript тоже вполне неплохо выводит типы, а в 2.0 вообще запилили вывод на основе анализа потока управления.
Продемонстрируйте вывод типов во flow такой, чтобы typescript такого не умел.
UFO just landed and posted this here
Пример показывает лишь, что в тайпскрипте коллекции ковариантны, а во флоу — инвариантны. Однако, вид вариантности должен определяться из контекста использования, что оба этих инструмента не умеют.
Например, такой код флоу не пропустит:
function read( a : Animal[] ) {
console.log(a[0].name)
}
read( cats )Хотя казалось бы, что мешает тут передать подтип? Взрослые языки позволяют хотя бы переключать вариантность модификаторами. Например:
void read( in Animal[] a ) {
writeln( a[0].name );
}
void write( Animal[] a ) {
a ~= new Cat;
}
void main()
{
Cat[] cats = [ new Cat ]; // can only contain cats
Animal[] animals = [ new Dog ]; // can only contain animals
read( cats ); // ok
write( cats ); // function app.write (Animal[] a) is not callable using argument types (Cat[])
}Мне кажется, я забыл упомянуть главное. TS — это как ни крути отдельный язык. Если из TS подключать js файл, ему нужно подсунуть аннотации (.d.ts). А flow работает поверх js. Ему не нужно ничего дополнительно указывать, только при особой необходимости.
А .d.ts это еще та боль. Единицы библиотек поддерживают эти самые аннотации, а внешние постоянно старые.
А .d.ts это еще та боль. Единицы библиотек поддерживают эти самые аннотации, а внешние постоянно старые.
Дык, кто бы спорил)) Просто лично мне от TypeScript ничего не нужно. Описанный плагин к Babel решает мою проблему, связанную не с TypeScript, а упорным отсутствием хотя бы опциональной типизации в стандарте. Лично мне именно ее больше всего не хватает в последней версии.
С TS придется немного попотеть.
Развернёте мысль?
Можно я разверну? Не придётся)) Компилированный JS дебажится без проблем
Без проблем! Несмотря на обьемное количество информации, у меня заняло некоторое время настроить окружение, чтобы нормально дебажить TS.
1. Надо было поставить плагины в среду разработки, чтобы редактор начал адекватно реагировать на TS(что нормально, поскольку это касается любой надстройки на нативным языком)
2. Надо было изменить конфигурацию дебаггера внутри IDE, потому как теперь нужно сначала скомпилить ts, а потом дебажить скомпиленный код
3. Вначале были проблемы с бандлерами типа Webpack или загрузчиками типа SystemJS, потому что их нужно было расширять дополнительно для работы с TS.
Это не является огромной проблемой — все это относительно просто можно сконфигурить, но наличие дополнительных движений все же стоит отнести к небольшим минусам.
1. Надо было поставить плагины в среду разработки, чтобы редактор начал адекватно реагировать на TS(что нормально, поскольку это касается любой надстройки на нативным языком)
2. Надо было изменить конфигурацию дебаггера внутри IDE, потому как теперь нужно сначала скомпилить ts, а потом дебажить скомпиленный код
3. Вначале были проблемы с бандлерами типа Webpack или загрузчиками типа SystemJS, потому что их нужно было расширять дополнительно для работы с TS.
Это не является огромной проблемой — все это относительно просто можно сконфигурить, но наличие дополнительных движений все же стоит отнести к небольшим минусам.
Вы сейчас про какую среду разработки-то?
С окружением все нормально, поднимается без проблем — этот пункт не стоит брать во внимание в вопросе о нужности/ненужности typescript.
В целом же, сабж — штука, конечно, прикольная, но писанины субъективно где-то на треть больше выходит. На мой взгляд, для мелких/средних проектов не особо целесообразно, для крупных же — вполне может оправдать себя.
В целом же, сабж — штука, конечно, прикольная, но писанины субъективно где-то на треть больше выходит. На мой взгляд, для мелких/средних проектов не особо целесообразно, для крупных же — вполне может оправдать себя.
Выше перечислены простые вещи, которые делаются один раз и это много времени не занимают. Гораздо более сложный вопрос с переходом может возникнуть если команда не готова работать с типами и ООП вообще (например елси в команде фанбои функциональщины, или просто не инженеры которые не привыкли писать поддерживаемый код).
Использовал TS в продакшне. Мне понравилось прямо очень. Минусы на мой взгляд притянуты за уши. Контраргументы по пунктам
1. Сама по себе строгая типизация является в TS опциональной. Не хотите — пишете any, и всё, что вас там напрягало, проходит мимо. Да, вы не получите соответствующих плюсов, но это же ваш выбор был. А .d.ts файлы считаю вообще прекраснейшим решением, которое позволяет подключить любой посторонний код и сделать его типизированным. Опять же: если не хотите — не делайте, это ваш выбор, но жаловаться на то, что библиотеки требуют дополнительного описания для того, чтобы они были типизированными — довольно нелогично.
2. Если надо быстренько поговнокодить через консоль, а потом вкинуть решение в продакшн, то вроде как никто этого сделать не мешает. По крайней мере у меня бывала парочка костылей такого плана, и компилятор никак не помешал
3. Дебажу прямо чистый JS в хроме. Учитывая, насколько он вообще читабельный на выходе — не понимаю, какие у вас с этим проблемы? Плюс при использовании Sourcemaps хром позволяет дебажить TS прямо в браузере, без всяких там штормов и студий. Хоть в саблайме пишите.
4. Помереть может что угодно. А говорить, что майкрософты это всегда плохо — довольно странно. Я расчитываю, что TS будет жить долго, хотя бы потому что Angular 2 пишут на нём.
1. Сама по себе строгая типизация является в TS опциональной. Не хотите — пишете any, и всё, что вас там напрягало, проходит мимо. Да, вы не получите соответствующих плюсов, но это же ваш выбор был. А .d.ts файлы считаю вообще прекраснейшим решением, которое позволяет подключить любой посторонний код и сделать его типизированным. Опять же: если не хотите — не делайте, это ваш выбор, но жаловаться на то, что библиотеки требуют дополнительного описания для того, чтобы они были типизированными — довольно нелогично.
2. Если надо быстренько поговнокодить через консоль, а потом вкинуть решение в продакшн, то вроде как никто этого сделать не мешает. По крайней мере у меня бывала парочка костылей такого плана, и компилятор никак не помешал
3. Дебажу прямо чистый JS в хроме. Учитывая, насколько он вообще читабельный на выходе — не понимаю, какие у вас с этим проблемы? Плюс при использовании Sourcemaps хром позволяет дебажить TS прямо в браузере, без всяких там штормов и студий. Хоть в саблайме пишите.
4. Помереть может что угодно. А говорить, что майкрософты это всегда плохо — довольно странно. Я расчитываю, что TS будет жить долго, хотя бы потому что Angular 2 пишут на нём.
Starche Не лишены логики первые три пункта, но:
Я заметил, что многие относят это к минусу, но я не имел ввиду, что это всегда плохо. Если это непонятно из контекста, исправим.
4. Помереть может что угодно. А говорить, что майкрософты это всегда плохо — довольно странно. Я расчитываю, что TS будет жить долго, хотя бы потому что Angular 2 пишут на нём.
Я заметил, что многие относят это к минусу, но я не имел ввиду, что это всегда плохо. Если это непонятно из контекста, исправим.
Только вот ng2 далеко не факт, что долго проживёт.
UFO just landed and posted this here
Эта влиятельная корпорация уже похоронила GWT и вот-вот похоронит Polymer. Основная причина смерти — излишняя сложность и недостаточная гибкость, не дающая технологии обрести популярность. jQuery и Angular взлетели именно за счёт простоты, можно было на коленке сваять что-то работающее и отправить в продакшен. A2 же — это сложно и громоздко.
jQuery разумеется, но откуда вдруг первый Angular стал простым? Его наоборот первое время в основном за переусложненность ругали.
Насчет Angular 2 — согласен, далеко не факт что взлетит так же как первый. Дело даже не в гибкости, уже достаточно много конкурентов и альтернативных подходов (React, и т.п.)
Насчет Angular 2 — согласен, далеко не факт что взлетит так же как первый. Дело даже не в гибкости, уже достаточно много конкурентов и альтернативных подходов (React, и т.п.)
так же как первыйпервый как раз взлетел, чтобы бы не писали React фанбои.
Он был не особо простым, но простое приложение на нём создать можно было очень просто. Вот с масштабируемостью у него просто беда.
Если быть честными, то GWT — это плохая технология, как JSF и куча других решений, которые предлагают на бекенд-языке писать под фронтенд.
Да, когда-то это было обосновано и, возможно, даже правильно. Но вот уже лет 5-10 как, это все стоит выкинуть на свалку истории, но до сих пор люди мучаются с поддержкой этого легаси.
Да, когда-то это было обосновано и, возможно, даже правильно. Но вот уже лет 5-10 как, это все стоит выкинуть на свалку истории, но до сих пор люди мучаются с поддержкой этого легаси.
А можно подробнее про то, почему GWT — это плохая технология? И что такое "бэкэнд-язык"? Какие особенности синтаксиса и семантики языка делают его пригодным для написания кода на фронтэнде, а какие — на бэкэнде?
> И что такое «бэкэнд-язык»?
В данном случае это java. Самая большая глупость, которую можно сделать — это генерировать js из java кода. Это кажется хорошей идеей, т.к. позволяет изучить только один язык и развиваться в нем.
На самом же деле — это лишь вводит ограничения в проект. Фронтенд уходит далеко вперед, а технологии, которые занимаются извращением — не могут поспевать за этим всем.
> Какие особенности синтаксиса и семантики языка делают его пригодным для написания кода на фронтэнде, а какие — на бэкэнде?
Если мы говорим про web, а мы говорим про него, то ответ очевиден: Главная особенность фронтенд языка — он поддерживается браузерами без плагинов.
> почему GWT — это плохая технология?
Мой позиция в том, что бекенд (в виде java) не должен заниматься рендером html, и уж тем более не должен заниматься кодогенерацией js. Есть конечно случаи, когда без серверного рендера не обойтись, но это можно сделать и без GWT. А вот генерировать js — это и вовсе плохая идея, по-моему, и ни одной адекватной причины для этого не вижу.
У проектов, где бекенд занимается рендером страниц нету возможности расширяться в сторону поддержки мобильных девайсов (или эта поддержка требует много усилий).
В данном случае это java. Самая большая глупость, которую можно сделать — это генерировать js из java кода. Это кажется хорошей идеей, т.к. позволяет изучить только один язык и развиваться в нем.
На самом же деле — это лишь вводит ограничения в проект. Фронтенд уходит далеко вперед, а технологии, которые занимаются извращением — не могут поспевать за этим всем.
> Какие особенности синтаксиса и семантики языка делают его пригодным для написания кода на фронтэнде, а какие — на бэкэнде?
Если мы говорим про web, а мы говорим про него, то ответ очевиден: Главная особенность фронтенд языка — он поддерживается браузерами без плагинов.
> почему GWT — это плохая технология?
Мой позиция в том, что бекенд (в виде java) не должен заниматься рендером html, и уж тем более не должен заниматься кодогенерацией js. Есть конечно случаи, когда без серверного рендера не обойтись, но это можно сделать и без GWT. А вот генерировать js — это и вовсе плохая идея, по-моему, и ни одной адекватной причины для этого не вижу.
У проектов, где бекенд занимается рендером страниц нету возможности расширяться в сторону поддержки мобильных девайсов (или эта поддержка требует много усилий).
Самая большая глупость, которую можно сделать — это генерировать js из java кода
Почему генерировать JS из Java — это плохо?
Это кажется хорошей идеей, т.к. позволяет изучить только один язык и развиваться в нем.
Я для своего предыдущего проекта использовал GWT, и, поверьте, я отлично знаю JS и вполне мог бы взять Angular. Проблема в том, что мне неудобно постоянно переключать контекст. И вопрос не только в синтаксисе, вопрос в либах, фреймворках, сборщиках, линтерах, IDE и т.д. Ну и в ряде ситуаций и при прямых руках удаётся добиться переиспользования определённой доли кода.
Фронтенд уходит далеко вперед, а технологии, которые занимаются извращением — не могут поспевать за этим всем.
Какие извращения? И в чём проблема с поспеванием? Из GWT можно отлично вызывать любой JS-код, самый новомодный и хипстерский.
Мой позиция в том, что бекенд (в виде java) не должен заниматься рендером html,
Есть разные задачи, в каких-то случаях лучше доверить рендеринг HTML бэкэнду, а на фронтэнде не держать почти никакой логики.
и уж тем более не должен заниматься кодогенерацией js
А GWT, к примеру, этим не занимается. GWT работает во время компиляции, а в рантайме вы имеете статический JS.
А вот генерировать js — это и вовсе плохая идея, по-моему, и ни одной адекватной причины для этого не вижу.
А я вижу одну адекватную причину — возможность писать приложения для браузера на языке, который я считаю более подходящим. К сожалению, разработчики браузеров не предоставили мне никакой возможности этого делать, кроме как взять компилятор этого языка, генерирующий JS.
У проектов, где бекенд занимается рендером страниц нету возможности расширяться в сторону поддержки мобильных девайсов
Это зависит от архитектуры. Если проект грамотно разбит на слои, то никаких проблем прокинуть два разных presentation (один — HTML, другой — REST) нет. Конечно, хотелось бы писать весь код один раз и запускать везде, но практика показывает что это невозможно. Хотя опять же, есть ряд задач, когда можно добиться почти 100% переиспользования кода (те же игры, например).
И да, к GWT это никак не относится, потому что GWT не занимается рендером страниц.
> Какие извращения? И в чём проблема с поспеванием? Из GWT можно отлично вызывать любой JS-код, самый новомодный и хипстерский.
Вот тут то и будет извращение. Вместо того, чтобы просто писать на js, часть логики будет на java(gwt), а часть на js. И в этом случае все так же придется переключаться между java и js.
Вот тут то и будет извращение. Вместо того, чтобы просто писать на js, часть логики будет на java(gwt), а часть на js. И в этом случае все так же придется переключаться между java и js.
Вместо того, чтобы просто писать на js, часть логики будет на java(gwt), а часть на js
В случае с GWT (может, даже не с GWT, а со сферическим транспайлером Java -> JS в вакууме) писать JS-код нужно сравнительно редко. Даже в GWT, где всё плохо и действительно приходится частенько заводить JSNI, писать кода на JS приходится очень и очень мало. В моём проекте на GWT из 100 тысяч строк на Java на JS было написано о силы строк 50.
В данном случае это java.
Поподробнее, пожалуйста. Почему на языки наклеивают ярлыки "это фронтэнд-язык, это — бэкэнд". Кто мешает взять CoffeScript или TS и писать на них код для node.js? Кто мешает взять GWT и писать на Java код для браузера? Да сейчас все кто не лень умеют компилироваться в JS, даже C++, даже Haskell, если не изменяет память. Так что же в языке может быть такого, что делает его более подходящим для бэкэнда и фронтэнда?
«java бекенд не должен заниматься рендером html и кодогенерацией js», но GWT тут каким боком?
Все ваши замечания справедливы только к JSF.
GWT компилиться в чистый JS, ему не нужен бекенд на сервере, как и плагины в браузере. Компилится во время разработки, а не в рантайме. В продакшене GWT — это папочка с уже готовыми js. А бекенд может быть любым.
В интерпрайзе например, со 100500 crud-формами, GWT легко справляется со всей клиентской частью. Без необходимости в JSNI коде.
Все ваши замечания справедливы только к JSF.
GWT компилиться в чистый JS, ему не нужен бекенд на сервере, как и плагины в браузере. Компилится во время разработки, а не в рантайме. В продакшене GWT — это папочка с уже готовыми js. А бекенд может быть любым.
В интерпрайзе например, со 100500 crud-формами, GWT легко справляется со всей клиентской частью. Без необходимости в JSNI коде.
А как вы отличаете плохую технологию от хорошей? ;-)
Количество боли (время, нервы, количество выпитого кофе), которую приходится испытывать при работе с технологией, по-моему, хороший показатель для этого.
Конечно это все субъективно, кому-то нравится, кому-то нет.
Конечно это все субъективно, кому-то нравится, кому-то нет.
Количество боли от конкретно GWT не является показателем того, что Java — это плохой язык для разработки фротнэнда. Это является лишь показателем того, что гугл этот самый GWT поматросил и бросил, не влил достаточного количества ресурсов, чтобы сделать из него конфетку. В последних версиях GWT преобразился (появилась инкрементальная компиляция, нормальный интероп и отладка), и количество боли от его использования стало заметно меньше. Если бы для него кто-то запилил что-то похожее на Angular — было бы вообще отлично. Но теперь-то кому какое до этого есть дело?
> не влил достаточного количества ресурсов, чтобы сделать из него конфетку
Зачем? Почему не взять html+js и не написать нормальный фронтенд без свистоплясок и трансформаций?
js+html выучить в разы легче, чем ту же java, думаю, js+html выучить легче, чем нормально разобраться в GWT =)
А если так — зачем использовать GWT и вливать в него ресурсы?
Зачем? Почему не взять html+js и не написать нормальный фронтенд без свистоплясок и трансформаций?
js+html выучить в разы легче, чем ту же java, думаю, js+html выучить легче, чем нормально разобраться в GWT =)
А если так — зачем использовать GWT и вливать в него ресурсы?
Зачем? Почему не взять html+js и не написать нормальный фронтенд без свистоплясок и трансформаций?
Какие конкретно свистопляски? Я таковых не обнаружил. Конечно, на старте GWT пришлось понастраивать, но это везде так. И Spring, и Hibernate пришлось настраивать, и, о боже, npm, webpack и grunt. Причём, не сказал бы, что с GWT было сильно больше свистоплясок, чем с последними тремя технологиями.
js+html выучить в разы легче, чем ту же java, думаю, js+html выучить легче, чем нормально разобраться в GWT =)
Я отлично знаю и Java, и JavaScript, и много других интересных вещей. Однако, мне проще писать на одном языке, в рамках единой экосистемы. Да, язык — это не просто синтаксис и семантика, это целая экосистема, которую он за собой тянет. И, кстати, их тоже надо изучать, и на это далеко не всегда есть время и силы.
GWT, кстати, очень даже жив, уже доступен 2.8 RC2, а это поддержка Java8 и новый JS interop, теперь вообще интеграция с JS практически идеальная. Для командной разработки Java лучше JS. И Google использует GWT для разработки Inbox, плюс пишут компилятор GWT в Closure, так что вполне себе живой и качественный продукт.
GWT, кстати, очень даже жив,
Ну, это как считать «живость». Число запросов где требуются разработчики на GWT резко снизилось по сравнению с тем, что было лет так 5 назад. И во многих девелоперских конторах он просто… исчез.
Вообще-то разработчик GWT — это Java разработчик, не понятно зачем это выделять в отдельную вакансию.
Вообще-то разработчик GWT — это Java разработчикЭто верно. Но обычно пишут какая технологии требуются.
С другой стороны, чтобы хорошо писать на GWT надо освоить и JS.
Но освоив JS зачем писать на GWT?
Я уже писал чуть выше, почему есть смысл писать на GWT, а не на JS. Незнание JS — это не причина использовать GWT, но зато за использование GWT есть много других причин.
JS как раз можно и не знать, и спокойно писать на Java. Знание CSS важнее, но тоже не обязательно.
UFO just landed and posted this here
AngularJS — простой, а Angular 2 — сложный? Вероятно Вы никогда плотно не работали ни с тем, ни с другим.
Angular 2 стал гораздо проще, по сравнению с первой версией. Тестирование стало проще, template syntax стал проще, angular «магии» и кастомщины стало меньше и, что не мало важно, выстрелить себе в ногу стало сложнее.
Angular 2 стал гораздо проще, по сравнению с первой версией. Тестирование стало проще, template syntax стал проще, angular «магии» и кастомщины стало меньше и, что не мало важно, выстрелить себе в ногу стало сложнее.
Похоронит потому, что не взлетит. А не взлетит, потому что технология довольно сложная: сложно отлаживать, сложно кастомизировать готовый компонент, сложно собирать, чтобы это всё не тормозило. При этом имеет ряд довольно серьёзных ограничений: гвоздями прибита к DOM, гвоздями прибита к JS, принудительная изоляция стилей, от которой больше вреда, чем пользы.
Для меня главный минус — отсутствие обратного компилятора. Чтобы те члены команды, которые хотят ТС могли легко интегрировать изменения, которые я сделал в сгенерированном ими ДжС.
С экзешниками вы тоже так балуетесь? :-)
Есть инструменты ES5 -> ES6, например lebab. Возможно есть подобия и для TS.
Но довольно глупо предполагать, что он будет со встроенным интеллектом и сможет восстановит типизацию и стиль кода ваших партнеров).
Но уже с помощью того же lebab вы можете подать им более-менее красивый код, близкий к синтаксису TS.
Вообще бывает очень удобно, когда приходиться переводит много старого кода на новую спецификацию.
Но довольно глупо предполагать, что он будет со встроенным интеллектом и сможет восстановит типизацию и стиль кода ваших партнеров).
Но уже с помощью того же lebab вы можете подать им более-менее красивый код, близкий к синтаксису TS.
Вообще бывает очень удобно, когда приходиться переводит много старого кода на новую спецификацию.
Для typescript это невозможно, так как «компиляция» там сводится в основном в удалении всего того, что относится к сути языка. например, были аннотации типов, в результирующем коде их нет, и нет никаких указаний на то, что они там были. И вообще, у кода, полученного из Typescript, нет вообще никакого runtime.
На самом деле это не так.
- Он создаёт функции extends и decorate
- Он может добавлять некоторую информацию о типах, если включить специальный флаг.
Полностью согласен, в примере с ES6 тоже не все обратимо. Мне больше нравится более узкий термин для таких инструментов.
Попробовать также найти let, const .., другие es next плюшки array.filter, array.find и т.д.
Конструкции типа for...of и тд. Некоторые классы, которые превращаются в нечто похожее на
Стрелочные функции, которые выглядят как то так
Возможно даже те же аннотации, если сохранились эти костыли в виде __decorate.
Рассуждая как любитель, могу предположить, что можно частично определить и типы, для начала хотя бы с явным присвоениям к базовым.
Если совсем заморочиться и проследить за цепочки вызовов и за аргументами функций, то можно помочь пользователю записями типа User|Object|any и если он уверен, то сможет сам в будущем удалить неверные.
Таким же поступить и с модификаторами доступа, если есть внешние обращения можно подсказать какие методы точно должны быть публичными. Если не ошибаюсь, легко определяются и явно статические методы. Можно попробовать выделить интерфейсы по общим методам.
Наш случай уникален тем, что наш JS и так уже можно считать TS))
Поэтому остается всего лишь аккуратно его бьютифаить, чтобы все продолжало работать.
Также в теории можно сделать супер-мега анализатор, прогоняя через него готовые тесты всех открытых библиотек на js, ts, coffescript и даже на очень далеких языках с хорошими конверторами в js.
Главное только успевать фиксить все баги и улучшать качество.
Можно паралелльно нейронку натаскивать на хорошие результаты в TSLint и на минимальное количество кода))
Как говорите, нет никаких указаний на то, что это все было в исходном коде, поэтому может быть и не было и есть шанс получить более чистый и декларированный код чем исходный)
Не знаю, стоит ли сильно расстраиваться, если немного потеряется часть этих красивых настроек над JS, те же типы, если типизация в TS всего лишь статическая и влияет только на тебя, а не на работу кода.
Compiling is the general term for taking source code written in one language and transforming into another.В любом случаи, есть все шансы получить обратно очень даже качественный код (конечно, не исходный), особенно, если большая часть этого кода была скомпилирована автоматически.
Transpiling is a specific term for taking source code written in one language and transforming into another language that has a similar level of abstraction.
Попробовать также найти let, const .., другие es next плюшки array.filter, array.find и т.д.
Конструкции типа for...of и тд. Некоторые классы, которые превращаются в нечто похожее на
var User = (function () { function User() { ... }; User.prototype.name = ...; return User; }());
Стрелочные функции, которые выглядят как то так
(function () { return ({...}); });
Возможно даже те же аннотации, если сохранились эти костыли в виде __decorate.
Рассуждая как любитель, могу предположить, что можно частично определить и типы, для начала хотя бы с явным присвоениям к базовым.
Если совсем заморочиться и проследить за цепочки вызовов и за аргументами функций, то можно помочь пользователю записями типа User|Object|any и если он уверен, то сможет сам в будущем удалить неверные.
Таким же поступить и с модификаторами доступа, если есть внешние обращения можно подсказать какие методы точно должны быть публичными. Если не ошибаюсь, легко определяются и явно статические методы. Можно попробовать выделить интерфейсы по общим методам.
Наш случай уникален тем, что наш JS и так уже можно считать TS))
Поэтому остается всего лишь аккуратно его бьютифаить, чтобы все продолжало работать.
Также в теории можно сделать супер-мега анализатор, прогоняя через него готовые тесты всех открытых библиотек на js, ts, coffescript и даже на очень далеких языках с хорошими конверторами в js.
Главное только успевать фиксить все баги и улучшать качество.
Можно паралелльно нейронку натаскивать на хорошие результаты в TSLint и на минимальное количество кода))
Как говорите, нет никаких указаний на то, что это все было в исходном коде, поэтому может быть и не было и есть шанс получить более чистый и декларированный код чем исходный)
Не знаю, стоит ли сильно расстраиваться, если немного потеряется часть этих красивых настроек над JS, те же типы, если типизация в TS всего лишь статическая и влияет только на тебя, а не на работу кода.
Только что понял, что lebab это перевернутый babel))
Cуровая у вас практика.
Я мог бы понять такой аргумент при работе с SCSS/LESS: из браузера CSS реально в разы удобнее писать, чем каждый раз перегенеривать. Это меня часто останавливает от использования CSS-препроцессоров.
Но вносить изменения прямо в JS… Что вас побуждает к таким действиям? почему в тайпскрипте не поправить?
А если вам надо отдельный файл подключить JS-ный, то это как раз никто не помешает сделать.
Я мог бы понять такой аргумент при работе с SCSS/LESS: из браузера CSS реально в разы удобнее писать, чем каждый раз перегенеривать. Это меня часто останавливает от использования CSS-препроцессоров.
Но вносить изменения прямо в JS… Что вас побуждает к таким действиям? почему в тайпскрипте не поправить?
А если вам надо отдельный файл подключить JS-ный, то это как раз никто не помешает сделать.
серьйозныйВы серьёзно?!
Рано или поздно, все полезные функции TS будет так или иначе перенесены в стандарт языка и TS повесит бутсы на гвоздь.
Очень мало вероятно. TS сделан инженерами для инженеров, а ES хипстерами. Если бы ES делали инженеры то типы бы уже там появились, но они просто добавляют синтаксического сахара, это говорит об их приоритетах.
Лучше напишите что-то против моих слов чем тупо минусы ставить. Ведь типов не видно в будующих стандартах и разве это не говорит о приоритетах авторов стандартов? Я понимаю они хотят оставить JS «простым», но вместе с этим реальных подвижек в стандарте нет (стрелочные функции, деструкторы и прочая мишура это просто сахар который не решает базовые проблемы JS).
с каких пор строгая типизация делает язык программирования «сложным» и более инженерным? не выдавайте свои предпочтения ооп фанбоя за какой то объективный факт.
Да, вы правы, типы не делают язык инженерным. А так же типы есть не только в ооп.
Ну и типы действительно делают язык более сложным.
Сложным становится потому, что:
1. движки должны переписаться для поддержки типов, думаю, на данный момент это сложно сделать;
2. разработчикам вместо того, чтобы закинуть просто объект, нужно будет сделать инстанс типа, а это больше кода и в консоли браузера тяжелее тестировать, и вообще «верните мне мой js» (когда-то был крик души на хабре про появление Angular в мире js).
Ну и типы действительно делают язык более сложным.
Сложным становится потому, что:
1. движки должны переписаться для поддержки типов, думаю, на данный момент это сложно сделать;
2. разработчикам вместо того, чтобы закинуть просто объект, нужно будет сделать инстанс типа, а это больше кода и в консоли браузера тяжелее тестировать, и вообще «верните мне мой js» (когда-то был крик души на хабре про появление Angular в мире js).
типы действительно делают язык более сложным
Это неправда. Не бывает «языка без типов» — все данные, которыми оперирует ваша программа, так или иначе имеют определенный тип. Если вы передаете в функцию
1 вместо [1], то функция скорее всего упадет с TypeError. А чтобы обезопасить себя от таких случаев, в JS принято использовать проверки с помощью typeof или instanceof. По факту, вы всё равно оперируете типами, но используете для этого другой синтаксис, отказываетесь от подсказок автодополнения и статических проверок.вместо того, чтобы закинуть просто объект, нужно будет сделать инстанс типа
Это также неправда. В Typescript типизация работает структурно, на основе списка полей и их типов. Например, вы можете объявить интерфейс, указав в нем список полей и их типы. Любой объект, в котором эти поля присутствуют, будет удовлетворять интерфейсу:
inteface IOptions {
path: string; // поле всегда должно присутствовать
version: string | number; // может быть строкой или числом
plugins?: string[]; // опциональное поле
}
function doStuff(options: IOptions) { ... }
doStuff({ path: 'test', version: 1 }); // всё окей
doStuff({ path: 'test', plugins: ['a'] }); // всё тоже окей
doStuff({ }); // ошибка: нет поля path
doStuff({ path: 'test', plugins: [1] }); // ошибка: plugins[0] будет Number, а нужен String
не выдавайте свои предпочтения ооп фанбоя за какой то объективный факт.мои личные предпочтения о которых я обычно не пишу, и оправданность их применения на реальных проектах совсем разные вещи.
Типизация и вообще структурирование кода (пускай это ООП или еще что-то) делает язык более сложным с точки зрения продумывания структуры того что ты пишешь. Очевидно типизация делает код более поддерживаемым тка же как и ООП, и это более инженерный подход чем слабать что-то на коленке, залить на продакшен, потом свалить из компании в другую и там снова фанбоить.
Это не проблемы JS, это проблемы крупных проектов и сверхнадежных библиотек. А JS позиционировался всегда, как язык для всех, даже для сайта из одной странички 5кб, написанной за вечер. Без малого бизнеса, некому вырастать в крупный. Поэтому JS никто и не трогает, а то, что браузеры не поддерживают другие языки, это вообще вопрос открытый и тут куча нюансов:
1. А нужны ли вообще крупные приложения в браузере? Современные системы позволяют быстро установить нативные приложения в ОС, написанные на любом языке.
2. Почему бы не оставить браузерам и JS то, для чего они и создавались, доступ к информации по URL с минимальным интерактивом на странице?
3. Что включить в браузер, поддержку каких языков/возможностей? Этот вопрос пытаются решить при помощи стандарта WebAssembly, но все равно кому-то чего-то будет не хватать. Кому скорости рендеринга, кому самого webassembly.
4. Если не развивать браузеры, а все силы вложить в разработку экосистемы нативных приложений, то не будет ли это логичным выходом из этого зоопарка, а браузеры оставить как испытательный полигон?
1. А нужны ли вообще крупные приложения в браузере? Современные системы позволяют быстро установить нативные приложения в ОС, написанные на любом языке.
2. Почему бы не оставить браузерам и JS то, для чего они и создавались, доступ к информации по URL с минимальным интерактивом на странице?
3. Что включить в браузер, поддержку каких языков/возможностей? Этот вопрос пытаются решить при помощи стандарта WebAssembly, но все равно кому-то чего-то будет не хватать. Кому скорости рендеринга, кому самого webassembly.
4. Если не развивать браузеры, а все силы вложить в разработку экосистемы нативных приложений, то не будет ли это логичным выходом из этого зоопарка, а браузеры оставить как испытательный полигон?
А JS позиционировался всегда, как язык для всех, даже для сайта из одной странички 5кб, написанной за вечер.
Не всегда, последние года 4 это уже не так. Задачи которые сейчас решает JS уже далеко не те которые он решал 5-10 лет назад. Серверная часто теперь как правило stateless (да теперь бекенерам проще стало чем было ранее, а в JS гораздо сложнее), состояние держится на клиенте. JS кода стало очень много, и когда кода много важну роль занимает его поддержка и развитие и здесь типизацию сложно недооценить.
А нужны ли вообще крупные приложения в браузере?
Речь идет не только о бразуераз, JS заполонил все направления, есть ведь любители писать много серверной бизнес логики на Node.js без какой либо типизации.
1. Есть, как минимум, две проблемы — кроссплатформенность и обновляемость.
4. Вроде как нативные приложения всё больше уступают место различным виртуальным машинам, которые скрывают от разработчика на каком железе и под какой осью работает его программа. И браузеры, наверное, пик этой виртуализации. Полностью не виртуализируют, но ближе всего к этому, как на практике, так и в теории.
4. Вроде как нативные приложения всё больше уступают место различным виртуальным машинам, которые скрывают от разработчика на каком железе и под какой осью работает его программа. И браузеры, наверное, пик этой виртуализации. Полностью не виртуализируют, но ближе всего к этому, как на практике, так и в теории.
> 1. Есть, как минимум, две проблемы — кроссплатформенность и обновляемость.
С обновляемостью вроде проблем нет, это вопрос скорее к издателям ОС? Над кроссплатформенностью тоже есть работы.
https://github.com/Microsoft/code-push
https://facebook.github.io/react-native/
>4. Вроде как нативные приложения всё больше уступают место различным виртуальным машинам, которые скрывают от разработчика на каком железе и под какой осью работает его программа. И браузеры, наверное, пик этой виртуализации. Полностью не виртуализируют, но ближе всего к этому, как на практике, так и в теории.
Браузеры все так же сражаются с HTML, CSS, JavaScript (!), Ajax, Url и т.д. То, что они пытаются эти технологии приспособить для всего на свете, не делает их пиком. Разница в том, что все эти технологии не общего назначения, а вполне конкретного. Операционная система предоставляет намного больше возможностей, чем браузер.
Вот Java со своей VM, когда-то была пиком, а сейчас такого пика нету, есть только местячковые нестандартизированные решения, типа cordova или react native.
С обновляемостью вроде проблем нет, это вопрос скорее к издателям ОС? Над кроссплатформенностью тоже есть работы.
https://github.com/Microsoft/code-push
https://facebook.github.io/react-native/
>4. Вроде как нативные приложения всё больше уступают место различным виртуальным машинам, которые скрывают от разработчика на каком железе и под какой осью работает его программа. И браузеры, наверное, пик этой виртуализации. Полностью не виртуализируют, но ближе всего к этому, как на практике, так и в теории.
Браузеры все так же сражаются с HTML, CSS, JavaScript (!), Ajax, Url и т.д. То, что они пытаются эти технологии приспособить для всего на свете, не делает их пиком. Разница в том, что все эти технологии не общего назначения, а вполне конкретного. Операционная система предоставляет намного больше возможностей, чем браузер.
Вот Java со своей VM, когда-то была пиком, а сейчас такого пика нету, есть только местячковые нестандартизированные решения, типа cordova или react native.
> стандарты JS идут в ногу со временем и интегрируют в сам язык многое, что было полезно в TS
afaik это TS реализовывал ранние предложения из стандарта ECMAScript а не наоборот
afaik это TS реализовывал ранние предложения из стандарта ECMAScript а не наоборот
Разработчики Typescript говорят, что Typescript генерирует примерно такой же код, который бы вы написали своими руками и поэтому отказаться от Typescript, в случае чего, будет очень просто — удалить ts файл и дальше использовать сгенерированный JS
И только ради типизации ипользовать все «прелести» компилятора.
Вы других плюсов не увидели?
P.S. Не пользуюсь псевдокомпилируемыми (компиляция это когда на выходе исполняемый машинный код, а не ещё один скрипт) языками — вредны для понимая логики исполнения и качества кода.
Например: Большинство SCSS кода, от говнокодеров, после компляции получается просто ужасным (как минимум исключающие и избыточные селекторы). Подумаеш, все равно какой код на выходе — браузер разберется, главное что в исходник «красивый». Скорость написания и синтаксический сахар это не аргументы, а отмазки. По факту получается, что нормально написанный руками CSS меньший или равняется не скомпилированному говно SCSS. А нормально написанного SCSS — «днем с огнем».
Вы других плюсов не увидели?
P.S. Не пользуюсь псевдокомпилируемыми (компиляция это когда на выходе исполняемый машинный код, а не ещё один скрипт) языками — вредны для понимая логики исполнения и качества кода.
Например: Большинство SCSS кода, от говнокодеров, после компляции получается просто ужасным (как минимум исключающие и избыточные селекторы). Подумаеш, все равно какой код на выходе — браузер разберется, главное что в исходник «красивый». Скорость написания и синтаксический сахар это не аргументы, а отмазки. По факту получается, что нормально написанный руками CSS меньший или равняется не скомпилированному говно SCSS. А нормально написанного SCSS — «днем с огнем».
Типизация это уже далкео не сахар а реально нужная вещь. Поддерживаемость кода имеет большое значение, часто большее чем очень оптимальный по размеру сгенерированный код на выходе и SCSS в этом плане выходит вперед перед голым CSS.
Типизацию придумали не вчера. И в JS она не нужна, основе язык запроектирован таким, что бы быть транслируемым! Если бы этого не нужно было, привязали бы стандартную JAVA и не плодили уродов. На сегодняшний день про это забыли. Как на меня надо упрощать, а не усложнять. Мы же хотим, что бы все работало быстро. Кроме того, с введением типизации, возникают новые трудности. Например, нужно передать объект который имплементировал все, что нужно для функции обработчика, но он нового класа и под ограничение типа не попал. И что — откатываемся назад к any и вставляем проверки. Но не забываем, что валидацию значений все равно нужно делать, а это теже проверки, так что TS практически ничего не дает в этом плане.
Поддерживаемость зависит не от языка, а от архитектуры. Если на SCSS архитектуры нет, то потдерживать его сложнее чем CSS без архитектуры. А если в CSS есть правильное архитектурное решение, то SCSS только усложнит потдержку.
Поддерживаемость зависит не от языка, а от архитектуры. Если на SCSS архитектуры нет, то потдерживать его сложнее чем CSS без архитектуры. А если в CSS есть правильное архитектурное решение, то SCSS только усложнит потдержку.
язык запроектирован таким, что бы быть транслируемым
Только вот факт в том что когда JS создавался никто не догадывался какую значимую роль он на себя возьмет в будующем, ознакомьтесь и историей, не нужно притягивать доводы за уши. К тому же он и остается транслируемым, в рантайме.
Мы же хотим, что бы все работало быстро.
Каким образом использование TS влияет на итоговую скорость работы скрипта? В итоге ведь тот же JS получается, и та же история с CSS процессорами.
но он нового класа и под ограничение типа не попал
Учите матчасть и проектируйте систему гибко. Суть как раз в том и состоит чтобы наложить жесткие ограничения.
А если в CSS есть правильное архитектурное решение
Самый простой и очевидный пример. Допустим у проекта много заказчиков и каждый хочет свою цветовую гамму (требование заказчика намеренно упрощено, но предположим кастомизируется только цветовая гамма). Как на чистом CSS вы сделаете это грамотно? C процессором я просто задам набор переменных для каждого заказчика.
Мой коментарий о типизации в JS, а не в TS.
Кроме того, с развитием HTML заначение JS для большинства страниц падает.
А для приложений лучше был бы язык ближе к JAVA.
Пример с цветовой схемой, очень наглядный. У вас получатся переменные, которые прописываются в общий CSS. А в CSS будет цветовые схемы в отдельных файлах, которые я могу поменять на ходу в браузере. А основной CSS станет короче на все эти правила, правда чуть удлинится HTML. И в итоге исходный код в общем короче и проще. А всё потому, что у меня архитектура. А у вас решение высосаное из пальца.
Кроме того, с развитием HTML заначение JS для большинства страниц падает.
А для приложений лучше был бы язык ближе к JAVA.
Пример с цветовой схемой, очень наглядный. У вас получатся переменные, которые прописываются в общий CSS. А в CSS будет цветовые схемы в отдельных файлах, которые я могу поменять на ходу в браузере. А основной CSS станет короче на все эти правила, правда чуть удлинится HTML. И в итоге исходный код в общем короче и проще. А всё потому, что у меня архитектура. А у вас решение высосаное из пальца.
> И в итоге исходный код в общем короче и проще. А всё потому, что у меня архитектура. А у вас решение высосаное из пальца.
Очень спорное суждение, удачи вам с вашей «архитектурой CSS», рад что вы довольны собой и своей архитектурой, я вот часто ставлю под сомнения свои решения и бывает их пересматриваю, но вам видимо это не знакомо потому что и так все идеально.
Очень спорное суждение, удачи вам с вашей «архитектурой CSS», рад что вы довольны собой и своей архитектурой, я вот часто ставлю под сомнения свои решения и бывает их пересматриваю, но вам видимо это не знакомо потому что и так все идеально.
И вам удачи.
Архитектура — это когда мы поднимаемся к абстракциям вида и описываем их кодом. А не наоборот из абстракций кода кое-как лепим вид.
P.S. Со временем поймете, что SCSS не заменяет архитектуру. А только дополняет абстракцию кода — увеличивает энтропию. На нем можно написать туже архитектуру, что говорю я, но это не одно и тоже. Не знаю как вы, но в общем случае пишут без архитектуры, заменяя её навязанными абстракциями кода. На выходе «говно» код, с большой вложенностью селекторов и высокой специфичностью.
Архитектура — это когда мы поднимаемся к абстракциям вида и описываем их кодом. А не наоборот из абстракций кода кое-как лепим вид.
P.S. Со временем поймете, что SCSS не заменяет архитектуру. А только дополняет абстракцию кода — увеличивает энтропию. На нем можно написать туже архитектуру, что говорю я, но это не одно и тоже. Не знаю как вы, но в общем случае пишут без архитектуры, заменяя её навязанными абстракциями кода. На выходе «говно» код, с большой вложенностью селекторов и высокой специфичностью.
На выходе «говно» код, с большой вложенностью селекторов и высокой специфичностью.
То что вам инстумент не подошел (инструмент ведь вам говнокод вам делает, не вы сами?) не причина его не использовать другим у кого говнокод не получается сделать.
Пользовался SASS/SCSS 5 лет и на выходе был приемлимый код (потому, что понимаю как оно будет скомпилировано). Но сейчас мене удобнее сделать всё на CSS. Времена поменялись.
Я не говорю инструмент плохой, я говорю о том безархитектурном коде который приходится переделывать. Если Вы с таким не сталкивались? Рад за Вас. Но ещё не вечер.
Я не говорю инструмент плохой, я говорю о том безархитектурном коде который приходится переделывать. Если Вы с таким не сталкивались? Рад за Вас. Но ещё не вечер.
interface Reader { read() : string }
interface Writer { write( str : string ) }
function uppercaser( a : Reader & Writer ) {
a.write( a.read().toUpperCase() )
}
uppercaser({
read() {
return 'hello!'
},
write( str ) {
alert( str )
}
})компиляция это когда на выходе исполняемый машинный код
Компиляция — это трансляция языка более высокого уровня в язык уровнем чуть ниже. Typescript под это определение отлично подпадает, равно как и Babel, Coffeescript и многие другие.
вредны для понимая логики исполнения и качества кода
Typescript повторяет логику ES6 практически один в один, но плюс к этому накладывает ограничения на заведомо ошибочные действия, которые программист может допустить по невнимательности. При прочих равных качество кода от этого становится только лучше.
Работаю с кодовой базой на TS порядка 1000 000 строчек, опыт есть (все — клиентский код).
В ваших утверждениях есть ряд ошибок:
1. «Debug».
Не нужно настраивать дебаг в IDE, пользуйтесь встроенным в Chrome отладчиком и отлаживайте прямо TS с включенными sourcemaps. Так правильнее, потому что IDE может потребоваться сменить, а браузер всегда и везде одинаков. По опыту, опять же, удобнее и быстрее в браузере отлаживать.
2. «А вдруг умерет?»
Нет. Один из принципов TS — не расходиться с будущим JS. По факту TS просто имплементирует будущие возможности JS, позволяя уже сейчас их использовать в браузерах (даже Async/await). Т.е. если и умрет, то только вместе с JS.
В конце концов, можете помочь его популяризации: документация на github на русском.
В ваших утверждениях есть ряд ошибок:
1. «Debug».
Не нужно настраивать дебаг в IDE, пользуйтесь встроенным в Chrome отладчиком и отлаживайте прямо TS с включенными sourcemaps. Так правильнее, потому что IDE может потребоваться сменить, а браузер всегда и везде одинаков. По опыту, опять же, удобнее и быстрее в браузере отлаживать.
2. «А вдруг умерет?»
Нет. Один из принципов TS — не расходиться с будущим JS. По факту TS просто имплементирует будущие возможности JS, позволяя уже сейчас их использовать в браузерах (даже Async/await). Т.е. если и умрет, то только вместе с JS.
В конце концов, можете помочь его популяризации: документация на github на русском.
Ну почему так много людей путают сильную и статическую типизацию?
UFO just landed and posted this here
Остались Babel и TypeScript — сложный выбор.Странно сравнивать Babel — инстурмент транслирования кода и TypeScript диалект ES. TypeScript сам по себе без всяких Babel может сделать вам ES5, некоторые даже используют TS вместо Babel для ES6 кода (не TS) потому что им больше нравится какой итоговый код он генерирует. Dart не полетел потому что новый синтаксис, сложнее порог вхождения и перспективы не очевидны опять же потому что это не насдстройка над JS. CoffeeScript d наiе время использовать глупо (для новых начинаний), потому что уже есть ES6.
На днях прочитал статью о Бабеле, открывшем мне его с новой стороны — по сути это инструмент создания своего языка. Набором плагинов вы создаёте свой собственный язык, свою версию JavaScript, не завязанную на спецификацию. Вот я прямо сейчас использую возможности, которые предлагались для включения в спецификацию, но были отвергнуты, но плагин для них сделать успели. Эта возможность получила популярность (в том числе поддерживается и в TypeScript с флагом) и отказываться от неё в обозримом будущем я не собираюсь.
Вот я прямо сейчас использую возможности, которые предлагались для включения в спецификацию, но были отвергнуты, но плагин для них сделать успели. Эта возможность получила популярность (в том числе поддерживается и в TypeScript с флагом) и отказываться от неё в обозримом будущем я не собираюсь.
Круто. Вы пишите на языке который кроме вас никто знать не будет?
Утрируя — да :) Но на самом деле нет — я не пишу свои плагины к бабелю, а использую сторонние, достаточно популярные и документированные. Другое дело, что комбинация плагинов в моих проектах может оказаться уникальной и поэтому какие-то расширения синтаксиса ES2015 могут оказаться кому-то незнакомыми, а какие-то знакомые — неработающими.
Один существенный минус (справедливый и для CoffeScript). Если планируете развивать проект на гитхабе, количество желающих внести свою лепту будет ограничего знающими TypeScript. Армия js-разработчиков скорее всего пройдет мимо
UFO just landed and posted this here
У меня дежавю. Пару лет назад читал такие же дифирамбы кофескриптеров про их язык. Так же предупреждал, что js-сообщество не будет вам помогать. И в ответ слышал то же самое: «Cами справимся. Нам не нужны неосиляторы божественного cs»
Хотите сказать что они были не правы? На мой взгляд кофескрипт умер не потому что что-то в нём было не так, а потому что перестал развиваться. В репозитории кофескрипта уже очень давно никто ничего не делал. А диалекту JS необходимо развиваться, потому что сам язык развивается.
В общем, если TS не забросят, как кофе, то всё будет с ним в порядке.
В общем, если TS не забросят, как кофе, то всё будет с ним в порядке.
Это не минус, это плюс. А армия JS разработиков пускай воюет себе с свой песочнице. Сообщество TypeScript и так достаточно сильное.
serf > А армия JS разработиков пускай воюет себе с свой песочнице. Сообщество TypeScript и так достаточно сильное.
Jaromir > Пару лет назад читал такие же дифирамбы кофескриптеров про их язык. Так же предупреждал, что js-сообщество не будет вам помогать. И в ответ слышал то же самое: «Cами справимся. Нам не нужны неосиляторы божественного cs»
Они решили наступить на те же грабли? — Смелые!
Jaromir > Пару лет назад читал такие же дифирамбы кофескриптеров про их язык. Так же предупреждал, что js-сообщество не будет вам помогать. И в ответ слышал то же самое: «Cами справимся. Нам не нужны неосиляторы божественного cs»
Они решили наступить на те же грабли? — Смелые!
За TS стоит MS. Даже если MS отойдет от дел, то все равно останется сообщество которое уже успело войти в курс дел.
За TS стоит MS. Даже если MS отойдет от дел, то все равно останется сообщество которое уже успело войти в курс дел.
За coffeescript стоял Google. Да, осталось сообщество. Но на coffeescript уже ставок ни у кого нет.
Но на coffeescript уже ставок ни у кого нет.
Это очевидно. Coffeescript сыграл свою роль и появился хипстерский ES6. Когда-то может быть и TS сыграет подобную роль и в ECMAScript все таки появится типизация (в очень отдаленной перспективе судя по текущему положению дел). Так вот пока типов в ECMAScript нет (и не появится в скором времени) можно использвать TS. Или предлагаете сидеть на ES6 и ждать пока там появятся типы?
Или предлагаете сидеть на ES6 и ждать пока там появятся типы?
Они не нужны.
Они не нужны.И зачем тогда выше вообще было что-то писать про кофискрипт и приводить какие-то доводы если ваша позиция объясняется так просто.
И зачем тогда выше вообще было что-то писать про кофискрипт если ваша позиция объясняется так просто.
И ООП не нужно.
Точно, и мозги тогда уже не нужны. Я хоть и не сторонник использования ФП для серьзеных и больших проектов особенно когда команда разношерстная, но так категоричеки о ФП не высказываюсь. Оно нужно как мннимум чтобы покрасоваться какой я «функциональный» (даже если это идет в разрез с инженерными практиками и делает проект неподдерживаемым) и влепить что-то в блог.
Точно, и мозги тогда уже не нужны.
Вы можете иметь отличные мозги, но изначальный выбор модели(архитектуры, стиля) программирования может привести вас к не очевидным вначале трудностям и даже не осознаваемым теперь трудностям — типа, деды так делали, отцы так делали, и мы так будем делать.
типа, деды так делали, отцы так делали, и мы так будем делать.
Я работаю по обе стороны барикад, сейчас это называют фуллстек, и свой выбор делаю не на основе некой исторической сложившейся истины или хипстерского тренда, а на основе своего опыта тк я имел возможность сравнить различные подходы на практике.
Я работаю по обе стороны барикад, сейчас это называют фуллстек, и свой выбор делаю не на основе некой исторической сложившейся истины или хипстерского тренда, а на основе своего опыта тк я имел возможность сравнить различные подходы на практике.
а на основе своего опыта тк я имел возможность сравнить различные подходы на практике.
Практика? Хм:
— Очистите html от js!
— Сделано.
— И тут бац — Angular!!!
— Очистите js от html!
— Сделано.
— И тут бац — React!!!
Хм, Практика.
> Когда-то может быть и TS сыграет подобную роль и в ECMAScript все таки появится типизация
В питоне и ПХП появилась. И как, питонисты и ПХП-шники ее начали использовать? Мне правда интересно
В питоне и ПХП появилась. И как, питонисты и ПХП-шники ее начали использовать? Мне правда интересно
Это интересный и серьёзный вопрос, потому как стандарты JS идут в ногу со временем и интегрируют в сам язык многое, что было полезно в TS: классы, стрелочные функции, и так далее.
Классы, стрелочные функции пришли в стандарт благодаря CoffeeScript. TypeScript появился позже. А что из TypeScript перейдет в стандарт? Типизация?
Согласен, перепроверил эту информацию — Вы правы. Могут перейти не только типы, но и Декораторы( типа Component, @Directive из ng2). Имеется ввиду сам функционал типа Декоратор.
Точнее он и будет имплементирован в стандарте ES7
ES2016 (ES7) был принят пару месяцев назад и там нет декораторов.
По-крайней мере он планировался и был на рассмотрении — ES7 Decorators. К сожалению, не заглянул в официальные доки.
Если у вас есть свободное время и вы хотите попробовать новый язык, попробуйте лучше Elm
Последнее время засел в него с головой. Проще, логичнее и лаконичнее TS. Некоторые архитектурные решения так вообще вызывают нескрываемый вау-эффект, хотя от react+redux+immutable в целом несильно отличаются. Выполнены просто элегантней.
Непонятно только как в прод это все протянуть, т.к. интероп с js ужасный (хоть и оправданный). Подумываю взять для начала для кусков логики, отвязанной от ui.
Непонятно только как в прод это все протянуть, т.к. интероп с js ужасный (хоть и оправданный). Подумываю взять для начала для кусков логики, отвязанной от ui.
Ну и основной затык — невозможность использования css-модулей, без которых, как мне кажется, если привыкнешь, то уже никуда.
Может, как-то это можно решить? Вроде есть какой-то пакет для описания стилей внутри elm, с последующей генерацией css, но мне это кажется таким же диким как и стили внутри jsx.
Может, как-то это можно решить? Вроде есть какой-то пакет для описания стилей внутри elm, с последующей генерацией css, но мне это кажется таким же диким как и стили внутри jsx.
Короче не стоит его изучать. В es6/es7 уже есть почти все, например декораторы в es7. Лучше сразу на стандарте писать, в последнее время за него очень серьезно взялись и JS самый популярный язык. Пробовать es7 можно уже и сейчас через траспилятор babel.
> Строгая типизация
> Позволяет более полно описывать свойства и методы обьектов и классов, из-за чего пропадает необходимость, которая, лично меня, дико раздражала, делать проверку всех, входящих в метод или функцию, аргументов
Да простят меня боги разработки, но я никогда не проверял входящие аргументы функций. Валидации получаемых извне данных — вот это да, важно. Если во время разработки програмы она ломается из-за аргументов функций — значит я где-то накосячил в коде. Поправляю, иногда добавляю тест. А если что-то поломается в боевых условиях, TS уже не поможет, так как в браузере его нет
Вообще, строгая типизация прежде всего хороша для компилятора. Зная типы на этапе компеляции он может заоптимизировать машинный код вусмерть. Слабая типизация при всех ее недостатках имеет и массу достоинств. Например возможность писать обобщенные алгоритмы не зарываясь с головой в лес угловых скобок.
> Позволяет более полно описывать свойства и методы обьектов и классов, из-за чего пропадает необходимость, которая, лично меня, дико раздражала, делать проверку всех, входящих в метод или функцию, аргументов
Да простят меня боги разработки, но я никогда не проверял входящие аргументы функций. Валидации получаемых извне данных — вот это да, важно. Если во время разработки програмы она ломается из-за аргументов функций — значит я где-то накосячил в коде. Поправляю, иногда добавляю тест. А если что-то поломается в боевых условиях, TS уже не поможет, так как в браузере его нет
Вообще, строгая типизация прежде всего хороша для компилятора. Зная типы на этапе компеляции он может заоптимизировать машинный код вусмерть. Слабая типизация при всех ее недостатках имеет и массу достоинств. Например возможность писать обобщенные алгоритмы не зарываясь с головой в лес угловых скобок.
Слабая типизация при всех ее недостатках имеет и массу достоинств.
Опять спутали слабую и динамическую типизации. У слабой aka неявной типизации сплошные минусы.
Например возможность писать обобщенные алгоритмы не зарываясь с головой в лес угловых скобок.
Это не является отличительным свойством ни слабой, ни динамической типизаций.
> Опять спутали слабую и динамическую типизации
Почему думаете что перепутал?
> Это не является отличительным свойством ни слабой, ни динамической типизаций
Это является отличительным свойством TS от JS
Почему думаете что перепутал?
> Это не является отличительным свойством ни слабой, ни динамической типизаций
Это является отличительным свойством TS от JS
Почему думаете что перепутал?
Потому что вы пишите "строгая типизация прежде всего хороша для компилятора." Однако, в питоне тоже строгая aka сильная типизация. Как и, главное, какому она помогает компилятору?
А вот в C, C++, JS и PHP слабая типизация. При этом, в C и C++ типизация ещё и статическая. И именно статическая, а не сильная, типизация помогает в оптимизации компилятору на этапе компиляции.
Это является отличительным свойством TS от JS
Нет, обобщённые алгоритмы без угловых скобок можно и на TS писать. Достаточно использовать тип any. Ещё можно поставить опцию компилятора noImplicitAny в значение false, чтобы явно не прописывать тип any.
Почему думаете что перепутал?
Да потому что «слабость» или «сильность» типизации определяет только возможности по явному и неявному приведению типов.
Слабая — разрешает неявное приведение типов (как в js или Си например)
Что-то среднее — разрешает явное приведение типов (python например)
Сильная — не разрешает приведение типов (haskell)
А вы говорите о «статичности» типизации, она определяет сколько информации о типах имеется в самом исходнике. В статически типизированной программе информация о типах имеется до того как её запустили, и неважно, есть ли в исходниках явные сигнатуры или они были выведены автоматически. В динамически типизированной программе типы данных становятся известны только в рантайме.
Что касается «возможности писать обобщенные алгоритмы не зарываясь с головой в лес угловых скобок», не во всех языках полиморфные типы реализованы так стрёмно как в C++ и его наследниках.
Что-то среднее — разрешает явное приведение типов (python например)
Таки нет, в питоне всё не так.
Потому что при вызове "функций" str, list, dict и т.д. не происходит никакого приведения типов, на самом деле это просто вызов конструктора одноимённого класса (str, list, dict и т.д). И этот вызов возвращает новый объект, а не изменяет тип старого.
Кто в курсе, когда в TS планируют запилить свой компилятор async-await в таргет ES5?
https://blogs.msdn.microsoft.com/typescript/2016/07/11/announcing-typescript-2-0-beta/
One feature you might be wondering about is support for async functions in ES3 & ES5. Originally, this was slated for the 2.0 release; however, to reasonably implement async/await, we needed to rewrite TypeScript’s emitter as a series of tree transformations. Doing so, while keeping TypeScript fast, has required a lot of work and attention to detail. While we feel confident in today’s implementation, confidence is no match for thorough testing, and more time is needed for async/awaitto stabilize. You can expect it in TypeScript 2.1, and if you’d like to track the progress, the pull request is currently open on GitHub (https://github.com/Microsoft/TypeScript/pull/9175).
Ликбез по типизации:
https://habrahabr.ru/post/161205/
https://habrahabr.ru/post/161205/
Не хочу конечно показаться радикальным, но делать надстройки для работы с классами и типизацией на языке который изначально под это не был построен, мне кажется глупым. Я считаю что для этого нужен третий язык, именно для построения больших frontend проектов. Javascript же идеален в своей простоте, решение небольших задач выглядит красиво и работает быстро.
>Уверен, что портирование таких монстров, как jQuery, потребовало немало приседаний.
То есть он (TS) не совсем совместим с JS?
Чтобы все работало, это все должно быть на TS?
Нафиг такое нужно. :)
П.С. (Утверждения немного преувеличенные)
Что вы к нам (JS) приползли со своим TS. Создайте себе отдельный браузер. :)
Причина популярности JS — кажущаяся простота. Крутые перцы захотели писать на языке быдла, потому что быдло создало большую экосистему, которую перцы не смогли создать.
То есть он (TS) не совсем совместим с JS?
Чтобы все работало, это все должно быть на TS?
Нафиг такое нужно. :)
П.С. (Утверждения немного преувеличенные)
Что вы к нам (JS) приползли со своим TS. Создайте себе отдельный браузер. :)
Причина популярности JS — кажущаяся простота. Крутые перцы захотели писать на языке быдла, потому что быдло создало большую экосистему, которую перцы не смогли создать.
А может с haxe сравнить?
https://blog.onthewings.net/2015/08/05/typescript-vs-haxe/
https://blog.onthewings.net/2015/08/05/typescript-vs-haxe/
Вот было бы неплохо во все браузеры засунуть runtime всех подходящих языков и фреймворков, ну будет дистрибутив браузера на десять мегабайт больше, у всех примерно runtime в сжатом виде 200-300кб, это ж можно засунуть 50 крупняков. Потом, например в заголовках передавать Accept-Runtime, и битовую маску какую-нибудь, сколько это добавит к запросу, 20-30 байт. Зато каждому сайту не придется грузить react, и можно будет реально писать на удобном языке. Мне кажется это могло бы сильно изменить web, упростить написание сайтов и ускорить весь интернет в разы.
А всего-то достаточно уговорить Google, MS и Mozilla внедрить в дистрибутив это дело. Ведь webassembly этих проблем все равно не решит.
А всего-то достаточно уговорить Google, MS и Mozilla внедрить в дистрибутив это дело. Ведь webassembly этих проблем все равно не решит.
Мне кажется это могло бы сильно изменить web, упростить написание сайтов и ускорить весь интернет в разы.
Была. Плагинная система запуска runtime разных. (одни шли прямо с броузером, другие можно было доустановить) — отказались -> Дыра на дыре и дырой погоняли. Устали латать.
Интересно, как изменится полемика в свете выхода TypeScript 2.0?
Пробую отлаживать ТС, пропущеный через babel в браузере. Соурсмапы работают, но стек выглядит нечитабельно. Имена импортированных модулей в сгенерированном js не соответствуют именам в ts, поэтому их значения в вотчере просто так не посмотришь. Отладка в сравнении с обычным js граничит с адом. У всех так, или у меня кривые руки?
Двоякое чуство: написание кода ускорилось, но отладка, которая обычно занимает большую часть времени - замедлилась.
Поделитесь кто как с этим живет?
Sign up to leave a comment.
Стоит ли Typescript усилий?