Ух ты! Сделаешь?
Предлагаю баттл: написать с нуля любую вероятностную структуру данных без ложнонегативных срабатываний (надеюсь вы хотя бы знаете что это такое). Например фильтр Блума. Кто напишет и пройдет все тесты, тот и победил.
ArbNet, можешь написать это на своем фреймворке, и доказать всему миру что это гибкое и производительное решение.
Sly32, можешь подтвердить свое высокомерие и доказать что ты больше не джун.
Потому что в 2020 году на robots срать всем, кроме сеошников, застрявших в 90х годах. Или вы думаете журнал выкинут из выдачи, потому что у них robots "подозрительно маленький", span не закрыли, а ещё у них нет оглавления как в сайтах Пузата?
Всегда умиляли люди, которые фапают на техническую оптимизацию, имея скучный, не уникальный (рерайт-рерайта в 3 поколении) контент, с украденными картинками, и при этом ещё удивляются почему сайт получает 3 калеки в месяц (и те боты).
Lord Maverik, слева рядом с номером строки жмакнуть.
Я бы вообще выбросил все эти плагины оптимизации, для начала. Если проблема есть, то тушить её нужно не плагинами.
Ценность разработчика не всегда исчисляется способностью решать бизнес-задачи за наиболее короткий интервал времени. Когда дело доходит до имплементации какого-то алгоритма или структуры данных, многие даже не знают с какой стороны подойти. А ведь в этом зарыты все самые интересные задачи.
На моей практике был случай, когда ни одна существующая система не отвечала требованиям по производительности. Первоначальный вариант на MariaDB со всеми твиками и тюнингом отдавал результат за 2-3 мс., что вроде и не плохо, но latency не единственная метрика которая фигурирует. В этот момент просто выжиралось все ЦПУ. Потом я попробовал Memcached и Redis, но из-за специфики задачи, они не сильно подходили (range-запросы, хоть в Redis и есть отсортированные множества и всякие пересечения, но этого не хватало). По производительности было лучше в два раза. В итоге пришлось пилить полностью свое решение. Был написан код, который работал хорошо, но ради забавы мы со знакомым оптимизировали даже L1 cache (65% хитрейт), loop-unrolling, SIMD. В итоге основной хот спот ушел из 2-5 мс. в 570 нс., т.е. 0.00057 мс.. И это без всяких рантайм оптимизаций (цветовые маркеры на основе статистики).
Это я к тому, что когда делаешь свое решение, оно либо гавно, либо тебе приходиться разбираться в том, как это работает, до мельчайших деталей, чтобы выродить что-то хоть сколько-то приемлимое. Это отличный способ изучить технологии в деталях.
Есть куча пыховых программистов, которые пишут код быстро, не задумываясь о том, как он работает. В итоге, в базу летят запросы, возвращающие зачем-то 10 тысяч строк. Вроде и работает, но когда приходит трафик, все обсирается.
Так что велосипедостроительство иногда бывате полезным.
ArbNet, лучше ваш инструмент, или хуже - покажет только его популярность. Сейчас можно написать по сути свой наколеночный Vue, используя Proxy API. Но зачем? И да, 32 кб.
ArbNet, вы молодец, как минимум тонко троллить вы умеете. А вообще, если без шуток, велосипедостроительство как правило и позволяет разобраться в деталях. Использовать готовое можно даже без понимания как оно работает, а для того, чтобы написать свой велосипед, как минимум нужно разобраться.
Ну я так понимаю что под эту задачу отлично подойдет Python. Тот же YouTube на питоне работает, и инстаграм. Но инстаграм на джанге, там нет стриминга (вроде).
silicoid, потому что он делался под девопсов (тогда этого термина даже не было), чтобы они могли набросать мало-мальски удобную админку по управлению кластером серверов. Потом это зарезили, и ленивые фронтендеры поняли фишку, что это решает проблему колоночной верстки, начали пихать его куда надо, и куда не надо.
Веб сильно изменился, а легаси 2000х будет на сайтах ещё десятки лет. Все зависит от задач на самом деле. Я под админки (и изредка публичную часть сайта) использую связку Vue+Bulma. Удобно, красиво и быстро, нарезал на компоненты, каждый компонент грузит только те стили, которые к нему относятся (и которые используются).
