Приложения любой степени сложности на, например, упомянутой nodejs можно писать на нативном ES6 безо всех этих костылей. JavaScript сегодня — не только браузер. Тут уже скорее вся остальная появившаяся инфраструктура приводит к появлению костылей для того чтобы в браузере работало "как там".
С другой стороны я гружу только один язык, а не язык + ключ на каждую фразу, когда работаю с языком по умолчанию. А в способе из статьи это точно всегда будет язык + ключи.
Да, но по идее это должно отслеживаться какой-то автоматикой.
В вышеприведенном Jed это решено и выглядит так:
i18n.translate("%d key doesnt exist").ifPlural( n, "%d keys dont exist" ).fetch();
https://slexaxton.github.io/Jed/ — что-то нашлось. Приделать удобный псевдоним в глобальное пространство (window.t, например) и какую-нибудь очень простую вещь, которая будет ловить все фразы, туда попадающие и выдавать по каким уже есть перевод, а по каким еще нет — и можно почти не терять времени на поддержку версий для разных языков.
А существуют ведь наверняка библиотеки интернационализации для js, которые не заставляют самостоятельно объявлять ключи, а используют в качестве ключа саму фразу на языке «по умолчанию»? (что-то вроде PHP-шного gettext).
Мне такой подход кажется куда более удобным, особенно если имеется удобные инструменты для собственно процесса перевода.
Правильно понимаете, но он не просто так сложился, так получилось и удобнее и чище. Начинал я с отдельного класса для компонент, имплементирующего angular.IComponentOptions, в который надо было импортировать отдельный «component view controller»
А у нас всего два фронтенд-девелопера, при этом поток запрашиваемых и реализуемых фич не остановить.
В этом решении я аккуратно обновил версию основной библиотеки, починил все, что вылезло при обновлении, убрал какие-то deprecated вещи в небольшом количестве, настроил обвязку и в «legacy» части проекта в общем ничего более не менял, она как работала, так и работает. А весь новый функционал уже разрабатывается в приближенном к angular 2 стиле.
Есть еще изощренные варианты с параллельным существованием двух версий angular в проекте, но наш клиентский код итак уже распух сверх всяких мер.
Angular 1.5 — это хороший шаг для начала затяжной миграции. Будут следующие релизы, которые добавят еще больше совместимости между версиями. Функционал потихоньку переписывается согласно рекомендациям из upgrade гайда и я тешу себя надеждой что в каком-то будущем мы осуществим переход.
Со всевозможными штуками, которые дает связка из TypeScript и ES6, javascript становится очень и очень приятным в работе. (Правда мне js и без них нравился)
Тут где-то должен быть водораздел. Разработчик должен написать сборку (точно шаги 6, 7 и вполне вероятно шаги 3, 4, 5 из вашего списка), с учетом всех нюансов работы в dev/prod/stage режимов, девопс должен написать все остальное и интегрировать в CI систему.
Через npm как правило ставят зависимости именно для сборки фронтенда. Сторонние библиотеки, которые используются непосредственно в работе клиента (типа jQuery или Angular) подтягиваются через bower как правило.
Перевод проекта на Typescript/Dart совсем не мешает вам писать на vanilla JS. Но при правильном подходе привносит в ваш код немалую толику самодокументируемости, статическую типизацию, статический анализ, отлов самых простых ошибок еще на этапе компиляции.
Если комбинировать его с мощью ES6 — то получается совсем хорошо.
Немножко не в тему — это не готовый бот, это система, которая позволит в пару (десятков) кликов создать вам своего собственного slack-бота на мощностях api.ai
А я 100%-й самоучка, по образованию инженер-конструктор (в смысле железа). И очень часто сильно жалею об отсутствии профильного образования. Просто иногда, не смотря на годы практики и долгий и упорный рост из джуниора, десятки больших и не очень завершенных проектов и прочая и прочая, не хватает знания какой-то базовой вещи.
Приложения любой степени сложности на, например, упомянутой nodejs можно писать на нативном ES6 безо всех этих костылей. JavaScript сегодня — не только браузер. Тут уже скорее вся остальная появившаяся инфраструктура приводит к появлению костылей для того чтобы в браузере работало "как там".
На днях писал статью (правда она скорее про настройку окружения и про то, как с этим жить).
Про компоненты сами по себе вот тут отлично написали.
Мой велосипед уже в продакшене, полет нормальный. Самодельные декораторы стоит заменить на ng-metadata
Добавьте чуть-чуть ng-annotate и просто разделите код, получится тоже самое, но гораздо лучше:
А если добавить es6, typescript и немного декораторов, то будет совсем здорово.
А в чем проблема?
gulp.src('path/to/file').pipe(ugilfy()).pipe(gulp.dest('path/to/build'));i18n.translate("%d key doesnt exist").ifPlural( n, "%d keys dont exist" ).fetch();Мне такой подход кажется куда более удобным, особенно если имеется удобные инструменты для собственно процесса перевода.
Правильно понимаете, но он не просто так сложился, так получилось и удобнее и чище. Начинал я с отдельного класса для компонент, имплементирующего angular.IComponentOptions, в который надо было импортировать отдельный «component view controller»
А у нас всего два фронтенд-девелопера, при этом поток запрашиваемых и реализуемых фич не остановить.
В этом решении я аккуратно обновил версию основной библиотеки, починил все, что вылезло при обновлении, убрал какие-то deprecated вещи в небольшом количестве, настроил обвязку и в «legacy» части проекта в общем ничего более не менял, она как работала, так и работает. А весь новый функционал уже разрабатывается в приближенном к angular 2 стиле.
Есть еще изощренные варианты с параллельным существованием двух версий angular в проекте, но наш клиентский код итак уже распух сверх всяких мер.
Angular 1.5 — это хороший шаг для начала затяжной миграции. Будут следующие релизы, которые добавят еще больше совместимости между версиями. Функционал потихоньку переписывается согласно рекомендациям из upgrade гайда и я тешу себя надеждой что в каком-то будущем мы осуществим переход.
Через npm как правило ставят зависимости именно для сборки фронтенда. Сторонние библиотеки, которые используются непосредственно в работе клиента (типа jQuery или Angular) подтягиваются через bower как правило.
Ну и да, в список еще клиетнские зависимости надо добавить (которые через bower install) и что-то, что из разберет по нужным папкам.
Если комбинировать его с мощью ES6 — то получается совсем хорошо.
Про него написана замечательная книга, которую можно найти и на русском языке.