Некоторое время назад у меня был интересный разговор, коллега активно защищал Angular, говоря, что он ускоряет веб-разработку.
Я занимаюсь разработкой сложных веб-сервисов более десяти лет, работал в Microsoft, в Spotware Systems на Кипре, сейчас создаю приложение для стартапа из Кремниевой долины и в целом слежу за трендами.
Однако я чувствовал себя динозавром, потому что до этого момента не видел смысла в использовании фронтенд-фреймворков, а оказалось, что это уже мейнстрим.
Это был 2014 год, я окунулся в мир Angular, Knockout и Backbone, что из этого вышло, почему я в итоге отказался от них и рекомендую своим коллегам сделать то же самое — ниже под катом.
Все мы знаем, что у Angular много проблем и одна из главных — отладка.
При появлении недокументированных ошибок вас может спасти только stackoverflow, и тогда вам придется искать, что именно произошло и главное — в каком месте.
У Backbone и Knockout тоже есть свои недостатки, но многие продолжают их использовать, потому что преимущества их нивелируют. И если честно, потому что не видят альтернативы.
Но есть альтернатива, о ней просто забыли.
Помните старый принцип программирования – каждый модуль должен выполнять один функция.
Если его два и более, его нужно разбить на части.
Желающие могут сами прочитать, почему это так и почему следует этого придерживаться в огромном количестве открытых источников.
Таким образом, все существующие фреймворки нарушают этот принцип.
Я скажу больше, сам «рамочный» подход его нарушает. Фреймворк загоняет нас в рамки, заставляя следовать «лучшим практикам», только лучшие практики постоянно развиваются и небольшая группа создателей просто не в состоянии знать, какие практики универсально подходят как для небольшой промо-страницы с анимацией, так и для панель управления со сложной логикой администрирования данных и для медиа-сайта с высокими требованиями к производительности.
Лучшие практики оттуда можно почерпнуть только в том случае, если вы совершенно новичок в программировании, тогда фреймворк вас дисциплинирует. Но я вам дам еще один совет — берите лучшие практики, но оставляйте фреймворк в стороне от работы.
Позвольте мне объяснить, что я имею в виду.
Кажется, что фреймворк — это что-то большое, что невероятно сложно воспроизвести.
Это на самом деле просто набор стандартных лекал .
Например, шаблон Observer, он используется в моделях Backbone, в привязке данных Angular и Knockout и выдает довольно громкое «Ух ты!» Но это всего лишь давно известный шаблон, который можно реализовать на JavaScript в 30 строк кода или скачать один из тысяч готовых вариантов (кстати, они все одинаковые, отличаются только названием методов, поскольку принцип паттерна тот же).
Остальные компоненты фреймворка структурированы аналогичным образом.
Зачастую, понимая принцип, можно вообще написать только ноль строк кода, например, при реализации MVP внутри небольшого компонента можно просто мысленно разделить, что эти методы — контроллер, эти свойства — модель и т.д… Пример из практики: однажды я проходил собеседование в компании в Испании.
Пришлось сделать тестовое задание, за час в режиме live-coding создать одностраничное приложение на основе документации, пока есть время.
Я справился полностью, на JavaScript только с модульными библиотеки .
Осталось даже немного времени на написание тестов.
Люди не понимали, как в такое время без фреймворков можно реализовать маршрутизацию с переключением страниц, сложные интерактивные элементы и многое другое.
Это ребята, которые, как и я, в индустрии уже 10 лет, но изучали конкретные решения, а не принципы.
Когда вы изучаете фреймворки - вы нужно переучиться переходите к новому решению, а они появляются постоянно, и большая часть ваших опыт стирается .
Когда ты учишься принципы - они остаются .
Я использую библиотеку для создания классов, написанную 5 лет назад. Module Injector, реализация наблюдателя, написанная примерно в то же время.
Каждый из них выполняет ровно одну функцию и выполняет ее хорошо.
Ни разу у меня не возникло желания поменять один компонент на другой, как это происходит с фреймворками, потому что «наблюдатель» — это «наблюдатель», это шаблон, а не код. Узоры можно комбинировать в зависимости от задачи, но они не меняются.
Еще один старый принцип: код можно дополнять, но нельзя изменять.
Ее обоснование также можно легко найти в Google или в книгах «банды четырех».
Следуя этой логике, если у фреймворка или библиотеки есть вторая, третья, десятая версия, какие-то функции удалены, какие-то изменены — это заведомо ущербный продукт. Единственная веская причина для изменения кода — адаптация к новым браузерам, но публичные методы ни в коем случае не должны меняться.
Программирование становится жертвой маркетинга.
Нам обещана волшебная кнопка, которая решит все наши проблемы.
Единственная цена за это — то, что многие становятся зависимыми от этого и уже не способны разлагать сложные вещи на составляющие, отделять зерна от плевел.
Использую ли я фреймворки? Да, когда вам нужно создать продукт, который в дальнейшем не нужно будет поддерживать.
Но использовать их в сервисе, который будет жить и развиваться хотя бы 1-2 года – полное самоубийство.
За это время вы напишете гораздо больше кода, чем включает в себя весь фреймворк, и много раз столкнетесь с его ограничениями.
Времени, которое вы потратите на написание костылей и исправление универсальных вещей под себя, вам будет более чем достаточно, чтобы вместо корявого фреймворка реализовать набор только необходимых компонентов.
Это не велосипедостроение, вы используете библиотеки, но комбинируете их по ситуации, а не каким-то одним предустановленным образом.
Вы также можете подключать расширения во фреймворках, но что, если я хочу получать модели Backbone, используя собственный API? Или не брать вообще.
Или возьмите его из localStorage. А если еще и сложная логика обновлений в зависимости от даты и флагов.
А после выборки нужно отправить пул той же модели на другой сервер.
Никогда не знаешь, какие особенности могут возникнуть.
И в таких ситуациях использовать Backbone? Будет 5% его функциональности , остальное это костыли и кастомная логика.
В то же время, понимая архитектурные принципы, нетрудно создать решение, максимально работающее именно под эту задачу.
И сделать его устойчивым к меняющимся требованиям, гибким.
Известно, что большую часть времени программист не печатает, а думает .
А мышление шаблонами проектирования полезно для повышения эффективности.
Обычно я читаю публичные методы новых библиотек в поисках интересных.
архитектурные решения .
Если реализация чего-то не понятна, могу посмотреть код, но как правило важны сами идеи.
Например, обещания выполняются за 10 минут, а какой эффект. Поэтому не изучайте фреймворки, изучайте архитектуру.
P.S.: Статья заведомо провокационная, в фреймворках есть хорошие вещи, но они культивируют невежество.
Обидно, когда человек не может решить задачу без рамок и застревает в работе на дни и недели.
На самом деле все просто, если уделять внимание правильным вещам, архитектурным решениям, то это именно ту мысль, которую я хотел донести.
Надеюсь, статья будет полезна, в первую очередь, новичкам, а описанный здесь подход сделает их гораздо лучшими профессионалами в будущем.
В опросе могут участвовать только зарегистрированные пользователи.
Войти , Пожалуйста.
Использовали ли вы фреймворки в крупных проектах B2C? 16,3% Использовал, ограничений больше, чем возможностей 464 31,02% Использовал, возможностей больше, чем ограничений 883 31,12% О каждом проекте по-своему 886 21,57% Не использовал 614 Проголосовали 2847 пользователей.
1615 пользователей воздержались.
Теги: #фреймворки #архитектура #как стать фронтенд-ниндзей #разработка сайтов
-
Ом, Георг Симон
19 Oct, 24 -
Пилотный Выпуск Подкаста Content-Review
19 Oct, 24 -
Рекомендации Для Заказчика В Рамках Проекта
19 Oct, 24
