• 0
    Судя по всему под гибридным подходом имеется именно PhoneGap/Cordova. Было бы интересно есть ли реальный опыт использования js + native views например: react native, titanium appcelerator или nativescript. Странно, что обошли эту тему стороной
    Натив или гибрид? Специалисты Яндекса отвечают на главный вопрос мобильной разработки
  • 0
    MVC — это разделение на M, V и С. А если коротко, то — разделение данных и представления. Ничего больше в этом подходе не подразумевается.

    То что подход многими реализуется через одно место, вовсе не означает, что это подразумевается подходом.
    Честный MVC на React + Redux
  • +2
    Уместно вспомнить про github.com/Microsoft/node
    Форк node.js использующий в качестве движка Chakra вместо V8,
    с полифилами для кода, заточенного под V8
    Исходный код JavaScript-движка Microsoft Edge будет открыт в январе
  • 0
    Кнопка воспроизведения, с режимом (а ещё с индикатором и устройством выключателя света), которая не обязана своим видом помогать что будет происходить (нет я не строил интуитивно понятный интерфейс — Раскин против) и есть оставшаяся за бортом большая часть идей? Серьёзно?
    Три правила проектирования интерфейсов с высокоскоростным пользовательским взаимодействием
  • 0
    О каких конкретно, оставшихся за бортом, идеях идет речь?
    Три правила проектирования интерфейсов с высокоскоростным пользовательским взаимодействием
  • 0
    не быстрые, а эффективные.

    задача чтобы и конструктор быстро исполнялся и сразу создавался правильный hidden class для объекта. задачи наследования, задачи получения доступа к неким общим свойствам не стоит
    Прокачиваем JavaScript с помощью TurboFan
  • +2
    «Prototype Chain всегда будет самым быстрым в JS»
    конечно же нет! youtu.be/tCG0aPNvkTs?t=10m39s
    всегда быстрей взять свойство непосредственно с объекта, чем с его прототипа

    особенно бессмысленно его использовать когда нужно создать сразу правильный hidden class для объектов у которых общий набор полей но значения полей у всех разные

    www.youtube.com/watch?v=tCG0aPNvkTs

    опять таки: задача сделать констуктор сравнительно эффективный такой же как
     function Point(x, y) {
       this.x = x;
       this.y = y;
    }
    


    при условии, что на этапе написания кода нет набора полей (this.x = x;), но он будет и будет ограничен после выполнения некоторого кода
    Прокачиваем JavaScript с помощью TurboFan
  • +1
    всё таки
    var MainArtist = function() {};
    
    _.forEach(artistProps, function(value, key){
        MainArtist[key] = value;
    })
    

    это не
    var MainArtist = function() {};
    
    _.forEach(artistProps, function(value, key){
        MainArtist.prototype[key] = value;
    })
    


    а наследование для задачи не нужно — нужны быстрые конструкторы
    Прокачиваем JavaScript с помощью TurboFan
  • +1
    var MainArtist = function() {};
    
    _.forEach(artistProps, function(value, key){
        MainArtist[key] = value;
    })
    


    а какой смысл в этом коде, если MainArtist[key] и (new MainArtist())[key] не имеют никакой связи?
    Прокачиваем JavaScript с помощью TurboFan
  • +1
    Оказалось, что Object.create для этой задачи бесполезен

    var mes = function(callback) {
      var start = new Date();
      callback();
      console.log('measure', new Date() - start);
    };
    
    var OldClass = function() {
      this.track = null;
      this.artist = null;
      this.full_title = null;
      this.url = null;
    };
    
    var artistProps = {
      track: { writable: true },
      artist: { writable: true },
      full_title: { writable: true },
      url: { writable: true}
    };
    
    mes(function() {
    	var items = [];
    	for (var i = 0; i < 1000000;i++) {
    		items.push(new OldClass());
    	}
    });
    
    mes(function() {
    	var items = [];
    	for (var i = 0; i < 1000000;i++) {
    		items.push(Object.create(null, artistProps));
    	}
    });
    


    measure 441
    measure 5436
    Прокачиваем JavaScript с помощью TurboFan
  • 0
    Спасибо за совет, не знал про второй аргумент Object.create. Думаю, это то что нужно для моей задачи, осталось проверить производительность. (а наследование для этой задачи не нужно)
    Прокачиваем JavaScript с помощью TurboFan
  • +1
    работает офлайн?
    История роутинга в проекте MAPS.ME
  • +1
    Для того чтобы автоматически создавать эффективные констукторы на базе которых будет создана тысяча другая объектов, набор полей которых ограничен (задаётся разработчиком не напрямую, но может быть определён с помощью алгоритма), но для которых крайне неудобно или невозможно написать тело на момент написания кода.

    Либо eval. Что не всегда возможно и просто небезопасно

    var evaledConstr = function(props) {
    
        var body = '"use strict";\n';
        for (var i = 0; i < props.length; i++) {
                body += 'this["' + props[i] + '"] = null;\n';
        }
        return new Function(body);
    };
    
    var EvaledConstr = evaledConstr(['track', 'artist', 'full_title', 'url']);
    
    new EvaledConstr();
    


    (как вы знаете браузерные движки очень хорошо оптимизируют такой код)
    var Contr = function(){
       this.myName = null;
    };
    


    Либо извращения с предварительной компиляцией.

    Либо оптимизации движком.
    Прокачиваем JavaScript с помощью TurboFan
  • +2
    Планируются ли оптимизации что бы можно было создавать генерируемые конструкторы, которые не сильно бы уступали в скорости инициализации обычным?

    Так что бы инициализация 1000 штук generatedClass1 или generatedClass2 не уступала OldClass

    var OldClass = function() {
      this.track = null;
      this.artist = null;
      this.full_title = null;
      this.url = null;
    }
    new OldClass();
    


    var getSetter = function(prop, callback) {
      return function(obj){
        obj[prop] = null;
        callback(obj);
      };
    };
    
    var realDyn = function(array) {
      // на основе списка свойств функция генерирует
      // функцию, которая не использует итерация
      var curSetter = function(){};
      for (var i = array.length - 1; i >= 0; i--) {
        curSetter = getSetter(array[i], curSetter);
      }
      return curSetter;
    };
    
    
    var gen = realDyn(['track', 'artist', 'full_title', 'url']);
    
    var GeneratedClass1 = function(){
      gen(this);
    };
    
    new GeneratedClass1();
    
    
    


    
    
    var make = function(array) {
      return function () {
        for (var i = 0; i < array.length; i++) {
          this[array[i]] = null;
        }
      };
    };
    
    var GeneratedClass2 = make(['track', 'artist', 'full_title', 'url']);
    new GeneratedClass2();
    
    
    Прокачиваем JavaScript с помощью TurboFan
  • 0
    Могут ли в этом конкурсе участвовать приложения, участвовавшие в другом конкурсе tizen? ( получил статус Honorable Mention в developer.tizen.org/ru/contests/tizen-app-challenge/music-video-entertainment-photo-and-font )
    Samsung объявляет конкурс Russia Tizen App Challenge для веб-разработчиков из России
  • +3
    Пост от лица компании, в корпоративном блоге. Тем не менее и у художника интересно было бы спросить что он думает о методах работы компании в которой он работает.
    Художник в игровой индустрии: организация рабочего процесса
  • 0
    Зачем вы свое поделие распространяете крайне навязчивыми средствами?
    Зачем вы устанавливаете «службу» которая висит и периодически запускает промо страницу на «Total Domination»?
    Почему ваше поделие нельзя удалить стандартными средствами?

    В интернете достаточно жалоб на внезапное и навязчивое появление на компьютерах «Total Domination» вы на это будете как-то реагировать?
    Художник в игровой индустрии: организация рабочего процесса
  • 0
    Если вы говорите о случае, когда вы загружаете структуру (шаблон) страницы отдельно, каждый раз заново, и всё это в приложении где вся логика интерфейса находится на клиентской стороне, то их можно загружать параллельно с данными. Но этом вообще речи не идёт.

    Речь идёт о приложениях в которых шаблоны, (структуры страниц) уже загружены к моменту когда пользователь начинает взаимодействовать с приложением. Эти принципы касаются и полноценных веб приложений и нативных приложений.

    Посмотрите сами seesu.me/o, можете попробовать засечь время за которое отображается структура страницы без данных :)
    Три правила проектирования интерфейсов с высокоскоростным пользовательским взаимодействием
  • 0
    Не понял о чем точно идет речь. Какие действия произвёл пользователь, как перемещался по страницам и какие запросы в каком порядке в этом предполагаемом случае отправлены?
    Три правила проектирования интерфейсов с высокоскоростным пользовательским взаимодействием
  • +1
    «Этот подход отлично работает с юзерами на медленном канале»
    Этот подход отлично работает с юзерами на медленном канале, с юзерами сервисов с медленными серверами, с юзерами сервисов использующих api других сервисов, у которых есть throttling. Этот подход превосходно работает с быстрыми серверами, мгновенно выполняющими запросы так, что страница наполняется данными прямо во время короткой анимации переходов между экранами. (можно поправить css в сису, увеличив время, и увидеть, что именно так всё и происходит))

    "«прыгающие» блоки (на seesu в том числе) очень раздражают"
    В seesu нет прыгающих блоков — "… фиксированное расположение, высота и ширина визуальных блоков ..."

    «Если канал большой, то почти моментально загружающиеся… »
    Возможно вы просто пропустили вторую часть, но я там пишу про то, что вконтакте, например, запрещает присылать больше одного запроса в секунду, discogs запрещает загружать больше одной картинки в секунду. Чтобы отобразить полностью страницу нужно отправить больше одного запроса.

    Таким образом какой бы широкий канал у вас не был — ждать вам всё равно придётся и если не пользоваться этими правилами, то ждать придётся всегда и долго.

    «Ну загрузись уже что ли в конце концов и покажи через секунду красивую страничку без уродливых пустых блоков!»
    Очевидно, что большой канал вас всё-таки не спасает.
    Смысл подхода в том, что не нужно ждать пока выполнятся все запросы, наполняющие страницу — можно мгновенно перейти на другую страницу. После перехода данные для выбранной страницы будут загружены в первую очередь.
    Три правила проектирования интерфейсов с высокоскоростным пользовательским взаимодействием
  • +1
    Вы описали ситуацию под названием «Плохо» с картинки
    habr.habrastorage.org/post_images/44e/74a/813/44e74a813a70bdc1da54885d31d26100.png
    интерфейсы, сделанные подобным образом, действительно вызывают крайне неприятные ощущения.

    В статье я рассказываю как сделать хорошо
    Три правила проектирования интерфейсов с высокоскоростным пользовательским взаимодействием
  • +1
    советы не про абстрактный дизайн, а про создание интерфейсов с которыми можно быстро взаимодействовать — о том, к чему у вас претензий нет ;)

    интересно было бы узнать почему идеи Джефа Раскина не позволяют создавать удобные унтерфейсы, или в чем приложение противоречит его идеям
    Три правила проектирования интерфейсов с высокоскоростным пользовательским взаимодействием
  • 0
    кроме того оптимизация реализована, и мне не нужно об этом думать :)
    Список оптимизаций рендеринга DOM, реализуемых на уровне Javascript фреймворка
  • 0
    иногда список может быть большой, иногда нужно полностью восстановить большую DOM структуру

    Например, тут chrome.google.com/webstore/detail/seesu-music/nhonlochieibnkmfpombklkgjpkeckhi когда popup закрывается его document удаляется, и при новом открытии приходится работать с новым документом
    Список оптимизаций рендеринга DOM, реализуемых на уровне Javascript фреймворка
  • 0
    Почему же под вебкит? Тут, кажется, все оптимизации касаются всех браузеров. К примеру приложение достаточно хорошо себя чувствует в устаревающей опере 12
    Список оптимизаций рендеринга DOM, реализуемых на уровне Javascript фреймворка
  • 0
    В том примере скроллинг не нативный; шаг скроллинга не пиксел, а целая строка, что точно не плюс. «не совсем правда», «есть способы с этим бороться» — не хотелось бы заниматься борьбой с фреймворком и постоянно решать одну и туже проблему (даже если решение известно, хотя то, что по ссылке точно не решение)

    Чтобы понять как должно быть организовано реально разделение на MVC нужно представить как использовать angularjs в системе, где ядро приложения (с моделями) находится в отдельной области видимости от представления (где вьюхи) и они могут общаться между собой чем-нибудь вроде window.postMessage, вьюха может быть полностью уничтожена, и иногда её нужно полностью воссоздать заново. Представить как использовать angularjs в системах, которые построенный на этом принципе, таких как www.appcelerator.com/titanium/. Нужно понять как во view будет передаваться структура/взаимосвязи моделей, их состояний, как будут передаваться оперативные обновления состояний, структуры во вьюхи, и как будет поставляться обратная связь из вьюх в модели.

    Система шаблонизации и датабайндинг в angularjs — единственные вещи, которые интересны в нём.

    Пока никому не предлагаю использовать свой «велосипед». Действительно трудно найти преимущества, когда я о них не рассказываю :)

    С другой стороны непонято — о каких именно «более-менее сложившихся фреймворках» идёт речь в контексте рендеринга? О каких фрейморках с выдающейся системой рендеринга вы знаете? Я знаю только шаблонизацию angularjs и шаблонизацию facebook react (это не mvc фрейморк), но facebook react опубликован 25 мая 2013 github.com/facebook/react/tree/75897c2dcd1dd3a6ca46284dd37e13d22b4b16b4, а я начал внедрять декларативную шаблонизацию в стиле angularjs примерно в феврале 2013 (при этом у меня уже было до этого атомарное изменении DOM) и к концу апреля 2013 у меня была работающее в декларативном стиле решение, покрывающее большинство вещей, требующихся мне. И с тех пор я в той части занимался в основном оптимизациями. Какой выбор был тогда у меня и какой сейчас?
    Список оптимизаций рендеринга DOM, реализуемых на уровне Javascript фреймворка
  • 0
    Похожа только часть отвечающая за представление.

    Для меня плюсы заключаются в том, что у меня реальное разделение на MVC в отличии от angularjs, и нет проблем с производительностью при работе со списками.

    Angularjs, построен так, что просто отрендерить большой список и изменить какое-нибудь поле у одного из элементов выливается в геморой с производительностью (он пойдёт по всему списку смотреть не изменилось ли чего у кого, заново выполняя функции на моделях, которые являются источником информации состояний. $digest… вот это всё)
    Список оптимизаций рендеринга DOM, реализуемых на уровне Javascript фреймворка
  • 0
    Во первых клонируется.


    О том, что при клонировании нодов свойства объектов (являющихся интерфейсом к dom node) не клонируются я писал. Если нам очень надо клонировать свойство, то это надо делать либо как я описал выше, либо через setAttribute().

    Во вторых зачем клонировать эти свойства из шаблона, если мы их меняем их и пользуемся в экземпляре?
    Список оптимизаций рендеринга DOM, реализуемых на уровне Javascript фреймворка
  • 0
    я не видел шаблонизаторов, основанных на клонировании нодов, поэтому каких-то чужих тестов не видел, а свои тесты не делал
    Список оптимизаций рендеринга DOM, реализуемых на уровне Javascript фреймворка
  • 0
    Именно клонирование корневого элемента с помощью cloneNode(true)? где true значит «клонировать, но только сам нод, но и всё дерево»

    Где-то есть на jsperf.com код?

    Я готов написать свою часть которая будет отвечать оговорённым требования шаблонизации по результату и возможностям, вроде
    1) какая-то большая структура
    2) нужно будет получить 100 экземпляров
    3) при передаче новых данных в экземпляр соотствествующие части будут автоматически обновлены

    Можно договориться об этих требованиях и кому интересно — предоставят реализации для тестирования. Ну и соответственно потом замерять скорость получения первого экземляра, скорость получения последующих, скорость применения изменений.
    Список оптимизаций рендеринга DOM, реализуемых на уровне Javascript фреймворка
  • 0
    Клонирование корневого нода структуры было медленней, чем result_node.innerHTML = '.....' или медленней чем
    var div = document.createEment('div');
    var pp = document.createEment('p');
    div.appendChild(pp)?

    Т.е. такое поэлементное воссоздание даже для большой структуры
    Реальный код из приложения
    <div class="playlist_panel" pv-nest="plarow">
    	<div class="playlist-actions">
    		<div class="pla-panel">
    			<span class="pla-button" pv-anchor="btrow-multiatcs" pv-events="click::switchPart:row-multiatcs" pv-type="way-point">● ● ●</span>
    			<span class="pl-settings-button" title="Playlists settings" pv-anchor="btrow-pl-settings" pv-events="click::switchPart:row-pl-settings" pv-type="way-point"></span>
    		</div>
    		<div 
    			pv-anchor="row_context"
    			class="pla-row-content has-dark-buttons hidden"
    			pv-class="pla-row-content has-dark-buttons {{!active_part && 'hidden'}}"
    			style="position:relative">
    			<span class="rc-arrow hidden" pv-anchor="arrow" pv-props="style.left: {{arrow_pos}}" pv-class="rc-arrow {{!active_part && 'hidden'}}">
    				<span class=" rc-s-arrow arrow-part"><span class="rc-s-arrow-bg arrow-part"></span></span>
    			</span>
    			<div class="pla-row hidden" pv-nest="context_parts for_model:row-multiatcs" pv-class="pla-row {{!active_view && 'hidden'}}">
    				<div class="left-buttons-group">
    					<span class="button-hole">
    						<a 
    							pv-events="click::makePlayable"
    							pv-type="way-point"
    							class="search-music-files nicebutton lang localize-playlist-getmp3">Find files for compositions</a>
    					</span>
    
    					<!-- href="http://seesu.me/generated_files/seesu_playlist.m3u"-->
    					<span class="button-hole">
    						<a
    							pv-events="click::makeExternalPlaylist"
    							pv-type="way-point"
    							class="open-external-playlist nicebutton lang localize-playlist-export">Save playlist to *.m3u file</a>
    					</span>
    
    				</div>
    				
    			</div>
    			<div class="pla-settings hidden" pv-nest="context_parts for_model:row-pl-settings" pv-class="pla-settings {{!active_view && 'hidden'}}">
    				<label class="dont-rept-pl">
    					<input type="checkbox" pv-anchor="dont-rept-pl"/>
    					<span class="lang localize-dont-rept-pl">Do not repeat playlist</span>
    				</label>
    			</div>
    		</div>
    	</div>
    	<div 
    		class="loader_disallowing_desc hidden"
    		pv-class="loader_disallowing_desc {{!loader_disallowing_desc && 'hidden'}}"
    		pv-text="{{loader_disallowing_desc}}"
    	></div>
    	
    	
    </div>



    будет быстрее чем клонирование каким-нибудь таким кодом?

    var samples = {};
    
    var getSourceNode = function( sample_name ){
    	if (!samples[sample_name]) {
    		samples[sample_name] = $( '.' + sample_name )[0];
    	}
    	return samples[sample_name];
    };
    
    var instance1 = getSourceNode('playlist_panel').cloneNode(true);
    var instance2 = getSourceNode('playlist_panel').cloneNode(true);
    var instance3 = getSourceNode('playlist_panel').cloneNode(true);
    
    Список оптимизаций рендеринга DOM, реализуемых на уровне Javascript фреймворка
  • 0
    Не понял о каких трудностях связанных с клонированием (учитывая что этот код не нужно каждый раз писать) идёт речь. Я, наверно, плохо описал как именно используется шаблонизация, уделив больше внимания собственно реализации. О каких проблемах идет речь?
    Список оптимизаций рендеринга DOM, реализуемых на уровне Javascript фреймворка
  • +127
    «Фу-фу-фу! Из-за этих айфонов люди не общаются друг с другом, то ли дело раньше!»

    image
    Общество телефонных зомби