Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 35
А как вы разделяете бизнес-логику и логику представления?
Это не MVC фреймворк, это библиотека, которая старается обойти все неудобства pure JavaScript для таких людей как я. Ничего не мешает добавить туда это разделение.
Производительность для мобильных приложений становится критической. И подход two-way binding'a уже не кажется решением всех проблем (AngularJs). Как и генерация страницы целиком на стороне клиента (ReactJs) у меня по прежнему вызывает лишь один вопрос — зачем? Зачем мне виртуальный DOM?
Не понимаю тогда, к чему этот абзац в статье? Как вы предлагаете решать проблему биндинга данных в веб-приложениях? Ваша библиотека изоморфна, умеет рендерить представление и на сервере, и на клиенте?
На мой взгляд, статья очень спорная.
В самом начале, взгляд цепляется за «Отсутствие удобного редактора кода»… Здесь можно привести WebStorm, который от версии к версии обрастает все новыми клевыми «рюшками», да и используя jsDoc проблем с удобной документацией (и отображением в IDE) даже пользовательских функций не возникает.
Любителям VS — в новых версиях 13,14 года Microsoft тоже весьма неплохо организовали поддержку не только TypeScript, но и чистого JS
Очень непонятно Ваше стремление превратить JS в AS… Хотите ООП? Можно заиспользовать TypeScript или Dart…
Плюс очень непонятно:
1) Что же не так с прототипным наследованием, что оно может просто быть ненавистным (ну ок, привыкли к ООП, можно понять)
2) Что не так с DOM API?
3) Какие проблемы с разделением на файлы?
4) Что не так с событиями?
В самом начале, взгляд цепляется за «Отсутствие удобного редактора кода»… Здесь можно привести WebStorm, который от версии к версии обрастает все новыми клевыми «рюшками», да и используя jsDoc проблем с удобной документацией (и отображением в IDE) даже пользовательских функций не возникает.
Любителям VS — в новых версиях 13,14 года Microsoft тоже весьма неплохо организовали поддержку не только TypeScript, но и чистого JS
Очень непонятно Ваше стремление превратить JS в AS… Хотите ООП? Можно заиспользовать TypeScript или Dart…
Плюс очень непонятно:
1) Что же не так с прототипным наследованием, что оно может просто быть ненавистным (ну ок, привыкли к ООП, можно понять)
2) Что не так с DOM API?
3) Какие проблемы с разделением на файлы?
4) Что не так с событиями?
Отвечу вместо автора на один пункт: DOM API очень громоздкое и для часто встречающихся задач не всегда удобное (хотя появление document.querySelectorAll и HTMLElement#matches уже здорово облегчает жизнь).
Постараюсь ответить на Ваши вопросы:
1) Когда-то давным давно ActionScript тоже был прототипным, я с него начинал. С точки зрения возможностей и функциональности он ничем не уступает ООП — вещи написанные на объектах, можно реализовать на прототипах, однако с точки зрения удобства это небо и земля. Человек, который ездит на ручной коробке передач, не понимает зачем ему автомат, а вот человек, который поездил на автомате, следующую машину скорее всего выберет с автоматической коробкой передач. Также и тут.
Тут сразу добавлю про TypeScript. Я везде люблю чистоту и порядок, TypeScript вначале показался панацеей. Что мне не понравилось:
1) Импорты по пути относительному к файлу. Это ужасно не удобно
2) Система сборки, когда порядком компиляции файлов нужно управлять самостоятельно, создавая списки и скармливая их компилятору.
3) Везде ключевое слово this. Это покажется дико, но это основная причина, почему я не стал использовать TypeScript.
4) Проблемы с замыканиями. Уже не помню, что именно мне не понравилось, но точно была одна из проблем: то ли область видимости терялась, то ли отписаться от события по функции было невозможно.
2) Про DOM — для сайтов это отлично. Наверное я не сделал акцент, на том, что это библиотека нужна для разработки кроссплатформенных мобильных приложений с использованием Cordova. Для них DOM по моему глубокому мнению — огромный минус. Возьмите тот, же фреймворк7 или ионик — сколько кода нужно вставить во view чтобы это заработало. Компонент в моём случае сам может собрать интересующуую его ветку — переходить к родителям и детям. Главный принцип — компонентный подход. Никаких шаблонов.
3) Немного об этом рассказал в первом пункте, однако нужно дополнить. Без инструментов таких как grunt, сделать сборку ручками достаточно проблематично. Тут наверное стоит добавить, что я не люблю инструменты ради инструментов. Мой внутренний мир страдает, когда в проект для сборки проекта я устанавливаю с десяток компонентов NodeJS, которые к моему проекту по большому счёту не имеют никакого отношения. И весят около 15 мегабайт. Я держу проекты в dropbox — и для меня это получается, тоже не очень удобно.
4) Просто вы не работали с событиями в ActionScript. Там суть событий в другом. Реализовать это на нативных событиях JavaScript невозможно и вот почему. Нельзя написать обёртку вокруг DOM ноды. Можно получить ссылку на узел. Но — это узел, а не объект с Вашими методами. Я считаю, что в больших проектах выборка по селектору — огромное зло. Нужна ссылка на объект получи её из события, если это ребёнок. Если состояние компонента изменилось — отправь событие вверх по дереву. Вглубь дерева — ссылки, которые хранятся в объекте. Вверх — событие, где event.target — объект, которое это событие испустил.
1) Когда-то давным давно ActionScript тоже был прототипным, я с него начинал. С точки зрения возможностей и функциональности он ничем не уступает ООП — вещи написанные на объектах, можно реализовать на прототипах, однако с точки зрения удобства это небо и земля. Человек, который ездит на ручной коробке передач, не понимает зачем ему автомат, а вот человек, который поездил на автомате, следующую машину скорее всего выберет с автоматической коробкой передач. Также и тут.
Тут сразу добавлю про TypeScript. Я везде люблю чистоту и порядок, TypeScript вначале показался панацеей. Что мне не понравилось:
1) Импорты по пути относительному к файлу. Это ужасно не удобно
2) Система сборки, когда порядком компиляции файлов нужно управлять самостоятельно, создавая списки и скармливая их компилятору.
3) Везде ключевое слово this. Это покажется дико, но это основная причина, почему я не стал использовать TypeScript.
4) Проблемы с замыканиями. Уже не помню, что именно мне не понравилось, но точно была одна из проблем: то ли область видимости терялась, то ли отписаться от события по функции было невозможно.
2) Про DOM — для сайтов это отлично. Наверное я не сделал акцент, на том, что это библиотека нужна для разработки кроссплатформенных мобильных приложений с использованием Cordova. Для них DOM по моему глубокому мнению — огромный минус. Возьмите тот, же фреймворк7 или ионик — сколько кода нужно вставить во view чтобы это заработало. Компонент в моём случае сам может собрать интересующуую его ветку — переходить к родителям и детям. Главный принцип — компонентный подход. Никаких шаблонов.
3) Немного об этом рассказал в первом пункте, однако нужно дополнить. Без инструментов таких как grunt, сделать сборку ручками достаточно проблематично. Тут наверное стоит добавить, что я не люблю инструменты ради инструментов. Мой внутренний мир страдает, когда в проект для сборки проекта я устанавливаю с десяток компонентов NodeJS, которые к моему проекту по большому счёту не имеют никакого отношения. И весят около 15 мегабайт. Я держу проекты в dropbox — и для меня это получается, тоже не очень удобно.
4) Просто вы не работали с событиями в ActionScript. Там суть событий в другом. Реализовать это на нативных событиях JavaScript невозможно и вот почему. Нельзя написать обёртку вокруг DOM ноды. Можно получить ссылку на узел. Но — это узел, а не объект с Вашими методами. Я считаю, что в больших проектах выборка по селектору — огромное зло. Нужна ссылка на объект получи её из события, если это ребёнок. Если состояние компонента изменилось — отправь событие вверх по дереву. Вглубь дерева — ссылки, которые хранятся в объекте. Вверх — событие, где event.target — объект, которое это событие испустил.
А где же мнение по поводу web-компонентов?
В общем-то никто не заставляет вас постоянно общаться с ДОМом в JS. Можно сделать обёртку, где вы будете работать с вью/лейатуами/ещё чем нибудь, а они, в свою очередь, будут реализовывать работу с ДОМ. На таком принципе построен довольно занятный фреймворк Famo.us
Haxe в этом плане на голову выше, странно, что он не имеет большой популярности у frontend-разработчиков.
Достаточно посмотреть на результат сборки, что бы понять почему его не используют. Думаю даже дарт не сравнится с объёмом выхлопного кода.
З.Ы. Помнится у OpenFL была демка, где просто рисовались шарики с физикой. Так вот, этот километр шариков рисовался на отдельном канвасе каждый шарик, а летали по полю они с помощью атрибутов DOM-элемента, включая повороты. Скорее всего это специфика самого фреймворка, но кто знает, я внутренности не смотрел.
CoffeeScript, Dart, TypeScript. Но все они очень сырые или неудобные.
Упасихоспади, CoffeeScript да неудобное или сырое? Право синтаксис у него откровенно наркоманский, но лучшей JS сахарозы и придумать сложно, учитывая все плюсы и минусы альтернативных реализаций разных препроцессоров.
В качестве редактора предлагаю посмотреть на IntelliJ IDEA (комьюнити версию, например). По-моему более приятная среда, правда чуть менее заточена под AS\Haxe, но пользоваться заметно удобнее.
Sublime 3
По-моему Саблайм идеален только как замена популярному Notepad++. Он в разы лучше всех существующих решений — да, но это просто редактор, а не IDE. Без статического анализа, без нормального автодополнения (имею ввиду интеллектуальный), без отладчиков, без терминала, без процессов, без… Ну в общем много чего «без». Конечно это решается кучей плагинов, но далеко не всё и не заменит IDE. Более того — тот же PhpStorm на нетбуке у меня просто летает, хотя девайс совсем не новый.
Есть какие-то реальные примеры его преимуществ, за исключением скорости старта?
Есть какие-то реальные примеры его преимуществ, за исключением скорости старта?
И чем же лучше? JS плагин и там и там один и тот же…
Вы PyCharm с WebStorm попутали.
В таком случае почему конкретно PyCharm, а не PhpStorm или RubyMine?
Да нет, WebStorm — это урезанный PHPStorm, а PyCharm — вообще для python'а. Я же просто купил полную идею и теперь все в одном месте, потому что у меня как веб, так и Java, так и Python, очень удобно.
Она и есть полная, только для нее плагины с тем же функционалом, что в сателлитах (PHPStrorm, PyCharm, ...) выходят позднее. Поэтому она всегда слегка отсталая, но лично мне не всегда позарез нужен свежайший функционал.
Надо заметить, что в IDEA v12, кажется, не было возможности управлять venv'ами для питона, а в PyCharm'e тех лет, была. Однако IDEA v14 (может и v13) такое уже умеет и мне комфортно работать в ней. Всяко это более удобно, чем иметь две или более IDE. Так что попробуйте идею еще раз, вдруг нужный вам функционал там уже появился.
Надо заметить, что в IDEA v12, кажется, не было возможности управлять venv'ами для питона, а в PyCharm'e тех лет, была. Однако IDEA v14 (может и v13) такое уже умеет и мне комфортно работать в ней. Всяко это более удобно, чем иметь две или более IDE. Так что попробуйте идею еще раз, вдруг нужный вам функционал там уже появился.
Даю 98.6% гарантии, что Вы просто плохо готовили IDEA, т.к. превратить из неё, например шторм — дело 5-ти минут. Не думаю что превратить из неё PyCharm очень сложно.
Интересно было бы узнать что за «настройка проектов и внешних библиотек», можно скриншотик или чуть более подробно об этом моменте?
Скрытый текст 
Интересно было бы узнать что за «настройка проектов и внешних библиотек», можно скриншотик или чуть более подробно об этом моменте?
В пользу «неудобности» и «сырости» coffescript говорит еще и то, что ECMAScript 6 копирует его плюшки 1 в 1.
О каких таких «его» плюшках идёт речь?
Например: habrahabr.ru/post/249751/
Про объём: наверное это критично в некоторых случаях, но для написания приложений и запакованных при помощи Cordova — это не имеет абсолютно никакого значения. Простите, если ввёл Вас в заблуждение по поводу сферы использования библиотеки.
Мне субъективно CoffeeScript не понравился. Сахар сахарком, но можно и забыть, что мы пьём чай. Однако у всех разное мнение и, несомненно, это хороший инструмент.
Наверное надо было упомянуть про IntelliJ IDEA. Я тоже её использую в Ubuntu.
Мне субъективно CoffeeScript не понравился. Сахар сахарком, но можно и забыть, что мы пьём чай. Однако у всех разное мнение и, несомненно, это хороший инструмент.
Наверное надо было упомянуть про IntelliJ IDEA. Я тоже её использую в Ubuntu.
Что мне в JavaScript нравится
•Отсутствие типизации;
•Прототипное наследование;
•Возможность разделения на файлы как тебе удобно;
•Взаимодействие с DOM деревом;
•Гибкая событийная модель; А также возможность создавать свои модели.
•Наличие удобных редакторов кода (VS, WebStorm)
•Отсутствие типизации;
•Прототипное наследование;
•Возможность разделения на файлы как тебе удобно;
•Взаимодействие с DOM деревом;
•Гибкая событийная модель; А также возможность создавать свои модели.
•Наличие удобных редакторов кода (VS, WebStorm)
Я рассматривал много технологий-обёрток вокруг JavaScript для типизации и объектного наследования. CoffeeScript, Dart, TypeScript.
Не могу сказать насчет TypeScript (т.к. не имел дел с ним), но Dart — это не «технология-обертка вокруг JavaScript для типизации и объектного наследования», а самостоятельный полноценный язык. Да, сейчас для его работы на клиенте его нужно компилировать в Javascript, но на сервере этого делать не нужно. Поэтому в вашей фразе только часть правды касательно Dart.
В статье слишком мало кода. Плюс не совсем понятно, зачем делать мобильные приложения на JS и Cordova, когда можно взять AS и AIR?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Приручаем JavaScript или очередной велосипед для frontend-приложений