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