И грабит всех подряд, включая тех, кому и так не хватает денег. Конечно круто грабить бедных, а потом якобы давать им бесплатные услуги на часто монополизированных рынках. Это же электорат, государство без него не может существовать)
Почему не придумали? В большинстве областей деятельности товары и услуги предоставляют частные компании. С теми услугами, которые якобы предоставляет государство тоже нет ничего такого, что не позволяет сделать исключительно частными.
Теория игр полезна до некоторой степени, всё же она не описывает на 100% происходящее в реальной жизни.
Люди могут вредить себе, с этим я не спорю, случается. Вот только запреты на государственном уровне вредят всегда, а это уже совсем другой уровень вероятности. Я за образование и свободный выбор.
Люди покупают то, что считают нужным. Если они покупают пластик — то это значит, что либо он им подходит больше, либо в противном случае они вообще ничего не купят.
Не нужно никаких ограничений, пусть каждый покупает что считает лучшим для себя. Для образования можете писать статьи с аргументацией, но люди не скот и должны иметь право выбирать что для них.
Нормальные люди должны просто игнорировать пластики, по возможности. Предлагаю начать с одноразовых зажигалок — пользоваться только спичками (это я курящим). Казалось бы это немного, но тут главное начать и дело пойдет. И не пользоваться одноразовыми стаканами, носить с собой 100 граммовый граненый стаканчик он небольшой.
В репозитории, ссылка есть в readme, там же есть ссылка на несколько скринкастов.
Вот прямой линк на текущую версию (для определённого релиза можно открыть на определённом тэге и посмотреть актуальную документацию на момент того релиза): https://github.com/nazar-pc/CleverStyle-Framework/tree/master/docs
Автоматических миграций (которые сравнивают текущую и нужную структуру, изменяя потом таблицы) нет, для обновления компонентов вы сами составляете SQL для преобразования структуры БД + пишете PHP код, если одной структурой не обойтись (либо ещё что-то кроме БД нужно мигрировать).
Пример в системном модуле: https://github.com/nazar-pc/CleverStyle-Framework/tree/6.28.1%2Bbuild-2543/modules/System/meta
А вообще есть системные события обновления компонентов, так что можно подписаться и реализовать автоматические миграции с помощью стороннего модуля если нужно.
Статья не самый лучший пример для таких вопросов.
Будьте добры, оформите с демкой здесь: https://github.com/nazar-pc/PickMeUp/issues
Там будем разбираться. Пример демки есть в readme, просто измените чтобы воспроизвести проблему.
Я знаком с внутренностями Poymer) Имел ввиду, что мета-информацию Polymer всё-таки при инициализации собирает, а мог бы собирать во время сборки, что позволило бы выжать ещё немного производительности.
В контексте статьи я говорю о производительности <template> и других нативных интерфейсов вроде непосредственной работы с DOM (или максимально приближенной к ней).
К примеру, сравнение использования <template> по сравнению со строкой для Shadow DOM: https://rawgit.com/ebidel/e9bcb6fc88b40fc26ed9e768f7d19961/raw/template_vs_innerhtml.html
Можете добавить тест с императивным созданием элементов что будет ближе к React и посмотреть на результат.
Всё верно, для того чтобы реализовать биндинги приходится пройтись по DOM и посмотреть на его внутренности. В то же время, частично внутренности уже готовы к использованию даже без парсинга, то есть, можно реализовать прогрессивную загрузку.
На счёт производительности как рантайма, так и загрузки и разбора я утверждать не возьмусь, ибо актуальный бенчмарков давно не видел, а сам с React не работаю.
Если соизволите сделать простой пример на React — с радостью портирую его на Polymer 1.x для сравнения.
На счёт сборки — да, для производительности инициализации это плюс. В теории для Polymer тоже можно реализовать систему сборки и дополнительно к <template> хранить ещё и мета-информацию о том, что находится внутри. На практике такое либо кто-то пробовал и увидел что бессмысленно, либо просто ни у кого не дошли до этого руки, вот уж не знаю что из этого.
Это зависит от многих факторов: иногда и правда дико сложно, иногда совсем нет.
Я работаю с Polymer, который старается максимально использовать веб-платформу. Когда он рендерит ряд элементов, используя массив — он не производит полноценный virtal DOM, он хранит лишь немного мета-информации. Когда вы модифицируете массив — он знает, что ему не нужно повторно рендерить все элементы, достаточно посмотреть мета-информацию и обновить только нужную часть.
Это альтернативный подход, где мы тоже достигаем эффективной работы с реальным DOM без добавления сложности, но при этом используем то, что встроено в браузер по максимуму.
На самом деле писать производительно (не на пике, но достаточно хорошо) не так и сложно. К тому же, не так много компонентов, где производительность критична, а те, где критично для того чтобы выжать максимум всё равно придется приблизиться к родному DOM.
Тот же Polymer работает с реальным DOM напрямую, и делает это достаточно эффективно. Он не строит виртуальный DOM, а использует реальный и возможности веб-платформы, что дает очень хороший уровень производительности (основные существующие просадки возникают из-за эмуляции Shadow DOM и кучи CSS возможностей из недалекого будущего).
Вы должны понимать, что оно никогда и никак не может работать быстрее чем DOM, потому как от самого DOM вы никуда не деваетесь. Вы кроме виртуального DOM всегда имеете рядом реальный.
Виртуальный DOM по сути является оверхедом по сравнению с тем, если бы вы эффективно использовали реальный. Да, он позволяет вам делать кривые вызовы и преобразовывать их в не такие кривые, получая прирост производительности, но в целом это всегда реальный DOM плюс (а не вместо) виртуальный.
И это уже не говоря о том, на сколько сгенерированный React сниппет будет медленней чем простой <template>, который браузер парсит напрямую, и то, что для <template> нет необходимости в системе сборки (всегда хорошо иметь необязательные вещи, это добавляет гибкости).
С одной стороны может быть дискомфорт. С другой стороны, загружая HTML с помощью HTML импортов, а не в виде строки вы используете возможности платформы для парсинга содержимого, что очень важно с точки зрения производительности.
Нет, я использую пакеты пока не порвутся. Всегда в рюкзаке 1-2 лежит на случай если будет нужно.
Не помню, я тогда был ещё маленький. Но то, что происходило, было не без участия государства и государственных структур.
P.S. Боюсь, мы уходим за тематику ресурса.
И грабит всех подряд, включая тех, кому и так не хватает денег. Конечно круто грабить бедных, а потом якобы давать им бесплатные услуги на часто монополизированных рынках. Это же электорат, государство без него не может существовать)
Почему не придумали? В большинстве областей деятельности товары и услуги предоставляют частные компании. С теми услугами, которые якобы предоставляет государство тоже нет ничего такого, что не позволяет сделать исключительно частными.
Теория игр полезна до некоторой степени, всё же она не описывает на 100% происходящее в реальной жизни.
Люди могут вредить себе, с этим я не спорю, случается. Вот только запреты на государственном уровне вредят всегда, а это уже совсем другой уровень вероятности. Я за образование и свободный выбор.
Люди покупают то, что считают нужным. Если они покупают пластик — то это значит, что либо он им подходит больше, либо в противном случае они вообще ничего не купят.
Не нужно никаких ограничений, пусть каждый покупает что считает лучшим для себя. Для образования можете писать статьи с аргументацией, но люди не скот и должны иметь право выбирать что для них.
Полагаю, это такая шутка?
В репозитории, ссылка есть в readme, там же есть ссылка на несколько скринкастов.
Вот прямой линк на текущую версию (для определённого релиза можно открыть на определённом тэге и посмотреть актуальную документацию на момент того релиза): https://github.com/nazar-pc/CleverStyle-Framework/tree/master/docs
Автоматических миграций (которые сравнивают текущую и нужную структуру, изменяя потом таблицы) нет, для обновления компонентов вы сами составляете SQL для преобразования структуры БД + пишете PHP код, если одной структурой не обойтись (либо ещё что-то кроме БД нужно мигрировать).
Пример в системном модуле: https://github.com/nazar-pc/CleverStyle-Framework/tree/6.28.1%2Bbuild-2543/modules/System/meta
А вообще есть системные события обновления компонентов, так что можно подписаться и реализовать автоматические миграции с помощью стороннего модуля если нужно.
Статья не самый лучший пример для таких вопросов.
Будьте добры, оформите с демкой здесь: https://github.com/nazar-pc/PickMeUp/issues
Там будем разбираться. Пример демки есть в readme, просто измените чтобы воспроизвести проблему.
Статья о том, что вы не обновляете ПО, я всё правильно понял? А при чем здесь безопасность неактуальных версий PhpBB?
Быть параноиком на XP — это сильно!
Я знаком с внутренностями Poymer) Имел ввиду, что мета-информацию Polymer всё-таки при инициализации собирает, а мог бы собирать во время сборки, что позволило бы выжать ещё немного производительности.
Preview даже близко не работает как нативная Firefox OS. Имею несколько устройств, и ставил эту preview на Android устройство.
А он был закрытым?)
В контексте статьи я говорю о производительности
<template>и других нативных интерфейсов вроде непосредственной работы с DOM (или максимально приближенной к ней).К примеру, сравнение использования
<template>по сравнению со строкой для Shadow DOM: https://rawgit.com/ebidel/e9bcb6fc88b40fc26ed9e768f7d19961/raw/template_vs_innerhtml.htmlМожете добавить тест с императивным созданием элементов что будет ближе к React и посмотреть на результат.
Всё верно, для того чтобы реализовать биндинги приходится пройтись по DOM и посмотреть на его внутренности. В то же время, частично внутренности уже готовы к использованию даже без парсинга, то есть, можно реализовать прогрессивную загрузку.
На счёт производительности как рантайма, так и загрузки и разбора я утверждать не возьмусь, ибо актуальный бенчмарков давно не видел, а сам с React не работаю.
Если соизволите сделать простой пример на React — с радостью портирую его на Polymer 1.x для сравнения.
На счёт сборки — да, для производительности инициализации это плюс. В теории для Polymer тоже можно реализовать систему сборки и дополнительно к
<template>хранить ещё и мета-информацию о том, что находится внутри. На практике такое либо кто-то пробовал и увидел что бессмысленно, либо просто ни у кого не дошли до этого руки, вот уж не знаю что из этого.Это зависит от многих факторов: иногда и правда дико сложно, иногда совсем нет.
Я работаю с Polymer, который старается максимально использовать веб-платформу. Когда он рендерит ряд элементов, используя массив — он не производит полноценный virtal DOM, он хранит лишь немного мета-информации. Когда вы модифицируете массив — он знает, что ему не нужно повторно рендерить все элементы, достаточно посмотреть мета-информацию и обновить только нужную часть.
Это альтернативный подход, где мы тоже достигаем эффективной работы с реальным DOM без добавления сложности, но при этом используем то, что встроено в браузер по максимуму.
На самом деле писать производительно (не на пике, но достаточно хорошо) не так и сложно. К тому же, не так много компонентов, где производительность критична, а те, где критично для того чтобы выжать максимум всё равно придется приблизиться к родному DOM.
Тот же Polymer работает с реальным DOM напрямую, и делает это достаточно эффективно. Он не строит виртуальный DOM, а использует реальный и возможности веб-платформы, что дает очень хороший уровень производительности (основные существующие просадки возникают из-за эмуляции Shadow DOM и кучи CSS возможностей из недалекого будущего).
Вы должны понимать, что оно никогда и никак не может работать быстрее чем DOM, потому как от самого DOM вы никуда не деваетесь. Вы кроме виртуального DOM всегда имеете рядом реальный.
Виртуальный DOM по сути является оверхедом по сравнению с тем, если бы вы эффективно использовали реальный. Да, он позволяет вам делать кривые вызовы и преобразовывать их в не такие кривые, получая прирост производительности, но в целом это всегда реальный DOM плюс (а не вместо) виртуальный.
И это уже не говоря о том, на сколько сгенерированный React сниппет будет медленней чем простой
<template>, который браузер парсит напрямую, и то, что для<template>нет необходимости в системе сборки (всегда хорошо иметь необязательные вещи, это добавляет гибкости).С одной стороны может быть дискомфорт. С другой стороны, загружая HTML с помощью HTML импортов, а не в виде строки вы используете возможности платформы для парсинга содержимого, что очень важно с точки зрения производительности.