Comments 61
Если вы не согласны с автором, то почему?
Вроде он высказал тезисы, которые сложно оспорить:
Не считая других, о которых мне сложно судить.
Вроде он высказал тезисы, которые сложно оспорить:
- TypeScript не управляется сообществом
- TypeScript имеет плохую совместимость с JavaScript библиотеками
- Рано или поздно поддержка типов будет в JavaScript и тогда TypeScript окажется никому не нужным.
Не считая других, о которых мне сложно судить.
Рано или поздно поддержка типов будет в JavaScript и тогда TypeScript окажется никому не нужным.
Как отмечает Austin "Все что нужно будет сделать – это исправить синтаксис с помощью поиска и замены", так вот когда появятся типы в ECMAScript тогда можно будет применить его волшебную "автозамену" :) Вообще не видно чтобы они там планиовалии типы в своих стандартах, так что ждать их появления в стандарте придется долго, не говоря уже о появлении в бразерах, а с TypeScript уже сейчас можно писать как принято говорить maintainable и scalable приложения.
Я могу оспорить ваши цитаты из перевода.
TypeScript не управляется сообществом
Вы имеете уникальную возможность пойти и прямо сейчас внести свой посильный вклад в развитие данной технологии. Путь начинается отсюда.TypeScript имеет плохую совместимость с JavaScript библиотеками
ts это надмножество js, следовательно, вы можете просто скопировать рабочее решение и использовать в ts — работать оно будет идентично. Если вам нужно чуть больше безопасности — на помощь придет tsd. Если оно устарело, чего-то не хватает, то вы можете сами это исправить и помочь другим.Рано или поздно поддержка типов будет в JavaScript и тогда TypeScript окажется никому не нужным.
Если бы вы следили за развитием языка, то увидели бы что он не вносит чего-то такого, что ломает концепции (как CoffeeScript, к примеру) — язык развивается последовательно. И я так может стать, что обещанная вами поддержка типов в js будет идентичной ts. Тогда все заиграет другими красками.
ts это надмножество js, следовательно, вы можете просто скопировать рабочее решение и использовать в ts — работать оно будет идентично
можно про этот момент поподробнее (я без стеба). не силен в typescript, только погружаюсь, уже несколько раз сталкивался с этим утверждением и все никак не вкурю — как можно безболезненно подкрутить ванильный js к typescript проекту? по любому как минимум тайпинг писать ведь придется?
typescript это superset js, так что любой уже написанный js будет изначально являтся валидным typescript кодом. С 1.8 версии добавился флаг --allowJs, в таком случае даже переименовывать файлы не нужно будет (то есть можно переводить на ts постепенно, но при этом собирая все в один бандл).
UFO just landed and posted this here
ts это надмножество js, следовательно, вы можете просто скопировать рабочее решение и использовать в ts — работать оно будет идентично. Если вам нужно чуть больше безопасности — на помощь придет tsd. Если оно устарело, чего-то не хватает, то вы можете сами это исправить и помочь другим.
А автор говорит, что для каждого подключенного файла в проект нужен tsd. Он не прав?
ts это надмножество js, следовательно, вы можете просто скопировать рабочее решение и использовать в ts — работать оно будет идентично.
Это из Вашего личного опыта следует или из праздничных деклараций евангелистов TypeScript? А вот мой личный опыт убеждает меня в том, что утверждение не совсем верно. Работающий код tsc может не скомпилировать, собственно, из-за несоответствия типов. И это не всегда ошибочный код, просто JavaScript более гибкий.
Потому что аргументы его субъективны.
1. «Не управляется сообществом» не означает автоматического fail: есть масса примеров, когда «управляемые сообществами» проекты загибались и наоборот, с ног до головы проприеритарные языки вполне торт.
2. Есть dts для популярных библиотек, совершенно не проблема написать свой, если совсем невмоготу: thirdPartyCompanent: any и дальше в старом добром js стиле.
3. Рано или поздно будут и яблони на Марсе, но что мне делать конкретно здесь и сейчас? TS ИМХО появился именно потому, что очень уж отдалённое это «рано или поздно» и вообще непонятно наступит ли.
Ну и еще пара вещей: «TypeScript доступен с 2012 года!!! Я считаю, что его популярность – это целиком и полностью заслуга Angular2» — а не наоборот: он настолько зрелый, удобный и популярный, что даже Google выбрал TS для разработки(не pure js, не свой собственный Darth, а ts oт Майкрософта. От богомерзкого Майкрософта, Карл)?
P.S. Пример Flash, как «провалившейся» технологии… 20 лет в интернете, фактически монополист в своей нише, до сих пор не могут выпилить… Если это «провал», что что же такое «успех»?
1. «Не управляется сообществом» не означает автоматического fail: есть масса примеров, когда «управляемые сообществами» проекты загибались и наоборот, с ног до головы проприеритарные языки вполне торт.
2. Есть dts для популярных библиотек, совершенно не проблема написать свой, если совсем невмоготу: thirdPartyCompanent: any и дальше в старом добром js стиле.
3. Рано или поздно будут и яблони на Марсе, но что мне делать конкретно здесь и сейчас? TS ИМХО появился именно потому, что очень уж отдалённое это «рано или поздно» и вообще непонятно наступит ли.
Ну и еще пара вещей: «TypeScript доступен с 2012 года!!! Я считаю, что его популярность – это целиком и полностью заслуга Angular2» — а не наоборот: он настолько зрелый, удобный и популярный, что даже Google выбрал TS для разработки(не pure js, не свой собственный Darth, а ts oт Майкрософта. От богомерзкого Майкрософта, Карл)?
P.S. Пример Flash, как «провалившейся» технологии… 20 лет в интернете, фактически монополист в своей нише, до сих пор не могут выпилить… Если это «провал», что что же такое «успех»?
TypeScript не управляется сообществом
Поддержка tsx (typescript and xml, аналог facebook'овского jsx для react с типами) была написана сообществом, после упорных доработок была включена в компилятор и уже полгода как доступна в Visual Studio. Официально. Говорить при этом, что TypeScript не управляется сообществом, мне кажется совершенно некорректно.
Если это популярная библиотека, то для нее, скорее всего, уже будет написан TSD. А если нет – то его придется писать вам. Или подменять все ее глобальные идентификаторы. Больше работы, больше головной боли, и с этим ничего нельзя поделать.
Для серьезного долгосрочного проекта однократное написание TSD не стоит ничего, к тому же количество добаляемых в проект библиотек обычно довольно ограничено и в первую очередь будут выбираться "взрослые" библиотеки для которыз TSD уже готовы. Полагаю этот Austin работает с серьезными проектами, но тогда мне не понятно зачем притягивать за уши подобные доводы.
Вот никак не могу понять как правильно написать d.ts для moment / jquery плагина, если в качестве менеджера тайпингов у меня
Пол дня уже долблюсь. Среди уже опубликованных тайпингов подходящего примера не нашлось.
typings.Пол дня уже долблюсь. Среди уже опубликованных тайпингов подходящего примера не нашлось.
То что мне надо описано в разделе Module Augmentation.
Вот только проблема, что я не могу написать
Вот только проблема, что я не могу написать
Scale.prototype.advancedMethod = /* insert implementation */; в t.sd файлеЯ считаю, что его популярность – это целиком и полностью заслуга Angular2.
Ох-ей. Как голословно-то. Angular2 появился не так уж и давно, что ставит под сомнение такие вот голословные высказывания.
Порой мне кажется, что сама Microsoft приплачивает таким вот хейтерам, чтобы язык был у всех на виду :)
Посмотрел LInkedin профиль этого Austin, вроде опытный человек (хотя не все опытыне являются инженерами), а пишет какую-то желтизну, как будто заказали ему этот пост или просто решил трафика/внимания привлечь к себе.
Typescript – это то, как, по мнению Microsoft, должен выглядеть JavaScript. У таких технологий, которые противопоставляют себя открытым / open source проектам есть одна закономерность. Они обычно проваливаются. Навскидку: Flash, Silverlight, CoffeeScript.
Что-то я не понял. И Typescript и CoffeScript являются open source.
TypeScript поддерживает компиляцию только для ES3/ES5/ES6. При этом nodejs 5.x только частично поддерживает ES6, так что при использовании TypeScript мы зависаем в непонятном “промежуточном состоянии”.Автор оригинала что, не догадался выстроить два транслятора в цепочку? :)
Решение же очевидно — сначала компилируем ts в es6, потом компилируем es6 в совместимый с nodejs 5.x код.
Компилирую из TypeScript в ES6, проблем с Node.js 5 не имею. Единственное, что нужно делать, это задавать опцию module: commonjs.
а что мешает компилировать в ES5 и запускать на ноде 5.x?
Поддерживаю выше недоумение! Сам компилирую цепочкой TypeScript (target ES6) -> Babel (куча настроенных presets) -> получаем ES5
скомпилируется из ts в es6?
Тут надо аналог babel для ts исходника :)
let { a, b, ...rest } = propsТут надо аналог babel для ts исходника :)
Насчёт типов… в Lua появился тип int в последней версии (5.3). В Python вводят возможность типизирования по желанию, насколько я знаю. Есть ещё mypy.
Короче, интересный тренд намечается.
Короче, интересный тренд намечается.
Возможность типизирования звучит странно. У питона и так строгая система типов, строку с числом вы сложить не сможете. Другой вопрос, если вводят опциональную статическую типизацию.
Что-то всё в кучу смешалось...
В lua есть такие базовые типы: nil, boolean, number, string, function, userdata, thread, table.
Просто до 5.3 все числа были с плавающей точкой. Нынче же тип number имеет 2 "подтипа" (вернее сказать, 2 реализации). Т.е. переменная, содержащая число, может быть в одном из 2-х внутренних представлений: либо float (как раньше), либо integer (вот это нововведение). Но это сделали только для оптимизаций. Т.е. в синтаксисе нет абсолютно никаких изменений, изменились только внутренние алгоритмы. Да и вообще, луа чаще всего используется как простой встраиваемый язык, так что статическая типизация в ней вряд ли появится.
Конечно нет.
Короче, в PEP крайне рекомендуют использовать эти фичи только на этапе анализа исходников, с целью упростить его.
Если более подробно:
Исторически в мире питона принято писать доки (в том числе и docstrings) в формате reStructuredText. Ну и там сложились некоторые договорённости об указании типов аргументов функции и возвращаемых значений. Со временем ИДЕшки научились парсить docstrings и выводить типы оттуда.
Потом добавили аннотации для функций (PEP-3107). По-сути, это просто доп. информация об аргументах функции и её возвращаемых значениях.
К версии 3.5 сообразили, что определения типов лучше бы добавить в стандарт, дабы юзеры не начали плодить кучу несовместимых форматов для описания типов.
В итоге, это не опциональная статическая типизация, хотя и выглядит похоже. Питон всё тот же язык с динамической типизацией. Например, можно объявить, что функция вернёт число, а в самой функции возвращать строку. Никаких ошибок интерпритатор не выдаст. В рамках самого python в принципе можно сделать некую простейшую проверку на правильность передаваемых и возвращаемых типов у функций (например, тривиально с помощью декораторов). Однако это будет только в рантайме и на деле будет просто кучей if-ов с вызовом isinstance(...). Т.е. никакой опциональной типизацией не пахнет.
TypeScript же — это не JS, а другой язык, который в JS компилируется. И проверки типов там есть только на стадии компиляции. Т.е. по-сути, это "надстройка" над языком (ну и плюс ещё некоторые фичи из ES будущего).
Но, используя PEP-0484 и PEP-3107, можно попытаться сделать что-то на подобии TypeScript для питона. Плюс питона тут в том, что не нужно будет менять текст исходных файлов и итоговых, так как синтаксис уже в стандарте и он не влияет на поведение кода (естественно, если мы сами что-то не добавим). Минус в том, что нужен будет довольно мощный анализатор кода. Зато, если будет готов такой анализатор, то останется дождаться, пока PyPy подружится с веткой 3.5. Тогда можно будет довольно сильно поднять производительность языка (ну или можно взять Julia уже сегодня).
в Lua появился тип int
В lua есть такие базовые типы: nil, boolean, number, string, function, userdata, thread, table.
Просто до 5.3 все числа были с плавающей точкой. Нынче же тип number имеет 2 "подтипа" (вернее сказать, 2 реализации). Т.е. переменная, содержащая число, может быть в одном из 2-х внутренних представлений: либо float (как раньше), либо integer (вот это нововведение). Но это сделали только для оптимизаций. Т.е. в синтаксисе нет абсолютно никаких изменений, изменились только внутренние алгоритмы. Да и вообще, луа чаще всего используется как простой встраиваемый язык, так что статическая типизация в ней вряд ли появится.
В Python вводят возможность типизирования по желанию
Конечно нет.
Цитата из PEP-0484
Python will remain a dynamically typed language, and the authors have no desire to ever make type hints mandatory, even by convention.
Короче, в PEP крайне рекомендуют использовать эти фичи только на этапе анализа исходников, с целью упростить его.
Если более подробно:
Исторически в мире питона принято писать доки (в том числе и docstrings) в формате reStructuredText. Ну и там сложились некоторые договорённости об указании типов аргументов функции и возвращаемых значений. Со временем ИДЕшки научились парсить docstrings и выводить типы оттуда.
Потом добавили аннотации для функций (PEP-3107). По-сути, это просто доп. информация об аргументах функции и её возвращаемых значениях.
К версии 3.5 сообразили, что определения типов лучше бы добавить в стандарт, дабы юзеры не начали плодить кучу несовместимых форматов для описания типов.
В итоге, это не опциональная статическая типизация, хотя и выглядит похоже. Питон всё тот же язык с динамической типизацией. Например, можно объявить, что функция вернёт число, а в самой функции возвращать строку. Никаких ошибок интерпритатор не выдаст. В рамках самого python в принципе можно сделать некую простейшую проверку на правильность передаваемых и возвращаемых типов у функций (например, тривиально с помощью декораторов). Однако это будет только в рантайме и на деле будет просто кучей if-ов с вызовом isinstance(...). Т.е. никакой опциональной типизацией не пахнет.
TypeScript же — это не JS, а другой язык, который в JS компилируется. И проверки типов там есть только на стадии компиляции. Т.е. по-сути, это "надстройка" над языком (ну и плюс ещё некоторые фичи из ES будущего).
Но, используя PEP-0484 и PEP-3107, можно попытаться сделать что-то на подобии TypeScript для питона. Плюс питона тут в том, что не нужно будет менять текст исходных файлов и итоговых, так как синтаксис уже в стандарте и он не влияет на поведение кода (естественно, если мы сами что-то не добавим). Минус в том, что нужен будет довольно мощный анализатор кода. Зато, если будет готов такой анализатор, то останется дождаться, пока PyPy подружится с веткой 3.5. Тогда можно будет довольно сильно поднять производительность языка (ну или можно взять Julia уже сегодня).
У меня Javascript с ароматом ванили.
Твои типы опять не туда угодили.
Твои типы опять не туда угодили.
Ожидал увидеть аргументированную позицию, вместо этого набор клеше. Коротко по основным пунктам.
3 года в мире frontend — это очень даже приличный срок на самом деле, даже если не брать в голову, что цифра взята невесть откуда. А вообще это сродни спору об использованию фреймворков, они как правило исчезают/заменяются гораздо быстрее и часто замена не масштабируется на сколько нибудь большой проект, но что-то я не вижу падаения спроса на них.
Имхо, замечательная закономерность, что авторы придерживаются стандартов.
Angular2 и не вышел-то еще толком и неясно еще как выстрелит, а автор приписываею ему заслугу популярности TS. Мне почему-то кажется, что ребята из Angular отказались от своего велосипеда в пользу TS как раз из-за его популярности и скожести идей.
Субъективно, конечно, но для меня показательно количество обсуждения и оперативная реакция на issues в сообществе на гитхабе.
Было бы здорово посмотреть на конкретные примеры, которые автор имеет в виду.
Сейчас TS позволяет использовать некоторые фичы ES7, а полная поддержка ожидается после того как устаканется ES7.
Это точно проблема TS или характерная черта любого транспилятора? Ну и sourcemaps никто не отменял.
Ответили выше.
Остается загадкой, что автор понимает под stage-0. Но вот здесь есть подробный роадмап того, что уже есть и что планируется.
В этом с автором согласен, мигрировать старый проект, который ничего не знает о типах, на типизированый скорее всего будет сильно веселой задачей. Но если автор пробовал миграцию старого проекта на ES6, то знает, что эта задача тоже сильно не уступает в веселости.
cпорю на что угодно, что через 3 года JavaScript все еще будет здесь. А вот про TypeScript я такое сказать, увы, не могу.
3 года в мире frontend — это очень даже приличный срок на самом деле, даже если не брать в голову, что цифра взята невесть откуда. А вообще это сродни спору об использованию фреймворков, они как правило исчезают/заменяются гораздо быстрее и часто замена не масштабируется на сколько нибудь большой проект, но что-то я не вижу падаения спроса на них.
Обратите внимание, что TypeScript раньше имел свой собственный синтаксис работы с модулями. А потом вышел ES6 и теперь разработчики TypeScript предлагают всем переходить на новый синтаксис. Чувствуете закономерность?
Имхо, замечательная закономерность, что авторы придерживаются стандартов.
Я считаю, что его популярность – это целиком и полностью заслуга Angular2.
Angular2 и не вышел-то еще толком и неясно еще как выстрелит, а автор приписываею ему заслугу популярности TS. Мне почему-то кажется, что ребята из Angular отказались от своего велосипеда в пользу TS как раз из-за его популярности и скожести идей.
Я не вижу сильного вовлечения сообщества в работе над спецификацией, грамматикой, языком.
Субъективно, конечно, но для меня показательно количество обсуждения и оперативная реакция на issues в сообществе на гитхабе.
По моим ощущениям, TypeScript ставит типы впереди JavaScript.
Было бы здорово посмотреть на конкретные примеры, которые автор имеет в виду.
TypeScript поддерживает компиляцию только для ES3/ES5/ES6.
Сейчас TS позволяет использовать некоторые фичы ES7, а полная поддержка ожидается после того как устаканется ES7.
А если компилировать в ES5 то получается много polyfills, которые сложно отлаживать.
Это точно проблема TS или характерная черта любого транспилятора? Ну и sourcemaps никто не отменял.
Три буквы: TSD
Ответили выше.
Так что, начав использовать TypeScript, я ожидал увидеть уже привычные “stage-1” и “stage-0” вещи из ES6.
Остается загадкой, что автор понимает под stage-0. Но вот здесь есть подробный роадмап того, что уже есть и что планируется.
Что превращает миграцию на TypeScript в непростую задачу.
В этом с автором согласен, мигрировать старый проект, который ничего не знает о типах, на типизированый скорее всего будет сильно веселой задачей. Но если автор пробовал миграцию старого проекта на ES6, то знает, что эта задача тоже сильно не уступает в веселости.
Но если автор пробовал миграцию старого проекта на ES6, то знает, что эта задача тоже сильно не уступает в веселости.
Я вообще считаю мигрировать на ES6 нет большого смыслы, ну станет год более "сахарным", но все фундаментальные проблемы то все равно останутся на месте, чего не скажешь о TypeScript.
cпорю на что угодно, что через 3 года JavaScript все еще будет здесь. А вот про TypeScript я такое сказать, увы, не могу
Это довольно серьезный аргумент для проектов которые собираются жить долго. Но насколько я понимаю typescript производит достаточно близкий код в javascript, так что если вдруг TypeScript ушел с горизонта транслируете все в js и сохраняете в репозитории. Признаюсь правда что сам на ts ничего не писал, рассказываю из того что о нем прочитал/просмотрел.
TypeScript весь фан убивает, как будто на Java пишешь. На больших проектах оно, говорят, помогает, но для себя я никакого смысла им пользоваться не вижу. Если уж хочется безопасности, то лучше ELM за вымя потрогать, он куда более изящный и концептуальный.
Статья в целом очень слаба, но вот это мне особенно понравилось:
Еще через пару недель его зацепит TypeScript и он напишет хвалебную статью?
Также следует учесть, что у меня всего 3 недели опыта его практического использования
Babel — *****! Если бы вы спросили меня год назад, буду ли я использовать транспайлер, я бы посчитал вас за сумасшедшего. Sourcemap, gulp/grunt/watch/build/итд звучали для меня каким-то кошмаром. А потом раз – и зацепило.
Еще через пару недель его зацепит TypeScript и он напишет хвалебную статью?
Если WebAssembly всё же взлетит, JS может ждать весьма печальное будущее.
Сейчас многие пользуются им лишь потому, что нет реальной альтернативы. А когда станет можно писать фронтэнд на любом языке, под который только создан компилятор, и начнут появляться всевозможные Java for Web, C++Web, WebHaskell и им подобные, JS может и вовсе скончаться.
Сейчас многие пользуются им лишь потому, что нет реальной альтернативы. А когда станет можно писать фронтэнд на любом языке, под который только создан компилятор, и начнут появляться всевозможные Java for Web, C++Web, WebHaskell и им подобные, JS может и вовсе скончаться.
Мы 20 лет обходились без статической типизации и не страдали. Почему вдруг это стало такой проблемой?
Потому что на дворе 2016 год, и на JS'е пишутся уже не только всякие менюшечки и слайдбарчики, но и крупные приложения.
Поэтому typescript захватил аж 0,03% рынка?
А как они это считают очень интересно было бы узнать. В случае с TypeScript вообще нельзя 100% определить, js писался «руками» или его компилятор выдал. И это в случае если у вас есть исходник, а не минифицированый бандл, там вообще о том, кто и как его писал сказать можно примерно ничего.
По поводу «почему это вдруг стало» — так оно совсем не вдруг. Вот вам списочек(когда я заглядывал туда последний раз года два назад там было около 200 наименований). За редким исключением всё это попытки как-то решить эту внезапную проблему на самых разных уровнях.
https://github.com/jashkenas/coffeescript/wiki/list-of-languages-that-compile-to-js
По поводу «почему это вдруг стало» — так оно совсем не вдруг. Вот вам списочек(когда я заглядывал туда последний раз года два назад там было около 200 наименований). За редким исключением всё это попытки как-то решить эту внезапную проблему на самых разных уровнях.
https://github.com/jashkenas/coffeescript/wiki/list-of-languages-that-compile-to-js
Они считают через публичное API.
Когда CSS стал сложным, появились LESS и SASS. Сейчас они вместе занимают больше 25% рынка.
Когда JS стал сложным, появились Backbone, Ember, Knockout и Angular. А TypeScript занял свои достойные 0,03%.
Когда CSS стал сложным, появились LESS и SASS. Сейчас они вместе занимают больше 25% рынка.
Когда JS стал сложным, появились Backbone, Ember, Knockout и Angular. А TypeScript занял свои достойные 0,03%.
Это что-то типа опроса, когда кто хочет тот и сообщает? Всё ясно, спасибо. Это типа «100% программ пишутся на Java, по результатам опроса через публичное API на сайте По данным опроса на java.com».
>Когда JS стал сложным, появились Backbone, Ember, Knockout и Angular.
Это просто библиотеки, при чём тут они к разговору? Тем более Angular, который видимо задолбались писать на pure js и таки начаи пилить в TS.
Вы пройдите по ссылке и увидите огромное разнообразие костылей: там и «пишем на C#/Java/… и перегоняем всё в js» и тонны специально придуманых языков TypeScript/CofeScript/Darth/… от груп энтузиастов до гигантов типа Google/MS.
Это всё попытки борьбы со сложностью, полытки переложить часть проверок на компилятор, игнорировать этот факт довольно глупо.
>Когда JS стал сложным, появились Backbone, Ember, Knockout и Angular.
Это просто библиотеки, при чём тут они к разговору? Тем более Angular, который видимо задолбались писать на pure js и таки начаи пилить в TS.
Вы пройдите по ссылке и увидите огромное разнообразие костылей: там и «пишем на C#/Java/… и перегоняем всё в js» и тонны специально придуманых языков TypeScript/CofeScript/Darth/… от груп энтузиастов до гигантов типа Google/MS.
Это всё попытки борьбы со сложностью, полытки переложить часть проверок на компилятор, игнорировать этот факт довольно глупо.
Когда CSS стал сложным, появились LESS и SASS. Сейчас они вместе занимают больше 25% рынка.
Всё наоборот, LESS, SASS, Stylus появились из-за того, что CSS слишком примитивный (сейчас по лучше).
В JS мир ринулось куча Java/C#/C++ разработчиков и начали страдать.
Согласен на счёт FlowType, действительно как-то ненавязчиво он типы добавляет, указал тип — проверяет, не указал — пытается как-то его вывести и если уж возникает, то очень редко и действительно по делу. С typescript приходиться пол дня разбираться как его так настроить, что бы он уткнулся и не лез там где его не просят. Причём совсем утыкаться он всё же не хочет и кучу any всё равно приходиться добавлять. FlowType ещё долго до ума доводить (typescript тут всё же сильно впереди), но основа у него явно поудачней будет.
Стиль изложения стартапщика из силиконовой долины, который под колесами после 16 часов непрерывной работы. Очередная вода с провокационным названием типа "Да, Детка, Typescript — Это Отстой". Автор пописав чего-то там на TS под node и Angular2 делает выводы по поводу языка вообще.
Мне в целом нравится TypeScript, но я считаю его нишевой штукой. Кмк, его стихия — это крупные, долгосрочные проекты. Там где некоторая дополнительная громоздкость и лишний элемент в технологическом стеке — разумная плата за упорядоченность. Массовый рынок он не захватит. Но и не загнется, а отъест несколько процентов в своем сегменте (если говорить об обозримой перспективе — что будет через 10+ лет, не знает никто).
Я начинал писать с Паскаля, где строгая типизация, не пошло, скатился в Бейсик :)
Потом был Делфи, надстройка над Паскалем, с такой же строгой типизацией. Использовал пару лет, достало, ушел в ПХП.
С ПХП перешел на ДжаваСкрипт. И тут, и там нету никакой типизации. И это очень хорошо!!!
Совсем не понимаю к чему ДжС типизация. Ну, зачем? Хотите быть уверенными в собственном коде? Пишите тесты/спеки. А часть по сути тестов засовывать в код — нехорошо.
Потом был Делфи, надстройка над Паскалем, с такой же строгой типизацией. Использовал пару лет, достало, ушел в ПХП.
С ПХП перешел на ДжаваСкрипт. И тут, и там нету никакой типизации. И это очень хорошо!!!
Совсем не понимаю к чему ДжС типизация. Ну, зачем? Хотите быть уверенными в собственном коде? Пишите тесты/спеки. А часть по сути тестов засовывать в код — нехорошо.
Sign up to leave a comment.
Почему я НЕ являюсь фанатом TypeScript