Если внешний JavaScript-файл размещается непосредственно перед закрывающим тегом body, то использование async и defer становится менее уместным
Менее уместно, но всё же уместно? Например, если у нас 5 внешних скриптов в конце body то без defer, они будут загружаться один за другим (так как парсер соответственно поочередно будет переходить от одного тэга script к другому). А вот с defer у каждого тэга можно загрузку распараллелить. Я правильно понимаю?
И вижу, что мы всё же работаем с каждым конкретным свойством. Если и font size зависит от type, выносите это тоже в тему? Не раздуваются ли темы тогда, что в них слишком много стейтов для разных компонент? Можно как-то именно расширять стили? Пример из вакуума:
Просто потому, что это его максимум. Он не расширяеться никак. Вот нам нужны ещё стейты danger, success, как нам условие переписать?
Немогли бы вы привести пример который хорошо и удобно масштабируется?
А как собирается проект/компонент? С импортами понятно, а что происходит со всеми этими литералами './player.component.html', ['./player.component.styl']?
А вы сравните два способа, через google и через msdn.com)
Google: в адр. строке "msdn CreateFile" [Enter] [Tab] (первый результат) [Enter] и вы уже на странице.
Msdn.com: в адр. строке "msdn.com" [Enter] [ Мышкой кликаем на поле пoиска] ["CreateFile"] [Enter] [Мышкой кликаем на первый результат].
Сравнили? И как вам, к тому же, скорость загрузки msdn?)
Отлично, в браузере стало действительно легче "дышать". А реклама в youtube приложении блокируется? А то у меня без рекламы только youtube в браузере. Но и это уже шикарно)
И такой вопрос, по теме Knox и фаервола, или возможно с их API как-то блокировать отдельные приложения для доступа в интернет по мобильной сети? А то в этой области такая же ситуация, или рут нужен, или приложения создают vpn и на том уровне блокируют, но работает это ужасно не стабильно.
Скажите пожалуйста, везде читаю про "глобальную" сборку, а как выглядит разбиение и сборка по страницам. Я сейчас имею ввиду не классические страницы, а всё ещё single page app. Просто его нужно же тоже разбивать на страницы (view), таким образом, что если пользователь заходит изначально в один view, то ресурсы для других не загружаются, переходит пользователь в другое вью, мы просто подгружаем ресурсы для него, и так далее, ну вы меня понимаете. Так вот, например, react-router: есть у нас компоненты UserList и UserEditor под разные маршруты. У каждой страницы свои зависимости. Но есть и глобальные зависимости для приложения, jquery.js например. И теперь когда собираем приложение:
будут ли ресурсы разделены по бандлам, например global.js, user-list.js и user-editor.js?
будут ли бандлы грузиться в зависимости от маршрута?
что будет происходить с компонентами которые будут и в UserList, и в UserEditor использованы, но не в глобальных зависимостях?
система сборки как-то перепишет мой код, что бы грузить сначала нужный бандл, вместо десятка скриптов для страницы?
Может знаете пример небольшого приложение, где будет разделение на страницы и соответственно сборка тоже по страницам. Не обязательно реакт, что нибудь, интересен просто подход. Или просто статью, где именно акцент на view dependencies.
Жаль, что не продуманы 2 вещи — прогресс и отмена. Особенно отмена, или как минимум прерывание цепочки .then(...).then(...).then(...), предлагают самому в каждом then проверять "флаги". И жаль, что always таки не попал в спецификацию.
это свойство лучше всего использовать ровно перед тем, как сама анимация будет совершена, например, навешивать это свойство при ховере
А как поступать, если мы открываем меню по нажатию горячих клавиш, на пример "m"? Добавлять свойство на keydown, а на keyup уже показывать? Но что если нужно показать непосредственно сразу при нажатии?
Ну не скажите, а утилиты, хэлперы, сервисы? А если строить систему на интерфейсах с внедрением зависимостей? А юнит-тесты? В любом случае, валидаторами дело не заканчиваеться, поэтому зря вы ими ограничиваетесь. По второму пункту: с чего вы взяли что клиент отресует картинку быстрее? Даже если скрипты закешированы их нужно вытащить-распарсить; шаблоны закешированы? и сново достать распарсить, без этого шаблонизатор не начинает создавать dom/html; также для рендеринга нужны данные, и за ними обычно идут по http. Как бы вы не противились, если трезво оценить ситуацию, это действительно два плюса. Я не утверждаю, что это прям всем нужно и без этого никак, но от этого они не перестают быть плюсами)
I. Не меняйте стили элемента напрямую в коде, используйте css-классы для переключения внешнего вида элемента. Или используйте свойство cssText.
А разве reflow это не отложенное действие, которое откладываеться на конец ивент лупа или до принудительного перерасчета? То-есть, изменяя свойства top, left произойдет лишь один reflow, как и в случаях с css классом и cssText.
Мой комментарий был лишь к тому, что бы читатель понимал из-за чего достигается подобное поведение. И я например не считаю, что это можно назвать асинхронностью, но и в дискуссию также не хочу вступать, если считаете иначе, то пускай так и будет. Это всего лишь мое мнение. Но изменение очереди вызова функций, лично мне, сложно назвать асинхронностью. Ведь в конце концов, вызов функций остаётся синхронным, лишь порядок изменяется. То есть здесь нет никого, кто бы выполнял какой либо таск вне потока ивэнт лупа. Но и вы тоже отчасти будете правы если скажете, что функция не синхронная, так как в данном случае мы не можем использовать, например return x, так как функция возвращает свой результат в коллбэке, который в свою очередь будет вызван хоть и синхронно, но после актуального вызова.
Ну какая же это асинхронность, это всего лишь отложенный вызов функции, который достигается перекладыванием на верх ивэнт лупа. Так же как и nextTick. Есть ещё setImmediate, который кладёт вызов функции вниз ивэнт лупа. Поэтому манипуляции с ивэнт лупом можно назвать "отложенностью", но никак не "асинхронностью".
Менее уместно, но всё же уместно? Например, если у нас 5 внешних скриптов в конце
bodyто безdefer, они будут загружаться один за другим (так как парсер соответственно поочередно будет переходить от одного тэга script к другому). А вот сdeferу каждого тэга можно загрузку распараллелить. Я правильно понимаю?Вау, шикарный и чистый код. Вот бы у всех так)
Ясно, спасибо. Немного подправлю и этот пример, потому что — интерполяция в интерполяции, а там ещё и трансформация?! :) Кхэ кхэ ...
И вижу, что мы всё же работаем с каждым конкретным свойством. Если и font size зависит от
type, выносите это тоже в тему? Не раздуваются ли темы тогда, что в них слишком много стейтов для разных компонент? Можно как-то именно расширять стили? Пример из вакуума:Пример абсолютно не удачный, и мне жалко тех, кто так пишет:
Просто потому, что это его максимум. Он не расширяеться никак. Вот нам нужны ещё стейты
danger,success, как нам условие переписать?Немогли бы вы привести пример который хорошо и удобно масштабируется?
А как собирается проект/компонент? С импортами понятно, а что происходит со всеми этими литералами
'./player.component.html', ['./player.component.styl']?Сразу бросились в глаза 2 ошибки производительности в
fiboJsMemoПочему автор не написал этот вариант также как и си. Не умышленно ли часом?
Главное, проценты у авторa получились красивые.
А вы сравните два способа, через google и через msdn.com)
Google: в адр. строке "msdn CreateFile" [Enter] [Tab] (первый результат) [Enter] и вы уже на странице.
Msdn.com: в адр. строке "msdn.com" [Enter] [ Мышкой кликаем на поле пoиска] ["CreateFile"] [Enter] [Мышкой кликаем на первый результат].
Сравнили? И как вам, к тому же, скорость загрузки msdn?)
Вместо windows лучше сразу писать "msdn open file". Для поиска по Mozilla Developer Network пишем "mdn open file".
Отлично, в браузере стало действительно легче "дышать". А реклама в youtube приложении блокируется? А то у меня без рекламы только youtube в браузере. Но и это уже шикарно)
И такой вопрос, по теме Knox и фаервола, или возможно с их API как-то блокировать отдельные приложения для доступа в интернет по мобильной сети? А то в этой области такая же ситуация, или рут нужен, или приложения создают vpn и на том уровне блокируют, но работает это ужасно не стабильно.
Скажите пожалуйста, везде читаю про "глобальную" сборку, а как выглядит разбиение и сборка по страницам. Я сейчас имею ввиду не классические страницы, а всё ещё single page app. Просто его нужно же тоже разбивать на страницы (
view), таким образом, что если пользователь заходит изначально в один view, то ресурсы для других не загружаются, переходит пользователь в другое вью, мы просто подгружаем ресурсы для него, и так далее, ну вы меня понимаете. Так вот, например,react-router: есть у нас компонентыUserListиUserEditorпод разные маршруты. У каждой страницы свои зависимости. Но есть и глобальные зависимости для приложения,jquery.jsнапример. И теперь когда собираем приложение:global.js,user-list.jsиuser-editor.js?UserList, и вUserEditorиспользованы, но не в глобальных зависимостях?Может знаете пример небольшого приложение, где будет разделение на страницы и соответственно сборка тоже по страницам. Не обязательно реакт, что нибудь, интересен просто подход. Или просто статью, где именно акцент на view dependencies.
Жаль, что не продуманы 2 вещи — прогресс и отмена. Особенно отмена, или как минимум прерывание цепочки
.then(...).then(...).then(...), предлагают самому в каждомthenпроверять "флаги". И жаль, чтоalwaysтаки не попал в спецификацию.Очень заманчивое предложение, однозначно было бы интересно поучаствовать и рассказать про мой опыт в atma и в частности о maskjs.
А как поступать, если мы открываем меню по нажатию горячих клавиш, на пример "m"? Добавлять свойство на keydown, а на keyup уже показывать? Но что если нужно показать непосредственно сразу при нажатии?
Всё ясно, спасибо)
Ну не скажите, а утилиты, хэлперы, сервисы? А если строить систему на интерфейсах с внедрением зависимостей? А юнит-тесты? В любом случае, валидаторами дело не заканчиваеться, поэтому зря вы ими ограничиваетесь. По второму пункту: с чего вы взяли что клиент отресует картинку быстрее? Даже если скрипты закешированы их нужно вытащить-распарсить; шаблоны закешированы? и сново достать распарсить, без этого шаблонизатор не начинает создавать dom/html; также для рендеринга нужны данные, и за ними обычно идут по http. Как бы вы не противились, если трезво оценить ситуацию, это действительно два плюса. Я не утверждаю, что это прям всем нужно и без этого никак, но от этого они не перестают быть плюсами)
У "изоморфности" двя плюса с которыми, как по мне, сложно спорить: переиспользование кода и скорость отображения контента.
А разве reflow это не отложенное действие, которое откладываеться на конец ивент лупа или до принудительного перерасчета? То-есть, изменяя свойства top, left произойдет лишь один reflow, как и в случаях с
cssклассом иcssText.Мой комментарий был лишь к тому, что бы читатель понимал из-за чего достигается подобное поведение. И я например не считаю, что это можно назвать асинхронностью, но и в дискуссию также не хочу вступать, если считаете иначе, то пускай так и будет. Это всего лишь мое мнение. Но изменение очереди вызова функций, лично мне, сложно назвать асинхронностью. Ведь в конце концов, вызов функций остаётся синхронным, лишь порядок изменяется. То есть здесь нет никого, кто бы выполнял какой либо
тасквне потокаивэнт лупа. Но и вы тоже отчасти будете правы если скажете, что функция не синхронная, так как в данном случае мы не можем использовать, напримерreturn x, так как функция возвращает свой результат вколлбэке, который в свою очередь будет вызван хоть и синхронно, но после актуального вызова.Ну какая же это асинхронность, это всего лишь отложенный вызов функции, который достигается перекладыванием на верх ивэнт лупа. Так же как и nextTick. Есть ещё setImmediate, который кладёт вызов функции вниз ивэнт лупа. Поэтому манипуляции с ивэнт лупом можно назвать "отложенностью", но никак не "асинхронностью".