Ну еще brunch.io более чем достоин внимания.
А так да, gulp — шик и блеск, API из 4-х методов позволяет описывать задачи именно в том виде, в котором их наиболее удобно читать и понимать, что эта штука делает. Конфиг grunt'а имеет особенность быстро разрастаться до не особо поддерживаемых и читабельных размеров.
Причем тут программирование мышкой? CSS-препроцессоры — это то, что увеличивает производительность разработки и поддерживаемость стилей в разы, причем, независимо от масштаба проекта. Для того, чтобы их использовать — нужно знать CSS, там нет ненужных абстракций.
Ну, в том то и дело, что Хром и иже с ним обновляют и major-версию совершенно незаметно. Не уверен, как сейчас Win обновляет браузеры (с major-версией или без). Благо, по статистике проектов, всеми IE ниже 10-ки можно пренебречь уже. Однако, и 10-ка сильно напрягает — fallback-и для flex-box'а и многие другие недочеты. Поэтому — пора бы ему.
Убивать браузер нельзя, как бы ни хотелось. Конкуренция — это хорошо. Но нужен качественный продукт. Самой крутой киллер-фичей IE была бы максимизация усилий команды по выведению из игры старых версий браузера (до 10-й включительно). Тогда можно будет убрать изрядную гору костылей в виде shim'ов и полифиллов из проектов и, наконец, полноценно использовать flex-box.
IE11 — в целом и общем — весьма неплохой браузер (в том смысле, что не причиняет огромного количества неудобств при мульти-браузерной разработке). Но IE10 и ниже — пора бы им уже того. И вот тут MS давно нужно было ввести какую-то более современную стратегию обновления браузеров, как у их «вечнозеленых» конкурентов.
мягко намекать пользователю что здесь и сейчас у тебя некорректно написано
Ну это же делается по «onblur».
Допустим если в поле для емейла пишем символы! и № они сразу убираются и пользователю показывается ая-яй.
Плохой вариант в сценариях, где вполне возможны «копи-пасты». Лучше выводить пользователю предупреждение прямо по ходу, а то и указывать на недопустимые символы.
Некоторые формы содержат порядка 40 полей ввода. И когда пользователь допускал ошибки хотя бы в 10(а это сплошь и рядом), он видел целый веер хинтов с предупреждениями. Это его пугало.
Это просто серьезная проблема с юзабилити. Значит, ваши поля были неочевидными, в них не было необходимых хинтов, и так далее — то есть, не было чего-то, что предотвратит ошибки пользователей. Ну а решить проблему вы решили кардинально, поменяв заложенное в браузер поведение элемента, не «сообщив» об этом пользователю. С последствиями, впрочем, столкнулись и уже, уверен, сами все понимаете.
Да как раз все понятно с ходу — несмотря на то, что в продакшене я с React не работал. Но работаю с Angular, Backbone, Ember, Knockout/Durandal, ExtJS (oh my) и еще несколько самописных полу-фреймворков, созданных кем-то под проект. Все концепции — знакомые. Разные фреймворки имеют разные (хотя и схожие) API, но внутри используют одинаковые механизмы.
P.S. С проектами на Rails ох как не все гладко. Не говоря уже о хаках (особенно, связанных с UI), когда предложенных «стандартных» методов не хватает.
Ох круто было бы :) Если бы. Вы много работали в фронтендом? Просто чересчур много аспектов, чтобы обойтись каким-либо «простеньким» DSL, и при этом он покрывал все необходимые кейсы.
Что касается 2-way-binding — очень большой вопрос как сделать это лучше. Функциональный подход — конечно, хорошо, но как по мне — декларативный тут укладывается лучше.
Ну вот о практичности и речь. Как по мне — слишком много разнообразных элементов, чтобы пытаться уложить все в одну парадигму. А так то — конечно, чистый функциональный код очень элегантен.
Да тут и нет особо никакой интроспекции. Обычные селекторы. Вы же, к примеру, с помощью React точно также должны определить в каком месте страницы должен появиться компонент. Но тут действительно — дело вкуса, «с какой стороны» определять позицию компонента.
В том же Angular — сложнее сделать динамические компоненты — то есть, в любом случае приходится из кода вызывать некоторый компонент/сервис, который генерирует DOM (обычно все равно с помощью директив и шаблонов) и запихивает его в страницу, в элемент с каким-то селектором. От этого никуда не деться, но используя Angular не могу избавиться от ощущения, что это хак :)
Тут дело уже не столько в строчках, сколько в том, что с ростом проекта и, соответственно, сложности — такой микс логики отображения, DOM-манипуляций, логики «моделей» и логики обработки удаленных запросов станет невозможно поддерживать.
Да в целом функционально то с ним все в порядке, но просто «HTML в коде» вызывает смешанные чувства. Но наоборот — presentation-специфичный код внутри HTML — воспринимается вполне интуитивно.
А так да, gulp — шик и блеск, API из 4-х методов позволяет описывать задачи именно в том виде, в котором их наиболее удобно читать и понимать, что эта штука делает. Конфиг grunt'а имеет особенность быстро разрастаться до не особо поддерживаемых и читабельных размеров.
О ком здесь идет речь? Сразу подумалось про TJ Fontaine, но никакой информации об этом нет.
Отнюдь :) Это просто связка. С таким же успехом это могло быть MongoDB+Rails+Angular или MongoDB+PHP+Angular.
А подход, в целом, интересный, нужно глянуть, что предлагает Catberry
IE11 — в целом и общем — весьма неплохой браузер (в том смысле, что не причиняет огромного количества неудобств при мульти-браузерной разработке). Но IE10 и ниже — пора бы им уже того. И вот тут MS давно нужно было ввести какую-то более современную стратегию обновления браузеров, как у их «вечнозеленых» конкурентов.
Ну а если по делу — навскидку выглядит круто, надо будет обязательно попробовать. Вообще, движение в этом направлении очень радует
Ну это же делается по «onblur».
Плохой вариант в сценариях, где вполне возможны «копи-пасты». Лучше выводить пользователю предупреждение прямо по ходу, а то и указывать на недопустимые символы.
Это просто серьезная проблема с юзабилити. Значит, ваши поля были неочевидными, в них не было необходимых хинтов, и так далее — то есть, не было чего-то, что предотвратит ошибки пользователей. Ну а решить проблему вы решили кардинально, поменяв заложенное в браузер поведение элемента, не «сообщив» об этом пользователю. С последствиями, впрочем, столкнулись и уже, уверен, сами все понимаете.
P.S. С проектами на Rails ох как не все гладко. Не говоря уже о хаках (особенно, связанных с UI), когда предложенных «стандартных» методов не хватает.
В том же Angular — сложнее сделать динамические компоненты — то есть, в любом случае приходится из кода вызывать некоторый компонент/сервис, который генерирует DOM (обычно все равно с помощью директив и шаблонов) и запихивает его в страницу, в элемент с каким-то селектором. От этого никуда не деться, но используя Angular не могу избавиться от ощущения, что это хак :)
А что вы называете «функциональной моделью»?