Typescript — это скриптовый язык, компилируемый в JavaScript. Разработка Microsoft, которая, на сегодняшний день, успела завоевать и фанатов и недоброжелателей. Главный вопрос для начинающих, и не только: «Зачем он мне нужен?».
Поскольку статей, описывающих достоинства и недостатки, описание языка и примеры работы — валом, я хотел бы описать практические выводы при работе в достаточно крупном приложении.
Начнем с основных плюсов:
- Строгая типизация
- Читабельность кода
- Более легкий переход из мира строгой типизации, нежели на JavaScript напрямую, в котором правит бал Динамика
- Обратная совместимость с JavaScript
- Широкая поддержка IDE
Строгая типизация
Позволяет более полно описывать свойства и методы обьектов и классов, из-за чего пропадает необходимость, которая, лично меня, дико раздражала, делать проверку всех, входящих в метод или функцию, аргументов:
function checkAllMyArgsAgain(check, me, please) {
if(check && me && please) {
if(check instanceof CheckObject){
console.log('Урааааа!');
} else {
console.log('И снова исключение...')
}
if(me){ } // И так далее.......
}
}
В любом случае, TypeScript сильно упрощает этот процесс:
function checkAllMyArgsAgain(check: CheckObject, me: MeObject, please: string): string {
return 'Какая проверка аргументов? Вы о чем? ';
}
И мы плавно перейдем ко второму пункту, которому первый сильно способствует:
Читабельность кода
Из примера выше, очевидно, что читать код на TypeScript будет проще, ввиду отсутствия нагромождений кода, характерные Javascript.
Можно представить, во что превратится код, написанный на JavaScript, спустя какое-то время…
function checkMe(check, me) {
if(check && me) {
if(check){ ... }
if(me){ ... }
}
}
function andCheckMe(check, me) {
if(check && me) {
if(check){ ... }
if(me){ ... }
}
}
function andCheckMeToo(check, me) {
if(check && me) {
if(check){ ... }
if(me){ ... }
}
}
Против:
function checkMe(check: CheckObject, me: MeObject) {
console.log('Ну круто же!');
}
function andCheckMe(check: CheckObject, me: MeObject) {
console.log('Просто песня');
}
function andCheckMeToo(check: CheckObject, me: MeObject) {
console.log('Писать легко и с удовольствием');
}
В некоторых случаях, в JS, можно уменьшить ущерб путем абстракций, но в целом, TS сильно впереди по данному вопросу.
Более легкий переход в мир JS из мира статики
Многие проявляют интерес к JS, но их отпугивает некая хаотичность и непредсказуемость языка. Здесь Вам сильно поможет TS, который позволяет писать JS, более привычным и понятным путем.
Обратная совместимость с JS
И это, таки, приятный бонус, потому как не придется переписывать весь существующий код, чтобы поиграться с TS и написать лишь часть приложения на нем + есть возможность перенести все любимые библиотеки с JS на TS, если будет такая необходимость.
Широкая поддержка IDE
TypeScript, на данный момент, имеет поддержку в любой популярной IDE, включая IDEA, WebStorm, Sublime, Atom, и так далее. Соответственно, менять любимую среду разработки не придется.
Теперь опишем основные минусы:
- Строгая типизация
- Компилятор
- Debug
- А вдруг помрет?
Строгая типизация
Этот пункт работает как во благо, так и во вред, потому что необходимо описывать все типы для всех обьектов, классов, переменных, и иже с ними, что было не свойственно JavaScript ранее.
Но куда большее зло — миграция существующих популярных JS решений на TS. Видите ли, для каждой портированной либы необходимо описать .d.ts файл, в котором и хранятся все возвращаемые типы и описание всех методов. Уверен, что портирование таких монстров, как jQuery, потребовало немало приседаний.
Компилятор
Он существенно уменьшает вероятность «тупой» ошибки, типа пропущенных запятых и неправильно написанных имен переменных, но, также, убивает всю прелесть JS, когда большую часть решений можно было написать на коленках и проверить в консоли браузера.
Не стоит забывать, что время от времени, придется обновлять и сам компилятор, поскольку язык развивается и, рано или поздно, появится необходимость обновить существующую версию компилятора, а, возможно, и самого кода.
Debug
Естественно, любому разработчику необходимо понимать, как, быстро и эффективно, проверять код на ошибки, ловить и исправлять баги. И, первым делом, надо разобраться, как это процесс наладить в TypeScript. Существует множество гайдов для различных IDE: WebStorm и Visual Studio о том, как все это дело настроить в редакторах кода и эффективно работать, но с JS этого делать не надо было, потому как, можно было запустить код, наставить точек останова внутри редактора или браузера и спокойно дебажить. С TS придется немного попотеть.
А вдруг помрет?
Это интересный и серьёзный вопрос, потому как стандарты JS идут в ногу со временем и интегрируют в сам язык многое, что было полезно в TS: классы, стрелочные функции, и так далее. Рано или поздно, все полезные функции TS будет так или иначе перенесены в стандарт языка и TS повесит бутсы на гвоздь. А если ребята из Microsoft решат, что им это не нужно и полностью оставят TS на волю open-source? Понятно, что являясь открытым продуктом, TS не лишиться поддержки совсем — всегда найдутся энтузиасты, но поддержка такого гиганта, как Microsoft, никогда не помешает.
Опять же сам Microsoft, как основного разработчика, многие относят к минусу, потому как репутация у гиганта весьма спорная: Skype, Nokia, Windows Phone, Windows Vista, и так далее.
Надеюсь, что помог кому-то с решением о данном вопросе, либо же заставил задуматься о целесообразности перехода.
Всем спасибо, все свободны!
Комментарии (182)
jsfun
23.08.2016 23:15Согласен, но если смотреть с этой точки зрения, то это полумера, так как все можно описать через any и использовать TS в некоторых частях кода, а не везде. Но я являюсь поклонником фразы: «Если используешь что-то, то используй это на 100%».
Можете глянуть — jQuery.d.ts, если будет интересно.
Но в целом — Вы правы.
Reeze
23.08.2016 23:18+7Вся прелесть TS именно в том, что я могу взять свой проект на javascript, перенести его в .ts и добавлять типы по мере необходимости.
Аннерс Хейлсберг именно это и задумывал.
sentyaev
23.08.2016 23:25+2Отличный язык, с одной стороны позволяет все затипизировать и иметь проверки на уровне компилятора, с другой стороны позволяет очень быстро сделать прототип решения (почти как в JS) и потом уже провести рефакторинг.
В общем нравится мне за гибкость.
prambeat
23.08.2016 23:46+3Стоит также взглянуть на flow
PaulMaly
24.08.2016 03:20А еще на соответствующий плагин для Babel. Очень выручает с типами, тем более что Babel сейчас юзается повсеместно.
serf
24.08.2016 09:13Это полумера, TypeScript больше чем просто типы. В любом случае на переход тратятся усилия, так лучше потратить их разумно чем хвататься за сомнительные поделки.
AndreyRubankov
24.08.2016 11:11-7Так ведь сам TypeScript — это сомнительная поделка.
Да, есть удобство от типизиации, но в целом спроектирован TS криво.
Сейчас они вроде перешли на более-менее нормальный импорт зависимостей (из ES2015), а раньше у них импорт описывался через комментарии с xml тегом.
Да и в целом, они решили сделать велосипед, в то время, когда их нужды без проблем мог покрыть ActionScript3. Который уже на тот момент имел поддержку во многих IDE, который был известен очень большому количеству людей и был очень даже популярным.
karudo
24.08.2016 11:50+2но в целом спроектирован TS криво
Выскажитесь по этому поводу подробнее, пожалуйста.
bromzh
24.08.2016 12:48+8но в целом спроектирован TS криво.
Наоборот, он спроектирован очень хорошо. Синтаксис берётся из самых свежих спецификаций ES, плюс надстройка в виде описания типов. Т.е. в отличие от coffee- и clojure-скриптов, код на TS выглядит почти как js-код будущего.
раньше у них импорт описывался через комментарии с xml тегом.
Это был не импорт, а что-то типа #include из мира C/C++. Хотя можно было вообще не добавлять эти комментарии, а просто настроить компилятор и использовать модули / namespace'ы.
Самый сок в том, что пока не было примерно понятно, как в ES будет выглядеть импорт/экспорт, в TS не стали добавлять какой-то свой синтаксис импорта в сам язык, что позволило сейчас относительно безболезненно ввести этот самый синтаксис. Разве это пример плохо спроектированного языка? По-моему, как раз наоборот.
hell0w0rd
24.08.2016 11:58+2Как человек, попробовавший typescript и сейчас пробующий flow, скажу, что вы не правы. Оба инструмента имееют преимущества и недостатки. Например flow можно включать не для всех файлов, или даже не для всего файла. Он также умеет самостоятельно выводить типы, что прямо крутая фича для динамического языка.
serf
24.08.2016 12:26Например flow можно включать не для всех файлов, или даже не для всего файла.
А в TS типизация не опциональна? Плюс теперь есть флаг «allowJs».
Что имеется ввиду под «выводить типы»?hell0w0rd
24.08.2016 12:59Что имеется ввиду под «выводить типы»?
https://flowtype.org/try/#0PQKgBAAgZgNg9gdzCYAoVBjOA7AzgFzHwFMCwBeMACgEoKA+MAchIKYG51X9aA6fOADEAlgA9iAE1qcgAserf
24.08.2016 13:10test.ts
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
impwx
24.08.2016 13:06Typescript тоже вполне неплохо выводит типы, а в 2.0 вообще запилили вывод на основе анализа потока управления.
Diverclaim
24.08.2016 14:48Продемонстрируйте вывод типов во flow такой, чтобы typescript такого не умел.
zorro1211
24.08.2016 21:31Добавлю про преимущества flow. На этом слайде демонстрируется один из наглядных примеров, хоть и надуманный немного. Так же babel может убирать типы из кода чтобы затем трасформировать надстройки вроде object spread или другие новшества которые могут появиться в языке. Если нужно использовать что-то вроде https://github.com/lodash/babel-plugin-lodash то придется компилировать 2 раза. Из минусов большая задержка была с поддержкой windows.
Но это не умоляет достоинств typescript. Он тоже очень хорош.
vintage
24.08.2016 22:24Пример показывает лишь, что в тайпскрипте коллекции ковариантны, а во флоу — инвариантны. Однако, вид вариантности должен определяться из контекста использования, что оба этих инструмента не умеют.
Например, такой код флоу не пропустит:
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[]) }
hell0w0rd
24.08.2016 21:35Мне кажется, я забыл упомянуть главное. TS — это как ни крути отдельный язык. Если из TS подключать js файл, ему нужно подсунуть аннотации (.d.ts). А flow работает поверх js. Ему не нужно ничего дополнительно указывать, только при особой необходимости.
А .d.ts это еще та боль. Единицы библиотек поддерживают эти самые аннотации, а внешние постоянно старые.
PaulMaly
25.08.2016 02:16Дык, кто бы спорил)) Просто лично мне от TypeScript ничего не нужно. Описанный плагин к Babel решает мою проблему, связанную не с TypeScript, а упорным отсутствием хотя бы опциональной типизации в стандарте. Лично мне именно ее больше всего не хватает в последней версии.
vintage
23.08.2016 23:49С TS придется немного попотеть.
Развернёте мысль?
jsfun
24.08.2016 00:01Без проблем! Несмотря на обьемное количество информации, у меня заняло некоторое время настроить окружение, чтобы нормально дебажить TS.
1. Надо было поставить плагины в среду разработки, чтобы редактор начал адекватно реагировать на TS(что нормально, поскольку это касается любой надстройки на нативным языком)
2. Надо было изменить конфигурацию дебаггера внутри IDE, потому как теперь нужно сначала скомпилить ts, а потом дебажить скомпиленный код
3. Вначале были проблемы с бандлерами типа Webpack или загрузчиками типа SystemJS, потому что их нужно было расширять дополнительно для работы с TS.
Это не является огромной проблемой — все это относительно просто можно сконфигурить, но наличие дополнительных движений все же стоит отнести к небольшим минусам.vintage
24.08.2016 00:24Вы сейчас про какую среду разработки-то?
jsfun
24.08.2016 00:26vintage Имеется ввиду IDE — IDEA, WebStorm, Sublime, Atom…
vintage
24.08.2016 00:28+1WebStorm поддерживает TS из коробки уже давно.
jsfun
24.08.2016 00:29vintage Да, но не все же на WebStorm работают, верно?
vintage
24.08.2016 08:53+5Но и не все обобщают опыт работы с одной IDE сразу на все, преподнося это как минус языка.
OnYourLips
24.08.2016 09:07+2А какие IDE для веб-разработки ещё есть с сопоставимыми возможностями? (конструкторы на базе редакторов не учитываем)
Получается, что выбора IDE нет, так что рассматривать это как минус не стоит.AndreyRubankov
24.08.2016 11:50-2Какие IDE, вы что! Все же гордятся, что в sublime text работают и им не нужны все эти монстроузорные IDE.
AndreyRubankov
24.08.2016 11:42-1Жаль, что поддерживает его довольно криво: компиляция происходит при каждом изменении файла, неприятно работать.
TihoFih
24.08.2016 18:26check box «Track changes»
https://www.jetbrains.com/help/webstorm/2016.2/typescript.html?utm_source=from_product&utm_content=2016.2.2&utm_medium=help_link&utm_campaign=__PACKAGE_CODE__
stas404
24.08.2016 00:43С окружением все нормально, поднимается без проблем — этот пункт не стоит брать во внимание в вопросе о нужности/ненужности typescript.
В целом же, сабж — штука, конечно, прикольная, но писанины субъективно где-то на треть больше выходит. На мой взгляд, для мелких/средних проектов не особо целесообразно, для крупных же — вполне может оправдать себя.Odrin
24.08.2016 14:48Да и на среднем проекте, в котором более одного разработчика, совместная разработка заметно упрощается благодаря интерфейсам. Лично для меня интерфейсы в TS — это как раз то, чего так долго не хватало в JS.
serf
24.08.2016 09:21Выше перечислены простые вещи, которые делаются один раз и это много времени не занимают. Гораздо более сложный вопрос с переходом может возникнуть если команда не готова работать с типами и ООП вообще (например елси в команде фанбои функциональщины, или просто не инженеры которые не привыкли писать поддерживаемый код).
Starche
23.08.2016 23:55+5Использовал TS в продакшне. Мне понравилось прямо очень. Минусы на мой взгляд притянуты за уши. Контраргументы по пунктам
1. Сама по себе строгая типизация является в TS опциональной. Не хотите — пишете any, и всё, что вас там напрягало, проходит мимо. Да, вы не получите соответствующих плюсов, но это же ваш выбор был. А .d.ts файлы считаю вообще прекраснейшим решением, которое позволяет подключить любой посторонний код и сделать его типизированным. Опять же: если не хотите — не делайте, это ваш выбор, но жаловаться на то, что библиотеки требуют дополнительного описания для того, чтобы они были типизированными — довольно нелогично.
2. Если надо быстренько поговнокодить через консоль, а потом вкинуть решение в продакшн, то вроде как никто этого сделать не мешает. По крайней мере у меня бывала парочка костылей такого плана, и компилятор никак не помешал
3. Дебажу прямо чистый JS в хроме. Учитывая, насколько он вообще читабельный на выходе — не понимаю, какие у вас с этим проблемы? Плюс при использовании Sourcemaps хром позволяет дебажить TS прямо в браузере, без всяких там штормов и студий. Хоть в саблайме пишите.
4. Помереть может что угодно. А говорить, что майкрософты это всегда плохо — довольно странно. Я расчитываю, что TS будет жить долго, хотя бы потому что Angular 2 пишут на нём.jsfun
24.08.2016 00:05Starche Не лишены логики первые три пункта, но:
4. Помереть может что угодно. А говорить, что майкрософты это всегда плохо — довольно странно. Я расчитываю, что TS будет жить долго, хотя бы потому что Angular 2 пишут на нём.
Я заметил, что многие относят это к минусу, но я не имел ввиду, что это всегда плохо. Если это непонятно из контекста, исправим.
vintage
24.08.2016 00:26+1Только вот ng2 далеко не факт, что долго проживёт.
sentyaev
24.08.2016 02:08+3Я считаю в кругу .NET разработчиков должен взлететь, особенно тех, кто веб-разработкой занимается (я сам кстати из этих).
Я когда начал писать на TS даже доки не читал, т.е. порог входа для тех кто знает JS + C# просто нулевой (понятно, что уже через пару часов полез на форумы). Думаю тоже касается и Java разработчиков.
Плюс он заточен как раз для больших проектов, это нравится энтерпрайзу.
Даже сейчас есть отличный тулинг, например отличная поддержка в WebStorm и обещают поддержку в новой VS, а также вполне уже для пет-проджектов можно использовать Angular-cli.
Да и за спиной у него стоит влиятельная корпорация которой доверяют.
Учитывая эти факты, я предполагаю, жить он будет долго.
Мне вот интересно, почему вы считаете, что «не факт»?vintage
24.08.2016 08:50+1Эта влиятельная корпорация уже похоронила GWT и вот-вот похоронит Polymer. Основная причина смерти — излишняя сложность и недостаточная гибкость, не дающая технологии обрести популярность. jQuery и Angular взлетели именно за счёт простоты, можно было на коленке сваять что-то работающее
и отправить в продакшен. A2 же — это сложно и громоздко.
YemSalat
24.08.2016 10:11+3jQuery разумеется, но откуда вдруг первый Angular стал простым? Его наоборот первое время в основном за переусложненность ругали.
Насчет Angular 2 — согласен, далеко не факт что взлетит так же как первый. Дело даже не в гибкости, уже достаточно много конкурентов и альтернативных подходов (React, и т.п.)serf
24.08.2016 11:16-1так же как первый
первый как раз взлетел, чтобы бы не писали React фанбои.YemSalat
24.08.2016 12:10Перечитайте, я именно это и сказал — первый взлетел, не факт что второй так же взлетит.
Angular 2… далеко не факт что взлетит так же как первый
serf
24.08.2016 12:29Ок, да второй вроде как позиционировался простым, но на деле там много всяких сущностей и итоговая структура приложения получается я бы не сказал что простая.
vintage
24.08.2016 13:14Он был не особо простым, но простое приложение на нём создать можно было очень просто. Вот с масштабируемостью у него просто беда.
AndreyRubankov
24.08.2016 12:00+3Если быть честными, то GWT — это плохая технология, как JSF и куча других решений, которые предлагают на бекенд-языке писать под фронтенд.
Да, когда-то это было обосновано и, возможно, даже правильно. Но вот уже лет 5-10 как, это все стоит выкинуть на свалку истории, но до сих пор люди мучаются с поддержкой этого легаси.konsoletyper
24.08.2016 13:00А можно подробнее про то, почему GWT — это плохая технология? И что такое "бэкэнд-язык"? Какие особенности синтаксиса и семантики языка делают его пригодным для написания кода на фронтэнде, а какие — на бэкэнде?
AndreyRubankov
24.08.2016 17:02> И что такое «бэкэнд-язык»?
В данном случае это java. Самая большая глупость, которую можно сделать — это генерировать js из java кода. Это кажется хорошей идеей, т.к. позволяет изучить только один язык и развиваться в нем.
На самом же деле — это лишь вводит ограничения в проект. Фронтенд уходит далеко вперед, а технологии, которые занимаются извращением — не могут поспевать за этим всем.
> Какие особенности синтаксиса и семантики языка делают его пригодным для написания кода на фронтэнде, а какие — на бэкэнде?
Если мы говорим про web, а мы говорим про него, то ответ очевиден: Главная особенность фронтенд языка — он поддерживается браузерами без плагинов.
> почему GWT — это плохая технология?
Мой позиция в том, что бекенд (в виде java) не должен заниматься рендером html, и уж тем более не должен заниматься кодогенерацией js. Есть конечно случаи, когда без серверного рендера не обойтись, но это можно сделать и без GWT. А вот генерировать js — это и вовсе плохая идея, по-моему, и ни одной адекватной причины для этого не вижу.
У проектов, где бекенд занимается рендером страниц нету возможности расширяться в сторону поддержки мобильных девайсов (или эта поддержка требует много усилий).konsoletyper
24.08.2016 17:16Самая большая глупость, которую можно сделать — это генерировать 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 не занимается рендером страниц.
AndreyRubankov
24.08.2016 17:32> Какие извращения? И в чём проблема с поспеванием? Из GWT можно отлично вызывать любой JS-код, самый новомодный и хипстерский.
Вот тут то и будет извращение. Вместо того, чтобы просто писать на js, часть логики будет на java(gwt), а часть на js. И в этом случае все так же придется переключаться между java и js.konsoletyper
24.08.2016 21:58Вместо того, чтобы просто писать на js, часть логики будет на java(gwt), а часть на js
В случае с GWT (может, даже не с GWT, а со сферическим транспайлером Java -> JS в вакууме) писать JS-код нужно сравнительно редко. Даже в GWT, где всё плохо и действительно приходится частенько заводить JSNI, писать кода на JS приходится очень и очень мало. В моём проекте на GWT из 100 тысяч строк на Java на JS было написано о силы строк 50.
konsoletyper
24.08.2016 17:20+1В данном случае это java.
Поподробнее, пожалуйста. Почему на языки наклеивают ярлыки "это фронтэнд-язык, это — бэкэнд". Кто мешает взять CoffeScript или TS и писать на них код для node.js? Кто мешает взять GWT и писать на Java код для браузера? Да сейчас все кто не лень умеют компилироваться в JS, даже C++, даже Haskell, если не изменяет память. Так что же в языке может быть такого, что делает его более подходящим для бэкэнда и фронтэнда?
r00tGER
25.08.2016 11:33«java бекенд не должен заниматься рендером html и кодогенерацией js», но GWT тут каким боком?
Все ваши замечания справедливы только к JSF.
GWT компилиться в чистый JS, ему не нужен бекенд на сервере, как и плагины в браузере. Компилится во время разработки, а не в рантайме. В продакшене GWT — это папочка с уже готовыми js. А бекенд может быть любым.
В интерпрайзе например, со 100500 crud-формами, GWT легко справляется со всей клиентской частью. Без необходимости в JSNI коде.
vintage
24.08.2016 13:04А как вы отличаете плохую технологию от хорошей? ;-)
AndreyRubankov
24.08.2016 16:36Количество боли (время, нервы, количество выпитого кофе), которую приходится испытывать при работе с технологией, по-моему, хороший показатель для этого.
Конечно это все субъективно, кому-то нравится, кому-то нет.konsoletyper
24.08.2016 16:42Количество боли от конкретно GWT не является показателем того, что Java — это плохой язык для разработки фротнэнда. Это является лишь показателем того, что гугл этот самый GWT поматросил и бросил, не влил достаточного количества ресурсов, чтобы сделать из него конфетку. В последних версиях GWT преобразился (появилась инкрементальная компиляция, нормальный интероп и отладка), и количество боли от его использования стало заметно меньше. Если бы для него кто-то запилил что-то похожее на Angular — было бы вообще отлично. Но теперь-то кому какое до этого есть дело?
AndreyRubankov
24.08.2016 17:18> не влил достаточного количества ресурсов, чтобы сделать из него конфетку
Зачем? Почему не взять html+js и не написать нормальный фронтенд без свистоплясок и трансформаций?
js+html выучить в разы легче, чем ту же java, думаю, js+html выучить легче, чем нормально разобраться в GWT =)
А если так — зачем использовать GWT и вливать в него ресурсы?konsoletyper
24.08.2016 17:25-1Зачем? Почему не взять html+js и не написать нормальный фронтенд без свистоплясок и трансформаций?
Какие конкретно свистопляски? Я таковых не обнаружил. Конечно, на старте GWT пришлось понастраивать, но это везде так. И Spring, и Hibernate пришлось настраивать, и, о боже, npm, webpack и grunt. Причём, не сказал бы, что с GWT было сильно больше свистоплясок, чем с последними тремя технологиями.
js+html выучить в разы легче, чем ту же java, думаю, js+html выучить легче, чем нормально разобраться в GWT =)
Я отлично знаю и Java, и JavaScript, и много других интересных вещей. Однако, мне проще писать на одном языке, в рамках единой экосистемы. Да, язык — это не просто синтаксис и семантика, это целая экосистема, которую он за собой тянет. И, кстати, их тоже надо изучать, и на это далеко не всегда есть время и силы.
slavap
25.08.2016 16:44GWT, кстати, очень даже жив, уже доступен 2.8 RC2, а это поддержка Java8 и новый JS interop, теперь вообще интеграция с JS практически идеальная. Для командной разработки Java лучше JS. И Google использует GWT для разработки Inbox, плюс пишут компилятор GWT в Closure, так что вполне себе живой и качественный продукт.
taujavarob
25.08.2016 16:59GWT, кстати, очень даже жив,
Ну, это как считать «живость». Число запросов где требуются разработчики на GWT резко снизилось по сравнению с тем, что было лет так 5 назад. И во многих девелоперских конторах он просто… исчез.slavap
25.08.2016 21:21Вообще-то разработчик GWT — это Java разработчик, не понятно зачем это выделять в отдельную вакансию.
taujavarob
26.08.2016 15:43Вообще-то разработчик GWT — это Java разработчик
Это верно. Но обычно пишут какая технологии требуются.
С другой стороны, чтобы хорошо писать на GWT надо освоить и JS.
Но освоив JS зачем писать на GWT?
konsoletyper
26.08.2016 18:41Я уже писал чуть выше, почему есть смысл писать на GWT, а не на JS. Незнание JS — это не причина использовать GWT, но зато за использование GWT есть много других причин.
taujavarob
26.08.2016 18:45Вы писали о GWT:
«Проблема в том, что мне неудобно постоянно переключать контекст. И вопрос не только в синтаксисе, вопрос в либах, фреймворках, сборщиках, линтерах, IDE и т.д. „
Ясно.
Кстати, это главная причина почему и JS лезет(Node) на сервер. :)
Имхо, конечно имхо.
slavap
26.08.2016 22:50JS как раз можно и не знать, и спокойно писать на Java. Знание CSS важнее, но тоже не обязательно.
taujavarob
29.08.2016 18:01JS как раз можно и не знать, и спокойно писать на Java. Знание CSS важнее, но тоже не обязательно.
html-теги
GWT не взлетел. Он противоречив:
С другой стороны, чтобы хорошо писать на GWT надо освоить и JS.
Но освоив JS зачем писать на GWT?slavap
29.08.2016 20:50А Android взлетел :-)? Ещё раз говорю, прекрасно можно писать практически не зная JS.
taujavarob
29.08.2016 20:54А Android взлетел
Да. За счёт Java-программистов. Но… там проблемы у Оракла с Гуглом. И этот полёт может войти в пике.
sentyaev
24.08.2016 13:26Насчет сложности я бы поспорил. Если сравнивать с React (это конечно не совсем верно, скорее нужно сравнивать не просто с React, а с тем набором библиотек и фрэймворков с помощью которых можно построить то, что мы называем React app), Ember, Aurelia, то Angular2 уже не выглядит слишком сложным.
У него есть большой плюс — все что нужно уже идет из коробки. Плюс уже сейчас есть UI библиотеки (Material и PrimeNG).
Конечно же я имею ввиду только полноценные SPA приложения. Если бы мне нужно было делать классическое веб-приложение, я бы взял что-то проще, например Knockout или просто jQuery.springimport
24.08.2016 22:15Сейчас в проекте использую AngularJS не в «SPA-варианте». Не приятно перекидывать данные в модели, но зато на фронте все удобно. Думаете, лучше jQuery?
sentyaev
24.08.2016 22:37Не факт, зависит от задач. Бывает, что одного jQuery не хватает. Тут вам виднее.
springimport
24.08.2016 22:58Я не смог отказаться от плюшек фреймворка для админки (yii2) и поэтому так сделал. Просто до сих пор не уверен в адекватности.
window.formData = xxx;
$scope.form = $window.formData;
Odrin
24.08.2016 15:50AngularJS — простой, а Angular 2 — сложный? Вероятно Вы никогда плотно не работали ни с тем, ни с другим.
Angular 2 стал гораздо проще, по сравнению с первой версией. Тестирование стало проще, template syntax стал проще, angular «магии» и кастомщины стало меньше и, что не мало важно, выстрелить себе в ногу стало сложнее.springimport
24.08.2016 23:00Вторую версию сходу не получилось поставить, не было времени гуглить ошибки, а с первой было сложнее разобраться, но зато «подключил и работает».
VolCh
24.08.2016 00:24-6Для меня главный минус — отсутствие обратного компилятора. Чтобы те члены команды, которые хотят ТС могли легко интегрировать изменения, которые я сделал в сгенерированном ими ДжС.
zartdinov
24.08.2016 01:03Есть инструменты ES5 -> ES6, например lebab. Возможно есть подобия и для TS.
Но довольно глупо предполагать, что он будет со встроенным интеллектом и сможет восстановит типизацию и стиль кода ваших партнеров).
Но уже с помощью того же lebab вы можете подать им более-менее красивый код, близкий к синтаксису TS.
Вообще бывает очень удобно, когда приходиться переводит много старого кода на новую спецификацию.
easimonenko
24.08.2016 15:15Для typescript это невозможно, так как «компиляция» там сводится в основном в удалении всего того, что относится к сути языка. например, были аннотации типов, в результирующем коде их нет, и нет никаких указаний на то, что они там были. И вообще, у кода, полученного из Typescript, нет вообще никакого runtime.
vintage
24.08.2016 17:35На самом деле это не так.
- Он создаёт функции extends и decorate
- Он может добавлять некоторую информацию о типах, если включить специальный флаг.
zartdinov
24.08.2016 19:28+1Полностью согласен, в примере с ES6 тоже не все обратимо. Мне больше нравится более узкий термин для таких инструментов.
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 всего лишь статическая и влияет только на тебя, а не на работу кода.
Starche
24.08.2016 01:52Cуровая у вас практика.
Я мог бы понять такой аргумент при работе с SCSS/LESS: из браузера CSS реально в разы удобнее писать, чем каждый раз перегенеривать. Это меня часто останавливает от использования CSS-препроцессоров.
Но вносить изменения прямо в JS… Что вас побуждает к таким действиям? почему в тайпскрипте не поправить?
А если вам надо отдельный файл подключить JS-ный, то это как раз никто не помешает сделать.
serf
24.08.2016 09:16-3Рано или поздно, все полезные функции TS будет так или иначе перенесены в стандарт языка и TS повесит бутсы на гвоздь.
Очень мало вероятно. TS сделан инженерами для инженеров, а ES хипстерами. Если бы ES делали инженеры то типы бы уже там появились, но они просто добавляют синтаксического сахара, это говорит об их приоритетах.serf
24.08.2016 11:01-4Лучше напишите что-то против моих слов чем тупо минусы ставить. Ведь типов не видно в будующих стандартах и разве это не говорит о приоритетах авторов стандартов? Я понимаю они хотят оставить JS «простым», но вместе с этим реальных подвижек в стандарте нет (стрелочные функции, деструкторы и прочая мишура это просто сахар который не решает базовые проблемы JS).
seryh
24.08.2016 12:00+2с каких пор строгая типизация делает язык программирования «сложным» и более инженерным? не выдавайте свои предпочтения ооп фанбоя за какой то объективный факт.
AndreyRubankov
24.08.2016 12:12-2Да, вы правы, типы не делают язык инженерным. А так же типы есть не только в ооп.
Ну и типы действительно делают язык более сложным.
Сложным становится потому, что:
1. движки должны переписаться для поддержки типов, думаю, на данный момент это сложно сделать;
2. разработчикам вместо того, чтобы закинуть просто объект, нужно будет сделать инстанс типа, а это больше кода и в консоли браузера тяжелее тестировать, и вообще «верните мне мой js» (когда-то был крик души на хабре про появление Angular в мире js).impwx
24.08.2016 13:55+1типы действительно делают язык более сложным
Это неправда. Не бывает «языка без типов» — все данные, которыми оперирует ваша программа, так или иначе имеют определенный тип. Если вы передаете в функцию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
serf
24.08.2016 12:50-3не выдавайте свои предпочтения ооп фанбоя за какой то объективный факт.
мои личные предпочтения о которых я обычно не пишу, и оправданность их применения на реальных проектах совсем разные вещи.
serf
24.08.2016 12:59-1Типизация и вообще структурирование кода (пускай это ООП или еще что-то) делает язык более сложным с точки зрения продумывания структуры того что ты пишешь. Очевидно типизация делает код более поддерживаемым тка же как и ООП, и это более инженерный подход чем слабать что-то на коленке, залить на продакшен, потом свалить из компании в другую и там снова фанбоить.
seryh
24.08.2016 13:21+3Очевидно что разработчик делает код более поддерживаемым, а инструменты которые разработчику в этом помогают не ограничены типизацией и ООП. Строгая vs динамическая типизация, ФП vs ООП, эти холивары идут уже многие годы, истина так и не найдена.
serf
24.08.2016 13:24-2Инженеры делают спокойно свою работу в то время когда ФП фанбои пишут свои блоги и заливают ролики на ютюб, им ведь нужны холивары чтобы привлечь к своей персоне внимание.
arvitaly
24.08.2016 12:47Это не проблемы JS, это проблемы крупных проектов и сверхнадежных библиотек. А JS позиционировался всегда, как язык для всех, даже для сайта из одной странички 5кб, написанной за вечер. Без малого бизнеса, некому вырастать в крупный. Поэтому JS никто и не трогает, а то, что браузеры не поддерживают другие языки, это вообще вопрос открытый и тут куча нюансов:
1. А нужны ли вообще крупные приложения в браузере? Современные системы позволяют быстро установить нативные приложения в ОС, написанные на любом языке.
2. Почему бы не оставить браузерам и JS то, для чего они и создавались, доступ к информации по URL с минимальным интерактивом на странице?
3. Что включить в браузер, поддержку каких языков/возможностей? Этот вопрос пытаются решить при помощи стандарта WebAssembly, но все равно кому-то чего-то будет не хватать. Кому скорости рендеринга, кому самого webassembly.
4. Если не развивать браузеры, а все силы вложить в разработку экосистемы нативных приложений, то не будет ли это логичным выходом из этого зоопарка, а браузеры оставить как испытательный полигон?serf
24.08.2016 12:55-2А JS позиционировался всегда, как язык для всех, даже для сайта из одной странички 5кб, написанной за вечер.
Не всегда, последние года 4 это уже не так. Задачи которые сейчас решает JS уже далеко не те которые он решал 5-10 лет назад. Серверная часто теперь как правило stateless (да теперь бекенерам проще стало чем было ранее, а в JS гораздо сложнее), состояние держится на клиенте. JS кода стало очень много, и когда кода много важну роль занимает его поддержка и развитие и здесь типизацию сложно недооценить.
А нужны ли вообще крупные приложения в браузере?
Речь идет не только о бразуераз, JS заполонил все направления, есть ведь любители писать много серверной бизнес логики на Node.js без какой либо типизации.
Kain_Haart
24.08.2016 10:36+6> стандарты JS идут в ногу со временем и интегрируют в сам язык многое, что было полезно в TS
afaik это TS реализовывал ранние предложения из стандарта ECMAScript а не наоборот
ZOXEXIVO
24.08.2016 11:25Разработчики Typescript говорят, что Typescript генерирует примерно такой же код, который бы вы написали своими руками и поэтому отказаться от Typescript, в случае чего, будет очень просто — удалить ts файл и дальше использовать сгенерированный JS
PretorDH
24.08.2016 11:25-4И только ради типизации ипользовать все «прелести» компилятора.
Вы других плюсов не увидели?
P.S. Не пользуюсь псевдокомпилируемыми (компиляция это когда на выходе исполняемый машинный код, а не ещё один скрипт) языками — вредны для понимая логики исполнения и качества кода.
Например: Большинство SCSS кода, от говнокодеров, после компляции получается просто ужасным (как минимум исключающие и избыточные селекторы). Подумаеш, все равно какой код на выходе — браузер разберется, главное что в исходник «красивый». Скорость написания и синтаксический сахар это не аргументы, а отмазки. По факту получается, что нормально написанный руками CSS меньший или равняется не скомпилированному говно SCSS. А нормально написанного SCSS — «днем с огнем».serf
24.08.2016 12:32+2Типизация это уже далкео не сахар а реально нужная вещь. Поддерживаемость кода имеет большое значение, часто большее чем очень оптимальный по размеру сгенерированный код на выходе и SCSS в этом плане выходит вперед перед голым CSS.
PretorDH
24.08.2016 15:47-2Типизацию придумали не вчера. И в JS она не нужна, основе язык запроектирован таким, что бы быть транслируемым! Если бы этого не нужно было, привязали бы стандартную JAVA и не плодили уродов. На сегодняшний день про это забыли. Как на меня надо упрощать, а не усложнять. Мы же хотим, что бы все работало быстро. Кроме того, с введением типизации, возникают новые трудности. Например, нужно передать объект который имплементировал все, что нужно для функции обработчика, но он нового класа и под ограничение типа не попал. И что — откатываемся назад к any и вставляем проверки. Но не забываем, что валидацию значений все равно нужно делать, а это теже проверки, так что TS практически ничего не дает в этом плане.
Поддерживаемость зависит не от языка, а от архитектуры. Если на SCSS архитектуры нет, то потдерживать его сложнее чем CSS без архитектуры. А если в CSS есть правильное архитектурное решение, то SCSS только усложнит потдержку.serf
24.08.2016 15:59-1язык запроектирован таким, что бы быть транслируемым
Только вот факт в том что когда JS создавался никто не догадывался какую значимую роль он на себя возьмет в будующем, ознакомьтесь и историей, не нужно притягивать доводы за уши. К тому же он и остается транслируемым, в рантайме.
Мы же хотим, что бы все работало быстро.
Каким образом использование TS влияет на итоговую скорость работы скрипта? В итоге ведь тот же JS получается, и та же история с CSS процессорами.
но он нового класа и под ограничение типа не попал
Учите матчасть и проектируйте систему гибко. Суть как раз в том и состоит чтобы наложить жесткие ограничения.
А если в CSS есть правильное архитектурное решение
Самый простой и очевидный пример. Допустим у проекта много заказчиков и каждый хочет свою цветовую гамму (требование заказчика намеренно упрощено, но предположим кастомизируется только цветовая гамма). Как на чистом CSS вы сделаете это грамотно? C процессором я просто задам набор переменных для каждого заказчика.
PretorDH
24.08.2016 16:31-1Мой коментарий о типизации в JS, а не в TS.
Кроме того, с развитием HTML заначение JS для большинства страниц падает.
А для приложений лучше был бы язык ближе к JAVA.
Пример с цветовой схемой, очень наглядный. У вас получатся переменные, которые прописываются в общий CSS. А в CSS будет цветовые схемы в отдельных файлах, которые я могу поменять на ходу в браузере. А основной CSS станет короче на все эти правила, правда чуть удлинится HTML. И в итоге исходный код в общем короче и проще. А всё потому, что у меня архитектура. А у вас решение высосаное из пальца.serf
24.08.2016 16:33> И в итоге исходный код в общем короче и проще. А всё потому, что у меня архитектура. А у вас решение высосаное из пальца.
Очень спорное суждение, удачи вам с вашей «архитектурой CSS», рад что вы довольны собой и своей архитектурой, я вот часто ставлю под сомнения свои решения и бывает их пересматриваю, но вам видимо это не знакомо потому что и так все идеально.PretorDH
24.08.2016 16:53И вам удачи.
Архитектура — это когда мы поднимаемся к абстракциям вида и описываем их кодом. А не наоборот из абстракций кода кое-как лепим вид.
P.S. Со временем поймете, что SCSS не заменяет архитектуру. А только дополняет абстракцию кода — увеличивает энтропию. На нем можно написать туже архитектуру, что говорю я, но это не одно и тоже. Не знаю как вы, но в общем случае пишут без архитектуры, заменяя её навязанными абстракциями кода. На выходе «говно» код, с большой вложенностью селекторов и высокой специфичностью.serf
24.08.2016 16:56На выходе «говно» код, с большой вложенностью селекторов и высокой специфичностью.
То что вам инстумент не подошел (инструмент ведь вам говнокод вам делает, не вы сами?) не причина его не использовать другим у кого говнокод не получается сделать.PretorDH
24.08.2016 17:07Пользовался SASS/SCSS 5 лет и на выходе был приемлимый код (потому, что понимаю как оно будет скомпилировано). Но сейчас мене удобнее сделать всё на CSS. Времена поменялись.
Я не говорю инструмент плохой, я говорю о том безархитектурном коде который приходится переделывать. Если Вы с таким не сталкивались? Рад за Вас. Но ещё не вечер.
vintage
24.08.2016 17:44+2
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 ) } })PretorDH
25.08.2016 00:40А скомпилировано как?
Я напишу код вот-так:
alert ( (function uppercaser(a) { return typeof a==«string»?a.toUpperCase():a })('hello!') );vintage
25.08.2016 08:52-1По ссылке всё есть.
Страшный код вы пишете, но даже его лучше было бы написать так:
alert ( ( function uppercaser( a : { toUpperCase() : string } ){ return a.toUpperCase() } )( 'hello!' ) );G-M-A-X
25.08.2016 09:40+2Необходимость отступов на ровном месте очень противоречива.
Код похож на решето. :)
impwx
24.08.2016 13:27компиляция это когда на выходе исполняемый машинный код
Компиляция — это трансляция языка более высокого уровня в язык уровнем чуть ниже. Typescript под это определение отлично подпадает, равно как и Babel, Coffeescript и многие другие.
вредны для понимая логики исполнения и качества кода
Typescript повторяет логику ES6 практически один в один, но плюс к этому накладывает ограничения на заведомо ошибочные действия, которые программист может допустить по невнимательности. При прочих равных качество кода от этого становится только лучше.
gooddaytoday
24.08.2016 11:50+2Работаю с кодовой базой на TS порядка 1000 000 строчек, опыт есть (все — клиентский код).
В ваших утверждениях есть ряд ошибок:
1. «Debug».
Не нужно настраивать дебаг в IDE, пользуйтесь встроенным в Chrome отладчиком и отлаживайте прямо TS с включенными sourcemaps. Так правильнее, потому что IDE может потребоваться сменить, а браузер всегда и везде одинаков. По опыту, опять же, удобнее и быстрее в браузере отлаживать.
2. «А вдруг умерет?»
Нет. Один из принципов TS — не расходиться с будущим JS. По факту TS просто имплементирует будущие возможности JS, позволяя уже сейчас их использовать в браузерах (даже Async/await). Т.е. если и умрет, то только вместе с JS.
В конце концов, можете помочь его популяризации: документация на github на русском.
fastwit
24.08.2016 11:57Выбор, обычно, стоит в том, чтобы либо писать на чистом JS, либо использовать более удобный язык, который можно транслировать в JS. Удобство языка — часто, основывается на субъективных предпочтениях. Поэтому, найдутся и те кто за, и те кто категорически против. Единственным критерием должен быть комфорт разработки. Как уже было упомянуто, C# разработчикам довольно-таки просто освоить TS, нежели CoffeeScript, например.
Итак, если мы решили писать не на чистом JS, который сейчас в основном ES5, то мы имеем выбор из технологий: Babel, TypeScript, CoffeeScript, Dart и что-то я точно забыл упомянуть… CoffeeScript и Dart синтаксически дальше от JS, поэтому, лично я бы не стал их использовать, разве что, они обладают какими-то исключительными возможностями, которые в конкретном проекте сэкономят трудозатраты и снизят риски. Остались Babel и TypeScript — сложный выбор. Однако, для себя, и тут я сам себе немного противоречу, я выбрал TypeScript, так как он не так завязан на JavaScript спецификации и может обзавестись «сахарком», который в ES6-7 еще даже не планируется.
На нескольких больших проектах, над которыми мне довелось поработать, при использовании TypeScript команда ощущала себя более продуктивной, чем с JS.serf
24.08.2016 13:21Остались Babel и TypeScript — сложный выбор.
Странно сравнивать Babel — инстурмент транслирования кода и TypeScript диалект ES. TypeScript сам по себе без всяких Babel может сделать вам ES5, некоторые даже используют TS вместо Babel для ES6 кода (не TS) потому что им больше нравится какой итоговый код он генерирует. Dart не полетел потому что новый синтаксис, сложнее порог вхождения и перспективы не очевидны опять же потому что это не насдстройка над JS. CoffeeScript d наiе время использовать глупо (для новых начинаний), потому что уже есть ES6.fastwit
24.08.2016 14:16+1Странно, что вы TypeScript не рассматриваете как инструмент транслирования TS кода в JS код. Если за общий знаменатель взять ES5, то что Babel занимающийся трансляцией кода из диалектов ES6 и ES7, что TypeScript занимающийся трансляцией некоего «диалекта ES» — инструменты одного порядка и сравнение вполне себе корректно. Dart не полетел в том числе, как вы правильно заметили, из-за того, что он не диалект ES. Но главная причина все же в том, что эта «армия js-разработчиков», как тут писали ниже, не осилила и не сформировала потребность в тотальном переходе на Dart. Очевидно, что на смену JS что-то прийдет. У нас были Java-applets, Flash, Silverlight, JavaFx — все это стремилось улучшить ситуацию с интерактивностью в вебе. Но будет ли Dart чем-то следующим — сомневаюсь, Google следовало бы для начала включить его в публичную сборку Хрома.
serf
24.08.2016 14:17TypeScript не рассматриваете как инструмент транслирования TS кода в JS код
Как раз рассматриваю, выше имел ввиду что TypeScript это боее чем просто транслятор и в этом случае нет большого смысла использовать Babel, а лучше взять TS плюс то что он дает в придачу.
Jaromir
24.08.2016 11:58Один существенный минус (справедливый и для CoffeScript). Если планируете развивать проект на гитхабе, количество желающих внести свою лепту будет ограничего знающими TypeScript. Армия js-разработчиков скорее всего пройдет мимо
fastwit
24.08.2016 12:26+5Этот существенный минус, я бы поставил под сомнение. Так как армия JS-разработчиков которых испугает TS — не внушает доверия, ES6-7 они тоже боятся? Важно же не количество, правда? Думаю, что заинтересованность в развитии проекта позволит вменяемому разработчику внести свой вклад. Знаю случаи, когда контрибьюторы изучили ЯП только для того, чтобы внести свою лепту в конкретный проект.
Jaromir
24.08.2016 14:28+2У меня дежавю. Пару лет назад читал такие же дифирамбы кофескриптеров про их язык. Так же предупреждал, что js-сообщество не будет вам помогать. И в ответ слышал то же самое: «Cами справимся. Нам не нужны неосиляторы божественного cs»
Starche
24.08.2016 15:34Хотите сказать что они были не правы? На мой взгляд кофескрипт умер не потому что что-то в нём было не так, а потому что перестал развиваться. В репозитории кофескрипта уже очень давно никто ничего не делал. А диалекту JS необходимо развиваться, потому что сам язык развивается.
В общем, если TS не забросят, как кофе, то всё будет с ним в порядке.
serf
24.08.2016 14:12-2Это не минус, это плюс. А армия JS разработиков пускай воюет себе с свой песочнице. Сообщество TypeScript и так достаточно сильное.
taujavarob
25.08.2016 01:27serf > А армия JS разработиков пускай воюет себе с свой песочнице. Сообщество TypeScript и так достаточно сильное.
Jaromir > Пару лет назад читал такие же дифирамбы кофескриптеров про их язык. Так же предупреждал, что js-сообщество не будет вам помогать. И в ответ слышал то же самое: «Cами справимся. Нам не нужны неосиляторы божественного cs»
Они решили наступить на те же грабли? — Смелые!serf
25.08.2016 01:29За TS стоит MS. Даже если MS отойдет от дел, то все равно останется сообщество которое уже успело войти в курс дел.
taujavarob
25.08.2016 16:25За TS стоит MS. Даже если MS отойдет от дел, то все равно останется сообщество которое уже успело войти в курс дел.
За coffeescript стоял Google. Да, осталось сообщество. Но на coffeescript уже ставок ни у кого нет.serf
25.08.2016 16:31-1Но на coffeescript уже ставок ни у кого нет.
Это очевидно. Coffeescript сыграл свою роль и появился хипстерский ES6. Когда-то может быть и TS сыграет подобную роль и в ECMAScript все таки появится типизация (в очень отдаленной перспективе судя по текущему положению дел). Так вот пока типов в ECMAScript нет (и не появится в скором времени) можно использвать TS. Или предлагаете сидеть на ES6 и ждать пока там появятся типы?taujavarob
25.08.2016 16:57Или предлагаете сидеть на ES6 и ждать пока там появятся типы?
Они не нужны.serf
25.08.2016 17:02-1Они не нужны.
И зачем тогда выше вообще было что-то писать про кофискрипт и приводить какие-то доводы если ваша позиция объясняется так просто.
taujavarob
25.08.2016 17:03+2И зачем тогда выше вообще было что-то писать про кофискрипт если ваша позиция объясняется так просто.
И ООП не нужно.serf
25.08.2016 17:06Точно, и мозги тогда уже не нужны. Я хоть и не сторонник использования ФП для серьзеных и больших проектов особенно когда команда разношерстная, но так категоричеки о ФП не высказываюсь. Оно нужно как мннимум чтобы покрасоваться какой я «функциональный» (даже если это идет в разрез с инженерными практиками и делает проект неподдерживаемым) и влепить что-то в блог.
taujavarob
25.08.2016 17:50Точно, и мозги тогда уже не нужны.
Вы можете иметь отличные мозги, но изначальный выбор модели(архитектуры, стиля) программирования может привести вас к не очевидным вначале трудностям и даже не осознаваемым теперь трудностям — типа, деды так делали, отцы так делали, и мы так будем делать.serf
25.08.2016 17:54типа, деды так делали, отцы так делали, и мы так будем делать.
Я работаю по обе стороны барикад, сейчас это называют фуллстек, и свой выбор делаю не на основе некой исторической сложившейся истины или хипстерского тренда, а на основе своего опыта тк я имел возможность сравнить различные подходы на практике.taujavarob
25.08.2016 18:09а на основе своего опыта тк я имел возможность сравнить различные подходы на практике.
Практика? Хм:
— Очистите html от js!
— Сделано.
— И тут бац — Angular!!!
— Очистите js от html!
— Сделано.
— И тут бац — React!!!
Хм, Практика.serf
25.08.2016 18:13Причем здесь фреймворки, речь шла о функциональщине против ООП с типизацией. Пишите свои глупости если хотите, но комментариев на них с моей стороны больше не будет.
taujavarob
25.08.2016 18:19+1речь шла о функциональщине против ООП с типизацией.
Вообще то всё началось с вопроса: нужны ли типы в js?
А пришли к вашей практике.
Но, о ней вы писать уже не будете.
Печально мне.
Jaromir
25.08.2016 19:31> Когда-то может быть и TS сыграет подобную роль и в ECMAScript все таки появится типизация
В питоне и ПХП появилась. И как, питонисты и ПХП-шники ее начали использовать? Мне правда интересно
sargonpiraev
24.08.2016 11:58+1Это интересный и серьёзный вопрос, потому как стандарты JS идут в ногу со временем и интегрируют в сам язык многое, что было полезно в TS: классы, стрелочные функции, и так далее.
Классы, стрелочные функции пришли в стандарт благодаря CoffeeScript. TypeScript появился позже. А что из TypeScript перейдет в стандарт? Типизация?jsfun
24.08.2016 11:59Согласен, перепроверил эту информацию — Вы правы. Могут перейти не только типы, но и Декораторы( типа Component, @Directive из ng2). Имеется ввиду сам функционал типа Декоратор.
jsfun
24.08.2016 12:21-1Точнее он и будет имплементирован в стандарте ES7
rock
24.08.2016 15:43+1ES2016 (ES7) был принят пару месяцев назад и там нет декораторов.
jsfun
24.08.2016 15:47По-крайней мере он планировался и был на рассмотрении — ES7 Decorators. К сожалению, не заглянул в официальные доки.
asci
24.08.2016 12:22Если у вас есть свободное время и вы хотите попробовать новый язык, попробуйте лучше Elm
raveclassic
25.08.2016 00:59Последнее время засел в него с головой. Проще, логичнее и лаконичнее TS. Некоторые архитектурные решения так вообще вызывают нескрываемый вау-эффект, хотя от react+redux+immutable в целом несильно отличаются. Выполнены просто элегантней.
Непонятно только как в прод это все протянуть, т.к. интероп с js ужасный (хоть и оправданный). Подумываю взять для начала для кусков логики, отвязанной от ui.raveclassic
25.08.2016 01:23Ну и основной затык — невозможность использования css-модулей, без которых, как мне кажется, если привыкнешь, то уже никуда.
Может, как-то это можно решить? Вроде есть какой-то пакет для описания стилей внутри elm, с последующей генерацией css, но мне это кажется таким же диким как и стили внутри jsx.
alexeyernest
24.08.2016 14:49-2Короче не стоит его изучать. В es6/es7 уже есть почти все, например декораторы в es7. Лучше сразу на стандарте писать, в последнее время за него очень серьезно взялись и JS самый популярный язык. Пробовать es7 можно уже и сейчас через траспилятор babel.
bromzh
24.08.2016 15:06+1Ну сколько можно говорить, что TS это по-сути и есть новейший стандарт ES. Можно писать обычный js-код, используя свежий синтаксис, а потом компилять не babel'ом, а TS. Только у последнего результат выглядит получше. Не нужны типы — не пиши.
raveclassic
25.08.2016 01:01Людям просто лень читать ветки комментариев, где это уже 50 раз разжевано.
Jaromir
24.08.2016 14:51+1> Строгая типизация
> Позволяет более полно описывать свойства и методы обьектов и классов, из-за чего пропадает необходимость, которая, лично меня, дико раздражала, делать проверку всех, входящих в метод или функцию, аргументов
Да простят меня боги разработки, но я никогда не проверял входящие аргументы функций. Валидации получаемых извне данных — вот это да, важно. Если во время разработки програмы она ломается из-за аргументов функций — значит я где-то накосячил в коде. Поправляю, иногда добавляю тест. А если что-то поломается в боевых условиях, TS уже не поможет, так как в браузере его нет
Вообще, строгая типизация прежде всего хороша для компилятора. Зная типы на этапе компеляции он может заоптимизировать машинный код вусмерть. Слабая типизация при всех ее недостатках имеет и массу достоинств. Например возможность писать обобщенные алгоритмы не зарываясь с головой в лес угловых скобок.bromzh
24.08.2016 15:00Слабая типизация при всех ее недостатках имеет и массу достоинств.
Опять спутали слабую и динамическую типизации. У слабой aka неявной типизации сплошные минусы.
Например возможность писать обобщенные алгоритмы не зарываясь с головой в лес угловых скобок.
Это не является отличительным свойством ни слабой, ни динамической типизаций.
Jaromir
24.08.2016 15:07> Опять спутали слабую и динамическую типизации
Почему думаете что перепутал?
> Это не является отличительным свойством ни слабой, ни динамической типизаций
Это является отличительным свойством TS от JSbromzh
24.08.2016 15:20Почему думаете что перепутал?
Потому что вы пишите "строгая типизация прежде всего хороша для компилятора." Однако, в питоне тоже строгая aka сильная типизация. Как и, главное, какому она помогает компилятору?
А вот в C, C++, JS и PHP слабая типизация. При этом, в C и C++ типизация ещё и статическая. И именно статическая, а не сильная, типизация помогает в оптимизации компилятору на этапе компиляции.
Это является отличительным свойством TS от JS
Нет, обобщённые алгоритмы без угловых скобок можно и на TS писать. Достаточно использовать тип any. Ещё можно поставить опцию компилятора noImplicitAny в значение false, чтобы явно не прописывать тип any.
f0rk
24.08.2016 15:37+1Почему думаете что перепутал?
Да потому что «слабость» или «сильность» типизации определяет только возможности по явному и неявному приведению типов.
Слабая — разрешает неявное приведение типов (как в js или Си например)
Что-то среднее — разрешает явное приведение типов (python например)
Сильная — не разрешает приведение типов (haskell)
А вы говорите о «статичности» типизации, она определяет сколько информации о типах имеется в самом исходнике. В статически типизированной программе информация о типах имеется до того как её запустили, и неважно, есть ли в исходниках явные сигнатуры или они были выведены автоматически. В динамически типизированной программе типы данных становятся известны только в рантайме.
Что касается «возможности писать обобщенные алгоритмы не зарываясь с головой в лес угловых скобок», не во всех языках полиморфные типы реализованы так стрёмно как в C++ и его наследниках.bromzh
24.08.2016 15:43Что-то среднее — разрешает явное приведение типов (python например)
Таки нет, в питоне всё не так.
Потому что при вызове "функций" str, list, dict и т.д. не происходит никакого приведения типов, на самом деле это просто вызов конструктора одноимённого класса (str, list, dict и т.д). И этот вызов возвращает новый объект, а не изменяет тип старого.f0rk
24.08.2016 15:47Ок, могу быть не прав, не питонист я :) В таком случае он тоже сильно типизированный, а в «что-то среднее» можно записать C++
nwalker
24.08.2016 15:08Кто в курсе, когда в TS планируют запилить свой компилятор async-await в таргет ES5?
serf
24.08.2016 16:08https://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).
triada63
24.08.2016 17:40-1Не хочу конечно показаться радикальным, но делать надстройки для работы с классами и типизацией на языке который изначально под это не был построен, мне кажется глупым. Я считаю что для этого нужен третий язык, именно для построения больших frontend проектов. Javascript же идеален в своей простоте, решение небольших задач выглядит красиво и работает быстро.
sentyaev
24.08.2016 17:52+3Я считаю что для этого нужен третий язык
Так бы и сделали, но… когда это появится в браузерах? Хочется же получить отдачу прямо сейчас, плюс получить совместимость со старыми браузерами.
Javascript же идеален в своей простоте, решение небольших задач выглядит красиво и работает быстро.
Вы правы, но не всем же маленькие проекты писать.
G-M-A-X
25.08.2016 09:48-1>Уверен, что портирование таких монстров, как jQuery, потребовало немало приседаний.
То есть он (TS) не совсем совместим с JS?
Чтобы все работало, это все должно быть на TS?
Нафиг такое нужно. :)
П.С. (Утверждения немного преувеличенные)
Что вы к нам (JS) приползли со своим TS. Создайте себе отдельный браузер. :)
Причина популярности JS — кажущаяся простота. Крутые перцы захотели писать на языке быдла, потому что быдло создало большую экосистему, которую перцы не смогли создать.sentyaev
25.08.2016 11:19уже писали в самом начале.
Видите ли, для каждой портированной либы необходимо описать .d.ts файл, в котором и хранятся все возвращаемые типы и описание всех методов.
Можно просто тип any использовать
declare var $: any;
taujavarob
25.08.2016 16:26Крутые перцы захотели писать на языке быдла, потому что быдло создало большую экосистему, которую перцы не смогли создать.
PHP?
k0t0vich
25.08.2016 14:00А может с haxe сравнить?
https://blog.onthewings.net/2015/08/05/typescript-vs-haxe/arvitaly
25.08.2016 15:52Вот было бы неплохо во все браузеры засунуть runtime всех подходящих языков и фреймворков, ну будет дистрибутив браузера на десять мегабайт больше, у всех примерно runtime в сжатом виде 200-300кб, это ж можно засунуть 50 крупняков. Потом, например в заголовках передавать Accept-Runtime, и битовую маску какую-нибудь, сколько это добавит к запросу, 20-30 байт. Зато каждому сайту не придется грузить react, и можно будет реально писать на удобном языке. Мне кажется это могло бы сильно изменить web, упростить написание сайтов и ускорить весь интернет в разы.
А всего-то достаточно уговорить Google, MS и Mozilla внедрить в дистрибутив это дело. Ведь webassembly этих проблем все равно не решит.
taujavarob
25.08.2016 16:21Мне кажется это могло бы сильно изменить web, упростить написание сайтов и ускорить весь интернет в разы.
Была. Плагинная система запуска runtime разных. (одни шли прямо с броузером, другие можно было доустановить) — отказались -> Дыра на дыре и дырой погоняли. Устали латать.
alibertino
25.08.2016 16:49Да, и отлично себя показала (flash). Просто работать плагины должны тоже в песочнице, грубо говоря сейчас это был бы просто набор JS-библиотек, а в будущем набор webassembly. И ничего латать не нужно.
taujavarob
25.08.2016 17:02Да, и отлично себя показала (flash).
Да, о "покойниках" либо хорошо… — Да, я вас понял.
hmspns
Можно просто тип any использовать
zartdinov
Верно, типизация в TypeScript опциональна и не причиняет больших не удобств, даже наоборот! )
Использовать часто any не совсем корректно. Обычно я быстренько описываю только используемые функции. Описания больших библиотек немного замедляют сборку, но все равно могут быть полезными в IDE.
TypeScript никак не конкурирует с JS, а развивает его, очень много крутых фишек, (которые возможно и были в спецификации!) быстрее реализовались в остальных компиляторах после того как были опробованы в TS.