JavaScript: Архитектура приложения с нуля?

Question

[thehighhomie]

Подскажите что по читать или ресурсы полезные для освоения материала по архитектуре приложения на js. Дело в том, что я хочу освоить это для себя, в плане развития, по этому про react, angular и тому подобные я не спрашиваю, с react'ом и так знаком.

Я пробую с нуля написать не большое приложение и мягко говоря получается дичь полная. Вот что я делаю:
Собираю вебпаком js, sass, pug, картинки.
JS разбит на компоненты описанные классами, и каждый компонент добовляется в свойство главного объекта. Проблема в том что это не гибко и говнокод дикий. Даже если я ставлю для каждого компонента возможность подписки/отписки событий то это не спасает, так как заставляет в некоторых местах кода вызывать события после инициализации приложения, так как компоненты присваиваются по очереди и у первого компонента нет возможности подписаться на метод второго... такая дичь просто...

Вот как примерно выглядит главный файл приложения:

тут импорты...

export default class App extends Observable {
  constructor() {
    super();

    this.navbar = new Navbar();
    this.sidebar = new Sidebar(this);
    this.content = new Content(this);
    this.footer = new Footer(this);
    this.slider = new Slider(this);

    this.trigger('init');
  }
}

вот такой быдло стак классов...

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

Остальные файлы версты тоже на компоненты разпределены и лежат в своих папках sass, pug.

Подскажите что по теме.

Comments

[Badanov]

Добрый день, столкнулся с такой же проблемой, хотелось бы узнать к чему Вы пришли? Какие решения нашли? А то в сухом остатке тоже сливаю всё в главный файл.

[thehighhomie]

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

Вы же понимаете, что способ который я описал выше такая дичь...

В общем я решил по изучать фреймворки, остановился на vue.

Если вам важно именно создать самому архитектуру, то изучите несколько фреймворков, у которых есть возможность посмотреть исходный код и вы потихоньку начнете соображать. Вот тогда, имея некое понимание, как пишутся современные фреймворки, вы можете попробовать создать что-то свое. Иначе огромное количество времени будет утеряно, и поверьте, вы пожалеете, что потратили его.

А то в сухом остатке тоже сливаю всё в главный файл

Ну это правильно, когда вы все инклюдите в точку входа.

[Badanov]

thehighhomie, спасибо большое за ответ, я как бы и сам не фанат создавать велосипеды, и согласен с тем что фреймворки облегчают создание приложений с правильной архитектурой. Просто не всегда хочется подтягивать целый фреймворк, а когда код вытикает за пределы одного класса и т.п хочется как-то всё красиво и верно с точки зрения архитектуры вынести и собрать. Но пока мало понимания как это делать, изучал ангуляр2+ так что мне понравилось что у них есть гайд по организации архитектуры приложения, но опять же когда появилась задача собрать калькулятор инвестиций на d3 библиотеке, мне не захотелось ещё плюсом ко всему подключать ангуляр, но код уже становиться очень грамоздким, а другие фреймворки по типу react и vue я не изучал глубоко но так понял что это всего лишь view и они не несут каких-то архитектурных рамок и правил за собой.

Answer 1

[Антон]

Не знаю как у вас с английским, но есть такое старое видео https://www.youtube.com/watch?v=vXjVFPosQHw про архитектуру масштабируемых приложений. Там как раз рассказывается про общие принципы. Презентация из этого видео - https://www.slideshare.net/nzakas/scalable-javascr... , в принципе там есть примеры кода, думаю, будет полезна.

Comments

[Александр Юдаков]

Здесь картинка и звук получше:
https://www.youtube.com/watch?v=b5pFv9NB9fs

[Антон Спирин]

Тухлячок семилетней давности. В современном модульном JavaScript нет нужды в подобных велосипедах.

[thehighhomie]

Антон Спирин, а что можешь предложить?

[Антон Спирин]

