Комментарии 21
Чувствуется русско-украинский язык :-)
Мысль сама по себе не нова. Чем плох coffee script?
В нем, как и в js, нет типизации.
CoffeeScript не плох. Просто он другой. Не каждому нравится его синтаксис. Лично мне CoffeeScript нравится за его лаконичность. Но нужно быть осторожным, уж очень много он позволяет.
Основная фишка TypeScript — статический анализ. В этом он чем-то похож на JSLint. Пока все эти декларации типов только для программиста, для IDE. Я уже привык к текстовым редакторам, но все-таки как же удобно было б с автокомплитом и проверкой типов.
Основная фишка TypeScript — статический анализ. В этом он чем-то похож на JSLint. Пока все эти декларации типов только для программиста, для IDE. Я уже привык к текстовым редакторам, но все-таки как же удобно было б с автокомплитом и проверкой типов.
Буквально сегодня я собрался с мыслями и впечатлениями от использования, и написал аналогичный пост: social.mirgames.ru/blog/html5/41.html
Отличная статья! Даже в стадии preview TypeScript — проект, заслуживающий внимания. Особенно мне понравилась видео-презентация, все по полочкам разложено.
>>> Многие разработчики уверены в том, что JavaScript — это язык, который совершенно не подходит для разработки больших проектов; что это медленный язык, опасный и в некоторой степени даже непредсказуемый.
После этого перестал читать.
После этого перестал читать.
Можно примерчик подобного проекта на JS?
В нестабильности виноват не JS, а разработчики, не знакомые с особенностями языка. По поводу медленности вообще глупости… Как может абстракция, транслируемая в какой-то язык, работать быстрее, чем код на изначальном языке… Согласен только по поводу непредсказуемости, и то она выражается в невнимательности разработчиков, которые, например, пропустили var и нагадили в глобальную область видимости.
То что на малых объемах незаметно, то на больших становится иногда правилом. Если в команде 1-2 разработчика это один вопрос, а если 50+ то вероятность попадания ошибки из-за невнимательности в сложном коде — 100%.
И по вопросу производительности, это с каких пор у нас процессоры умеют нативно выполнять JS?
И по вопросу производительности, это с каких пор у нас процессоры умеют нативно выполнять JS?
Как много проектов, JS-часть которых пишут 50+ разработчиков?
Причем тут процессоры, нативно исполняющие JS? JS достаточно высокоуровниевый и выполняется во всех браузерах, не вижу смысла в абстракциях. Поэтому вместо того, чем учить язык, результат работы над которым всё равно выльется в JS-код, лучше совершенствовать навыки в JS. А вот подобные ситуации случаются, когда backend-разработчики с java или с# добираются до frontend.
Причем тут процессоры, нативно исполняющие JS? JS достаточно высокоуровниевый и выполняется во всех браузерах, не вижу смысла в абстракциях. Поэтому вместо того, чем учить язык, результат работы над которым всё равно выльется в JS-код, лучше совершенствовать навыки в JS. А вот подобные ситуации случаются, когда backend-разработчики с java или с# добираются до frontend.
Ну мы вроде про большие проекты говорим?=) И о проблемах JS в больших проектах. Если у вас есть возможность оградить себя от части проблем, почему не использовать эту возможность?
JS — это не только frontend, это в том числе и backend, и whatever, а правильные абстракции уменьшают количество энтропии в системе. Ограничения, накладываемые языком, упрощают дальнейшую поддержку кода. Особенно в тех случаях, когда над кодом работают несколько групп людей, и каждый человек пытается придумать свой собственный подход. Именно для того, чтобы сосредоточиться на задаче, а не изобретать подходы, придумывают всевозможные DSL'и, максимально заточенные под конкретную предметную область.
Вам в любом случае потребуются какие-то инфраструктурные абстракции — возможно вы будете использовать какую-то систему наследования, вероятно будете придумывать систему модульности, и т.п. Преимущество TypeScript/CofeeScript в том, что они предоставляют уже готовое решение.
Ну и кроме того, TypeScript в основном добавляет лишь типизацию. Классы, свойства и интерфейсы — это часть draft'а ECMAScript 6. Можно ожидать, что скоро появится экспериментальная поддержка в браузерах :-)
Вам в любом случае потребуются какие-то инфраструктурные абстракции — возможно вы будете использовать какую-то систему наследования, вероятно будете придумывать систему модульности, и т.п. Преимущество TypeScript/CofeeScript в том, что они предоставляют уже готовое решение.
Ну и кроме того, TypeScript в основном добавляет лишь типизацию. Классы, свойства и интерфейсы — это часть draft'а ECMAScript 6. Можно ожидать, что скоро появится экспериментальная поддержка в браузерах :-)
Абстракция, которая транслируется в другой язык, не может работать быстрее этого языка. Я и не писал, что TypeScript — это серебряная пуля, которая к тому же летит быстрее JS, но так или иначе многие действительно уверены, что на JS сложно писать большие проекты, и этих людей весьма сложно переубедить. Сам я считаю, что если авторы JS кода грамотны, то и проблем никаких не возникнет (разве что из-за опечаток, а их неплохо отлавливает JSLint). Я сам ратую за то, что JS — прекрасный и недооцененный язык.
P.S. Согласен, предложение кривовато: язык не может быть быстрым или медленным.
P.S. Согласен, предложение кривовато: язык не может быть быстрым или медленным.
Такая отличная статья скрыта от посетителей хабра, которые не читают комментарии :(
Спасибо, интересно, но вот тут: " Синтаксис TypeScript — подмножество синтаксиса EcmaScript 5 (ES5) " я бы рекомендовал подправить (superset — надмножество или, более по-русски, надстройка или расширение… по ряду пунктов совместимое с проектом стандарта EcmaScript 6, но выходящее за его пределы).
И что хорошо — практически мгновенная (пока) реакция на баг-репорты.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
TypeScript: статический анализ, автодополнение и немножко ES6 для JavaScript