Смотря что имеете в виду под полифилами. За глаза хватает того, что предлагает Angular и lodash. От jQuery уже избавились (lodash на очереди). В том-то и дело, что ES6 фишки далеко не так сильно востребованы как об этом пишут. Классы и какие-то сложные вещи не нужны, потому что Angular и архитектура проекта берут это на себя и бизнес-логика описывается простым кодом. А сахар… Можно и без него прожить.
Резко высказался. Я не против ES6, Babel и т. п. Я против того, чтобы использовать эти вещи для разработки. Если последний Хром поддерживает ES6, то пусть разработчики отлаживают в нём, а сборщик просто соберет финальный билд под ES5 или соберет специальную версию для старых браузеров (сейчас это не поддерживается, но потом добавлю), Babel в роли Autoprefixer для JS вполне катит.
На счет Webpack всё жду, когда кто-нибудь напишет: Вот наш конфиг для Вебпака, который делает примерно то же самое, но без кучи самописных вещей :-)
На счет структуры проекта, жду когда кто-нибудь выложит свою структуру. Пусть с костылями, пусть не на Ангуляре. Просто не с чем сравнивать.
Именно по этому стараюсь делать сборщик, да и архитектуру приложения под технологии, а не под фреймворки. Т.е. Он работает с проектами поддерживающими DI (просто сейчас это реализовано через RequireJS), проектов с веб-компонентами (реализация ангуляровскими директивами), ORM (ангуляровскими ресурсы), кеширование (http/templateCache). В самом проекте свожу использование фишек Ангуляра к минимуму, например, никогда не используются ng-controller и ng-include (всё через роутер), никогда не используется $http (всё через $resource). Это позволит легко перейти на Angular2, а если он не выстрелит, на что-то другое. Потому что фреймворки меняются, а технологии остаются :-) Напишу подробнее в статье по архитектуре.
RequireJS и Gulp всего лишь инструменты для реализации идеи. Их можно и заменить.
P.S. Последняя утверждённая спецификация- это бежать впереди поезда. Ехать на поезде — это спецификация, поддерживаемая основными браузерами
Кофескрипт, вообще, первый показатель того, что человека не стоит брать на работу по причине неадекватности. Как правило, это люди, пришедшие с бекенде или языков с похожим синтаксисом, которым лень освоить обычный js, либо те кто без разбору хватается за всё новое, пытаясь сэкономить на спичках вместо того чтобы писать по сути лучший код. (Сорри, если кого-то задел. Это субъективные наблюдения)
За Тайпскриптом наверняка будущее, но оно настанет не раньше чем через 3 года. Недавно специально прошёлся с поиском по своим проектам и по популярным фреймворкам, чтобы узнать в скольки местах можно применять новые фишки. Оказалось, что классов в проектах используется не больше 10 штук, стрелочные функции были нужны в ~5 местах и остальной сахар так же не настолько уж необходим.
Про commonJs и AMD та же история. Синтаксисы имеют одинаковую сложность, только AMD работает без компиляции. История о том, что можно использовать одни и те же модули на фронтендщик и на ноде не выдерживает никакой критики. У них совершенно разный код в 99,9% случаев.
Стандартная просьба. Покажите, пожалуйста, ваши 70 строчек. Не скажу, что горю желанием поддерживать очередную библиотеку. Если найду решение лучше — возьму на вооружение.
Имею в виду проекты где можно было бы посмотреть код и минимальную документацию к нему. Не думаю, что даже на своих технологиях Фейсбук, Гугл и т. п. смогут развернуть и поддерживать проекты без команды в 1000 высококлассных программистов.
Так покажите проект на аналогичной технологии. Свой или любой, который нравится. Отовсюду слышу про Вебпак, Реакт, что там всё круто, но не видел ни одного проекта, архитектура которого покрутилась бы год-два в продакшене, чтобы можно было скачать и сразу клепать своё на основе.
Сборка начинается с того, что по цепочке зависимостей вытягиваются js-файлы. Далее рядом с каждым js-файлом ищется файл template.html и style.css (styl, less,...). Если находится, то теплейт добавляется в $templateCache Ангуляра, а стиль в файл со всеми стилями. Такая выборочность позволяет отключать любые части от проекта не удаляя отключенные файлы из проекта (достаточно убрать их из зависимостей). Также можно заимствовать какие-то модули из других проектов и быть уверенным что вместе с ними загрузятся их шаблоны и стили.
Это более высокий уровень абстракции. Пользователю предлагается оптимальная структура проекта и оптимальный с точки зрения быстродействия результат сборки. Так же ему не придётся задумываться о поиске и настройке плагинов, т. к. всё что нужно включено в сборщик и настроено. Идея в том, чтобы фронтендщик установил однажды модуль и навсегда забыл о сборке.
Если webpack или другая технология подойдёт лучше gulp в качестве основы и вы сможете объяснить как её настроить подобным образом — буду благодарен.
Что касается Babel, ES6 и т. п. то действительно считаю баловством использование в продакшене языков не поддерживаемых основными браузерами. Изучать новые технологии нужно, но бежать впереди поезда не слишком эффективно.
События это зло. Их просто использовать, но невозможно отлаживать и они сильно ломают логику приложения. Лучше избегать их по возможности. Над расширением подумаю
Наконец-то адекватный человек на Хабре. А то смотришь вакансии, а там требуется человек со знанием нескольких фреймворков. Приходишь на собеседование — тебе в запой рассказывают о своих костылях: эта часть у нас на Angular, тут перешли на React и используем еще 100500 мелких библиотек. Да что там другие компании, от своих не могу добиться, чтобы выпилили lodash с фронтенда. Тащят 50 КБ ради трех методов. Ну хоть jQuery выпилили, уже прогресс.
Никак нельзя (конечно, можно обернуть все в свою директиву или найти элемент селекта в контроллере, а там найти инпут и повеситься на Enter, но это нехорошо).
Нужно следить за изменением модели с помощью watch и выполнять нужные действия. Так код будет максимально независим от элемента селекта.
Резко высказался. Я не против ES6, Babel и т. п. Я против того, чтобы использовать эти вещи для разработки. Если последний Хром поддерживает ES6, то пусть разработчики отлаживают в нём, а сборщик просто соберет финальный билд под ES5 или соберет специальную версию для старых браузеров (сейчас это не поддерживается, но потом добавлю), Babel в роли Autoprefixer для JS вполне катит.
На счет Webpack всё жду, когда кто-нибудь напишет: Вот наш конфиг для Вебпака, который делает примерно то же самое, но без кучи самописных вещей :-)
На счет структуры проекта, жду когда кто-нибудь выложит свою структуру. Пусть с костылями, пусть не на Ангуляре. Просто не с чем сравнивать.
RequireJS и Gulp всего лишь инструменты для реализации идеи. Их можно и заменить.
P.S. Последняя утверждённая спецификация- это бежать впереди поезда. Ехать на поезде — это спецификация, поддерживаемая основными браузерами
За Тайпскриптом наверняка будущее, но оно настанет не раньше чем через 3 года. Недавно специально прошёлся с поиском по своим проектам и по популярным фреймворкам, чтобы узнать в скольки местах можно применять новые фишки. Оказалось, что классов в проектах используется не больше 10 штук, стрелочные функции были нужны в ~5 местах и остальной сахар так же не настолько уж необходим.
Про commonJs и AMD та же история. Синтаксисы имеют одинаковую сложность, только AMD работает без компиляции. История о том, что можно использовать одни и те же модули на фронтендщик и на ноде не выдерживает никакой критики. У них совершенно разный код в 99,9% случаев.
Стандартная просьба. Покажите, пожалуйста, ваши 70 строчек. Не скажу, что горю желанием поддерживать очередную библиотеку. Если найду решение лучше — возьму на вооружение.
Если webpack или другая технология подойдёт лучше gulp в качестве основы и вы сможете объяснить как её настроить подобным образом — буду благодарен.
Что касается Babel, ES6 и т. п. то действительно считаю баловством использование в продакшене языков не поддерживаемых основными браузерами. Изучать новые технологии нужно, но бежать впереди поезда не слишком эффективно.
Нужно следить за изменением модели с помощью
watchи выполнять нужные действия. Так код будет максимально независим от элемента селекта.