Человеку нравится Китай, и его государственное устройство, в этом нет ничего плохого. Старшее поколение борется за традиционные отношения, за религию, потому что считает это правильным. У нас может быть другое мнение и это абсолютно нормально. Главное оставаться людьми и относится уважительно к друг другу. Ценности общества меняются так быстро, что можно погибнуть за идею, которая через 5 лет никому будет не нужна. Ругаться в комментариях и клеймить кого-то точно не стоит.
Ещё можешь посмотреть в сторону haxe. Отлично собирается в js, и богатый функционал для написания макросов. Я год назад делал похожую библиотеку, только вместо server function writeDataToDb использовал function srv_writeDataToDb. При компиляции в эту функцию добавлялась проверка на то, что этот фрагмент выполняется на сервере, иначе нужно упаковывать все аргументы функции в пакет и отправить на сервер.
Пробовал и ts, и haxe. TS для меня проигрывает в большинстве случаев. Если изначально закладываться на определённые платформы для клиента и сервера (а не расчитывать на то что он соберётся под любую платформу), то можно избежать трудностей с несколькими кодовыми базами. А если распробуете макросы в хакс, то наверное уже сложно будет его на что-то променять.
Только что пришло письмо от Юлмарта с недавно просмотренными товарами, хотя я не авторизовывался никогда с рабочего компьютера, и вот неожиданность, в отписке от рассылки caltat.com
Если коротко: Кто-то кому то сказал, что Flash плохой, поэтому Flash надо выбросить. Flash чудесен. Альтернативы ему как не было так и нет. HTML5 это сайты, Flash — интерактивный контент. Не удобно использовать Word, чтобы сделать себе презентацию. Для всего свои инструменты.
Нам бы ваш красочный космос к себе в игру..) Мы начинали своих «космических рейнджеров» звёздного века чуть чуть пораньше, когда ещё не было Старлинга и поддержки видео карт. Делали всё в 2d и на flex. Вы принципиально решили отказаться от размещения в социальных сетях? И конечно желаю удачи в вашем проекте ;)
Нет, библиотека применима только при разработке фронтендов на JavaScript. Этот абзац в статье — мои внутренние мучения при выборе технологии и подхода при создании таких приложений. И как результат формирование отличных от популярных принципов для данной библиотеки.
Про объём: наверное это критично в некоторых случаях, но для написания приложений и запакованных при помощи Cordova — это не имеет абсолютно никакого значения. Простите, если ввёл Вас в заблуждение по поводу сферы использования библиотеки.
Мне субъективно CoffeeScript не понравился. Сахар сахарком, но можно и забыть, что мы пьём чай. Однако у всех разное мнение и, несомненно, это хороший инструмент.
Наверное надо было упомянуть про IntelliJ IDEA. Я тоже её использую в Ubuntu.
Это не MVC фреймворк, это библиотека, которая старается обойти все неудобства pure JavaScript для таких людей как я. Ничего не мешает добавить туда это разделение.
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 — объект, которое это событие испустил.
Информация
В рейтинге
Не участвует
Откуда
Санкт-Петербург, Санкт-Петербург и область, Россия
github.com/Unity-Technologies/Graphics/blob/master/com.unity.render-pipelines.universal/Editor/SavedParameter.cs и поменял на public. Кажется, более простое решение.
Странно, что прошёл год, а до сих пор не появилось более универсального решения. Конечно, возможно, что это я плохо искал
Проект замечательный, желаю автору успехов и дальнейшего развития.
Мне субъективно CoffeeScript не понравился. Сахар сахарком, но можно и забыть, что мы пьём чай. Однако у всех разное мнение и, несомненно, это хороший инструмент.
Наверное надо было упомянуть про IntelliJ IDEA. Я тоже её использую в Ubuntu.
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 — объект, которое это событие испустил.