+- 10% от рынка тут мало (когда нужны деньги можно взять небольшую шабашку на +10-20% к ЗП и это получается более гибкая схема), но если это ультимативно рынок +50-100% то звучит уже разумно, ну и конечно отличный коллектив, вменяемый начальник и интересная работа
да-да, согласен
просто очень важно, что пришел игрок, который может помочь вылизать код + создать инфраструктуру, если бы сейчас все было хорошо, то приход гугла не был бы новостью)
а сильно больше и не надо — сахар, чуть слаще и все
Я знаю, что грех, но иногда использую => для сохранения контекста + возможность перекинуть if & for в конец строки — радует, реально меньше строчек и часто файл умещается в экран
Плюс очень приятные проверки a = obj?.field1?.field2
Код получается простой и понятный и после 2-ух недель на coffeescript.org ты четко понимаешь какую конструкцию в js получишь
PS Меня в нем бесит if a then value1 else value2, вместо прекрасного a? value1: value2, а так все ок
ru.wikipedia.org/wiki/Model-View-ViewModel
Мне кажется, что прелесть идеи в том, что мы декларативно (в верстке) задаем как отображать модель пользователю, правда в wpf это доведено до «абсурда» — XAML прекрасен. Среди веб фреймворков я бы назвал backbone, как максимально близкую реализацию классического MVVM.
У меня есть небольшой проект bindit, как раз для веб-проектов, это не совсем чистый MVVM, но вдохновение я черпал оттуда. Вчера довел библиотеку до версии 0.3 и скоро напишу статью на эту тему.
На самом деле большинство браузеров уже поддерживают их.
Но претензия звучит так — представьте метод который меняет 20-30 полей в модели и будет 20-30 строк типа
Начну с критики, но ее следует воспринимать, как IMHO
1. Мне кажется более естественным использовать деклоративный binding (мы все равно никуда от html не уйдем, так почему бы не указывать модель там)
2. Может мне показалось, но в данном фреймворке достаточно трудно будет повторно использовать ViewModel
3. Я немного укушен ember и мне тоже не нравиться объект js (как-то оно слишком сложно)
4. Основная проблема всех шаблонизаторов, что мы не можем просто получить дочерний элемент из созданного элемента — хотелось бы видеть в библиотеке решение
Теперь немного похвалы. На самом деле, я понимаю, насколько это огромная работа и очень мощно, что Вы за нее взялись и довели до рабочего состояния.
Ну и в конце вопрос:
1. Как Вы тестируете код на кроссбраузерность? У меня в аналогичном проекте проблема: хочу чтобы оно работало во всех основных браузерах, но не хочу руками тестировать этот момент — как-то оно дорого по трудозатратам.
И да — я голосую за javascript.
Вполне в духе раннего Джобса
просто очень важно, что пришел игрок, который может помочь вылизать код + создать инфраструктуру, если бы сейчас все было хорошо, то приход гугла не был бы новостью)
Я знаю, что грех, но иногда использую => для сохранения контекста + возможность перекинуть if & for в конец строки — радует, реально меньше строчек и часто файл умещается в экран
Плюс очень приятные проверки a = obj?.field1?.field2
Код получается простой и понятный и после 2-ух недель на coffeescript.org ты четко понимаешь какую конструкцию в js получишь
PS Меня в нем бесит if a then value1 else value2, вместо прекрасного a? value1: value2, а так все ок
Мне кажется, что прелесть идеи в том, что мы декларативно (в верстке) задаем как отображать модель пользователю, правда в wpf это доведено до «абсурда» — XAML прекрасен. Среди веб фреймворков я бы назвал backbone, как максимально близкую реализацию классического MVVM.
У меня есть небольшой проект bindit, как раз для веб-проектов, это не совсем чистый MVVM, но вдохновение я черпал оттуда. Вчера довел библиотеку до версии 0.3 и скоро напишу статью на эту тему.
+ он умеет запускать только selenium тесты, а у меня все на qunit — придется их как-то дружить
смотрится лучше чем
Но претензия звучит так — представьте метод который меняет 20-30 полей в модели и будет 20-30 строк типа
то есть работа с моделью отличается от принятого в языке стандарта
1. Мне кажется более естественным использовать деклоративный binding (мы все равно никуда от html не уйдем, так почему бы не указывать модель там)
2. Может мне показалось, но в данном фреймворке достаточно трудно будет повторно использовать ViewModel
3. Я немного укушен ember и мне тоже не нравиться объект js (как-то оно слишком сложно)
4. Основная проблема всех шаблонизаторов, что мы не можем просто получить дочерний элемент из созданного элемента — хотелось бы видеть в библиотеке решение
Теперь немного похвалы. На самом деле, я понимаю, насколько это огромная работа и очень мощно, что Вы за нее взялись и довели до рабочего состояния.
Ну и в конце вопрос:
1. Как Вы тестируете код на кроссбраузерность? У меня в аналогичном проекте проблема: хочу чтобы оно работало во всех основных браузерах, но не хочу руками тестировать этот момент — как-то оно дорого по трудозатратам.