Указанный в статье способ проблему FOUC не решит. Он был придуман в расчете на html import, от которого отказались.
Имеется так же ряд других проблем с конфликтом версий во вложенных компонентах и относительными путями. В целом идея хорошая, но использование связанно с дополнительными сложностями.
Когда код компилируется в WASM управление памятью (по сути типизированным массивом) происходит на стороне js. Обычно сгенерированный файл js для управления памятью занимает очень много места, но иногда нам не нужна аллокация с дефрагментацией, и можно значительно упростить логику выделения памяти, тогда вместо 1500 строк кода сгенерированного аллокатора можно вложится в 100-200.
Уменьшить время загрузки получается только по сравнению с асмжс, по сравнению с обычным жс время наоборот растет, так как приходится дополнительно грузить 1500 строк на жс для управления памятью (это может поменятся, если добавят сборщик мусора). Пока штука весьма полезная для портирования существующего кода в браузер (игры, криптография и т.п.) но весьма сомнительная для того, чтоб писать что-то с нуля для браузера. JS сейчас серьезно не хватает структур, целочисленная арифметика работает вполне сносно с помощью приведения Number к Int32 (a|0), плюс есть предложения как раз для арифметики (SIMD к сожалению пока в js решили не принимать и вернули на stage 1).
В реальном проекте как раз с этим проблемы. В контексте конструктора компонента документ равен основному документу, и как следствие относительные пути не работают. Так что, чтоб создать действительно переносимый компоненты приходится парсить цсс и дом (src картинок и т.п.) и менять все пути на абсолютные во время создания.
Подскажите, если нашли более элегантное решение данной проблемы.
Это означает, что если авторы модулей начнут публиковать исходный код на ES2015+ в npm, то они, вероятно, сломают некоторые сборки пользователей и просто вызовут путаницу.
Было предложение добавить поле module в package.json, чтоб решить эту проблему, но пока воз и ныне там.
посмотрите на авл-деревья они более простые (разница в длине веток не должна быть больше одного элемента) и на реальных данных обычно работают быстрее (удаление обходится дороже но если мало удаляете то можно смело использовать). идея везде до ужаса простая — если у вас есть список N элементов, то чтоб найти какой-то конкретный элемент вам нужно в худшем случае пробежаться от начала и до конца списка, то есть пройти N шагов, а если вы тот же список разветвили (с помощью операции сравнения) и превратили в дерево — то уже нужно пройти log N шагов. Любая операция — вставка или удаление должны менять дерево так, чтоб оно оставалось ветвистым (для авл деревьев — разница между высотой веток не больше 1 элемента, для красно-черных — не больше чем в два раза (потому их и красят в два цвета)) и не нарушалось правило поиска.
если вам нужно реализовать неизменяемые структуры данных то без деревьев они будут потреблять слишком много памяти. сортированные таблицы тоже без деревьев нормально не сделаешь.
Да нет, ее можно в функциональном написать, просто нужно еще состояние добавить аргументом (текущую суму), а реализацию трансдьюсера через фор делать, так быстрее.
Статьи эти смешные конечно, они на самом деле не о функ программировании а как-то вообще не о чем. Функ программирование по моему это скорее про структуры данных, тут ни слова о функторах и фолдебл, зато много пафоса про фор мертв.
Из реальных примеров все что генерируется компилятором удобнее писать в функ стиле так как оно тупо менее многословно и подчиняется простым правилам. А вот реализация этого функ стиля уже делается этими самыми мертвыми фор =)
Паша, зачем тебе пример из Рамды? Я думаю ты сам можешь написать функцию, которая вместо проверки длинны массива результатов выходит при другом условии.
Имеется так же ряд других проблем с конфликтом версий во вложенных компонентах и относительными путями. В целом идея хорошая, но использование связанно с дополнительными сложностями.
Подскажите, если нашли более элегантное решение данной проблемы.
Было предложение добавить поле module в package.json, чтоб решить эту проблему, но пока воз и ныне там.
Да нет, ее можно в функциональном написать, просто нужно еще состояние добавить аргументом (текущую суму), а реализацию трансдьюсера через фор делать, так быстрее.
Статьи эти смешные конечно, они на самом деле не о функ программировании а как-то вообще не о чем. Функ программирование по моему это скорее про структуры данных, тут ни слова о функторах и фолдебл, зато много пафоса про фор мертв.
Из реальных примеров все что генерируется компилятором удобнее писать в функ стиле так как оно тупо менее многословно и подчиняется простым правилам. А вот реализация этого функ стиля уже делается этими самыми мертвыми фор =)