azproduction
+2
Из-за декларативности компонент/шаблонов React выигрыш огромен. Вам не нужно определять все состояния компонента и переходы между ними. При увеличении сложности это значительно упрощает поддержку.
azproduction
+4
Вся суть React в декларативности шаблонов. Компонент при каждом изменении полностью перерисовывается (но виртуально), затем React вычисляет минимально дешевую мутацию состояний из А в Б. В императивном подходе все мутации состояний нужно определять руками. При увеличесии сложности компонента возрастает сложности определения всех состояний и переходов. Соответсвенно возрастает риск ошибки и сложность понимания.
azproduction
+7
Ну и ряд функциональных подходов
  • Tail optimized recursion
    function loop(fn) {
        var index = 0;
        
        return function over(array) {
            if (index >= array.length) {
                return;
            }
            fn(array[index], index, array);
            index++;
            over(array);
        };
    }
    
    var consoleLog = loop(function (item, index, array) {
        console.log(item, index, array);
    });
    
    consoleLog([1, 2, 3, 4]);
    

    jsbin.com/rimabu/3/edit?js

  • Y Combinator
    function Y(le) {
        return function(f) {
            return f(f);
        }(function(f) {
            return le(function(x) {
                return (f(f))(x);
            });
        });
    }
    
    function loop(fn) {
        var index = index || 0;
        return function (over) {
            return function (array) {
                if (index >= array.length) {
                    return;
                }
                fn(array[index], index, array);
                index++;
                over(array);
            };
        };
    }
    
    var consoleLog = Y(loop(function (item, index, array) {
        console.log(item, index, array);
    }));
    
    consoleLog([1, 2, 3, 4]);
    
    

    jsbin.com/ligawa/2/edit?js
azproduction
0
Спасибо. По крайней мере судя по времени берут по полной. Нода стартует с нуля.
azproduction
0
Отличная статья, спасибо!

Есть ли какие-то данные по тому какую память считает AWS Lambda: память занятая бинарем node + память занятая после запуска модуля или только память занятая модулем?

И еще есть ли данные по Startup latency: заводят ли они ноду с нуля каждый раз или реиспользуют пул процессов?

Просто нода сама по себе хорошо отъедает памяти и может долго стартовать.
azproduction
+3
html {
    filter: hue-rotate(180deg) invert(0.9);
}
// Keep images untouched (invert back)
img {
    filter: hue-rotate(180deg) invert(0.9);
}

Close enough ;)
azproduction
+3
Самый badass способ :)
<button>
    <h1 contenteditable>Pewpew</h1>
</button>

jsfiddle.net/m8kr4o8w/
azproduction
+6
Поигравшись с девайсом полчаса, он был убран обратно в коробочку, вместе с желанием пользоваться или что-то девелопить с его участием.
Я, к сожалению, поступил аналогично. Надеюсь продолжить пользование с выходом Oculus VR.
azproduction
0
Вопрос думать о зависимостях или нет. Если не использовать eval, то я могу гарантировать, что нет никаких подводных булыжников. Просто потыкайте в демку ;)
azproduction
+2
Нет, при генерации кода Autopolyfiller их обернет в if () {}. Репозиторий же хранит полифилы в чистом виде (да это может смущать).
azproduction
0
Набрать базу лояльных разработчиков :)
azproduction
+4
Короткий кэш из 5 итемов, к примеру, по ключу {format, timestamp[, locale]}. Lookup итема происходит без «Хэш-индекса» ака var index = {}; те просто for-ом по массиву, иначе будут тормоза с удалением добавлением итема в «индекс». Потом есть pointer который указывает в какую ячейку кэша нужно положит будущий результат. Всей этой структурой мы добиваемся того, чтобы не было GC на объектах кэша и не тратим время на конструирование составного ключа.

Большие кэши не нужны тк эта функция зависит от времени и каждый раз на вход могут подаваться разные знаения -> много промахов+тормоза.

var cache = [{
    value: null,
    format: null,
    ts: null
}, ...];
var pointer = 0;

var ts = date.getTime();

// lookup
for (var i = 0; i < cache.length; t++) {
    if (cache[i].format === format && cache[i].ts === ts) return cache[i].value;
}