thehighhomie, лучшее, что может предложить человек прошедший путь от Backbone.js до React, это не изобретать велосипедов. Если фронтенд вашего проекта требует масштабируемой и поддерживаемой архитектуры используйте фреймворки. Если же надо просто добавить слушатель на кнопку в футер или оживить карусельку, то тут лучший вариант JQuery. Просто оживить форму, корзину и прочее, можно модулем на Vue.
Свой велосипед для более менее сложного приложения это худшее решение которое только может придти в голову в 2018 году.
Хотите понимать как строить правильную модульную фронтенд архитектуру? Изучите историю становления фрейворков от Backbone.js до React/Vue. Предпосылки к появлению, мотивацию к использованию, недостатки, узкие и проблемные места. При этом желательно понять, почему со временем отказались от тех или иных решений и почему пришли к тому, что есть. Фреймворки и есть та самая архитектура о которой вы грезите. Если бы масшатбируемый и поддерживаемый фронтенд был простым делом, программисты бы их не использовали.

[Роман]

Антон Спирин,
Изобреть велосипед можно и нужно ) Если хотите разобраться в архитектуре приложений как таковой, а также препарировать что вам по вкусу ангуля/реакт/вью
Чтобы понимать как они устроены.

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

[Антон Спирин]

Роман,
1. Изобретать велосипед в коммерческих проектах не нужно. У такого подхода только объективные минусы:
- замедляется скорость разработки
- onboarding в разы дольше
- трудно найти адекватных людей, согласных колупаться в вашем коде, даже за хорошие деньги
- в случае ухода ключевых разработчиков, проект возможно будет обречен
- архитектурные просчеты могут стоить слишком дорого
- исходя из предыдущего пункта рефакторинг и масштабирование, могут быть лютой болью
- отсутствие готовых типовых решений может быть проблемой как для новичков, так и для программистов среднего уровня
- минусов гораздо больше, смысла нет все перечислять.

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

3. Не судите по большей части, вы большую часть не знаете. Все хорошие программисты и изучают исходники(а многие являются контрибьюторами в open source проектах), и знают паттерны проектирования, и много чего еще. А так же они рационально подходят к решению задач. Велосипед вместо фреймворка в 2018 году, это, в подавляющем большинстве случаев, нерациональный подход.

Вы видимо не поняли посыл моего комментария.

[Роман]

Антон Спирин,
Не видел, где тут речь о коммерческих проектах ? Человек пишет приложение для себя, чтобы разобраться как создать архитектуру с нуля. А коммерческие проекты вы приплели, чтобы был аргумент использовать фреймворки.

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

[Антон Спирин]

Роман, я в первом комментарии давал рекомендации, которые, имхо, будут куда полезней опыта велосипедостроения.
В том то и дело, что сейчас передовые фреймворки ушли далеко вперед от идей о масштабируемой архитектуре 2010 года. И ковыряние с протофреймвоком, конечно, немного развивает, но оно и рядом не встанет, с глубоким анализом эволюции идей за последние 8 лет.
Имхо, хорошо научиться писать модули и библиотеки. Для этого, опять же, достаточно провести анализ хороших примеров на Github и написать свою.
Вопрос о пользе от знания всех классических паттернов проектирования ООП во фронтенд разработке, весьма спорный. А без знания нормального ООП языка вроде Java, нет смысла заставлять человека детально изучать большинство из них.
Во фронтенде используются свои паттерны, как в самом JS, так и в разработке с использованием современных фреймворков. Вот их знать хорошо, но и изучить совсем не долго.

[Роман]

Антон Спирин, Хорошо, что вы признаете это ИМХО )
Ну, и немного странно, человек про архитектуру спрашивает, а вы ему про модули и библиотеки..ну да ладно.

А вот паттернами фронтенда заинтересовали )) Можете привести пример чисто фронтового паттерна ? )
Я просто никогда о таких не слышал )))

[Антон Спирин]

Роман, в том то и дело, что в отличии от меня вы свое имхо, вроде "можно и нужно" от объективной реальности, видимо, не отличаете.
Где я посоветовал автору модули и библиотеки? Вы что-то путаете. Это был лишь оффтоп в дискуссии с вами.
Если у вас паттерны ассоциируются только с классикой, то у меня для вас плохие новости.

spoiler

