Вы можете боготворить файрфокс, отрицать реальность, топать ножкой, ставить минусы но от этого он быстрей не станет и реальную картину верой не заменишь.
Любой современный сайт с большим количеством JavaScript работает заметно медленней даже без синтетических тестов.
Просто, я подозреваю, для многих пользователей эта разница не критична и они готовы пожертвовать своим удобством или просто не замечают разницы, из-за каких-то других убеждений или фишек.
Это не притензия к FastApi, но наверное к всему питону. Обычные рутинные операции по вычитке 200 строчек из бд и их обработка легко может занимать 10-20 секунд, что на .NET, Java, Node.js невозможно представить.
Не ведитесь на слово Fast в названии, подумайте дважды выбирая питон для бекенда или проводите тесты и учитывайте низкую производительность изначально.
Все таки автор прав и не стоит писать подобные предложения в технических статьях, кто бы там не был автором. Лучше оставьте подобное "остроумие" для личной страницы в одноклассниках или фейсбук.
SonarQube не решает обозначенные мной проблемы примерно никак, он только проверяет корректность CSS-синтаксиса, никаих более продвинутых правил, вроде обнаружения неиспользуемого кода, там нет.
Я не писал, что он что-то решает, наоборот добавляет проблем, но является стандартом для некоторых компаний. Просто линтеры в целом сходят с ума от CSS в JavaScript.
Примерно так же думал и я, в 2016 году. Но сейчас уже 2021й, хорошие практики настоялись, технологии вышли на плато продуктивности, и говорить об их непригодности – это чистое ретроградство.
Именно, CSS-синтаксис подтянут, зарефакторят некоторые фрейморки и отпадет необходимость забивать гвозди пасатижами.
Это не ретроградство, CSS-in-JS, ИМХО, это тупиковая ветка развития технологии и выше я писал почему так считаю.
Мне кажется, вы на это смотрите только в разрезе React. Там из-за необдуманой архитектуры самого фреймворка это в какой-то мере необходимо. Но также добавляет большие проблемы, в тех же больших проектах существуют коорпоративные стандарты линтирования, покрытия тестами и написанию кода, например, с репортами в SonarQubе. Те же линтеры не успевают дописывать за всеми библиотеками и нужно очень постараться, чтоб привести styles в JS к JavaScript\TypeScript подобному виду и правилам.
ИМХО, описывать стили в JS — это как стрелять из пушки по воробьям. И сейчас чистая спекуляция от меня — она не получит дальнейшего развития и всегда будет на третьих рядах после «нативный СSS» или «компиляция SASS подобных языков в СSS».
Первый не является плюсом и я выше обьяснил почему. Вы можете запаковать несколько файлов как сборку, это успешно реализовано во всех языках практически с их появления и это никак не будет отличается от «один файл». Кроме того разбивание на мелкие файлы имеет преимущество контроля изменения, мерджа в GIT и много других плюсов.
«В читаемости» Субьективно вы говорите, для меня читаемость значительно ухудшается, CSS специализированный язык и он хорошо подходит для решения своих задач без всяких библиотек и тем более без ужасной реализации в JS, где потом любой линтер сходит с ума.
Выше привели вам пример, что производительность ухудшается и это понятно почему. Вы имели ввиду размер пакета, но даже это успешно решается, простым контролем и линтированием.
Так уж оказалось, что сочетание стилей и остального кода компонента в одом месте – это очень практично.
Спорное субьективное утверждение. Мне, например, это максимально непрактично.
Это всегда воспринималось как антишаблон и большие компании всегда пытались разделять представление от реализации (даже если это css, html и JavaScript). Да про что говорить, если бы «всё в одом месте» было хоть как-то практично, то до сих пор верстали бы с использованием style атрибута, но к счастью этого не происходит и никто не жалуется.
Тот же компонент тоже можно поставлять как сборку из нескольких файлов, никакой проблемы с этим вообще нет.
По моему скромному мнению такой подход просто временное решение каких-то возникших проблем с незрелыми технологиями, что мы имеем сейчас. Это никто и никогда не потянет в стандарты.
«Особенно — в мире React.»
Хорошо бы, чтоб этот костыль там и оставался.
Ухудшается производительность, ухудшается читаемость, теряются нативные наработки работы с анализом, парсингом css. Как ни крути, это была попытка лишь решить проблему одного фреймворка и ничего хорошего я в этом не вижу.
Биткоин привязан к усилиям на его выпуск.
Он ценен и транзакции проходят пока его майнят.
«если все держатели биткоина захотят вывести его, то его курс начнет стремительно падать.»
Если бы да кабы, вот только предьявить некому. «Вывести» его можно если кто-то пожелает его забрать выдав вам деньги.
Авиаперелёты сначала были тоже только для богатых.
Что там фалькон не полетел? Уже можно начинать смеяться?
Я правильно понимаю, что главные изменения из года в год - новые нескучные обои рабочего стола?
В чем реальная разница новой версии кроме меню пуск?
Это вопрос без издёвки и сарказма
venturebeat.com/2020/01/15/browser-benchmark-battle-january-2020-chrome-firefox-edge-brave/2
Любой современный сайт с большим количеством JavaScript работает заметно медленней даже без синтетических тестов.
Просто, я подозреваю, для многих пользователей эта разница не критична и они готовы пожертвовать своим удобством или просто не замечают разницы, из-за каких-то других убеждений или фишек.
Файрфокс медленный, так что просто альтернатив нет.
Сомневаюсь, что сворачивание из-за недовольства пользователей.
Очень, очень, очень медленно работает.
Это не притензия к FastApi, но наверное к всему питону. Обычные рутинные операции по вычитке 200 строчек из бд и их обработка легко может занимать 10-20 секунд, что на .NET, Java, Node.js невозможно представить.
Не ведитесь на слово Fast в названии, подумайте дважды выбирая питон для бекенда или проводите тесты и учитывайте низкую производительность изначально.
Всегда приходит диктатура, когда начинаются подобный рассуждения.
Вот вы бы точно разобрались как деньги распределять.
Был подкреплён китайскими майнерами и теневой экономикой.
Причина? "Я ненавижу то чего не понимаю"?
Я точно также могу заявить, что поддерживают контейнеры сейчас практически все.
Так что для меня более актуально версия языка поставляемая с базовым образом docker file
Все таки автор прав и не стоит писать подобные предложения в технических статьях, кто бы там не был автором. Лучше оставьте подобное "остроумие" для личной страницы в одноклассниках или фейсбук.
У их было конкурентов, то они могли себе позволить бюрократию и много оверхеда.
Как только запахло жаренным, то сразу "государство спаси" - сразу стали социалистами!
Так было с многими отраслями: телеграф, стационарная сеть телефонов.
Я не писал, что он что-то решает, наоборот добавляет проблем, но является стандартом для некоторых компаний. Просто линтеры в целом сходят с ума от CSS в JavaScript.
Именно, CSS-синтаксис подтянут, зарефакторят некоторые фрейморки и отпадет необходимость забивать гвозди пасатижами.
Это не ретроградство, CSS-in-JS, ИМХО, это тупиковая ветка развития технологии и выше я писал почему так считаю.
ИМХО, описывать стили в JS — это как стрелять из пушки по воробьям. И сейчас чистая спекуляция от меня — она не получит дальнейшего развития и всегда будет на третьих рядах после «нативный СSS» или «компиляция SASS подобных языков в СSS».
В чем плюс?
Спорное субьективное утверждение. Мне, например, это максимально непрактично.
Это всегда воспринималось как антишаблон и большие компании всегда пытались разделять представление от реализации (даже если это css, html и JavaScript). Да про что говорить, если бы «всё в одом месте» было хоть как-то практично, то до сих пор верстали бы с использованием style атрибута, но к счастью этого не происходит и никто не жалуется.
Тот же компонент тоже можно поставлять как сборку из нескольких файлов, никакой проблемы с этим вообще нет.
По моему скромному мнению такой подход просто временное решение каких-то возникших проблем с незрелыми технологиями, что мы имеем сейчас. Это никто и никогда не потянет в стандарты.
Хорошо бы, чтоб этот костыль там и оставался.
Ухудшается производительность, ухудшается читаемость, теряются нативные наработки работы с анализом, парсингом css. Как ни крути, это была попытка лишь решить проблему одного фреймворка и ничего хорошего я в этом не вижу.
Он ценен и транзакции проходят пока его майнят.
«если все держатели биткоина захотят вывести его, то его курс начнет стремительно падать.»
Если бы да кабы, вот только предьявить некому. «Вывести» его можно если кто-то пожелает его забрать выдав вам деньги.