• Как мы на React 16 переезжали
    0

    Ещё раз: проблема не в отсутствии обратной совместимости, что нормально для мажорной версии (16 раз за 4 года уже ломали апи или просто так счётчик накручивали?). Проблема в невозможности постепенного переезда. "Не правильные" и "недокументированные" методы использовались ведь не просто так, а решали конкретные задачи, которые без них, "правильными" и "документированными" методами было не решить. Те же "порталы", например.


    Ну а аргумент "мы вам пол года кидали варнинги — почему вы до сих пор не обновили код сторонних библиотек?!?" — вообще мимо кассы.

  • Организация отступов в верстке (margin/padding)
    0

    А чем модификаторы хуже?

  • Архитектуры ReactNative, Xamarin, PhoneGap и Qt. Часть 1
    0
    За то что у вас все висит в однопоточном WebView. Соответственно как только речь заходит о разработке больших приложений начинаются лаги, тормоза и т.п.

    На самом деле WebView не такой уж и однопоточный. Композиция и соответствующие анимации, не требующие перерисовки, происходят в отдельном потоке. Тормоза начинаются если анимации делаются на JS и если пытаться рендерить сразу все элементы, в то время как видимыми из них будут хорошо если 5%. Мы пробовали использовать полимер и ионик и всё тупило даже в тривиальных примерах. Поэтому запилили свой фреймворк, который по умолчанию рендерит лишь минимум, а остальное дорендеривает лишь по мере прокрутки. Давайте кооперироваться ;-)

  • Как мы на React 16 переезжали
    0

    У вас взаимоисключающие параграфы. Невозможность частичного перевода проекта на новую версию библиотеки — типичная детская болезнь.

  • Организация отступов в верстке (margin/padding)
    +2
        & + & {
            margin-top: 2px;
        }
        &--big + & {
            margin-top: 4px;
        }
    
        & + &--big {
            margin-top: 10px;
        }
        &--big + &--big {
            margin-top: 20px;
        }   

    Для тех, кто собирает имена классов по кусочкам (что в css, что в js) — есть отдельный котёл в аду.

  • Как мы на React 16 переезжали
    0

    Отсутствие инкапсуляции и огромный размер либы привели к тому, что нельзя постепенно переходить на новый рендерер. Обновил рендерер — изволь сразу же поправить всю свою кодовую базу и все сторонние библиотеки, иначе не взлетит. Детский сад.

  • Cj — новый язык программирования
    +1

    const z = (x+y+384)%256-128

  • Cj — новый язык программирования
    0

    Ну, если сформулируете — присоединяйтесь: https://t.me/lang_idioms :-)

  • Организация отступов в верстке (margin/padding)
    0

    Сколько сложностей. Проще же элементам списка дать половинный margin, а контейнеру половинный padding.


    ul {
        padding: .5rem;
    }
    li {
        margin: .5rem;
    }

    У любой строки текста из-за line-height будет отступ сверху и снизу, который вы никак не уберёте (вариант с line-height=1 как правило не катит ибо не дружит с переносом текста). То есть вам в любом случае придётся учитывать, что у некоторый блоков будут симметричные отступы сверху и снизу. Поэтому лучше сразу всё и делать на симметричных отступах. Это и кода меньше займёт и лучше дружит с переносами блоков на новую строку.

  • Cj — новый язык программирования
    0

    Идея не может быть сырой. Просто у меня похожие идеи. Могли бы заняться перекрёсным опылением.

  • Cj — новый язык программирования
    0

    Не хотите ли рассказать о своей идее по подробней?

  • Вы уволили самого талантливого сотрудника. Надеюсь, теперь вы довольны
    +1

    Вовсе не обязательно, хотя споров будет много, конечно. Эйнштейнов лучше сразу сажать в отдельной переговорке :-)

  • Киллер фича Vim
    +1

    Вы зря переключение языка по разным клавишам считаете решением. Предлагаемый вами подход приводит к одному из 2 сценариев:


    1. Если пользователь переключает раскладку лишь когда думает, что сейчас не та, то получает одни и те же проблемы что с одной клавишей переключения, что с двумя.
    2. Если пользователь переключает на нужную раскладку каждый раз начиная ввод, то это очень дофига ритуализированных нажатий. Любое сколь угодно краткое вырывание из потока ввода текста и надо снова актуализировать выбранную раскладку. Кстати, идея для вима: переходить в режим ввода текста, не по нажатию на i, а по выбору конкретного языка ввода. ir и ie, например.

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


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

  • Путешествие из Node в Crystal
    0

    Не миллион, не преувеличивайте, они же фильтруются по типу первого аргумента.

  • Cj — новый язык программирования
  • $mol: reactive micromodular ui-framework
  • Идеальный UI фреймворк
    0
    Про todomvc — какой оценивать реальную производительность фреймворка по этому показателю?

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


    Думаете кто то реально будет использовать фреймворк на 1мб для реализации подобных задач?

    Это уже происходит, ибо с фреймворком разработка идёт быстрее.


    Почти любой разраб реализует эту задачу на vanila.js более качественно чем с фреймворком.

    Почему же тогда VanillaJS реализация существенно проигрывает половине фреймворков? Ассемблер Ванильный яваскрипт позволяет талантливому разработчику написать быстрое приложение. Си++ Фреймворк позволяет посредственному разработчику написать приложение не хуже за вдвое меньшее время.


    А на более сложных задачах все будет в большей степени зависеть от конкретной реализации, в меньшей степени от фреймворка.

    Только если вы сначала продумываете архитектуру, а потом подбираете/пишите для неё фреймворк. Но зачастую сначала выбирают фреймворк, а потом он диктует архитектуру приложения.


    Если отрисовка и фпс — самый критичный фактор — вряд ли кто то вообще будет использовать фреймворк, т.к. нативная реализация будет заведомо более оптимизируемой и контролируемой.

    Почему же игры (где за низкий фпс вас закидают геймпадами) поголовно делаются на фреймворках (так называемых "движках")?

  • Cj — новый язык программирования
    +1

    Сомневаюсь, что вы найдёте единомышленников в разработке языка под вас. Но если будут интересные идеи касательно языков — пишите нам в телеграм чат: https://t.me/lang_idioms

  • Киллер фича Vim
    0

    А чего вы не используете средства миграции для обновления хранимок?

  • Киллер фича Vim
    0

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

  • Киллер фича Vim
    0
    Ну люди же работаю как-то на Mac'е где нужно помнить в какой программе это Ctrl-C/V, а в какой — Command-C/V и ничего.

    Что за бинарное мышление? Наличие неудобства не означает, что его невозможно терпеть. А а возможность человека привыкать к неудобствам не означает, что эти неудобства не стоит устранять.

  • Киллер фича Vim
  • Киллер фича Vim
    –1

    Конечно же я попрусь править код на сервере, чтобы уронить вообще всё к чертям.

  • Киллер фича Vim
    0

    И про это там тоже есть. Можете поискать по "не находится в локусе внимания".

  • Киллер фича Vim
    +2

    Никогда не понимал тех мазохистов, что правят код прямо на сервере.

  • Как собеседовать инженеров-программистов
  • Киллер фича Vim
    0

    Нет, тут разница скорее между однопоточностью и многопоточностью. То, что в однопоточной программе получается автоматически, в многопоточной (гуй — это почти всегда несколько потоков) требует намеренной реализации.

  • TeaVM — инструмент для создания веб-фронтэнда на Java, Kotlin и Scala
    0

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

  • TeaVM — инструмент для создания веб-фронтэнда на Java, Kotlin и Scala
    0

    https://habrahabr.ru/post/126818/


    Не нужно городить лишних абстракций. Фреймворк может брать на себя оптимизации, позволяя программисту писать простой и понятный код.

  • TeaVM — инструмент для создания веб-фронтэнда на Java, Kotlin и Scala
    0

    Скорее всего пользователь сделает как проще и всё буде тормозить. Насколько я понял Flavour никакой не фреймворк, а просто библиотека для рендеринга.

  • TeaVM — инструмент для создания веб-фронтэнда на Java, Kotlin и Scala
    0

    Обновление массива от обновления дома ни чем принципиально не отличается. В обоих случаях при изменении одного состояния нужно изменить другое за минимальное число шагов, не делая при этом лишней работы.

  • TeaVM — инструмент для создания веб-фронтэнда на Java, Kotlin и Scala
    0

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

  • TeaVM — инструмент для создания веб-фронтэнда на Java, Kotlin и Scala
    –1

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


    Присылайте пул-реквест сюда: https://github.com/eigenmethod/todomvc

  • TeaVM — инструмент для создания веб-фронтэнда на Java, Kotlin и Scala
  • Киллер фича Vim
    –1

    В emacs разве ещё нет встроенного браузера и мессенджера? :-)

  • Киллер фича Vim
    –4

    Хочу из списка слов разделённых пробелами получить все варианты их перестановок, каждый на отдельной строке.


    Хочу по нескольким введённым словам получить осмысленное предложение-палиндром, начинающееся с них.


    Хочу по введённой строке текста получить список словосочетаний, которые рифмуются с окончанием строки.

  • Киллер фича Vim
    +5

    Всё, что вы описали умеет любой современный редактор. И подсветка синтаксиса за 10 минут и рефакторинг по регуляркам и прочие радости жизни.

  • Киллер фича Vim
    0

    Вы правда считаете, что 40мб для консольной утилиты — это мало?

  • Киллер фича Vim
    –2

    Неужели экономия одного нажатия рядом стоящей клавиши стоит введения ещё одного "режима"? Это совершенно не то место, где нужно оптимизировать. Вот закрывающие теги в HTML — это да, экономия. Хотя, куда лучше вообще отказ от HTML если не на уровне исходных кодов, то уж на уровне представления при редактировании — точно.

  • JavaScript ES8 и переход на async / await
    +1

    Что не так с веб-аппами?