// put
var value = strftime(format, date);
if (pointer > cache.length) pointer = 0;

cache[pointer].format = format;
cache[pointer].value = value;
cache[pointer].ts = ts;

pointer++;
return value;
azproduction
+3
Максимум выжал 21х без кэша — 3.3kk op/sec для %Y-%m-%dT%H:%M:%S%z. С FIFO кэшом x200 — 33kk op/sec. При 100% промахе кэша производительность деградирует до 18х.

Буст в 50 раз даже ручным кодом не удалось получить для паттерна выше. Для получения 50x без кэша/тредов точно не обойтись.

Заводилось в 1 ядро: Node v0.10.28 @ V8 3.14.5.9.
azproduction
–2
И скомпилит emscripten в asm.js
azproduction
+8
Там будет отлично смотреться реклама
azproduction
+1
Я ответил вполне на конкретный вопрос: «Не могу понять, в чем разница между вашим кодом и моим?». Не знаю стало ли проще если я бы ответил, что в JS область видимости через var создает только функция, поэтому в следующем тике event loop значение переменной будет 3 и эта переменная будет общая для всех безымянных «замыканий» аргумента setTimeout.
azproduction
–2
Ваш код синхронный. Мой асинхронный.
azproduction
+1
Классика:
for (var i = 0; i < 3; i++) {
    setTimeout(function () {
        alert(i);
    }, 100);
}
azproduction
+3
Поэтому не стоит делать из языка элитарное сообщество, ограниченное трехметровым порогом входа. Не забывайте, что есть ряд людей, которые не пишут фуллтайм на JS, но им приходится с ним работать.
azproduction
+4
Мне как и вам прочитать не сложно. Любой не посвященный в JS скажет, что !!x — читается как магия; Boolean(x) — все понятно ;)
azproduction
+5
Не знаю как вы, но я пишу код для людей, мучаться должны роботы и переделать код как им нужно при минификации ;)
azproduction
+1
Фейсбучный beanstalkd? (pевью на Quora)
azproduction
0
IDE многое пропускают и они могут быть разные. В моей команде, например, используется минимум 3 различных IDE/текстовых редакторов и нам приходится использовать инструменты jshint + jscs + editorconfig + csscomb, чтобы уровнять редакторы.
У многих IDE, конечно, есть интеграция с jshint, но он отловит только часть проблем, да и ничего не мешает забыть/не заметить/проигнорировать замечание IDE.
Я предпочитаю максимально минимизировать потенциальную проблему всеми возможными средствами. С текущим workflow это прекрасно получается. За последний год я не видел ни одного комента вида «а ты тут пробел забыл».
azproduction
+2
Зато избавляют от кучи треш-коментов вида «а ты тут пробел забыл» и позволяет полностью сосредоточиться на чтении и понимании кода и внесении значимых корректировок. Функциональные особенности это уже не Code-Style, IMO ;)
azproduction
+5
Можно навязать единый code style и реально проверять, что он соблюдается, а не просто на бумажке закреплен
И это должен делать софт, а то Code Review превратится в Code-Style Review. Благо сегодня каждый ЯП обзавелся дюжиной статический анализаторов.
azproduction
0
Кстати, с одной стороны песочница это крутая штука, но она может превратиться в большой слой бюрократии если постоянно все везде ограничивать. Те когда нужно получать какие-то новые данные приложения приходится добавить этот модуль в песочницу, а потом вызвать его в Модуле. Похоже на антипаттерн Павлик Морозов.

В свою очередь интерфейс CommonJS модулей так же является своеобразной песочницей и эта песочница положительно сказывается на качестве продукта и не вставляет палок в колеса.
azproduction
0
Штука крутая! Только заголовок статьи очень смущает :) Читаешь его и думашь, что статья будет про кодописание, а не инструмент/документацию.
azproduction
+1
Веб Компоненты могут убрать эту фрагментированность: все компоненты будут совместимы друг с другом, потому что это будет просто HTML.
Я согласен, что они будут работать. Однако вы не будете использовать компоненты написанные на «чужом языке» и сделанные «чужим инструментом» потому как эти компоненты могут тянуть какие-то тяжелые зависимости (платформу), вы не будете понимать как они устроены и напишете свой. Да они будут скомпилированы в CSS, HTML и JS но сорцы их будут на Stylus, Jade и например TypеScript с примесью React.
azproduction
+6
Сегодня WebComponents это buzzword как раньше был HTML5. Это прекрасная идея кастомного HTML элемента (которая существовала с эпохи Web 2.0) и несколько API, которые делают жизнь чуть-чуть проще. Я думаю, что для вас не секрет, что каждый первый web-UI-движок так или иначе позволяет создавать такой элемент, что BEM Tools, что React, что jQueryUI. Совсем другое дело это какой интерфейс будет на выходе и на сколько сложно в него вникнуть.

