розумію, але деколи станеться, що щось напишу, а потім приходиться розширювати, і я такий "ой, написано так-сяк, а у мене лапки"

а щоб писати НЕ так-сяк - потрібен хоч якийсь орієнтир

а є якесь продуктивніше чтиво в цьому плані?

Щиро кажучи, в цьому плані продуктивно писати код. Codewars після вирішення задачі показують чужий код - хто ще як це написав

Можна пошукати опції контриб'ютити в оперсорс - там часто дають офігезне кодрев'ю

З дозвідом будеш краще писати. Продуктивніше хз яке чтиво сам я тільки клінкод читав

хуїта

Пиши проект

да ничего толком не подходит

Сорян, но только дошел до этого
http://perfectionkills.com/how-ecmascript-5-still-does-not-allow-to-subclass-an-array

Да я согласен что классы не просто сахар, не мог не поделиться статейкой, очень хитрый способ с iframe описа(прям вспомнились формы без перезагрузки страниц=)

В ноде можно vm заюзать для такого, но смысла немного если конечно вы не сидите на 4 ноде=)

и че делать?

Смириться с несовершенством мира

и доставать KABOL

Тимур, хотел бы услышать ваше мнение. Бытует такое среди новичков, что прежде чем идти в бэкенд на ноде, надо пописать бэкенд на настоящем строгом яп как Джава, с взрослым ООП, без этого тебе будет сложно писать хороший бэк.

Это верное утверждение хоть я и не Тимур =)

Совсем не обязательно. Более того, у этого есть обратная сторона медали - начинаешь писать бек условно "джава стайл", игнорируя преимущество возможностей  js в тех аспектах где оно есть

Такие разработчики обычно превозносят nestjs :)

Да спасибо, любое мнение интересно. Можно подробнее почему, так?

Ага вот это интересно. В целом мне понятно, что бэку с любого ЯП, перейти на бэк на ноде проще, чем с фронта на нода бэкенд. У первых разница в языке, у вторых общий только язык, а в остальном у них различные подходы.

Я не соглашусь если речь идёт о хорошем фронтендере, а не тех кто "кнопочки красит". Хороший фронт требует достаточного понимания как функционирует бек "снаружи" а как он организован внутри - как и во фронте в 80% случаев это плюс минус одна и та же архитектура.

Разница в языке обеспечивает ощутимую разниц в стилях и подходах к реализации (но не в архитектуре) - я это ощущаю по себе, когда вижу что в ruby on rails стиль решения ряда проблем существенно отличается от того же node.js и PHP, эффективно утилизируя выразительные возможности языка