hllwlrd

под мак, без всего того дрочева что написано в этой статье, есть опенсурсная https://diffusionbee.com/ которая ставится в пару кликов

я не продажник и не тиктокер, но, тут вопрос заключался не в том, кто пользуется тиктоком, а как использовать трафик (людей) из этого приложения для личных нужд (бизнес, реклама себя и т.п.)

если вам все равно на свой веб-сайт и вы готовы к огромным рискам, т.е. к потере органического трафика, к «вечному» бану своего домена и т.д., то крутите ПФ и ни о чем не думайте, в ином же случае никогда о таком даже и не задумывайтесь, ибо это «чёрное сео»

в Яндексе работают одни из умнейших людей страны (и даже мира), и обмануть их эвристики - ну хз, нужно быть гением. Ну а если даже у вас и получится обмануть Яндекс, то рано или поздно вас все равно настигнет анальн*я кара

—

в качестве подтверждения своих слов, я прикрепил ссылку на статью, в которой чувак делится своим многолетним опытом, связанным с накруткой ПФ (абсолютно бесплатно и без всякой рекламы)

ведь все зависит от областей применения этих ЯПов, разве нет?

тот же Python юзают математики / физики / биологи / химики, ML девелоперы и т.д., а на JS можно уходить в WebGL или в какие-нибудь сложные анимации, где без лин. мата, интегралов, элементарной физики и т.п. вообще не обойтись (при условии, что прогается физ. движок)

всему этому, конечно, можно научиться самостоятельно, без высшего образования (как и абсолютно любому «ремеслу»), но.. лично моя позиция, что если будущий девелопер хочет уйти во что-то большее и более сложное, к примеру в поисковые движки (алгоритмы ранжирования и т.д.) или в gamedev писать физ. движки (а не просто собирать игрульки с помощью unity, UE), то без глубокой подготовки и сильной мат. базы (которой уделяют очень много времени на том же КТ в ИТМО или мехмате МГУ) просто не обойтись

+ вышка (в хорошем ВУЗе) дает очень сильный буст при переезде в Европу и связанных с нею стран

крч, имхо, все зависит от ситуации и целей прогера

интересно, а если скушать все эти ноотропы одновременно, то станешь суперпупергероемгением?

Привет! Я сразу подумал о том, что вариации управлением временными интервалами при выдачи кроются в GET запросах.

Когда вы переключаете периоды, можно заметить, как в адресной строке меняется URL
https://yandex.ru/search/?text=vc.ru&lr=2&within=2

Тут нам интересен именно within (2 - это 1 месяц), который как раз и отвечает за то, чтобы регулировать временные интервалы для выдачи. Попробуйте установить within=6, и увидите статьи чуть ли не с прошлого года.

P.S. если не совсем понятно, то URL в итоге будет выглядеть вот так: https://yandex.ru/search/?text=vc.ru&lr=2&within=6

P.P.S. можете поиграться с within, но почему-то больше 10 не пускает :(

Привет! Я более чем уверен в том, что на vc.ru вряд ли оценят мои "технические" статьи и труды, т.к. ресурс больше заточен под бизнес / новости / инсайды и т.д.
Да и если Вам интересно углубиться в подобную тему, то для этого есть habr.com, medium.com и прочие подобные ресурсы, где материала по этой теме - несчитанное кол-во.

Кстати, специально для Вас нашел замечательную таблицу со всеми (основными) видами типов веб-приложений

Несколько слов поводу SPA и их "недостатках" (буду высказываться в контексте Vue.js)
1) Для SEO в мире SPA существует SSR (Server side rendering) - Nuxt.js.
Если кратко, то когда пользователь впервые обращается к сайту, то на стороне сервера делаются все необходимые запросы к API для получения данных + "раскрывается" вся html, выполняется еще куча различных действий и в итоге на клиент улетает уже развернутая html, со всеми необходимыми данными, а дальше web-приложение начинает работать как обычное SPA.

2) Производительность при первой инициализации сайта на стороне клиента (без использования SSR) действительно будет уступать многостраничным (MPA) приложением, но когда дела доходит до роутинга (переходам по страницам) выбору фильтров, оформления покупки и т.д. (AJAX), то SPA в десятки раз выигрывает по производительности у MPA приложений, т.к. время на отрисовку при каждом действии всей страницы (как в MPA) требуется гораздо больше, нежели чем SPA приложению (т.к. перерисовывается только то, что изменилось и не более того). Стоит помнить, что самая дорогая операция в вебе - это рендер / отрисовка

А если же использовать SPA + SSR, то MPA приложения проигрывают по производительности практически во всех аспектах.

Так же, с помощью SSR мы можем реализовывать следующую технику: загружать только те части js / css, которые необходимы для работы конкретного компонента, т.е. представьте, что у нас есть страница каталога с закрытой картой и с закрытыми фильтрами. Когда мы загружаем эту страницу, то у нас не подгружаются компоненты, связанные с картой и фильтрами (т.к. она закрыты) => размер страницы будет крайне мал, а когда человек включает карту или (и) фильтры, то у нас динамически со стороны сервера подгружаются эти самые компоненты (Code Splitting), крч мы подгружаем компоненты только тогда, когда в них есть необходимость.
И дополню, что Code Splitting работает не только для отдельных компонентов, но и для целых страниц, что очень сильно облегчает размер бандла => скорость отдачи web-приложения на сторону клиента.

3) Утечка памяти: если над SPA приложением работает (ют) квалифицированные разработчики, то я на 99.8% уверен в том, что подобной проблемы не возникнет, т.к. методы / тулзы для профилирования (анализа работы приложения) уже давным-давно вышли на новый уровень и сейчас не эпоха ie6, где люди дебажили (искали баги / ошибки) с помощью alert's. И непонятно, почему этот пункт отнесся именно к SPA, ведь в любом приложении, где есть хоть какая-то логика, может возникнуть подобная ситуация, ни?

4) Поддержка js - я хз, но мы сейчас не в 2001 году, и я никогда (на основе личного опыта) не видел подобных людей, у которых был бы отключен js (исключение - это Opera Mini или всякие proxy browser, доля которых 0.0001% (наобум)), да даже в том же Tor Browser уже по умолчанию включен js (просто знаю).
В дополнении к этому, могу сказать, что для этого в мире SPA, и не только - существует специальная техника, которая называется Graceful Degradation (можно так же посмотреть в сторону Progressive Enhancement, как делает VK и многие другие популярные платформы).

5) Про PWA / TWA даже писать не буду, т.к. для этого нужно писать отдельную статью о том, что в этой статье не так.

Для frontend developer'ов: я постарался выражаться не с точки зрения программиста, а с точки зрения "обывателя", чтобы всем было понятно, о чем я говорю, поэтому примите и простите.