• ES6 const это не про иммутабельность
    –1

    Здесь действительно почти не надо, но лишний тик в голове всё же иногда происходит, есть более сложные случаи. Процитирую себя:


    Приведите конкретный пример кода и давайте обсудим как программист читая его лучше понимает его суть за счёт использования в нём const?

    Как знание о том, что $this не будет меняться помогает вам понять логику дальнейшего кода? И если этого не происходит, то нахрена спрашивается вы в него вцепились? Модно, ES6 и всё такое?

  • ES6 const это не про иммутабельность
    –1

    Ну ок, так всё таки, что это даст в сравнении с бездумным let везде? Зачем мне лишний раз задумываться выбирая const или let?

  • ES6 const это не про иммутабельность
    –1

    Это уже другой подход, отличный от


    нужно изначально писать везде только const, и по мере надобности добавлять let

    его я не пробовал, но могу предположить, что постоянно задумываться будет ли переменная меняться мне нафик не надо, особенно если это не приносит мне какой-то пользы.
    Большой комментарий чуть ниже тоже вам))

  • ES6 const это не про иммутабельность
    +1

    Только в случае неиспользуемых переменных от этого нельзя совсем избавиться, а в случае с const можно.


    Вот вы все тут набрасываете на мои аргументы против const, но никто толком не говорит зачем он ему пригодился? Единственный аргумент сразу не ломающийся о какой-нибудь линтер или ещё что-то привёл swandir :


    С учётом вышеизложенного, const делает код более читаемым.
    То есть назначение const в том, чтобы дать человеку, читающему код, сигнал, что переменная переприсвоена не будет. А let, соответственно, сигнализирует о том, что переменная скорее всего будет переприсвоена, соответственно это что-то вроде счётчика или флага, который далее будет проверен, то есть нужно обратить на это внимание.

    Но вот кто-то из вас пробовал проверить как это работает на практике? Я вот пробовал, именно этот аргумент ещё с год назад показался мне достаточно убедительным чтобы попробовать. И знаете как он работает? Вообще никак! Вот открываю я чуть ранее (не знаю, может надо было дольше ждать) написанный мною код с const, вижу переменную объявленную через const, ура, теперь я знаю, что она не будет меняться, но что мне это даёт? Зачем мне это знать? Это как-то помогает понять логику далее написанного кода? Я этого вообще не заметил, скорее наоборот, это абсолютно лишняя инфа, отвлекающая от сути. Приведите конкретный пример кода и давайте обсудим как программист читая его лучше понимает его суть за счёт использования в нём const? Это реально будет лучшим доказательством его полезности. Я пробовал иначе, взял готовый код написанный ещё на var-ах и начал переписывать его на const+let, я думал, что может используя const я найду какие-то хитрые баги, которые раньше не замечал и которые const автоматом пресекает. Но и этого не произошло. Все теоретические плюсы const которые можно найти в Интернете на практике либо не работают, либо вообще идут в минус. Мне намного интереснее было бы услышать в качестве аргументов за const не эту теоретическую копипасту с Интернета, а чей-то практический опыт, пусть и субъективный, что-то типа: чувак, вот я начал писать с const и я реально ощутил, что мне стало проще перечитывать свой ранее написанный код. Вот вы можете так сказать?


    Кстати ещё один минус const вспомнил:


    let a;
    let b;
    let c;
    let d;

    намного красивей чем:


    const a;
    let b;
    const c;
    let d;

    Если же группировать несколько переменных в один const/let, то ещё хуже получается, приходиться либо постоянно разрывать группу, либо делать две группы и раскидывать переменные по ним, что приводит к тому, что две переменные, которые близки по сути и должны объявляться рядышком, оказываются далеко друг от друга.


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

  • Matreshka.js 2 — самый простой фреймворк во Вселенной
    0

    Посмотрите на Riot, самое что надо для новичков. Если хочется немного реактивное программирование показать, то можно Vue.js посмотреть, отлично подойдёт. KnockoutJS тоже всё ещё хорош.

  • Matreshka.js 2 — самый простой фреймворк во Вселенной
    0

    bindNode как раз нифига не декларативно, linkProps тормозной, а кроме этого в фреймворке остаётся солянка каких-то утилитных методов на все случаи жизни. Зачем тащить пак таких методов, минимум половина из которых будет не нужна в проекте, когда можно устанавливать только нужное из npm?

  • Matreshka.js 2 — самый простой фреймворк во Вселенной
    +2
    Ни какой.

    Ок, перефразирую. В необходимости какого модуля у вас есть сомнения?


    что вы заново зарегистрировались относительно недавно

    Смотрите здесь: https://habrahabr.ru/users/riim/


    Зарегистрирован: 16 мая 2015 в 21:41
    Приглашен: 02 декабря 2015 в 12:15 по приглашению НЛО

    Я в принципе на хабре не так давно, около года, регистрировался 1 раз, уж не знаю что и где вы там видите)) Видимо всё же с кем-то путаете меня.
    Зачем мы это вообще обсуждаем? Это вы так от вопросов о фреймворке ушли?

  • Matreshka.js 2 — самый простой фреймворк во Вселенной
    –1

    Что-то в этом есть, но это скорее проблема реализации. Раньше работал с библиотекой Rivets.js там действительно такое случалось, сейчас при работе с Rionite вроде всё хорошо, но потенциально есть места где возможны такие проблемы. В тоже время не вижу проблем в их устранении, думаю мне будет чем заняться в свободное время)) Спасибо за идею)

  • Matreshka.js 2 — самый простой фреймворк во Вселенной
    0
    я тоже задался вопросом "зачем"

    какой именно модуль вам интересен?


    почему вы ходите в каждый пост о Matreshka.js

    вы меня с кем-то путаете, посмотрел свои комментарии, это первый ваш пост, в котором я есть))

  • Matreshka.js 2 — самый простой фреймворк во Вселенной
    0

    Большинство претензий к фреймворку в комментариях как раз на тему "Нахрена он?" и пока вы не можете нормально на это отвечать. Думаю да, для вас это будет выходом.

  • Matreshka.js 2 — самый простой фреймворк во Вселенной
    –1

    Вебразработка пережила вебкомпоненты? А я то всё думал, что вебкомпоненты — это будущее вебразработки.
    Можете рассказать почему считаете "if/else в виде атрибутов — антипаттерн"?

  • Matreshka.js 2 — самый простой фреймворк во Вселенной
    –2

    Отправил. Не все, к сожалению, дожили до сегодняшнего дня))

  • Matreshka.js 2 — самый простой фреймворк во Вселенной
    –1
    if/else в виде атрибутов — антипаттерн

    разработчики стандарта вебкомпонентов смотрят на вас с недоумением)

  • Matreshka.js 2 — самый простой фреймворк во Вселенной
    –2

    Сделать можно и на jQuery, вопрос в удобстве поддержки. Могу скинуть в ЛС минимум три крупных проекта (ещё один в разработке) с которыми работал и которые было бы крайне непросто поддерживать будь они сделаны на матрёшке.

  • Matreshka.js 2 — самый простой фреймворк во Вселенной
    0

    Нет, вы неправильно понимаете, перечитайте ещё раз. Можно и без коллекции:


    <template is="rt-if-then" if="user">
        <div class="user-card">
            <img src="{user.avatar}">
            <span>{user.name}</span>
        <div>
    </template>
  • Matreshka.js 2 — самый простой фреймворк во Вселенной
    –1

    Я уже отвечал вам, что вам проще не изобретать велосипед, а взять что-то готовое и встроить в свой фреймворк. Вариантов сейчас хватает, не нравиться мой, возмите jin-atom, тоже отличный вариант.

  • Matreshka.js 2 — самый простой фреймворк во Вселенной
    0

    Речь не про то где они, а про возможность создания условных биндингов. В примере выше <template is="rt-repeat" for="user of users"> и {user.name} автоматически сбиндятся как только появится список users с ненулевой длинной (и разбиндятся при надобности). По матрёшке сложилось впечатление, что в такой ситуации прийдётся ручками подписываться на users и в обработчике опять же делать всё ручками. Это уже отстой, плюс в результате всё это будет раскладываться по методам и биндинги будут не в одном месте каждого компонента (так компоненты-то есть?) а размазаны по всему файлу, ищи их потом при изменениях в вёрстке.

  • Matreshka.js 2 — самый простой фреймворк во Вселенной
    0

    Ок, попозже обновлю)

  • Matreshka.js 2 — самый простой фреймворк во Вселенной
    0

    Ещё не понятно, что с условными биндингами? Например, в Rionite я могу написать так:


    <template is="rt-if-then" if="users?.length">
        <ul>
            <template is="rt-repeat" for="user of users">
                <li>{user.name}<li>
            </template>
        </ul>
    </template>

    Реально переписать на матрёшку?

  • Matreshka.js 2 — самый простой фреймворк во Вселенной
    0

    Кстати, матрёшка в тесте предложенном в ишъю показала почти самый худший результат, хуже только Kefir.js. Во второй версии что-то изменилось?

  • Matreshka.js 2 — самый простой фреймворк во Вселенной
    0
    для больших и бесконечно расширяемых приложений

    Честно говоря, очень сомнительно. Я тут пару месяцев назад, выполняя ишъю, поковырялся немного в вашем фреймворке, много вопросов появилось и главный — это биндинги, которые сделаны таким образом, что при любом изменении вёрстки прийдётся каждый раз перепроверять все биндинги соответствующего вёрстке компонента. Есть какая-то уверенность, что в действительно большом проекте, над которым работают много разработчиков и который динамически дорабатывается, это начнёт настолько жёстко напрягать, что человека предложившего делать проект на матрёшке начнут просто избивать ногами)). Так же не понятно есть ли в матрёшке какая-то компонентная система? И если нет и нет какой-то альтернативы, то опять же непонятно о каких больших проектах вообще можно заикаться?
    На мой взгляд ниша фреймворка — маленькие представительские странички, но и в этой нише тот же angular-light явно выигрывает в удобстве.

  • ES6 const это не про иммутабельность
    0

    Ответил ниже.

  • ES6 const это не про иммутабельность
    0
    при доработке уже написанного с ним кода

    Про то и речь, что везде const, только где надо let, и вот при дороботке кода один из let становиться неизменяемым и это вообще никак не видно, код продолжает отлично работать. Если не следить за этим, то получаем неконсистентные объявления, что меня как перфекциониста напрягает, если следить вручную, то на это уходит уже значимое время, вроде бы немного, но везде помаленьку и начинает реально напрягать постоянно на это отвлекаться. Если настроить prefer-const, как посоветовали выше, скорей всего будет заметно лучше, изредка прийдётся править замечания линтера и постоянно писать на два символа больше. Мелочи, но и плюсы тоже совсем незначительны. Для меня минусы перевесили, да и вообще, складывается впечатление, что большинство использует const не ради каких-то реально видимых для себя плюсов, а просто потому что это сейчас модно.

  • ES6 const это не про иммутабельность
    –1

    Ну если только так)

  • ES6 const это не про иммутабельность
    0

    Так в чём сила const, если единственная причина его существования ломается о любой линтер? При этом есть минимум два минуса, один из которых я привёл выше (prefer-const решает его лишь частично).

  • ES6 const это не про иммутабельность
    0

    Ну мне видимо уже не нужно)) По сути профит const в том, что не получится написать if (a = b) вместо if (a == b), но вот такого как раз и не случается, так как любой линтер такое с пелёнок проверять умеет.

  • ES6 const это не про иммутабельность
    0

    const не нравиться потому что при доработке уже написанного с ним кода нужно постоянно следить не пора ли какой-то let переделать в const, если не следить, объявления получаются неконсистентными. Отвлекает, а какого-то профита я так и не заметил. Наверно можно какой-нибудь линтер настроить, что бы он находил такие let-ы, но не видя профита я решил не заморачиваться и использовать везде let.

  • Структуры данных для самых маленьких
    0

    Самогонный аппарат вроде))

  • SPA — не серебряная пуля, или альтернативный подход к web-разработке. Часть 1
    +1

    И самое весёлое, когда часть сохраняемого состояния нужно генерить на сервере, а другую часть восстанавливать на клиенте. Что-то запихиваем в url, что-то в localStorage, ваще ништяк получается))

  • SPA — не серебряная пуля, или альтернативный подход к web-разработке. Часть 1
    0

    А затем вдруг часть состояния с одной страницы нужно передать на другую и начинается гемор с сохранением его куда-то и дальнейшим восстановлением. Через какое-то время приложение становиться достаточно сложным и гемор с постоянным сохранением/восстановлением начинает перекрывать все другие плюсы. Выкидываем всё сделанное, пишем нормальное SPA.

  • Выбираем состав изоморфных React-приложений на следующие 12 месяцев
    +1
    что думаете?

    была отличная общая статья про атомы: Атом — минимальный кирпичик FRP приложения, повлиявшая в том числе и на cellx. Вряд ли я могу написать лучше, общих статей и без меня хватает, если же я уйду в более подробное описание оптимизаций, вряд ли кто-то кроме vintage это осилит. Вот статейка типа "Пилим тудулист на React+cellx" может вполне интересной получится.


    Но почему — совсем непонятно

    как раз всё очень понятно, mobx крутится на западе, где легко собрать большое сообщество заинтересованных пользователей, а не просто покидаться какахами в комментах. Мне с моим китайским английским там довольно неуютно. Всё что я могу — постить ссылочки на хабре, но тут проблема — менталитет наших разработчиков — средний наш разработчик с большим восторгом воспринимает практически всё приходящее с запада, но и с не меньшей настороженностью смотрит на то, что делает его сосед. Ведь сосед — это не Джон, а просто Вася)), а Вася по определению должен быть тёмным.

  • Выбираем состав изоморфных React-приложений на следующие 12 месяцев
    0

    Добавил результаты.

  • Выбираем состав изоморфных React-приложений на следующие 12 месяцев
    0

    Да, результат заметно лучше и я вспомнил почему не добавил этот вариант — очень нестабильный результат, в новой вкладке ставлю 25к и запускаю несколько раз, результаты: 1644, 1258, 1685, 1258, 1383, 1333, 1891, 1368, 23092 !!!, 22571, 45864.
    Создаю новую вкладку и по новой: 1299, 1211, 1289, 1288, 1300, 1498, 23249 !!!, 27635, 52475. Я просто не знал и сейчас не знаю, что мне с этим делать. То есть на 5-10 запуске резкое падение производительности (консоль пустая). Могу добавить средний результат до этого падения (1300 примерно), так норм будет?

  • Выбираем состав изоморфных React-приложений на следующие 12 месяцев
    0
    25000 слоёв — это какое-то мифическое суперсложное приложение будущего

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


    Оптимизировал работу с глубокими цепочками: http://nin-jin.github.io/lib/props/props1.js

    ok, на днях добавлю)

  • Выбираем состав изоморфных React-приложений на следующие 12 месяцев
    0
    реальное приложение

    я тоже люблю поговорить про реальные приложения, особенно когда это касается каких-то view-фреймворков, но что касается cellx-а — я особо не пытаюсь привязать его только к реалиям сегодняшнего фронтенда, забивая при этом на любые проблемы возникающие за пределами этих реалий, я пытаюсь создать некую идеальную реализацию с самым минимумом ограничений и способную хорошо работать в том числе в любых нестандартных ситуациях: нужно бешенное число слоёв — пожалуйста, какие-то изменения ячеек прямо внутри расчёта предыдущих изменений — сколько угодно (прошлый раз вы тоже говорили, что такого в реальных приложениях массово не случается, но в более ранних версиях Rionite, когда он ещё на morphdom работал, вся развёртка компонентов происходила как раз во время расчёта уже случившегося изменения, при этом происходило как массовое создание ячеек, так и их массовое изменение и всё это в идеале отрабатывало, как видите может и что-то нестандартное пригодиться), множественные изменения единичных ячеек — без проблем, всё красиво схлопнется в одно событие с единичным изменением в dom-дереве (кто-то говорил, что это плохо и хочется полного контроля над всем случившимся, какие проблемы, в evt.prev полная история всего что схлопнулось). И так далее.
    Я заморачиваюсь над избавлением от RangeError в разных ситуациях, добиваюсь идеального увеличения времени расчёта при увеличении числа ячеек (в 5 раз увеличилось число ячеек, ровно в 5 раз, но не более, должно увеличится время расчёта), добиваюсь идеального высвобождения памяти после всего. Многое из этого вряд ли нужно сегодняшнему фронтенду, мне же просто нравится, спортивный интерес наверно.
    И именно поэтому я не выкладываю остальные свои тесты, часть из них пытается выявить ещё какие-то ловушки производительности (порой их довольно сложно привязать к какому-то реальному кейсу), другая — ещё какие-то мои заморочки. Я выложил, наверное, наиболее близкий к сегодняшней фронтендерской реальности тест, ловушка, что в нём, реально может подпортить нервов, но даже этот тест всякие умники (да да, вы тот ещё умник, в самом хорошем смысле :) ) постоянно пытаются выставить как какой-то неправильный и ничего не показывающий. Тут я ещё могу как-то отбиваться, выложив остальные тесты я просто создам кучу хороших вариантов для выставления cellx-а не в лучшем виде, просто примеряя их к той самой реальности (от которой порой, в нестандартных ситуациях, всё же приходится отходить и в случае многих реализаций сразу нарываться на проблемы).


    Мой патч не вносил никаких проседаний.

    если хотите, пришлите мне ещё раз ссылку на пропатченную версию, я оформлю её результаты отдельной колонкой. Лучше конечно если этот патч будет в основной версии, как я сказал, с пол года назад я легко ускорял cellx в 2-2.5 раза (в 3 раза вырезая часть функционала), затачивая именно под этот тест, но так, конечно, не совсем честно.

  • Выбираем состав изоморфных React-приложений на следующие 12 месяцев
    0
    Помнится мы с автором обсуждали этот вопрос,

    обсуждали и я уменьшал число слоёв с увеличением числа ячеек в каждом, для библиотек не умирающих на этом тесте (все кроме Knockout, Kefir.js и Matreshka.js) соотношение результатов не менялось, просто усложнялся код бенчмарка, поэтому для простоты повторения оставил как есть. Цель теста как раз отсечь библиотеки имеющие эту ловушку производительности и спокойно сравнивать уже оставшиеся (другие ловушки либо не так критично убивают производительность, либо почти невозможны в реальных приложениях).


    вносил патч в jin-atom

    я тоже знаю как внести патч в cellx что бы он стал в 3 раза быстрее заодно просев в некоторых других тестах (выложен только один из примерно 10).

  • Выбираем состав изоморфных React-приложений на следующие 12 месяцев
    0

    Примерно в три раза быстрее стал, на 1000 слоёв — 40-60, на 5000 так же — RangeError.

  • Выбираем состав изоморфных React-приложений на следующие 12 месяцев
    0

    Посмотрите на cellx, почти в 10 раз быстрее mobx-а, в остальном единственное значимое отличие — декораторы сделаны отдельным модулем. Коннектор к реакту здесь.

  • DiffHTML.js — утилита для патчинга DOM
    +1

    Аналог: morphdom и мой форк с поддержкой встроенного svg, сохранением позиции фокуса и гарантированным переиспользованием существующих уникальных (с id, key — в моём форке) элементов (оригинальный morphdom всё ещё имеет несколько кейсов типа этого).

  • Год использования ReactJS: подводим итоги
    0
    Но видимо для разработчиков с 10+ летним опытом это всё слишком тяжело.

    То что вы этого не видели, с вашим 10+летним опытом, отлично показывает что у вас за опыт.

    Общаться с вами стало просто неприятно, удачи вам.