Хабр Курсы для всех
РЕКЛАМА
Большая витрина: от крупнейших школ до частных авторов. Сравнивайте по цене, длительности, формату и выбирайте самый подходящий курс!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 18
Меня в web-девелопменте, равно как и в javascript, поражает одна простая вещь — средства разработки и отладки «не успевают» не только за фреймворками, но и за средствами самого языка.
Кто-нибудь видел полностью «зеленый» js\html\css-файл в том же Webstorm? Я — нет, но может у меня просто проекты такие неправильные были. Порой приходится прикладывать какие-то воистину титанические усилия для того, чтобы сделать какую-то сравнительно элементарную вещь. В такие моменты с какой-то особенной грустью вспоминается ctrl+space в дельфях\билдере\шарпах\чёмугодно, умеющий раскрывать структуру классов, понимающий область видимости, пространства имён и кучу других банальных штук.
Все эти event-driven паттерны — это, безусловно, круто, и какой-то определенный кайф в эмуляции ООП поверх prototype тоже есть. Есть ощущение того, что JS можно завязать каким угодно узлом, и оно всё равно будет работать. В итоге большинство HTML+JS-приложений представляют из себя набор таких «узлов». Потом выясняется, что в IE версии N+1 это не работает, и наступает какая-то чернейшая безудержная печаль.
При этом основной рост сложности происходит из-за того, что «нативно» на однопоточной событийной парадигме javascript сделать что-то толковое довольно проблематично, а свести задачу к линейному последовательному выполнению без жуткого количества спагетти-кода стандартными средствами языка попросту невозможно.
А потом приходится героически сражаться с невменяемой сложностью отладки. Останется только разобраться с интеграцией фреймворков, и можно снова изобретать себе грабли, на этот раз с маскировкой и утяжеленной ручкой.
Кто-нибудь видел полностью «зеленый» js\html\css-файл в том же Webstorm? Я — нет, но может у меня просто проекты такие неправильные были. Порой приходится прикладывать какие-то воистину титанические усилия для того, чтобы сделать какую-то сравнительно элементарную вещь. В такие моменты с какой-то особенной грустью вспоминается ctrl+space в дельфях\билдере\шарпах\чёмугодно, умеющий раскрывать структуру классов, понимающий область видимости, пространства имён и кучу других банальных штук.
Все эти event-driven паттерны — это, безусловно, круто, и какой-то определенный кайф в эмуляции ООП поверх prototype тоже есть. Есть ощущение того, что JS можно завязать каким угодно узлом, и оно всё равно будет работать. В итоге большинство HTML+JS-приложений представляют из себя набор таких «узлов». Потом выясняется, что в IE версии N+1 это не работает, и наступает какая-то чернейшая безудержная печаль.
При этом основной рост сложности происходит из-за того, что «нативно» на однопоточной событийной парадигме javascript сделать что-то толковое довольно проблематично, а свести задачу к линейному последовательному выполнению без жуткого количества спагетти-кода стандартными средствами языка попросту невозможно.
А потом приходится героически сражаться с невменяемой сложностью отладки. Останется только разобраться с интеграцией фреймворков, и можно снова изобретать себе грабли, на этот раз с маскировкой и утяжеленной ручкой.
Понимаю, завтра понедельник, накипело и еще пятничные проблемы. Но js(node.js) для меня стал вторым языком по удобству и первым по пониманию, что происходит, вслед за руби.
Warning: В этом тексте используются callbacks и [call, apply] с передачей контекста.
Warning: В этом тексте используются callbacks и [call, apply] с передачей контекста.
У нас практически все файлы javascript «зеленые», другие просто code review не проходят:
И подсказки IDE вполне себе информативные — чтобы WebStorm было проще, пишите jsdoc ко всему. Это, кстати, поможет и вам, когда вернетесь к коду через месяц-другой.
Мне кажется, вполне можно сказать, что «большинство плохо написанных программ представляют собой код, завязанный разными непонятными узлами». Тут, я думаю, не в web-технологиях проблема.
Разбивайте код на модули, если совсем тяжело с асинхронностью — используйте «обещания», и не будет спагетти.
Ну и современные средства отладки javascript — это не alert, как когда-то, я бы не стал говорить о «невменяемой сложности».
И подсказки IDE вполне себе информативные — чтобы WebStorm было проще, пишите jsdoc ко всему. Это, кстати, поможет и вам, когда вернетесь к коду через месяц-другой.
Мне кажется, вполне можно сказать, что «большинство плохо написанных программ представляют собой код, завязанный разными непонятными узлами». Тут, я думаю, не в web-технологиях проблема.
Разбивайте код на модули, если совсем тяжело с асинхронностью — используйте «обещания», и не будет спагетти.
Ну и современные средства отладки javascript — это не alert, как когда-то, я бы не стал говорить о «невменяемой сложности».
Я согласен с asavin, при правильном подходе всё замечательно работает, это зависит лишь от навыков программистов. Я так понимаю, что вам ближе идеи тех языков, с которых вы начинали программировать, и их парадигмы программирования. Однако, не все начинали писать с Delphi или C. Лично я начинал с PHP, после которого начал заниматься JavaScript, и мне привычно то, что для вас кажется странным.
Но что касается сложности отладки, то на мой взгляд, предмет этой статьи — это тот недостающий кирпичик, которого нехватало JavaScript для полного отказа от разных корявых решений типа console.log и alert.
Но что касается сложности отладки, то на мой взгляд, предмет этой статьи — это тот недостающий кирпичик, которого нехватало JavaScript для полного отказа от разных корявых решений типа console.log и alert.
Ну как вам сказать) Да, видел) Более того — стараюсь вновь создаваемые модули специально доводить до зелёного состояния, если они почему-то вдруг пожелтели ;-)
Я нашел для себя некоторое спасение в TypeScript. В нём можно не терять зеленость даже на весьма мудреном коде и получить обратно все преимущества IDE (и в WebStorm он есть, да).
Ну не знаю, мне кажется довольно странной идея превращения динмически типизированного языка в статический(или около того).
А за «зеленость», я считаю, должны отвечать тесты.
А за «зеленость», я считаю, должны отвечать тесты.
А вы видели, как именно там достигается это превращение? Я был несказанно удивлен, что типизация TS вообще не ограничивает возможностей. В конце концов, если надо, можно задать тип
И там еще куча более хитрых возможностей описать возможные типы или структуру переменных, которые, к сожалению, не очень хорошо описаны в мануалах (типа, стандарт вам в помощь, ага).
Все это даёт возможность описать даже ожидаемый результат из API, например, и пользоваться всеми прелестями IDE по полной программе.
any. Можно расписать состав объекта, аля params: {foo: bool; extra?:any;}, указывая часть элементов как необязательные. И заметьте, при желании можно не объявлять лишнего класса.И там еще куча более хитрых возможностей описать возможные типы или структуру переменных, которые, к сожалению, не очень хорошо описаны в мануалах (типа, стандарт вам в помощь, ага).
Все это даёт возможность описать даже ожидаемый результат из API, например, и пользоваться всеми прелестями IDE по полной программе.
Я не хочу сказать ничего плохого про TS, не подумайте…
Просто JS не предполагает таких возможностей в меру того, что он изначально спроектирован динамически типизированным. Это означает, что он никогда не будет поддерживать подобной TS типизации. Ошибочно говорить, что это хорошо или плохо, это просто иначе.
По сути, вы можете использовать любой язык со статической типизацией, который транслируется в JavaScript. Рекомендую взглянуть на Dart
Просто JS не предполагает таких возможностей в меру того, что он изначально спроектирован динамически типизированным. Это означает, что он никогда не будет поддерживать подобной TS типизации. Ошибочно говорить, что это хорошо или плохо, это просто иначе.
По сути, вы можете использовать любой язык со статической типизацией, который транслируется в JavaScript. Рекомендую взглянуть на Dart
Мне тоже как раз TypeScript симпатизирует в сравнении с аналогами. В сравнении с cofeescript у TP есть реальные преимущества (статическая типизация, хотя используя any есть и динамическая), по мне cofee вообще довольно спорное решение (свой синтаксис, и реальных преимуществ особо нет). В сравнении с dart — синтаксис аналогичен js. Но безусловно теряется «прелесть» работы с чистым js :) то есть уже становится похожим на допустим java, а это более скучно.
А с появлением статической типизации прелесть работы с «чистым» JavaScript не теряется?
Странное у вас представление о «чистом» языке. Ведь язык — это не только синтаксис, следуя которому мы пишем код, это ещё и определенная концепция, заложенная в язык. Разве я не прав?
Странное у вас представление о «чистом» языке. Ведь язык — это не только синтаксис, следуя которому мы пишем код, это ещё и определенная концепция, заложенная в язык. Разве я не прав?
Когда писал о «прелестях», то имел ввиду TP (ну и dart тоже соответственно), то есть как раз во многом из-за статической типизации и теряется «прелесть», видимо поэтому я эти модные штуки и не использую пока что, и вообще в последнее время работаю преимущественно с js, а не с java как ранее. Но если и выбирать замену js сейчас, то TP по моему наиболее целесообразно использовать.
Уже писал коментарий к оригиналу (к сожалению, он почему-то не отправился или не сохранился, так и не понял):
Почему-то не работает даже на их примерах под мак, на версии 33 и на canary build тоже… Флаг стоит, а чуда не происходит =(
Почему-то не работает даже на их примерах под мак, на версии 33 и на canary build тоже… Флаг стоит, а чуда не происходит =(
скриншот
Это шикарно! Я уже было хотел писать свой велосипед, а тут такая новость от ребят из Google. Огромный респект!
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Отладка асинхронного JavaScript с помощью Chrome DevTools