Не думаю, что тут стоит употреблять «закостылять». Сегодня эти «костыли» помогают создавать приложения под все платформы, позволяют писать компоненты, которые можно реиспользовать в рамках ваших договоренностей. Просто нужно их понять как и любой другой API в том числе Web Components.

Я считаю, что утверждение «стандарт построения кастомного HTML элемента спасет мир» — это миф. Опять будет тасяча галерей, просто написанных на WebComponents API. И, я уверен, что вы напишете свою потому как чужие галереи несут такой невероятные оверхэд по количеству поддерживаемых фичей из-за того, что их создатель не понимает KISS.

«Прописал импорт компоненты с CDN и вуаля» — так не будет. Мы и через 10 лет будем пытаться сокращать количество запросов. Как обычно скачаем все компоненты и будем использовать инструменты для сборки этих компонент.

Shadow DOM и Scoped CSS поможет избежать конфликтов «Встраиваемым приложениям» (Disqus например). В прочем, мы можем и так можем свести количество конфликтов к 0, используя кастомные теги (как делают API Яндекс Карт) и методологию BEM.

W3C молодцы, что выделили эту часть HTML5 в отдельное понятие Web Components. По крайней мере теперь разработчики будут копаться в этом слове (Components) и начнут осознавать, что жирные библиотеки вроде jQuery нужно заменять маленькими компонентами(модулями), которые будут использоваться на 100%.

Начните пользоваться Компонентами (без Web-) и начните забывать слово Библиотека, например, попробуйте выкинуть jQuery и заменить его на что-то более изящное.
azproduction
+1
Отличное название! Сравните с каким-нибудь «Blob Business Storage Enterprise Solution» ;)
azproduction
+5
на сервере MVC может быть только если у нас пользовательский интерфейс полностью реализован на сервере, т.е. нет браузерного кода, интерфейс генерируется на сервере, а браузер просто показывает его.
V будет, но мнимая. Должен же кто-то словари и массивы отрисовать в JSON ;)
azproduction
–1
Есть еще одна библиотека — debug (npm debug). Ее очень удобно использовать как в процессе написания библиотек, так и для логирования. Она не имеет привычных уровней логирования, вместо этого вводятся id типа логов, кооторые можно гибко включать, используя wildcard.

var debug = require('debug')('worker');

setInterval(function(){
  debug('doing some work');
}, 1000);


$ DEBUG=http,worker node server.js


image

Рекомендую ;)
azproduction
+1
Часть моих лайков все еще приходится на статьи из RSS. Реквестирую возможность подключить Feedly!
azproduction
+1
Это так называемое 2.5D С одного кадра такое автоматически сделать сложно. Софт по кадру не сможет построить правильную глубину. Руками это делается не так долго.
azproduction
+1
Насчет PHP не знаю. Можно распарсить код в AST на JS, а потом нарисовать его в читаемом виде.
azproduction
+6
Хорошо, что этот плеер отчуждаемый (iframe) его можно встроить к себе на страницу или сохранить как приложение на экран телефона :)
azproduction
0
Эти формы уже старые :) Новые формы — это твиттер аккаунт двери, которая постит фотки приходящих.
azproduction
0
Если почитать эту статью дальше, то там написано, что
Формат Simplified CommonJS для RequireJS «не родной», просто разработчиком пришлось его сделать. Если начать писать такие модули, то RequireJS начнет искать зависимости данного модуля регулярками.
Регулярки в Simplified CommonJS косячные, AMD при большом числе модулей плохо читается. Зачем использовать AMD? :)
azproduction
+1
Есть похожий сервис choir.io проигрывает звуки событий различных сервисов. Например так звучит Github.