Seed проект Minko мне не понравился по двум причинам:
Очень сложная система сборки. Когда мне надо было добавить стороннюю библиотеку в зависимости, и у меня ничего не заработало из коробки, я начал разбираться. У него там куча каких-то скриптов, непонятно что из них что делает, откуда все берется и куда следует. В итоге я добавил эту библиотеку в папку с исходниками и так решил проблему. Что особенно печально, на тот момент не было другого сида, который делал бы AOT и tree-shaking. Тогда-то я и начал разбираться в теме, чтобы сделать свое.
Не работает compile-on-save. Дев сборка в его сиде (когда я с ним работал) копировала файлы в специальную папку (как у меня релизная сборка). В результате, пока ты не запустишь из консоли билд (который довольно долгий), изменения в браузере не посмотришь. Может сейчас он это уже изменил, не знаю.
В своем стартере я старался сделать максимально простую и прозрачную систему, чтобы в ней легко было разобраться. Я намеренно оставил ряд вещей не автоматизированными (например, редактирование index.html), дабы не плодить громоздких gulp-конструкций.
Решения вида "черный ящик", конечно, хорошо, но только до тех пор пока все работает. Если что-то идет не так, то ты сразу же оказываешься в безвыходной ситуации. Остается только писать ишью, на которые неизвестно когда ответят. Поэтому для продакшена мне страшновато использовать Angular CLI. Может быть когда-нибудь, когда она станет совсем стабильной (как Ember CLI)...
Ох не возьмусь оправдывать Angular, его сложность и размеры действительно пугают. Хотя вот Ember еще больше, только там кажется даже tree-shaking не применишь. Оставлю только вот эту ссылочку в защиту Angular. Все-таки, как не крути, а есть у Ангуляра киллер-фичи. За одну изоляцию CSS я готов с ним мириться.
Для vim тоже есть плагин. Если нужно что-то быстро поправить без настройки рабочей среды, можно запустить из консоли gulp build-dev --color, это запустит компиляцию всего.
На крайняк можно запустить tsc --watch, но добавлять это в стартер я бы не стал по все тем же причинам — никогда не знаешь, что и как ты получишь, все зависит от порядка и скорости нажатия Ctrl+S.
О какой IDE речь? Из коробки кажется только VS поддерживает, в остальных нужно ставить плагины. Без compile-on-save вся идея dev-окружения теряет смысл. Проще тогда взять тот же Angular CLI и не париться.
Browsersync у меня как-то не прижилось — мне кажется нерациональным гонять браузер постоянно (ноутбук относительно слабый). Сохраняю я часто, а переключаюсь на браузер гораздо реже. Да и вообще, не очень доверяю подобной автоматике — F5 надежнее, все под контролем. Впрочем, если есть интерес, с удовольствием замержу пулреквест (при условии что browsersync будет запускаться отдельной командой).
Как раз следующая тема, с которой хотел разробраться — это серверный рендеринг. Lazy loading без code splitting смысла особо не имеет к сожалению. Кстати, как у webpack получается сплиттить, кто-нибудь пробовал? Гугл говорит вроде умеет, но интересно как это на практике.
Имхо, нужно задать больше вопросов, каждый из которых будет в общем об одном и том же, но сформулированы они по разному. Один вертикальный, другой горизонтальный, третий еще какой-нибудь. Из нескольких ответов больше вероятность интерполировать адекватный приоритет.
Еще идея — сделать поле "важность". Если пользователь ставит высокую важность, то запускается какой-то процесс, для выяснения действительной важности вопроса. Например, по варианту 1 — специалист ТП связывается с пользователем, и приоритет. Ведь, главная проблема в том, что важные вопросы могут простаивать.
Однако если вы используете Angular 2, то ваша система сборки уже может содержать в себе реализацию Reflect, и после установки пакета reflect-metadata вы можете получить runtime ошибку Unexpected value 'YourComponent' exported by the module 'YourModule'. В этом случае лучше установить только typings.
В этом плане JavaScript похож на SmallTalk, который прародитель ООП, и который некоторые называют образцовым ООП-языком. Все объекты, в том числе и классы, и функции. Так что, это скорее современные языки отошли от "классического" ООП в пользу удобства и практичности.
Интересно, на сколько же у Вас сложная логика на клиенте, что начинает сказываться производительность JS? Обычно тормозит DOM, или чудовищные алгоритмы (вроде неумеренных вотчей в Angular 1). И как Вы находите те самые 20% кода, которые выполняются 80% времени?
Интерфейсы, как минимум, имеют смысл только при статической типизации. А статическая типизация основной профит имеет, когда язык компилируемый. Мне нравится, как в TypeScript все это сделали, там и интерфейсы, и статическая типизация, и компиляция, и классы можно объявлять в синтаксисе ES6 компилируя в ES5, или даже ES3.
Вообще так Гугл и Яндекс знают не только где я залогинен, но все чем я интересовался в последнее время. Стоит поискать какой-то товар, как сразу все рекламные блоки наполняются соответствующей рекламой. Если не параноить со всякими RequestPolicy, то приватность в интернете штука вообще весьма относительная.
То есть, Вы считаете, что в промышленной разработке все "настолько просто", что заботиться о читаемости кода не нужно?
Я соглашусь, что Реакт дает больше гибкости. Можно, например, вынести часть рендеринга в метод, и переопределить его в дочернем классе. Вопрос в том, как часто нужна такая гибкость? Все-таки, 80% веба это простой контент, без особых замороченных контролов.
Я бы сравнил Реакт с электролобзиком, тогда как Ангуляр — бензопила. Если надо валить лес — бери бензопилу, если вырезать фигурки из дерева — бери лобзик. В идеале, мне кажется рано или поздно эти две технологии так или иначе сольются в одну.
Как интересно вы выразились. Значит веб априори менее качествен чем десктоп? Как вы определяете качество в данном случае?: )
А какого рода проблемы? Можете привести случаи из жизни?
Seed проект Minko мне не понравился по двум причинам:
В своем стартере я старался сделать максимально простую и прозрачную систему, чтобы в ней легко было разобраться. Я намеренно оставил ряд вещей не автоматизированными (например, редактирование index.html), дабы не плодить громоздких gulp-конструкций.
Решения вида "черный ящик", конечно, хорошо, но только до тех пор пока все работает. Если что-то идет не так, то ты сразу же оказываешься в безвыходной ситуации. Остается только писать ишью, на которые неизвестно когда ответят. Поэтому для продакшена мне страшновато использовать Angular CLI. Может быть когда-нибудь, когда она станет совсем стабильной (как Ember CLI)...
Ох не возьмусь оправдывать Angular, его сложность и размеры действительно пугают. Хотя вот Ember еще больше, только там кажется даже tree-shaking не применишь. Оставлю только вот эту ссылочку в защиту Angular. Все-таки, как не крути, а есть у Ангуляра киллер-фичи. За одну изоляцию CSS я готов с ним мириться.
Для vim тоже есть плагин. Если нужно что-то быстро поправить без настройки рабочей среды, можно запустить из консоли
gulp build-dev --color, это запустит компиляцию всего.На крайняк можно запустить
tsc --watch, но добавлять это в стартер я бы не стал по все тем же причинам — никогда не знаешь, что и как ты получишь, все зависит от порядка и скорости нажатия Ctrl+S.О какой IDE речь? Из коробки кажется только VS поддерживает, в остальных нужно ставить плагины. Без compile-on-save вся идея dev-окружения теряет смысл. Проще тогда взять тот же Angular CLI и не париться.
Browsersync у меня как-то не прижилось — мне кажется нерациональным гонять браузер постоянно (ноутбук относительно слабый). Сохраняю я часто, а переключаюсь на браузер гораздо реже. Да и вообще, не очень доверяю подобной автоматике — F5 надежнее, все под контролем. Впрочем, если есть интерес, с удовольствием замержу пулреквест (при условии что browsersync будет запускаться отдельной командой).
Как раз следующая тема, с которой хотел разробраться — это серверный рендеринг. Lazy loading без code splitting смысла особо не имеет к сожалению. Кстати, как у webpack получается сплиттить, кто-нибудь пробовал? Гугл говорит вроде умеет, но интересно как это на практике.
Была статья на эту тему How it feels to learn JavaScript in 2016: ))
И что происходит? Останавливается предыдущая сборка и запускается новая?
Имхо, нужно задать больше вопросов, каждый из которых будет в общем об одном и том же, но сформулированы они по разному. Один вертикальный, другой горизонтальный, третий еще какой-нибудь. Из нескольких ответов больше вероятность интерполировать адекватный приоритет.
Еще идея — сделать поле "важность". Если пользователь ставит высокую важность, то запускается какой-то процесс, для выяснения действительной важности вопроса. Например, по варианту 1 — специалист ТП связывается с пользователем, и приоритет. Ведь, главная проблема в том, что важные вопросы могут простаивать.
Это и не предлагалось.
В этом плане JavaScript похож на SmallTalk, который прародитель ООП, и который некоторые называют образцовым ООП-языком. Все объекты, в том числе и классы, и функции. Так что, это скорее современные языки отошли от "классического" ООП в пользу удобства и практичности.
Интересно, на сколько же у Вас сложная логика на клиенте, что начинает сказываться производительность JS? Обычно тормозит DOM, или чудовищные алгоритмы (вроде неумеренных вотчей в Angular 1). И как Вы находите те самые 20% кода, которые выполняются 80% времени?
Лихо Вы сбросили со счетов IE11 и ниже.
Интерфейсы, как минимум, имеют смысл только при статической типизации. А статическая типизация основной профит имеет, когда язык компилируемый. Мне нравится, как в TypeScript все это сделали, там и интерфейсы, и статическая типизация, и компиляция, и классы можно объявлять в синтаксисе ES6 компилируя в ES5, или даже ES3.
Мой косяк про ES7, убрал из статьи. Спасибо.
Спасибо, я смотрел все эти proposal, и так и не понял, приняли декораторы или нет. Жаль, конечно. Но все-таки stage 2 это уже немало.
Вообще так Гугл и Яндекс знают не только где я залогинен, но все чем я интересовался в последнее время. Стоит поискать какой-то товар, как сразу все рекламные блоки наполняются соответствующей рекламой. Если не параноить со всякими RequestPolicy, то приватность в интернете штука вообще весьма относительная.
То есть, Вы считаете, что в промышленной разработке все "настолько просто", что заботиться о читаемости кода не нужно?
Я соглашусь, что Реакт дает больше гибкости. Можно, например, вынести часть рендеринга в метод, и переопределить его в дочернем классе. Вопрос в том, как часто нужна такая гибкость? Все-таки, 80% веба это простой контент, без особых замороченных контролов.
Я бы сравнил Реакт с электролобзиком, тогда как Ангуляр — бензопила. Если надо валить лес — бери бензопилу, если вырезать фигурки из дерева — бери лобзик. В идеале, мне кажется рано или поздно эти две технологии так или иначе сольются в одну.
Angular 2 все Ваши пункты покрывает с горкой.