Одно из преимуществ Deno, которые мы тут обсуждаем — отказ от npm, package.json
Ну, не совсем.
npm — менеджер пакетов. Ряд озвученных вами вопросов, действительно стоит остро, и утилиты, для анализа всей кодовой базы или какой-то части и вывода статистики по всем зависимостям по модульно действительно не хватает. И, если будет потребность, то такие появятся. Но текущие реализации, я думаю, жертвы привычки.
package.json — Можно назвать глобальным конфигом для всего проекта. В нем и название, и версия, и зависимости, и инструкции по сборке, и имена авторов и все все все. Deno предлагает перенести список зависимостей из глобального реестра непосредственно в кодовую базу. Но, это не означает, полный отказ от глобального файла с конфигурацией проекта. Вполне может существовать какой-то package.json с названием, списком авторов, какими-то ссылками на документацию, репозиторий, лицензию, списком точек входа для запуска тестов или самого приложения.
Сейчас Deno и его сообщество в зародыше. Лучшие практики ещё не выработаны, инструменты не написаны.
Но вот эта штука с импортами — не пришей нигде рукав.
Может и так. Лично я пока не вижу тут проблем. Но, справедливости ради, я и не искал особо. Мне видится тут больше гибкости. Вы пишите что-то простое? Вам не нужно заворачиваться с установкой зависимостей локально. Просто пишите код. Работаете над чем то побольше? Создайте свой реестр зависимостей. Со временем появятся инструменты для их анализа.
Deno как и NodeJs — это среда исполнения. Для NodeJs существует отдельная утилита — пакетный менеджер — npm. Она берет на себя роль управления всеми зависимостями, не только для рантайма, а в целом по проекту, их обновлением и всё в таком духе.
Мне видится в этом больше преимущество. Как я понимаю в этом и весь прикол, что у вас нет списка зависимостей на весь проект. А каждый ваш модуль/файл имеет собственный набор зависимостей. И вы можете спокойно изменять зависимости в одном модуле не боясь сломать все остальные.
Вот представьте ситуацию:
Вам пришла задача, сделать какую-то фичу. Для вас это не проблема, вы нашли библиотеку "А" и хотите её использовать. Но вот проблема — в проекте уже применяется библиотека "А" причем версии "0.0.1" в старом многолетнем legacy. Имея такую систему как у Deno, вы об этом вообще можете не думать. Старый модуль будет использовать свою версию, а вы можете использовать свою.
Потому, что иногда имеет смысл ожидать результат позже
// Start downloading data in advance
const promise = fetch('/user')
// Do something very difficult and time consuming
heavy()
// Waiting for the data download to finish
const {user} = await promise
Как мне кажется, это уже вопрос архитектуры. Если есть два независимых модуля, то один не должен ломаться при изменении реализации второго. Главное чтобы возвращаемые структуры были идентичными. А если два "модуля" сильно связаны между собой, тогда здравый смысл подсказывает, что они должны использовать общую версию зависимостей.
Ну, по моему это легко решится. Как только придёт необходимость появятся утилиты аля "deno-outdated" которые будут смотреть по всем файлам и выдадут список устаревших зависимостей для каждого модуля.
Вы, конечно правы. Но как мне видится идея в том, что у вас не весь ваш проект зависит от moment, а каждый отдельный модуль/файл зависит от moment конкретной версии. Я вижу в этом возможность очень легко переводить обновление зависимостей в проекте по частям.
Вы правы. Я не дизайнер. И если уж на то пошло, то и верстальщиком себя не считаю. Тема статьи — показать преимущества одной CSS функции в определённом спектре задач. Если вы работаете над одним сайтом, со статическим контентом, где каждое слово, каждое подчеркивание выверено до субпикселя того, я полагаю, описанные мною техники для вас не важны, или даже вредны. Но есть же и другие задачи. Скажем разработка темы для какой-то CMS. Там вы не можете знать какой контент будет на странице. Или конвеерная разработка. Когда нужно скопировать бОльшую часть из одного проекта, добавить куски другого чутка изменить и выкатить
Здесь скорость, гибкость и простое масштабирование куда важнее. Как бы грустно это не звучало.
Да и не только для дизайнеров. Первый же юзкейс который приходит на ум: вы делаете библиотеку компонентов. И в каждый компонент можно передать значение Hue но только его. При некоторых значениях цвет будет восприниматься слишком ярким, или темным, что вынудит пользователя вашей библиотеки дополнительно запарится чтобы выровнять воспринимаемою яркость у отдельных элементов.
Да, если хранить в переменных весь цвет, тогда не важно в каком он формате. Но гибкость появляется в тот момент, когда в переменных вы храните именно составляющие части цвета а не цвет целиком. Тогда вы можете получать цвет из составных частей "на месте", внутри каждого компонента и изменять их под разные нужды в зависимости от ситуации. Это часто необходимо, когда вы создаёте что-то более чем просто верстку по идеальному макету. Когда у вас есть необходимость получать производные цвета от какого-то одного, но вы не знаете какой он, или хотите иметь возможность легко его изменять. Или когда вы занимаетесь поддержкой проекта, в который постоянно вносятся изменения и часто, без макета с отдельным артбордом на каждую правку.
Всем привет из Киева. Тут жопа наступила уже чуть больше двух недель назад.
Все компании по немножечко загибаются.
Всех сотрудников, в почти принудительном порядке перевели на удалёнку. Из моих знакомых некоторым сократили зарплаты на 15-20%, и не ясно будет ли это как-то компенсироваться. Тех кто не может работать удалённо, отправляют в отпуск. Иногда оплачиваемый, но чаще нет.
Бизнес переходит в режим супер экономии. Пытаются получать хоть какую-то прибыль. В ресторанах предлагают скидки под 30% на еду (только с доставкой на дом). Кинотеатры предлагают дешевые промокоды которые после карантина можно будет обменять на билеты на любой сеанс. Некоторые сервисы доставки начали работать бесплатно (вернее перестали брать деньги за доставку непосредственно с покупателя). Провайдеры ТВ и интернета предлагают скидки на свои сервисы.
Те кто работают в рекламной сфере, сообщают, что большинство их клиентов отменяют рекламные кампании и любое промо. Как следствие рекламные агентства теряют деньги, Google теряет деньги, все кто зарабатывает на AdSence теряют деньги. Предположу, что похожая ситуация с большинством рекламных платформ. А это затрагивает ну очень много людей.
Пока ещё я не слышал об волне увольнений. Но всё чаще всплывают разговоры об этом. В некоторых компаниях, с которыми я работаю была внутренняя рассылка, примерно такого содержания: "Времена трудные. Мы очень не хотим распускать наш коллектив. И будем держаться как можем. А для этого нашей компании нужно очень сильно экономить. Ну, вы ж понимаете?".
Как долго это будет длится? Формально до середины апреля. Но по некоторым предположениям — до мая и не раньше.
Я вот тоже не совсем понимаю преимуществ фабричной функции перед классом. Как по мне это два совершенно разных паттерна и применяться они должны для разных ситуаций, а иногда даже совместно.
function createSpecies(type, name, gender) {
if (type === 'frog') {
return new Frog(name, gender)
} else if (type === 'human') {
return new Human(name, gender)
} else if (type == undefined) {
throw new Error('Cannot create a species with an unknown type')
}
}
const species = createSpecies('frog', 'sally', 'female');
// Проверка типов
species instanceof Frog // true
species instanceof Human // false
The number of in-object properties is predetermined by the initial size of the object. If more properties get added than there is space in the object, they are stored in the properties store
Это называют "Переосмысление" :)
Ну, не совсем.
npm — менеджер пакетов. Ряд озвученных вами вопросов, действительно стоит остро, и утилиты, для анализа всей кодовой базы или какой-то части и вывода статистики по всем зависимостям по модульно действительно не хватает. И, если будет потребность, то такие появятся. Но текущие реализации, я думаю, жертвы привычки.
package.json — Можно назвать глобальным конфигом для всего проекта. В нем и название, и версия, и зависимости, и инструкции по сборке, и имена авторов и все все все. Deno предлагает перенести список зависимостей из глобального реестра непосредственно в кодовую базу. Но, это не означает, полный отказ от глобального файла с конфигурацией проекта. Вполне может существовать какой-то package.json с названием, списком авторов, какими-то ссылками на документацию, репозиторий, лицензию, списком точек входа для запуска тестов или самого приложения.
Сейчас Deno и его сообщество в зародыше. Лучшие практики ещё не выработаны, инструменты не написаны.
Может и так. Лично я пока не вижу тут проблем. Но, справедливости ради, я и не искал особо. Мне видится тут больше гибкости. Вы пишите что-то простое? Вам не нужно заворачиваться с установкой зависимостей локально. Просто пишите код. Работаете над чем то побольше? Создайте свой реестр зависимостей. Со временем появятся инструменты для их анализа.
Deno как и NodeJs — это среда исполнения. Для NodeJs существует отдельная утилита — пакетный менеджер — npm. Она берет на себя роль управления всеми зависимостями, не только для рантайма, а в целом по проекту, их обновлением и всё в таком духе.
Deno не поставляется со своим аналогом npm. И хотя возможно устанавливать отдельные утилиты в директорию проекта, это сложно назвать полноценным пакетным менеджером.
Но, народные умельци уже написали несколько утилит:
А как бы вы поступилии в случае с Node?
Мне видится в этом больше преимущество. Как я понимаю в этом и весь прикол, что у вас нет списка зависимостей на весь проект. А каждый ваш модуль/файл имеет собственный набор зависимостей. И вы можете спокойно изменять зависимости в одном модуле не боясь сломать все остальные.
Вот представьте ситуацию:
Вам пришла задача, сделать какую-то фичу. Для вас это не проблема, вы нашли библиотеку "А" и хотите её использовать. Но вот проблема — в проекте уже применяется библиотека "А" причем версии "0.0.1" в старом многолетнем legacy. Имея такую систему как у Deno, вы об этом вообще можете не думать. Старый модуль будет использовать свою версию, а вы можете использовать свою.
Точно так же как и в случае с node: скачать все зависимости локально и закинуть на сервер папку с кэшем.
Потому, что иногда имеет смысл ожидать результат позже
Или не ожидать результат вовсе
Как мне кажется, это уже вопрос архитектуры. Если есть два независимых модуля, то один не должен ломаться при изменении реализации второго. Главное чтобы возвращаемые структуры были идентичными. А если два "модуля" сильно связаны между собой, тогда здравый смысл подсказывает, что они должны использовать общую версию зависимостей.
Ну, по моему это легко решится. Как только придёт необходимость появятся утилиты аля "deno-outdated" которые будут смотреть по всем файлам и выдадут список устаревших зависимостей для каждого модуля.
Вы, конечно правы. Но как мне видится идея в том, что у вас не весь ваш проект зависит от moment, а каждый отдельный модуль/файл зависит от moment конкретной версии. Я вижу в этом возможность очень легко переводить обновление зависимостей в проекте по частям.
Просто у Microsoft уже существуют наработки — Visual Studio Codespaces. Сейчас это просто интегрируют в GitHub.
Меня оскорбляет то, что на первом изображении Vue ниже чем Angular и React
Вы правы. Я не дизайнер. И если уж на то пошло, то и верстальщиком себя не считаю. Тема статьи — показать преимущества одной CSS функции в определённом спектре задач. Если вы работаете над одним сайтом, со статическим контентом, где каждое слово, каждое подчеркивание выверено до субпикселя того, я полагаю, описанные мною техники для вас не важны, или даже вредны. Но есть же и другие задачи. Скажем разработка темы для какой-то CMS. Там вы не можете знать какой контент будет на странице. Или конвеерная разработка. Когда нужно скопировать бОльшую часть из одного проекта, добавить куски другого чутка изменить и выкатить
Здесь скорость, гибкость и простое масштабирование куда важнее. Как бы грустно это не звучало.
Да и не только для дизайнеров. Первый же юзкейс который приходит на ум: вы делаете библиотеку компонентов. И в каждый компонент можно передать значение Hue но только его. При некоторых значениях цвет будет восприниматься слишком ярким, или темным, что вынудит пользователя вашей библиотеки дополнительно запарится чтобы выровнять воспринимаемою яркость у отдельных элементов.
Да, если хранить в переменных весь цвет, тогда не важно в каком он формате. Но гибкость появляется в тот момент, когда в переменных вы храните именно составляющие части цвета а не цвет целиком. Тогда вы можете получать цвет из составных частей "на месте", внутри каждого компонента и изменять их под разные нужды в зависимости от ситуации. Это часто необходимо, когда вы создаёте что-то более чем просто верстку по идеальному макету. Когда у вас есть необходимость получать производные цвета от какого-то одного, но вы не знаете какой он, или хотите иметь возможность легко его изменять. Или когда вы занимаетесь поддержкой проекта, в который постоянно вносятся изменения и часто, без макета с отдельным артбордом на каждую правку.
Просто под сокращение попали люди, чья роль заключалась в том, чтобы сообщать сотрудникам, что они попали под сокращение. :)
Всем привет из Киева. Тут жопа наступила уже чуть больше двух недель назад.
Все компании по немножечко загибаются.
Всех сотрудников, в почти принудительном порядке перевели на удалёнку. Из моих знакомых некоторым сократили зарплаты на 15-20%, и не ясно будет ли это как-то компенсироваться. Тех кто не может работать удалённо, отправляют в отпуск. Иногда оплачиваемый, но чаще нет.
Бизнес переходит в режим супер экономии. Пытаются получать хоть какую-то прибыль. В ресторанах предлагают скидки под 30% на еду (только с доставкой на дом). Кинотеатры предлагают дешевые промокоды которые после карантина можно будет обменять на билеты на любой сеанс. Некоторые сервисы доставки начали работать бесплатно (вернее перестали брать деньги за доставку непосредственно с покупателя). Провайдеры ТВ и интернета предлагают скидки на свои сервисы.
Те кто работают в рекламной сфере, сообщают, что большинство их клиентов отменяют рекламные кампании и любое промо. Как следствие рекламные агентства теряют деньги, Google теряет деньги, все кто зарабатывает на AdSence теряют деньги. Предположу, что похожая ситуация с большинством рекламных платформ. А это затрагивает ну очень много людей.
Пока ещё я не слышал об волне увольнений. Но всё чаще всплывают разговоры об этом. В некоторых компаниях, с которыми я работаю была внутренняя рассылка, примерно такого содержания: "Времена трудные. Мы очень не хотим распускать наш коллектив. И будем держаться как можем. А для этого нашей компании нужно очень сильно экономить. Ну, вы ж понимаете?".
Как долго это будет длится? Формально до середины апреля. Но по некоторым предположениям — до мая и не раньше.
Я вот тоже не совсем понимаю преимуществ фабричной функции перед классом. Как по мне это два совершенно разных паттерна и применяться они должны для разных ситуаций, а иногда даже совместно.
Я так и подумал :) Просто сделал сноску для следующего читателя.