В статье много идеализаций. Особенно в экономической части:
Эти пользователи — мертвый груз, они должны быть уничтожены вне зависимости от того сколько денег они вам приносят.… они того не стоят.
Сколько бы денег не приносили — они того не стоят? А если миллионы? А если миллиарды?
Потратьте лучше эти часы на создание новых версий и наймите разработчиков, которые будут помогать пользователям с переходом.
Мы только что отказались от миллиардов, так на какие деньги нанимать разработчиков? Впрочем, ответ следует дальше:
Решениями, принятыми для толпы, которая уже давно и безнадежно отстала от технологий, вы отчуждаете и негативно влияете на продвинутых пользователей, способных принести гораздо большие деньги.
На самом деле сложно оценить кто больше принесёт денег: продвинутые пользователи, внимание которых ещё нужно заслужить, или толпа, которая уже приносит нам деньги?
В целом я тоже за прогресс, но не стоит забывать и о бизнесе. Если не будет денег, то не будет никаких разработчиков и новых продуктов вообще. Статья какая-то однобокая.
Если использовать «зелёную трубку» в PhpStorm, то настраивать DBGProxy и IDE Key не нужно, это ни на что не повлияет, IDE Key вообще может различаться в php.ini и в PhpStorm.
И второе: запущенный xdebug (вне зависимости от того, запущен PhpStorm или нет) заметно тормозит приложение, поэтому вместо remote_autostart=on рекомендую использовать букмарклеты.
Я раньше писал корпоративные веб приложения под ie 6 с интеграцией с SAP и другими самописными корпоративными приложениями, часть из которых была написана ещё на COBOL! Чтобы добавить боли, скажу, что был проект на ExtJs (что само по себе мрачно) — представляете как оно «быстро» работало на ie 6? Нет, не представляете… пользователи сидели на тонких клиентах с подключением к терминальному серверу на Windows 2003. Минутка боли закончилась, пойду лучше почитаю нетрадиционные обзоры React и Angular!
Хех, я думал сейчас подискутируем о js фреймворках (vs js-библиотеки может)… а так, да, «по старинке» спору нет. Но эта страница истории уже перевёрнута.
AngularJs 1.3 vs 2.0 — действительно боль, но не всё так страшно
* Ушел Роб Эйзинберг, вернувшись к своему старому начинанию — ещё ничего не значит. Может он просто устал, есть свои идеи, хочется чего-то свежего. Команда Ангуляра от этого не исчезает и там много сильных профессионалов.
* 2.0 полностью переписан и не понятно как мигрировать с 1.3 — действительно так. Но представим себе, что это просто новый фреймворк! Мы же не жалуемся, что мигрировать между Angular и React тяжело — разные фреймворки, каждый со своими фишками. Вопрос в том, на сколько эти фишки заманчивы, чтобы начать новый проект на Angular 2.0 или даже взять и переписать старый с нуля? Посмотрим. Верим, надеямся, ждём…
* Будут распылять свои силы между поддержкой AngularDart, 1.3 и 2.0…
AngularDart существовал и во времена 1.x и это «распыление» не мешала двигаться от 1.1 к 1.2 и к 1.3. Напротив, как писали разработчики в своём блоге, опыт с AngularDart их многому научил и какие-то идеи они портировали обратно в AngularJs.
Что действительно пугает: поддержка 1.3 может станет минимальной (например, гугловцы захотят форсировать этим повсеместное использование 2.0) и тогда миллионы проектов написанных на Angular 1.2 и 1.3 окажутся в неприятной ситуации. В а в заголовках описаниях вакансий мы увидим «Требуется разработчик Angular 1.3» или "… Angular 2.0". В итоге всё может получиться как с Python 3 или Perl 6.
Ещё не понятно как гуглить вопросы/ответы/обсуждения касающиеся какой-то определённой версии Angular, если будут два активных коммунити с разными фреймворками, но одинаковым ключевым словом «Angular».
В статье много здравых мыслей. Но некоторые суждения явно следуют лишь из того, что автор работал с ним всего 40 часов.
Например:
Когда я писал такое же приложение в первые раз на Реакте, мне понадобилось 28¾ часов. То же самое приложение на Angular я писал 39½ часа, не смотря на то, что я мог использовать часть кода из первой попытки на Реакте. Десять часов сверху. Причина — излишняя сложность Angular.
Ангуляр действительно сложнее, чем Реакт. Но попробуйте написать не первое приложение, а десятое, и окажется, что на Реакте вам всё ещё требуются условно 20 часов, а на Ангуляре справитесь за 5!
Тупо разница в объёме кода: на Реакте кучу всего придётся написать ручками (опять и опять и опять, если только не начнёте использовать какую-то высокоуровневую абстракцию поверх Реакта), а в Ангуляре достаточно будет воспользоваться магическими иероглифами «=», «&», «=*», и «@»; «E», «A», и «EA», так критикуемые автором, которые к десятому проекту вы уже выучили.
Ещё один стоящий комментарий, на этот раз из facebook/flux репозитория на github:
Пример чат-приложения я подготовил специально для конференции ForwardJS осенью 2014 года…
… мы хотели показать вызов серверного API из Action Creators, как это предпочитает делать Jing (автор Flux). Однако, внутри FB многие обычно делают запросы к серверу непосредственно из Store. Я считаю оба эти способа корректыми и не отдаю предпочтения какому либо из них.
Одно из преимуществ обращаться к серверу в Action Creator, а не в Store, это обработка ошибок.
Да, комментарии стоящие.
Позволю себе перевести один из них.
Я работаю над Atlas в Facebook и использую React+Flux уже полтора года, так что могу ответить на некоторые вопросы:
— Как отправлять данные на сервер и обратно?
Отправка данных на сервер: Action Creator делает асинхронный запрос к серверу и, как только получен success или failure результат, посылает Action с соотвествующей информацией в Dispatcher, а затем обновляются и Store. Впрочем, Action Creator может послать Action не дожидаясь ответа от сервера, предполагая оптимистичный исход.
Получение данных от сервера: когда вы запрашиваете данные из Store, он может начать загружать данные в бекграунде и проинформировать вас, как только они получены. Store может быть синхронным, в этом случае getBlah() возвращает null если данные не были загружены, или асинхронным, тогда getBlah() возвращает Promise.
— Как управлять связью между компонентами не имеющими общего родителя?
Используйте Actions и Stores — они глобальны и могут использоваться любыми компонентами.
Надо пробовать… из описания нет ясности, т.к. все скриншоты на примере git репозитория расположенного на bitbucket. Особенно в конце такая фраза "...just click Update from GIT button..."
Сделать форк Trident, почистив от старого кода и режимов совместимости — одобряю, это правильно!
Но что я не понимаю:
1) В Spartan реализован подход с двойным движком. В интернете автоматически подключится EdgeHTML, а в старом корпоративном приложении MSHTML — ок, удобно.
2) В Internet Explorer будет аналогичный подход с двойным движком: в интернете EdgeHTML, а в корпоративном приложении MSHTML.
Внимание вопрос: а в чём тогда разница между браузерами? В дизайне кнопочек, табов и адресной строки?
Чую, что EdgeHTML замутили классные парни из отдела разработки, а вот Spartan, как отдельный браузер, это уже маркетологи подключились.
Сколько бы денег не приносили — они того не стоят? А если миллионы? А если миллиарды?
Мы только что отказались от миллиардов, так на какие деньги нанимать разработчиков? Впрочем, ответ следует дальше:
На самом деле сложно оценить кто больше принесёт денег: продвинутые пользователи, внимание которых ещё нужно заслужить, или толпа, которая уже приносит нам деньги?
В целом я тоже за прогресс, но не стоит забывать и о бизнесе. Если не будет денег, то не будет никаких разработчиков и новых продуктов вообще. Статья какая-то однобокая.
И второе: запущенный xdebug (вне зависимости от того, запущен PhpStorm или нет) заметно тормозит приложение, поэтому вместо remote_autostart=on рекомендую использовать букмарклеты.
* Ушел Роб Эйзинберг, вернувшись к своему старому начинанию — ещё ничего не значит. Может он просто устал, есть свои идеи, хочется чего-то свежего. Команда Ангуляра от этого не исчезает и там много сильных профессионалов.
* 2.0 полностью переписан и не понятно как мигрировать с 1.3 — действительно так. Но представим себе, что это просто новый фреймворк! Мы же не жалуемся, что мигрировать между Angular и React тяжело — разные фреймворки, каждый со своими фишками. Вопрос в том, на сколько эти фишки заманчивы, чтобы начать новый проект на Angular 2.0 или даже взять и переписать старый с нуля? Посмотрим. Верим, надеямся, ждём…
* Будут распылять свои силы между поддержкой AngularDart, 1.3 и 2.0…
AngularDart существовал и во времена 1.x и это «распыление» не мешала двигаться от 1.1 к 1.2 и к 1.3. Напротив, как писали разработчики в своём блоге, опыт с AngularDart их многому научил и какие-то идеи они портировали обратно в AngularJs.
Что действительно пугает: поддержка 1.3 может станет минимальной (например, гугловцы захотят форсировать этим повсеместное использование 2.0) и тогда миллионы проектов написанных на Angular 1.2 и 1.3 окажутся в неприятной ситуации. В а в заголовках описаниях вакансий мы увидим «Требуется разработчик Angular 1.3» или "… Angular 2.0". В итоге всё может получиться как с Python 3 или Perl 6.
Ещё не понятно как гуглить вопросы/ответы/обсуждения касающиеся какой-то определённой версии Angular, если будут два активных коммунити с разными фреймворками, но одинаковым ключевым словом «Angular».
Перефразируя вопрос: а на чём разработка шла бы заметно быстрее?
Например: Ангуляр действительно сложнее, чем Реакт. Но попробуйте написать не первое приложение, а десятое, и окажется, что на Реакте вам всё ещё требуются условно 20 часов, а на Ангуляре справитесь за 5!
Тупо разница в объёме кода: на Реакте кучу всего придётся написать ручками (опять и опять и опять, если только не начнёте использовать какую-то высокоуровневую абстракцию поверх Реакта), а в Ангуляре достаточно будет воспользоваться магическими иероглифами «=», «&», «=*», и «@»; «E», «A», и «EA», так критикуемые автором, которые к десятому проекту вы уже выучили.
Пример чат-приложения я подготовил специально для конференции ForwardJS осенью 2014 года…
… мы хотели показать вызов серверного API из Action Creators, как это предпочитает делать Jing (автор Flux). Однако, внутри FB многие обычно делают запросы к серверу непосредственно из Store. Я считаю оба эти способа корректыми и не отдаю предпочтения какому либо из них.
Одно из преимуществ обращаться к серверу в Action Creator, а не в Store, это обработка ошибок.
Позволю себе перевести один из них.
Я работаю над Atlas в Facebook и использую React+Flux уже полтора года, так что могу ответить на некоторые вопросы:
— Как отправлять данные на сервер и обратно?
Отправка данных на сервер: Action Creator делает асинхронный запрос к серверу и, как только получен success или failure результат, посылает Action с соотвествующей информацией в Dispatcher, а затем обновляются и Store. Впрочем, Action Creator может послать Action не дожидаясь ответа от сервера, предполагая оптимистичный исход.
Получение данных от сервера: когда вы запрашиваете данные из Store, он может начать загружать данные в бекграунде и проинформировать вас, как только они получены. Store может быть синхронным, в этом случае getBlah() возвращает null если данные не были загружены, или асинхронным, тогда getBlah() возвращает Promise.
— Как управлять связью между компонентами не имеющими общего родителя?
Используйте Actions и Stores — они глобальны и могут использоваться любыми компонентами.
Но что я не понимаю:
1) В Spartan реализован подход с двойным движком. В интернете автоматически подключится EdgeHTML, а в старом корпоративном приложении MSHTML — ок, удобно.
2) В Internet Explorer будет аналогичный подход с двойным движком: в интернете EdgeHTML, а в корпоративном приложении MSHTML.
Внимание вопрос: а в чём тогда разница между браузерами? В дизайне кнопочек, табов и адресной строки?
Чую, что EdgeHTML замутили классные парни из отдела разработки, а вот Spartan, как отдельный браузер, это уже маркетологи подключились.