Шаблон проектирования или паттерн - повторяемая архитектурная конструкция, представляющая собой решение проблемы проектирования в рамках некоторого часто возникающего контекста.

С почином.

Я не писал "чисто свои", я мел ввиду свой набор и конкретные реализации, которые хорошо знать.

[Роман]

Спасибо, я тоже так и подумал - что никаких своих паттернов во фронте нет.
А классика, она на то и классика )
Если автор будет знать классику - тогда не будет разницы, фронт это или бэк. Это если мы говорим об архитектуре. Хоть на Java напишите Observer, хоть на Java-Script

[Антон Спирин]

Роман,

я тоже так и подумал - что никаких своих паттернов во фронте нет.

Как же нет, если есть.

банальный пример

var module = (function () {
    var a = 1;
    
    function bar() {
      return 2;
    }

    return {
        foo: function (arg) {
            return a + bar() + arg;
        }
    }
})();

Даже если в работе с API фремворка находят эффективные архитектурные решения с конкретными реализациями, которые становятся стандартами, это уже паттерн проектирования.

Если автор будет знать классику - тогда не будет разницы, фронт это или бэк. Это если мы говорим об архитектуре.

Сдается мне опыта работы с языками вроде Java у вас нет. Знали бы как сильно отличаются реалии разработки по сравнению с JS.

Я не спорю, что знание паттернов очень полезно. Заметьте я писал лишь, что "Вопрос о пользе от знания всех классических паттернов проектирования ООП во фронтенд разработке, весьма спорный."
Это было в противопоставление вашим словам: "но большая часть "синьоров" начинают путаться в паттернах и для решения каких проблем их придумали". Вы думаете вас на оффлайн интервью не поставить в тупик задачей на паттерны? Если это так, то вы слишком самонадеянны.

Если вы в проектах пишите собственные реализации Observer, то мне вас искренне жаль. Вы делаете напрасную работу.

И если говорить об архитектуре. В случае с Observer для архитектуры проекта не будет никакой разницы реализовывали вы его сами или нет. Неудачный пример.

[Роман]

Антон Спирин, И какой паттерн в вашем примере представлен ? )

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

Вы согласны по существу вопроса ?
Или ему нужно изучить все фрейворки, их историю и архитектуру - начиная с бэкбона ? Простите, не могу сдержать улыбку )))

[Антон Спирин]

Роман, с почином еще раз. Я, вроде, даже переменную так назвал. Странно, что вы рассуждаете о паттернах, о важности знания их поименно, но на деле даже самых простых не знаете.

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

О нет, если забыли, то это вы мне написали и начали спор с утверждением, о том, что велосипеды писать "можно и нужно". А не с того, что "Нужно читать про архитектуру". Это два разных утверждения.
Вопрос автора лично мне был: "а что можешь предложить?". На что я ему ответил то, что думаю о самописной архитектуре и предложил более рациональный со своей точки зрения вариант.

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

Или ему нужно изучить все фрейворки,

Я такого не писал. Давайте я процитирую свой комментарий:

Изучите историю становления фрейворков от Backbone.js до React/Vue. Предпосылки к появлению, мотивацию к использованию, недостатки, узкие и проблемные места. При этом желательно понять, почему со временем отказались от тех или иных решений и почему пришли к тому, что есть.

Есть множество статей с такими разборами, которые недолго почитать. Исходники лежат на Github, изучить интересные места не долго.

Так же напомню, что когда начали появляться первые фронтенд фреймворки, паттерны проектирования и принципы SOLID уже давно существовали, но целому сообществу понадобились годы, чтобы придти к тому, что есть сейчас. По сему, мое мнение, начинать путь с велосипеда прото-фреймворка отнюдь не самое рациональное решение, особенно для новичка.

[thehighhomie]

ахах))) ну вы тут устроили)))))

[Роман]

Антон Спирин, о, наконец-то )) и SOLID вы вспомнили, и модуль знаете ) а то, что в js модуль можно реализовать через IIFE - это не отменяет того, что это модуль. Нет никаких, сугубо фронтовых паттернов )
Вот пришла на ум аналогия:
Кто-то хочет спроектировать автомобиль. Пробует, полученный результат, даже, может ездить Но автор, задумывается о том, как же сделать это правильно.

