• Как мы добавили подъезды на карту и сократили размер баз на 10%
    0

    Зачем вы пишете откровенно ложную информацию? Яндекс сам производит картографическую информацию.

  • Vidom — blazingly fast alternative to React
    +1

    В версии 0.3.9 размер, благодаря использованию rollup, был уменьшен с 10 до 8Кб, а также еще ускорен ssr.

  • Vidom — blazingly fast alternative to React
    0

    Про preact ниже есть коммент, а с deku в плане производительности еще более все печально.

  • Vidom — blazingly fast alternative to React
    0

    propTypes в режиме production отключен у React

  • Vidom — blazingly fast alternative to React
    0

    Потому что внутри Vidom устроен совершенно по-другому, несмотря на похожее апи. Нельзя взять и просто адаптировать одно под другое. К тому же, как сами создатели React пишут, DOM — это second class citizen для них, у них другой уровень абстракции. Vidom же сосредоточен только на работу с DOM.

  • Vidom — blazingly fast alternative to React
    0
  • Vidom — blazingly fast alternative to React
    +1

    А вы сами его использовали? Там урезано многое, если хотите как в React, то нужно подключать уже дополнительные модули, а с ними размер, соответственно, увеличится. И я помню, что у меня коллеги хотели его использовать вместо React, но у них постоянно что-то не так работало или чего-то не хватало, в итоге они вернулись на React.


    Но, самое интересное, сейчас посмотрел на бенчмарки, в которых есть Preact, он проигрывает даже React в них.

  • Vidom — blazingly fast alternative to React
    +2

    Он есть в Repaint rate challenge, можете сами сравнить ;)

  • Vidom — blazingly fast alternative to React
    0
    В repaint rate challenge morhpdom намного медленее даже react, что как бы намекает про DOM vs VDOM.
  • Vidom — blazingly fast alternative to React
    0
    Cудя по бенчмаркам с morhpdom, гораздо медленнее. Ну и плюс есть вопросы про ключи (насколько я понял, morphdom использует id), и, особенно, про ssr.
  • Vidom — blazingly fast alternative to React
    +1
    Был бы рад помощи в этом месте. Я не могу чисто физически написать все сопутствующие библиотеки.
  • Vidom — blazingly fast alternative to React
    0
    Поправил, так понятнее?
  • Vidom — blazingly fast alternative to React
    0
    Production-ready. Запущено уже несколько внутренних веб-приложений.
  • Vidom — blazingly fast alternative to React
    0
    Если скрещивалось с React, то, с очень большой долей вероятности, скрестится и с Vidom. Если statefull-компоненты не нужны, то можно их и не использовать.
  • Vidom — blazingly fast alternative to React
    0
    Там же: https://cdnjs.cloudflare.com/ajax/libs/vidom/0.3.3/vidom.min.js
  • Vidom — blazingly fast alternative to React
    0
    Вообще, в тексте, есть про это, но не про 16Кб, а про 10Кб после gzip ) Собрано, кстати, не webpack, а browserify+babelify, но да, я тоже в результирующем бандле тоже вижу много «лишнего» от babel и это меня печалит, конечно, но, пока, некритично.
  • Vidom — blazingly fast alternative to React
    +3
    Я же про это честно говорю. Но у меня и задачи такой нет (сделать аналог react native). Есть задача максимально быстро делать это в браузерах и в nodejs. Зато, за счет одной целевой платформы, есть возможность отказаться от кучи абстракций и срезать кучу углов.
  • Модульная система YM
    +1
    Ну если бы вы использовали прекрасный стэк технологий сборки ENB, то я бы порекомендовал использовать плагин github.com/enb-make/enb-modules, который умеет строить граф сборки на основания зависимостей самой модульной системы.
  • Модульная система YM
    +1
    Целт публикации — показать проблемы в существующих решениях и рассказать как эти проблемы мы решили у себя.
  • Модульная система YM
    +1
    Еще раз — модуль ничего ни за кого, кроме себя, ничего не решает, он только декларирует под неким именем некую функциональность, которую может предоставить. Модули, которые его используют, просто декларируют зависимость от него, для них он — черный ящик. Все. В AMD же это как раз не так.
  • Модульная система YM
    0
    Тем, что она необратносовместима с AMD.
  • Модульная система YM
    –1
    Если вы проскроллите чуть ниже, то увидите, что автор require.js думает на этот счет.
  • Модульная система YM
    0
    Модульная система должна заниматься модулями и разрешением их зависимостей, а вместо этого я вижу нечто, подобное этому:
    curl(['js!nonAMD.js'])
        .next(['dep1', 'dep2', 'dep3'], function (dep1, dep2, dep3) {
            // do something before the dom is ready
        })
        .next(['domReady!'])
        .then(
            function () {
                // do something after the dom is ready
            },
            function (ex) {
                // show an error to the user
            }
        );
    

    В итоге, теплое смешано с мягким.
  • Модульная система YM
    –1
    Спасибо за ваше интересное мнение. Но, в плане общее решение/своя альтернатива, я выделяю три стадии развития разработчика:
    1. Когда он не использует общие решения, не понимая зачем они, под каждую задачу пишет свою альтернативу. Как правило, на этой стадии альтернатива гораздо хуже общего решения.
    2. Когда он понимает, зачем общие решения, и использует их.
    3. Когда он понимает, чем его не устраивает общее решение, что можно сделать лучше, и он пишет альтернативу. На этой стадии альтернатива имеет гораздо больше шансов оказаться лучше, чем общее решение.

    Есть еще, конечно, момент с исправлением существующих общих решений, но: это далеко не всегда возможно, у авторов общих решений есть свое видение, как правило. не совпадающее с твоим; не всегда вообще можно общее решение доработать без потери обратной совместимости; и, что вообще не любят разработчики, надо потратить уйму времени на разговоры и объяснения, часто безрезультатные. Возможно, это 4-я стадия :)
  • Модульная система YM
    0
    Это не то, что нужно. Это тоже свмое, что во всех примерах с AMD выше. Нужна абстракция от этого.
  • Модульная система YM
    +1
    А почему, то что ymaps это какой-то особый модуль должен знать именно потребитель этого модуля? Мой посыл в том, что все особенности модуля должны быть в самом модуле, а никак у его пользователей.
  • Модульная система YM
    +3
    Да, потому что только после этого события появляется нужный класс. И все пользователи этого класса должны быть избавлены от этого знания.
  • Модульная система YM
    0
    Непонятно, как это предложение соотносится с тем, что я написал.
  • Модульная система YM
    0
    Даже, если бы проблема была только в этом, это неприемлемый компромисс для нас. Все про модуль должно быть написано в модуле, уж извините.
  • Модульная система YM
    +3
    Не может ymaps сразу ничего вернуть, он использует дозагрузку своих собственных модулей.
    Да и не нужна асинхронность, там где она не нужна, извините за тафтологию. Не нужно пользователю класса ComplexLayer знать о том, откуда и как он берется, вроде это очевидно. Если мне нужно написать:
    var complexLayer = new ComplexLayer();
    
    я должен так и писать, а не делать странные вещи типа:
    var complexLayerPromise = ComplexLayerClassPromise.then(function(ComplexLayer) {
        return new ComplexLayer;
    });
    

    и все последующие методы complexLayer звать только через промисы.
  • Модульная система YM
    0
    Я не уверен, что такая доработка будет обратносовместима со всеми инструментами вокруг AMD.
    Плюс, в YM еще есть несколько отличий от AMD, которые на рассмотрены в статье, но для нас являются важными, например возможность додекларации/передекларации существующих модулей.
  • Модульная система YM
    +1
    Ну это же очень странно. с точки зрения пользователей ComplexLayer, они все должны будут знать, что им не класс предоставляется, а какой-то промис, который будет зарезолвлен потом классом. Это, мягко говоря, неудобно.
  • Модульная система YM
    0
    выглядит так, как будто автор не делал анализ существующих решений.
    Все модульные системы из статьи (CommonJS, AMD) я использую и использовал (собственно, для NodeJs алльтернативы CommonJS и нет), и именно из-за их недостатков была и сделана YM, а не потому что надо было сделать очередное «свое». Если бы хоть одна отвечала нашим потребностям, я бы никогда не стал писать свое.
  • Модульная система YM
    +2
    Вы указываете в конфигурации AMD-загрузчика, что модуль ymaps находится под таким URL (map.yandex.ru/api/...) потом ComplexLayer просто его указывает в зависимостях и использует (прям как у вас в коде).
    А вам не кажется, что это усложнение модульной системы? Более того тут есть нарушение принципов модульности, так как помимо самого модуля, мне еще что-то куда-то нужно дописывать.

    И можно, все-таки, код увидеть? Как там обрабатывается, допустим, ситуация с ymaps.ready, которая наступает позже загрузки самого апи?
  • Модульная система YM
    0
    По URL config.hosts.ymaps + '/2.1.4/?lang=ru-RU&load=package.full&coordorder=longlat&format=AMD' отдается AMD модуль.
    Как это помогает, в плане асинхронности, наследованию моего модуля от класса, предоставляемого из апи? Приведите пример описания модуля ComplexLayer для AMD из статьи.

    Нельзя ответить на вопрос «когда?».
    А зачем на него отвечать для статического анализа кода?
  • Модульная система YM
    +1
    Мне кажется это смешивание системы модулей и загрузчика модулей в одно целое. Более того, не самое удачное.
    Вы ошибатесь. Загрузчик — это всего лишь обычный, ни чем ни лучше других, модуль в модульной системе. Сама модульная система знает только про модули и разрешение зависимостей между ними, ничего более. Модуль-загрузчик приведен лишь в качестве примера, иллюстрирующего случай, когда нужен асинхронный провайд модуля.

    Но никто не мешает сделать тоже самое с AMD
    Можете привести пример кода для AMD, иллюстрирующего модуль, которые экспортирует класс, который наследуется от класса из API Яндекс.Карт? Тот же пример, который в статье разобран.

    Далее, у меня мнение, что система модулей должна быть статически анализируема.
    А что в YM этому сейчас препятствует? В этом плане он ничем не отличается ни от CommonJs, ни от AMD.
  • Модульная система YM
    0
    Судя по примерам на yuilibrary.com/yui/docs/yui/index.html, это выглядит все очень ненатурально, как будто подшито костылями уже постфактум. Руками где-то описываются вещи типа async: true, сам Loader, опять же, не является просто модулем, а зашит в глобальный объект. В общем, совсем не то, что хотелось от модульной системы.
  • Модульная система YM
    +1
    Нет, конечно. Есть соответствующие тулзы, которые на основании графа зависимостей, полученного из описания модулей, собирают результирующий файл.
  • Модульная система YM
    +2
    YM занимается только тем, что касается модулей и разрешения зависимостей между ними. Причем здесь сжатие кода я пока не очень понимаю.
  • Путь JavaScript модуля
    0
    Тебе спасибо за статью и комментарии, теперь есть куда ссылку давать, чтобы каждый раз не объяснять все заново :)