Ну собственно, да, тоже не вижу особого смысла: у телефонов (т.е. как раз там, где актуальны ограничения по трафику) высокая плотность как раз быстрее зафиксируется, чем у мониторов. В итоге, получится, а для кого старались?
По джаваскрипту — ну тут просто библиотеки вроде jQuery подтянутся. Разбор строки — всё-таки куда менее затратная операция, чем обращение к элементам DOM, так что с этой точки зрения ничего страшного тут не случится.
В определённом смысле, да, но плотность будет примерно одинаковой (как была примерно одинаковой до появления ретины). То есть в итоге скорее всего получится условные x1 для легаси-устройств (а они понятно ещё долго будут в употреблении) и условные x2 для современных. Потом окажется, что x1 не нужен и останется только x2. Я к тому, что другие значения вряд ли кому понадобятся.
Я думаю, через какое-то время все перейдут на «ретиновую» плотность, и вопрос отпадёт сам собой: всё, что меньше, выйдет из употребления, а больше просто не нужно.
А вот размещу-ка ссылку в порядке самопиара: http://sourcetalk.net/
Идея в чём-то пересекается, но не идентична. Сервис позволяет обсуждать исходный код в браузере с синхронизацией выделения и полосы прокрутки между всеми участниками. Варианты применения: code review, обучение новых сотрудников, расшаривание кода, обсуждение возникающих вопросов и т.д. — сервис старались делать максимально простым и гибким, не заточенным под какой-то конкретный сценарий.
Есть плагины для SublimeText 2 и Emacs, на подходе ещё несколько (плагины пока только позволяют создавать конференцию с текущим кодом в браузере, но планируем более тесную интеграцию).
В планах интеграция с GitHub и BitBucket.
На самом деле, суть сингулярности в том, что понять, что будет после, невозможно: мы не можем спрогнозировать ход мысли интеллекта, более мощного, чем наш собственный.
Возможно, её наступления просто не допустят: слишком велика неопределённость. Как в том же Нейроманте: «этим тварям никто не доверяет».
Гибсон много чего напредсказывал верно, а Нейромант 30 лет назад написан.
Тут во многом от интуиции «предсказателя» зависит. Хотя для большинства людей это горизонт в 3-5 лет, да, а то и меньше.
А смысл в этих todo? Они ничего не показывают. Хороший фреймворк для написания todo != хороший фреймворк для написания сложных приложений.
Приложения — это во-первых, данные, во-вторых, бизнес-логика. И только в третьих — представление. Именно поэтому все UX-центричные фреймворки я недолюбливаю. В качестве дополнения к Backbone (где в центре внимания данные и логика) — да, хорошо. В качестве замены — нет, спасибо.
Ну позиция понятна, но мигрировать с бэкбона на маску я точно не собираюсь. Если бы хотел мигрировать, выбрал бы Angular, но я уже обозначил выше, что идеологически бэкбон мне намного ближе.
В качестве шаблонизатора с байндингом/компонентами поюзал бы, но нет так нет.
Вопрос-то очень простой: если не использовать бэкбоновские модели, тогда зачем бэкбон? Если не использовать байндинги, тогда зачем маска (односторонних шаблонизаторов для бэкбона пруд пруди)?
Я поэтому и спросил, можно ли использовать вместе. Получается, фактически нельзя.
Так где же «модель может выглядеть как угодно», если вы мне ответом выше сказали «не используйте бэкбоновские модели», и здесь говорите, что байндинги с ними работать не будут?
Это плохой вариант, в Backbone на модели завязано очень многое, в том числе и фетчинг. То есть фетч там забирает данные сразу в модель, а вы мне говорите, не используйте бэкбоновские модели. Всю работу с серверной частью вы предлагаете вынести в голые Ajax-запросы? Во-первых, это шаг назад, во-вторых, от бэкбона тогда остаётся только роутер, то есть это никак не тянет на «использовали маску с бэкбоном». Да и использовать бэкбон только ради роутера смысла нет, роутер можно и отдельно найти.
В общем, советую пересмотреть концепцию: пока получается, что на серьёзных проектах использовать «голую» маску большого смысла нет, так как она не решает значительной части актуальных задач, а гибкости для сочетания с фреймворками, которые эти задачи решают, не хватает.
Чтобы мне долго не разбираться (идея навскидку неплохая, но времени сейчас нет) — пробовали ли сочетать с Backbone.js? Раз уж за мейнстримом следите.
Скажем, Backbone мне по идеологии нравится значительно больше аналогов, но по части работы с DOM он безнадёжно отстал от жизни (из основного: нет встроенной системы байндинга, нет компонент). Если использовать Backbone для роутинга/фетча а Mask для отрисовки, много ли придётся дорабатывать напильником? Скажем, обращение к атрибутам модели там только через параметризованные геттеры: model.get( «someAttr» ). Mask это сможет обрабатывать, включая отслеживание изменений?
И да, плюсую по предыдущему комментарию: синтаксис шаблонов действительно избыточен.
Ну не знаю насчёт самый функциональный, он по большому счёту даже со всем допиливаниями и плагинами не умеет (или умеет криво) многое из того, что современные редакторы делают из коробки и без лишнего напряга (нет, понятно, что теоретически к нему можно прикрутить абсолютно любую функциональность). Тот же multimode совершенно кошмарен, я в конце концов от него отказался, т.к. головной боли больше, чем пользы.
Я Emacs юзаю в основном за то, что при всех недостатках это очень удобный текстовый редактор. Который поставленную перед ним задачу — редактирование текста — решает лучше, чем всё остальное, что мне довелось пробовать. А всё остальное… ну не знаю, каждый новый плагин — это в первую очередь куча глюков и нестыковок с уже собранным зоопарком при спорной пользе. Скажем, автодополнение я даже не пытался к Emacs прикручивать и на удивление никакого дискомфорта от этого после перехода с Eclipse не испытал: мне проще набить название метода/переменной/класса по памяти, чем ждать, пока редактор протормозится и родит список вариантов, потом просмотреть список и убедиться, что нужный вариант присутствует, и затем выбрать его из списка.
Разве этот вопрос не решается выплатой процента с продаж? Я вполне готов переплатить за шарик. Думаю, я не одинок, поскольку в премиальном сегменте яблочная продукция задаёт тренды, к ней многие привыкли.
По джаваскрипту — ну тут просто библиотеки вроде jQuery подтянутся. Разбор строки — всё-таки куда менее затратная операция, чем обращение к элементам DOM, так что с этой точки зрения ничего страшного тут не случится.
http://sourcetalk.net/
Идея в чём-то пересекается, но не идентична. Сервис позволяет обсуждать исходный код в браузере с синхронизацией выделения и полосы прокрутки между всеми участниками. Варианты применения: code review, обучение новых сотрудников, расшаривание кода, обсуждение возникающих вопросов и т.д. — сервис старались делать максимально простым и гибким, не заточенным под какой-то конкретный сценарий.
Есть плагины для SublimeText 2 и Emacs, на подходе ещё несколько (плагины пока только позволяют создавать конференцию с текущим кодом в браузере, но планируем более тесную интеграцию).
В планах интеграция с GitHub и BitBucket.
Возможно, её наступления просто не допустят: слишком велика неопределённость. Как в том же Нейроманте: «этим тварям никто не доверяет».
Тут во многом от интуиции «предсказателя» зависит. Хотя для большинства людей это горизонт в 3-5 лет, да, а то и меньше.
Приложения — это во-первых, данные, во-вторых, бизнес-логика. И только в третьих — представление. Именно поэтому все UX-центричные фреймворки я недолюбливаю. В качестве дополнения к Backbone (где в центре внимания данные и логика) — да, хорошо. В качестве замены — нет, спасибо.
В качестве шаблонизатора с байндингом/компонентами поюзал бы, но нет так нет.
Я поэтому и спросил, можно ли использовать вместе. Получается, фактически нельзя.
В общем, советую пересмотреть концепцию: пока получается, что на серьёзных проектах использовать «голую» маску большого смысла нет, так как она не решает значительной части актуальных задач, а гибкости для сочетания с фреймворками, которые эти задачи решают, не хватает.
Скажем, Backbone мне по идеологии нравится значительно больше аналогов, но по части работы с DOM он безнадёжно отстал от жизни (из основного: нет встроенной системы байндинга, нет компонент). Если использовать Backbone для роутинга/фетча а Mask для отрисовки, много ли придётся дорабатывать напильником? Скажем, обращение к атрибутам модели там только через параметризованные геттеры: model.get( «someAttr» ). Mask это сможет обрабатывать, включая отслеживание изменений?
И да, плюсую по предыдущему комментарию: синтаксис шаблонов действительно избыточен.
Я Emacs юзаю в основном за то, что при всех недостатках это очень удобный текстовый редактор. Который поставленную перед ним задачу — редактирование текста — решает лучше, чем всё остальное, что мне довелось пробовать. А всё остальное… ну не знаю, каждый новый плагин — это в первую очередь куча глюков и нестыковок с уже собранным зоопарком при спорной пользе. Скажем, автодополнение я даже не пытался к Emacs прикручивать и на удивление никакого дискомфорта от этого после перехода с Eclipse не испытал: мне проще набить название метода/переменной/класса по памяти, чем ждать, пока редактор протормозится и родит список вариантов, потом просмотреть список и убедиться, что нужный вариант присутствует, и затем выбрать его из списка.