Моя позиция - это порекомендовать ему изучить принципиальное устройство автомобиля: двигатель, кузов, шасси и т.д. И как эти модули взаимодействуют друг с другом. Тогда он может и свой вело ...автомобиль спроектировать и в чужом разобраться.

А ваша - это то, что устройство автомобилей значительно изменилось за последние 8 лет )) И тем более, это особые "фронтенд" автомобили - и рассматривать их устройство в классических терминах: двигатель, кузов и т.д. весьма сомнительно ) Потому что, у них коробка передач через IIFE сделана ))).

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

На этом, считаю спор завершенным, автора запроса - получившим нужные ответы, и оставляю вам право на завершающее едкое замечание )
Спасибо за терпение.

[Антон Спирин]

Роман,

Моя позиция... А ваша...

У вас либо нарушения либо памяти, либо явные проблемы с логическим мышлением.
Вы, наверно, забыли, но вы рекомендовали "изобретать велосипед" и это якобы поможет "понять как фремворки работают под капотом. Какие паттерны используются, что такое депенденси Инжекшен и почему где-то это основа фреймворка, а где-то запросто без этого обходятся". Только первое не подразумевает второе. А моя рекомендация как раз поможет понять как они работают внутри и по пути изучить все архитектурные подходы за последние 10 лет со всеми их преимуществами и недостатками.

При этом вы весь разговор пытаетесь заставить перевести тему с начального утверждения "велосипед изобретать нужно" на важность знания паттернов проектирования, принципов SOLID(правда о SOLID вы пытались говорить своими словами, если не знали такого термина, то с очередным, уже третьим, почином вас).
При этом, вы даже не знаете ничего о подготовке автора: знает ли он паттерны, слышал ли о SOLID, об архитектурах. Тем более по его примеру видно, что какие-то статьи или даже книги об архитектурах он явно читал.
Так же, вы забываете(а скорей даже не осознаете), что люди которые экспериментировали с архитектурой фронтенда 10 лет назад были известными и сильными программистами, но плоды их трудов зачастую были мертворожденные, несмотря на подготовку, опыт и багаж фундаментальных знаний.

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

Исходя из начальных тезисов, считаю вашу рекомендацию "изобретать велосипеды" плохой и к пониманию "как фреймворки работают под капотом" скорей всего не приводящей.

По сему, вынужден не согласиться с вами насчет велосипедов, но желаю удачи вам в этом нелегком деле.

Answer 2

[voronkovich]

Помимо ссылки на видео (с Nicolas Zakas), которое привели выше, можете посмотреть также t3js фреймворк. Он собственно и был создан Закасом, с учетом идей о которых он говорит в видео.

Answer 3

[Aleksei Podgaev]

Если говорить о высокоуровневой архитектуре приложений, то я в последнее время сталкиваюсь с двумя подходами: шина событий (event bus) и flux/redux. В клиентской части популярнее вторая, в серверной - первая (за счёт популярности микросервисной архитектуры). У обоих подходов есть свои плюсы и минусы, серебряной пули нет. Для обоих подходов есть соответствующие библиотеки в документации к которым обычно описаны best practices.
Кроме того, не стоит бояться писать говнокод, особенно для своих проектов. Вы не научитесь писать хороший код, если не будете знать, что такое говнокод. Напишите так, как можете приложение до работающего прототипа, а потом, в следующей итерации, подумайте, как можно сделать лучше. Преждевременная оптимизация - главный враг перфекциониста!
P.S.: забыл добавить, что прямые взаимные зависимости между компонентами - это действительно наихудший подход. Оба описанных подхода преследуют одну цель - избавиться от этих зависимостей.

Answer 4

[Роман]

Есть замечательная статья на Хабре про архитектуру приложений. Пока это лучшее, что попадалось
Создание архитектуры программы или как проектирова...

Там есть и критерии хорошей архитектуры, и декомпозиция, и инверсия контроля и много чего другого.
А затем вам эти подходы нужно будет применить в js.