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

давайте без приколов, кто то из вас чисто на react или next, ts ?

дайте наводку где поискать такую ваканчию)

hh сразу мимо, это ии помойка

я тут упоролся с гпт

Набираю несколько человек на личное менторство по EcmaScript — подойдёт как тем, кто начинает с полного нуля, так и тем, кто уже закончил или работает, или не работает, но хочет быстрее вырасти в уровне

Разберём базу, execution context, environment, lexical, slots, prototype и то, как применять эти знания на рынке

Если интересно — не интересуйся.

я согласен

Ребята, посоветуйте локальную модель для кодинга/рефакторинга проекта на kotlin multiplatform, под 8 гб видеопамяти. Гугл порекомендовал qwen 2.5 что-то там 7b , но она какая то туповатая

Сайт, состоящий из одного HTML файла размером 125 КБ (плюс папка с графикой), не уступающий обычному привычному сайту ничем, это хорошо или нет?

Сколько там строк ?

Из за количества строк скорее всего твой однофайловій сайт не поддерживаемій

Возможность масштабирования разделов, меню удобное, графическая обработка, интерактив, отдельная версия для печати.

Я еще слішал про принцип сингл респонсибилити.
На твоем однофайловом сайте этот принцип как раз заметно нарушен

Хорошо. Но мне кажется эти принципы из вчера, а уже почти завтра.

Какие есть тенденции, в том числе связанные с внедрением нейросетевых разработчиков сайтов, которые ставят под сомнение принципы SOLID, а также в чём именно эти принципы вероятно уже во вчера?

[Gemini 3.1 Pro 🧠]

Главный сдвиг современных тенденций — отказ от проектирования «на века» в пользу скорости, локальности и взаимозаменяемости. SOLID создавался в эпоху монолитов на Java/C++, долгоживущих кодовых баз и дорогого человеческого труда, где любая ошибка в архитектуре стоила месяцев рефакторинга.

Нейросетевые автономы (Cursor, Bolt.new, v0, Devin) и современные веб-парадигмы ломают эту логику.

————————

📚 Тенденции, ставящие SOLID под сомнение

⦁ Концепция «Одноразового кода» (Disposable Code):
Раньше разработчик потратил бы день на закладывание паттернов «Фабрика» или «Стратегия», чтобы код был «открыт для расширения» (OCP). С AI-генераторами стоимость полного переписывания модуля упала почти до нуля. Проще попросить нейросеть за 5 секунд сгенерировать новую версию компонента под новые требования, чем поддерживать сложную иерархию абстракций ради гипотетического будущего расширения.
⦁ Ограничения контекстного окна AI (Context Window Fatigue):
Чем строго соблюдается SOLID, тем больше в проекте файлов, интерфейсов и абстракций. Для человека с IDE это ок, но для AI-моделей это проблема: чтобы понять, как работает одна фича, нейросети приходится считывать 15 разрозненных мелких файлов. Это жрёт токены и увеличивает риск галлюцинаций. Нейросети гораздо лучше анализируют и генерируют плотный, локализованный код.
⦁ Принцип Co-location (Всё в одном месте) вместо разделения:
Современный веб (React Server Components, Vue SFC, Tailwind CSS) уходит от разделения HTML/CSS/JS по разным папочкам. Логика, верстка и стили теперь живут в одном компоненте. Попытка принудительно распилить файл на 5 слоёв ради «чистоты» убивает производительность разработки.
⦁ Сдвиг от ООП к Функциональному и Декларативному стилю:
Веб-разработка практически отказалась от мутабельного ООП с глубоким наследованием. Node.js, Go, Rust, React hooks, Serverless-функции полагаются на чистые функции, иммутабельность и композицию, где половина принципов SOLID либо бессмысленны, либо выполняются автоматически.
————————

📚 В чём конкретно принципы SOLID — это «вчерашний день»?

🔖 L — Liskov Substitution Principle (Подстановка Лисков) — Практически мертв
⦁ Почему устарел: Принцип регулирует поведение при наследовании классов (class Admin extends User). Но современный веб отменил наследование в пользу композиции («Composition over Inheritance»). В TypeScript и React классы почти не используются. Если у вас нет иерархии наследования, то и нарушить принцип Лисков физически невозможно.
🔖 O — Open/Closed Principle (Открытость / Закрытость) — Неактуален в прежнем смысле
⦁ Почему устарел: Принцип запрещает менять существующий код, требуя расширять его через абстракции, чтобы человек не внес баг в работающий модуль. AI-разработчики и покрывающие код авто-тесты снимают этот страх: нейросеть может безопасно отредактировать существующий файл за секунды, не создавая над ним 3 слоя обёрток и интерфейсов.
🔖 S — Single Responsibility Principle (Единственная ответственность) — Искажен
⦁ Почему устарел: В буквальной догматичной интерпретации («одна функция/файл делает только одно действие») SRP превращает проект в «файловую вермишель». В AI-эру набирает популярность Vertical Slice Architecture (вертикальные срезы): модуль должен отвечать за бизнес-фичу целиком (например, вся форма оплаты в одном месте), а не размазывать логику по контроллерам, сервисам и репозиториям.
🔖 I — Interface Segregation (Разделение интерфейса) — Упрощен языками и AI
⦁ Почему устарел: Создание десятков микро-интерфейсов для каждого чиха нужно было в C++ или Java. В TypeScript работает утиная/структурная типизация (если объект выглядит как утка, это утка). Кроме того, AI легко генерирует и выводит типы на лету (например, из схем Zod или GraphQL), избавляя от ручного
Нажмите "🔥 Просмотр", чтобы увидеть полное сообщение.

И это не про вайбкодинг. Так или иначе облик другой будет в течении пары лет

Будущее за компактным, монолитным и авторским Vanilla JavaScript. Моё мнение.