Если гоборить о «interface first», то мы сразу создаем эндпойнты и апи-модели, так и документацию можем сразу сгенерировать, и сервер сразу поднять, при необходимости даже модели через рефлекшн заполнять. Плюс, что спорно конечно, но мне ужасно не нравится когда api документация и код разделены. Ну и в конце концов, так час-другой обсуждений и api frontend готов.
Нет, это просто подключение к удалённому браузерному движку. Вот например как можно удобно дебажить сайты и PhoneGap приложения на андроиде: developer.chrome.com/devtools/docs/remote-debugging. Можно ли похожим механизмом подключаться к приложению на боксе?
Я, например, уже давно html не использую. MaskJS имеет более лаконичный синтаксис, поддерживает декларацию компонент, наследование, merge шаблонов, модули — импорт/экспорт компонент, scope компонент; загрузка данных, скриптов и стилей; друсторонний байндиг, и много всего другого.
А у нас совсем другой подход. Используются в системе `file accessor middlewares`: У статического сервера (если разрабатывается лишь front-end вэб приложение) или у обычного бэкэнда (разрабатываем на nodejs) есть плагины (или прослойки на чтение файлов). Например все `*.es6` на лету компилируются в ecmascript 5. За файловым расширением может быть зарегистрировано несколько прослоек: трансформировать все `if conditional comments`, a потом трансформировать в ecmascript 5.
Плюсы:
— Трансформации принимаются по шаблону имени файла, например только с расширением `es6`
— Приложение и система сборки не зависит от содержимого самого файла,
— «Совместное существование и легкий переход». Мы просто переименовываем `*.js` в `*.es6` и всё работает как обычно, учитывая что ес6 обратно совместим, но мы можем и переименовать в `*.coffee` и подправить содержимое.
— Система кеширование файлов и file watchers позволяют только один раз трансформировать файл, а при изменение просто файл «перечитать».
— Такой же подход используется одинаково для *.less, *.yml файлов — достаточно лишь установить плагин.
А при чём здесь шаблонизатор? Я говорю о более чистом разделение ответственности, ведь иначе пример из главной похож больше не на «JavaScript фреймворк для программистов», а на «JavaScript фреймворк для верстальщиков». Никаким образом нельзя смешивать селекторы для стилизации и селекторы для связывания. И последние должны также выделяться префиксом для явности.
Ладно «убирание», но ведь таким образом мы ставим контроллер в зависимость от шаблона. Здесь программист должен заранее подумать какой селектор потом будет или уже есть в шаблоне. Как минимум, лучше объявить соглашение: Связь «свойство-елемент» создается через селектор, например, ".bind-NAME". Тогда можно будет и «автоматом» связывать шаблон и модель, как это обычно делается, а на случай экзотического поведения уже вручную связывать некоторые свойства с элементами по селектору. Скажем такое поведение уже на порядок лучше:
<input type="text" class="bind-foo">
<script>
var app = new Matreshka({
foo : null
});
app.foo = 'Двустороннее связывание данных в JS? Серьезно?';
</script>
Возможно идиотские вопросы, но от темы пока что далёк) Интересно узнать насколько это опасно пересекать океан на столь небольшом катамаране? Весь путь прошли под парусами?
Изначально да, но если вы в хроме посмотрите пример, то там вам и треугольничек и «зазырил» все варианты ) А в других браузерах отсутствует лишь треугольник. Конечно, это ещё не идеальное решение, но эволюция вэба идет семимильными шагами.
Может на статью хорошую кто и укажет, дам пару ссылок на фреймворки: Derby, Meteor, React тоже можно запускать и рендерить на ноде. Ну и мы тоже немного разрабатываем такой подход: MaskJS, в целом это фронтэнд фреймворк, но также есть модуль который те же компоненты рендерит на ноде, а далее в браузере восстанавливает компоненты, как если бы они рендерелись на клиенте. Может немного запутано, но можно посмотреть несколько примеров в репозитории: Mask.Node
Очень много таковых появилось для NodeJS. При первом запросе компоненты генерируются на сервере, в браузере происходит лишь инициализация компонент, далее компоненты могут отсылать/запрашивать данные, и обновлять себя, и рендерить другие компоненты.
Я понимаю, что вы хотите сделать, но вы через чур вдаетесь в детали — нужно подняться немного выше)
— Сеттеры/Геттеры — по моему опыту, они должны быть очень легкими, лишь манипуляция полями своего объекта и отсылка событий, в противном случае код и архитектура становятся запутанными и не явными.
— Методы — вот здесь имеет место разговор о асинхронности, но что при этом выполняется абсолютно не важно, потому что абстракции предполагают что мы можем, например, использовать разный транспорт для сохранения объекта. И не важно будь то удалённый вызов процедур, запись в локальную базу или ещё что-то там.
Как для меня, самым лучшим вариантом является ваш третий вариант, но модифицирован — Promise но с async/await. Также как сейчас в C# Task<T>var user = await Service.Fetch(params);. ES7 движется в этом направлении, и с traceur уже можно с этим играться.
Похоже вышло недопонимание. > А вы предлагаете все действия проводить синхронно, блокируя поток в однопоточном JS? :)
Я предлагаю совсем не проводить никаких тяжёлых действий в сеттерах.
> Вы считаете лапшу из коллбэков более предсказуемой, чем async / await и обещания?
Между каких строк вы это увидели? :). Совсем нет, но автор комментария предлагает вовсе отказаться от ключевых слов — async/await, и в дополнение речь шла не только о асинхронных функциях, но и сеттерах.
:) Уже давно клинки сточили о «тяжелые сеттеры», а вы ещё предлагаете асинхронные действия проводить. Рай, он может так со стороны кажеться, а оказавшись там — увидите, что код станет абсолютно не предсказуем. Явное лучше неявного, особенно в js.
Используете
Chrome Developer Toolsчерезchrome://inspectдля профилирования и дебага? Все приставки поддерживают remote protocol?Плюсы:
— Трансформации принимаются по шаблону имени файла, например только с расширением `es6`
— Приложение и система сборки не зависит от содержимого самого файла,
— «Совместное существование и легкий переход». Мы просто переименовываем `*.js` в `*.es6` и всё работает как обычно, учитывая что ес6 обратно совместим, но мы можем и переименовать в `*.coffee` и подправить содержимое.
— Система кеширование файлов и file watchers позволяют только один раз трансформировать файл, а при изменение просто файл «перечитать».
— Такой же подход используется одинаково для
*.less,*.ymlфайлов — достаточно лишь установить плагин.Пример `babel` плагина: Loader.Babel
Ладно «убирание», но ведь таким образом мы ставим контроллер в зависимость от шаблона. Здесь программист должен заранее подумать какой селектор потом будет или уже есть в шаблоне. Как минимум, лучше объявить соглашение: Связь «свойство-елемент» создается через селектор, например, ".bind-NAME". Тогда можно будет и «автоматом» связывать шаблон и модель, как это обычно делается, а на случай экзотического поведения уже вручную связывать некоторые свойства с элементами по селектору. Скажем такое поведение уже на порядок лучше:
<input list>: jsfiddle; caniuse «datalist»?Изоморфные фреймворки
Очень много таковых появилось для NodeJS. При первом запросе компоненты генерируются на сервере, в браузере происходит лишь инициализация компонент, далее компоненты могут отсылать/запрашивать данные, и обновлять себя, и рендерить другие компоненты.
— Сеттеры/Геттеры — по моему опыту, они должны быть очень легкими, лишь манипуляция полями своего объекта и отсылка событий, в противном случае код и архитектура становятся запутанными и не явными.
— Методы — вот здесь имеет место разговор о асинхронности, но что при этом выполняется абсолютно не важно, потому что абстракции предполагают что мы можем, например, использовать разный транспорт для сохранения объекта. И не важно будь то удалённый вызов процедур, запись в локальную базу или ещё что-то там.
Как для меня, самым лучшим вариантом является ваш третий вариант, но модифицирован — Promise но с async/await. Также как сейчас в C#
Task<T>var user = await Service.Fetch(params);. ES7 движется в этом направлении, и с traceur уже можно с этим играться.> А вы предлагаете все действия проводить синхронно, блокируя поток в однопоточном JS? :)Я предлагаю совсем не проводить никаких тяжёлых действий в сеттерах.
> Вы считаете лапшу из коллбэков более предсказуемой, чем async / await и обещания?Между каких строк вы это увидели? :). Совсем нет, но автор комментария предлагает вовсе отказаться от ключевых слов — async/await, и в дополнение речь шла не только о асинхронных функциях, но и сеттерах.
↓