Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 123
Аминь! Жаль, что многие спустя даже годы практики продолжают упорно наступать на те же самые фреймворки грабли…
В последнее время наметился тренд на «не-фреймворковость». Новые решения больше походят на библиотеки, чем на фреймворки, и в основном состоят из компонуемых функций и минимума состояния. Это радует.
Есть пример на почитать?
А то меня тут на фреймворки подсаживают…
А то меня тут на фреймворки подсаживают…
А почему Highland только для коммуникации M и V? Где C? Просто у меня сложилась привычка связывать M и V через контроллер, и, чтобы они друг о друге не знали. У V иногда может быть своя M для внутренних состояний, он так же может быть слегка сам себе контроллер. Пример: блок с необязательными полями, который можно свернуть/развернуть. Тут есть Модель данных, которая мапится на поля ввода, и микромодель Вида с одним атрибутом скрыто/развёрнуто. V сообщает C об изменении полей, C может отправить изменения в M. Изменения M тоже слушает контроллер, и может при этом обновить V. А у вас как обычно устроено?
P.S. Спасибо за библиотеки, отличная подборка!
P.S. Спасибо за библиотеки, отличная подборка!
У V иногда может быть своя M для внутренних состоянийВы всё абсолютно верно говорите, это состояние, но в данном случае не модели, а представления, и его ещё называют ViewModel. Автор Мифрила, кстати, в своей документации упоминает ViewModel и эта библиотека прекрасно работает с идеей VM.
По поводу контроллеров и FRP, то оно там и будет использоваться. Просто контроллер по-хорошему должен быть очень тонким, по сути, простая прослойка, вызывающая функции модели и отправляющая сформированные чанки данных во View. Большинство проверок и всю логику данных следует класть в модель, потому что они и относятся к модели данных. А контроллер здесь только приводит ответы вида error или ok к виду, в котором View может его употребить. По сути, FRP и будет использоваться в контроллере: скажем Model является источником некоторого потока, контроллер его фильтрует/приводит к нужному виду и отправляет во View. То же самое в обратную сторону.
Лично в моём коде контроллеры выполняют минимальные вещи. Это положительно влияет на логику кода и его читаемость. Если не используется FRP, а есть какие-то ивент-эмиттеры (а это почти всегда), то я стараюсь их сделать более явными, приблизить их по качеству к потокам данных. Если есть промисы, то хорошо. Максимум асинхронщины в промисах, это позволяет более чётко отлавливать все ситуации. Далее — декомпозиция и функциональные преобразования. То есть по сути, FRP, но на коленке. Если FRP уже есть, то хорошо.
Да, кстати, для Мифрила есть свой аналог JSX, называется, естественно, MSX.
Спасибо, т.е. можно было бы сказать «Highland для коммуникаций M и V через контроллер», да? Я так и подумал сначала.
Мне подход FRP очень понравился. В какой-то момент разных событий и промисов становится так много, что напрашивался какой-то новый подход.
Мне подход FRP очень понравился. В какой-то момент разных событий и промисов становится так много, что напрашивался какой-то новый подход.
Можно и так сказать. Я считаю, возможности обширнее, и задача шире. Можно привести всю асинхронщину к одному знаменателю. И это не только в рамках идеологии MVC. Например, я вполне могу представить cli программы, которые представляют собой единый поток от stdin к stdout со всякими фильтрами, асинхронными запросами на сторону итд.
А вообще, главное достижение FRP в том, что этот подход делает потоки данных более явными. Это лучше промисов (которые уже очень хороши) и уж точно лучше пачки ивент-эмиттеров. Промисы уже сделали очень и очень большой шаг в направлении явных потоков данных (в улучшении архитектуры, приведении её к явному виду), FRP продолжает этот путь, вводя постоянные потоки (в противовес промисам, где функция порождает новый промис при каждом вызове).
А вообще, главное достижение FRP в том, что этот подход делает потоки данных более явными. Это лучше промисов (которые уже очень хороши) и уж точно лучше пачки ивент-эмиттеров. Промисы уже сделали очень и очень большой шаг в направлении явных потоков данных (в улучшении архитектуры, приведении её к явному виду), FRP продолжает этот путь, вводя постоянные потоки (в противовес промисам, где функция порождает новый промис при каждом вызове).
Принцип единственной ответственности рулит, ergo, микро-библиотеки тоже рулят, да.
Фреймворки хороши тем, что когда ты видишь приложение на %известный-тебе-фреймворк%, ты уже примерно знаешь, где и как искать то, что тебе нужно пофиксить или поменять. А еще тем, что когда надо быстро сделать прототип, то проще взять бойлерплейт под любимый фреймворк (под angular, кажется, тысячи их), чем долго и нудно все сетапить.
Вот если бы все фреймворки состояли из микро-библиотек, было бы счастье.
Фреймворки хороши тем, что когда ты видишь приложение на %известный-тебе-фреймворк%, ты уже примерно знаешь, где и как искать то, что тебе нужно пофиксить или поменять. А еще тем, что когда надо быстро сделать прототип, то проще взять бойлерплейт под любимый фреймворк (под angular, кажется, тысячи их), чем долго и нудно все сетапить.
Вот если бы все фреймворки состояли из микро-библиотек, было бы счастье.
Фреймворки и «лучшие практики» — это хорошо, очень хорошо. Не потому, что охватывают большую часть задач среднего проекта. Это спорный вопрос.
Потребность в кадрах сегодня такая, что на работу готовы брать кого угодно, отрасль растет огромными темпами. Центров обучения веб-технологиям практически нет. Каждый второй веб-программист сегодня — зеленый новичок. Фреймворки решают важнейшую задачу — быстрый старт, возможность получить человека, который может делать эффекты через jQuery и писать корректные MVC-приложения.
Сравните — сколько времени нужно, чтобы стать C++ программистом, который не стреляет себе в ногу указателями? И сколько нужно времени, чтобы писать веб-приложения просто в соответствии с принятой архитектурой? В каком случае разработка и поддержка кода дешевле?
Потребность в кадрах сегодня такая, что на работу готовы брать кого угодно, отрасль растет огромными темпами. Центров обучения веб-технологиям практически нет. Каждый второй веб-программист сегодня — зеленый новичок. Фреймворки решают важнейшую задачу — быстрый старт, возможность получить человека, который может делать эффекты через jQuery и писать корректные MVC-приложения.
Сравните — сколько времени нужно, чтобы стать C++ программистом, который не стреляет себе в ногу указателями? И сколько нужно времени, чтобы писать веб-приложения просто в соответствии с принятой архитектурой? В каком случае разработка и поддержка кода дешевле?
Откровенно говоря, мне было бы стремно взять на работу человека, который «может делать эффекты на jQuery». Был опыт, ничего хорошего не вышло. Корректных MVC-приложений не вышло:)
Хороших веб-девелоперов мало, да. Но хороших профессионалов везде мало.
Потому все и выбирают веб как платформу, что писать и поддерживать дешевле. А дешевле просто потому, что HTML+CSS+JS гораздо более высокоуровневая вещь, чем плюсы.
Хороших веб-девелоперов мало, да. Но хороших профессионалов везде мало.
Потому все и выбирают веб как платформу, что писать и поддерживать дешевле. А дешевле просто потому, что HTML+CSS+JS гораздо более высокоуровневая вещь, чем плюсы.
Статья реально мало полезная. Если бы вы смогли описать какие-то архитектурные принципы, которыми вы владеете или как реализовать какие-то возможности фреймворка используя более легкие библиотеки, то тут была бы польза. А так, просто себя пропиарили.
Да нет, все верно.
Ангуляр и им подобные плохи тем, что реально создают собственную замкнутую экосистему.
Сейчас выйдет вторая версия — и приложения на первой будут жить еще два года. Дальше — никаких даже обновлений безопасности. Это разве хорошо? Особенно с учетом того, что есть куча приложений на MEAN, а значит — еще и на сервере.
Комбинировать — удобно.
Что нам нужно на клиенте?
Хранилище — кэш и прослойка для бэкэнда. Можно написать свое, можно взять что-нибудь готовое, можно вообще извратиться и поднять на клиенте PouchDB.
Отображение — вьюмодели или представления+экшны — можно взять реакт или тот же vue.js, они именно библиотеки, а не фреймворки.
Модули — да стандартный CommonJS пользуйте и не мучайте себя.
Решений — десятки и сотни, стоит просто подобрать по вкусу и не мучаться.
Ангуляр и им подобные плохи тем, что реально создают собственную замкнутую экосистему.
Сейчас выйдет вторая версия — и приложения на первой будут жить еще два года. Дальше — никаких даже обновлений безопасности. Это разве хорошо? Особенно с учетом того, что есть куча приложений на MEAN, а значит — еще и на сервере.
Комбинировать — удобно.
Что нам нужно на клиенте?
Хранилище — кэш и прослойка для бэкэнда. Можно написать свое, можно взять что-нибудь готовое, можно вообще извратиться и поднять на клиенте PouchDB.
Отображение — вьюмодели или представления+экшны — можно взять реакт или тот же vue.js, они именно библиотеки, а не фреймворки.
Модули — да стандартный CommonJS пользуйте и не мучайте себя.
Решений — десятки и сотни, стоит просто подобрать по вкусу и не мучаться.
Сейчас выйдет вторая версия — и приложения на первой будут жить еще два года. Дальше — никаких даже обновлений безопасности. Это разве хорошо?
А если вы пишите на своих решениях вы будете их обновлять? Да скорей если вы сделали и уволились или делали на заказ все ваши баги проще не править, а переписать по новой и снова те же грабли. Фреймворки дают большой плюс в виде обновлений без вашего участия (ну это со стороны заказчика), в новых версиях вполне может быть как поддержка новых браузеров так и увеличение производительности. А вы готовы бесплатно оказывать такую поддержку в течении времени жизни проекта?
Разница в том, что хорошо спроектированное приложение будет с одной стороны расширяемо, а с другой стороны — устроено всё равно проще, чем целый фреймворк. В результате получается, что для того, чтобы продолжать поддерживать мой код потребуется более низкая квалификация, чем для того, чтобы поддерживать код, созданный на ныне почившем фреймворке и при этом наполненный костылями.
Ну то есть Вы сравниваете замкнутую систему Ангуляра с чем?
Давайте сравним замкнутую систему Ангуляра с Вашей замкнутой экосистемой.
Вы возьмете эти 25 чудных библиотек и напишите свой glue-код, который и будет этой самой экосистемой.
Так вот Ваша экосистема думаю и года без Вас не проработает, особенно если нужно будет обновить какую-нибудь библиотеку, которую Вы использовали, до мажорной версии. То есть удобства поддержки — нет(потому что Вы можете не соблюдать общепринятые гайдлайны) и обновлять используемые библиотеки тоже нельзя, потому Ваш glue-код сломается.
Прелесть использования фреймворков как раз и заключается в отсутствии необходимости этим заниматься и поддерживать эту рутинную работу.
Давайте сравним замкнутую систему Ангуляра с Вашей замкнутой экосистемой.
Вы возьмете эти 25 чудных библиотек и напишите свой glue-код, который и будет этой самой экосистемой.
Так вот Ваша экосистема думаю и года без Вас не проработает, особенно если нужно будет обновить какую-нибудь библиотеку, которую Вы использовали, до мажорной версии. То есть удобства поддержки — нет(потому что Вы можете не соблюдать общепринятые гайдлайны) и обновлять используемые библиотеки тоже нельзя, потому Ваш glue-код сломается.
Прелесть использования фреймворков как раз и заключается в отсутствии необходимости этим заниматься и поддерживать эту рутинную работу.
Прелесть отдельных библиотек в том, что их в большинстве своем не нужно обновлять.
Есть page.js, крошечная библиотека для History API — рутинга. History API уже утвержден и не будет меняться, оно просто работает.
Есть CommonJS и browserify — система модулей и сборщик. Систему модулей CommonJS тоже никто ломать не будет.
Есть язык шаблонизации Jade. Шаблоны на нем компилируются и будут компилироваться, он слишком хорошо развит, чтобы меняться до несовместимости.
Продолжать можно до бесконечности.
Да, у меня есть пара довольно больших проектов, для которых я сделал архитектуру и которые развиваются без моего участия уже полтора-два года, я не в курсе ситуации с ними уже, честно говоря, но ко мне новые их разработчики обращались с вопросами один или два раза.
Они сделаны на маленьких проверенных решениях, которые склеены максимально очевидным образом. Да, есть несколько своих и внутренних библиотек, в среднем на 200-300 строк кода и с 100% test coverage, которые делают свою работу, и опять же — проверены в боевых условиях.
Нет никакой замкнутой экосистемы, она вам только кажется.
А ангуляр, как и другие большие системы, постоянно экспериментирует с архитектурой, ищет правильные ходы, поэтому и отмирают старые версии. У реакта сейчас та же история с es6 classes и неподдерживаемыми миксинами, например, что меня очень печалит.
Это не так плохо, но это труднее поддерживать, потому что конкретный модуль можно обновить, а целиком фреймворк из-за security issue довольно трудно обновить через большой промежуток времени.
Есть page.js, крошечная библиотека для History API — рутинга. History API уже утвержден и не будет меняться, оно просто работает.
Есть CommonJS и browserify — система модулей и сборщик. Систему модулей CommonJS тоже никто ломать не будет.
Есть язык шаблонизации Jade. Шаблоны на нем компилируются и будут компилироваться, он слишком хорошо развит, чтобы меняться до несовместимости.
Продолжать можно до бесконечности.
Да, у меня есть пара довольно больших проектов, для которых я сделал архитектуру и которые развиваются без моего участия уже полтора-два года, я не в курсе ситуации с ними уже, честно говоря, но ко мне новые их разработчики обращались с вопросами один или два раза.
Они сделаны на маленьких проверенных решениях, которые склеены максимально очевидным образом. Да, есть несколько своих и внутренних библиотек, в среднем на 200-300 строк кода и с 100% test coverage, которые делают свою работу, и опять же — проверены в боевых условиях.
Нет никакой замкнутой экосистемы, она вам только кажется.
А ангуляр, как и другие большие системы, постоянно экспериментирует с архитектурой, ищет правильные ходы, поэтому и отмирают старые версии. У реакта сейчас та же история с es6 classes и неподдерживаемыми миксинами, например, что меня очень печалит.
Это не так плохо, но это труднее поддерживать, потому что конкретный модуль можно обновить, а целиком фреймворк из-за security issue довольно трудно обновить через большой промежуток времени.
Прелесть отдельных библиотек в том, что их в большинстве своем не нужно обновлять.
Это же ужасное заблуждение. Фреймворк — это набор библиотек, который собрали для вас и за вас. Если фреймворк обновляется — скорее всего обновляются сами библиотеки внутри него.
Именно. Это сборка и клей, примерно как дистрибутив линукса. Убунту, например. В новых версиях стабильно что-то не работает из старого ПО, потому что «это фреймворк и он знает, как лучше». При этом отдельные утилиты — grep, curl, awk — с ними можно работать, не предполагая, что методы работы с ними изменятся, потому что «разработчик осознал свои ошибки».
Ой, да ладно!
Grep и другие подобные команды ведут себя одинаково от версии к версии просто потому, что их время активной разработки уже прошло. А не потому, что были «написаны идеально» изначально.
Grep и другие подобные команды ведут себя одинаково от версии к версии просто потому, что их время активной разработки уже прошло. А не потому, что были «написаны идеально» изначально.
И, кроме того, разные варианты grep ведут себя несколько по разному. Разные реализации расширений, не описанных в POSIX.
а я и не говорю, что они идеальны, я говорю что они работают себе и работают. Нужно другое поведение, другой инструментарий — делается другая тулза. Не зря ж есть и sed, и awk, и еще куча всяких удовольствий жизни. Когда «разработчик осознает свои ошибки» он делает новый инструмент, а не ломает старый, а все кто хотят из этих мелких кирпичиков собирают что им надо. Я именно об этом говорю. Просто, как я и писал, фреймворки имеют, гхм, склонность терять совместимость с старыми интерфейсами.
реакт или тот же vue.js, они именно библиотеки, а не фреймворки.
Как вы отличаете фреймворки от библиотек, какие критерии?
Библиотека предоставляет функции, но не навязывает архитектуру. Их можно использовать где и как угодно.
Фреймворк помимо функций задает каркас архитектуры, в который уже встраивается все остальное. Отсюда и название.
Фреймворк помимо функций задает каркас архитектуры, в который уже встраивается все остальное. Отсюда и название.
Можете подсказать как называется подход преимущественно декларативный, где вообще практически на 99.99% нет кода. И архитектуру не навязывает, и функции вызывать не нужно.
Попробую включить экстрасенсорику: возможно, вы имеете ввиду DSL — Domain-Specific Language.
Нет представьте какой нибудь WPF или HTML5 + any framework(например Polymer), который позволяет не писать код связанный с интерфейсами или с логикой взаимодействия с сервером, только бизнес логика если она есть.
Не знаю как насчёт JS, но код на Java, особенно «качественный», «enterprise-уровня», оставляет стойкое ощущение того, что 80% строк — это boilerplate, который по-хорошему надо бы или писать на другом языке программирования или вынести с глаз долой в библиотеку. К сожалению, Java — язык не-функциональный, поэтому второй вариант нереален.
Просто уровень абстракции здесь настолько высок, что код начинает походить на декларативный. Не думаю, что у этого есть какое-то конкретное название, помимо «декларативности», но это вы и сами упомянули в вопросе.
К примеру, директивы ангуляра. Декларативные. Решают широкий спектр задач. Но за каждой директивой стоит императивный код.
Декларативные языки стоят не выше императивных, а на их плечах.
К примеру, директивы ангуляра. Декларативные. Решают широкий спектр задач. Но за каждой директивой стоит императивный код.
Декларативные языки стоят не выше императивных, а на их плечах.
А декларативный код — это, по-вашему, не код?
С библиотекой вы вызываете функции библиотеки, с фреймворком — он вызывает ваш код.
Если глянуть на jQuery, что считается библиотекой, зачастую она вызывает ваш код, те же callback'и на события или инициализация плагинов.
Или взять фреймфорк Angular.js, на нем можно сделать что-то простое (и бесполезное) где вы будете вызывать Ангуляр, а он не будет вызывать ваш код.
На мой взгляд, больше всего подходит определение, что фреймворки навязывают архитектуру, а библиотеки нет.
Хотя библиотеки тоже задают разные «архитектурные» правила, например в vue.js при написании директив и компонент нужно соблюдать что где прописывать.
Можно закопаться глубже и разделять навязанные правила на архитектурные и другие.
Вообщем тонкая грань, где нет четких критериев. И классификация происходит по ощущениям, поэтому иногда происходят споры.
Или взять фреймфорк Angular.js, на нем можно сделать что-то простое (и бесполезное) где вы будете вызывать Ангуляр, а он не будет вызывать ваш код.
На мой взгляд, больше всего подходит определение, что фреймворки навязывают архитектуру, а библиотеки нет.
Хотя библиотеки тоже задают разные «архитектурные» правила, например в vue.js при написании директив и компонент нужно соблюдать что где прописывать.
Можно закопаться глубже и разделять навязанные правила на архитектурные и другие.
Вообщем тонкая грань, где нет четких критериев. И классификация происходит по ощущениям, поэтому иногда происходят споры.
Вы и в сишной либе вызывая функцию можете передать ей ссылку на на вашу функцию (коллбэк тот самый), но от этого бибилиотека фреймворком не становится. Основное отличие фреймворка от библиотеки в том, что фреймворк дает каркас приложения (например), который вы наращиваете уже своим кодом, но не меняя при это кода самого фреймворка. Другими словами — вы расширяете фреймворк не меняя его — код фреймворка в нужное время будет вызывать ваш код, а интерфейс не поменяется. С библиотекой такого не получится.
Я согласен, это иногда тонкая грань. А определение это скорее шуточное, зато умещается в одно предложение. Надо было смайлик поставить.
Если говорить серьезно — у каждого понимания библиотеки и фреймворка свои, но это не потому что каждый по-своему смотрит. А потому что библиотеку ушатывать можно, а фреймворк скорее ушатает тебя, чем сдастся и поддастся на уговоры.
Дело в том, что фреймворк подразумевает «магию». Когда для тебя jQuery — это подключил плагины, запустил через $().plugin, и радуешься — это фреймворк. Когда ты знаешь, что это просто обертка над набором нативных функций и полифиллы — приходит понимание того, что это просто библиотека.
Когда долго работаешь с бэкбоном или реактом — ты знаешь, что это просто очередная библиотека, потому что ее при желании ушатать абсолютно любым путем можно.
С vue.js в общем-то то же самое, со временем приходит понимание, что это просто ядреный дата-биндинг к определенному элементу, и шатать можно как угодно, абсолютно. Тем более в версии 0.11 Эван очень сильные нововведения сделал в эту сторону.
Ангуляр — единственная на моей памяти неушатываемый фреймворк. Вот вообще никак. Хрена с два подключишь свою систему модулей, хрена с два настроишь какой-то сторонний парсер, хрена с два прилично поотлаживаешь интерполируемые выражения, он слишком жирно замыкает все на себя и на свой «ангуляр-вей», который хочется расстрелять со временем из двустволки.
Да там даже рутинг строится почти всегда на встроенном, чтобы совсем кастомный сделать — это надо ой как постараться.
Дело не в кривой обучения, даже через большое время работы с ангуляром разработчики так или иначе продолжают держаться «лучших практик», потому что знают, что шаг вправо-шаг влево караетсярасстрелом долгим ковырянием с старым кодом в тот момент, когда внезапно окажется, что его хрен подправишь в нужном направлении. Да, со временем шаги вправо-влево побольше можно делать, но это не отменяет того, что даже специалисты в ангуляре, которые про него лекции читают, не могут ушатать его под корень.
Кому-то это нравится — что за него все решают, кто-то хочет свободы. Это примерно как айфоны и андроиды — одни красивенькие, но хрена с два что сделаешь, у других не такой классный интерфейс, но они чувствуют себя владельцем устройства (ну, если человек разбирается, конечно).
В общем-то определение достаточно верное: библиотеке ты говоришь, что делать, фреймворк — говорит тебе.
Дело в том, что фреймворк подразумевает «магию». Когда для тебя jQuery — это подключил плагины, запустил через $().plugin, и радуешься — это фреймворк. Когда ты знаешь, что это просто обертка над набором нативных функций и полифиллы — приходит понимание того, что это просто библиотека.
Когда долго работаешь с бэкбоном или реактом — ты знаешь, что это просто очередная библиотека, потому что ее при желании ушатать абсолютно любым путем можно.
С vue.js в общем-то то же самое, со временем приходит понимание, что это просто ядреный дата-биндинг к определенному элементу, и шатать можно как угодно, абсолютно. Тем более в версии 0.11 Эван очень сильные нововведения сделал в эту сторону.
Ангуляр — единственная на моей памяти неушатываемый фреймворк. Вот вообще никак. Хрена с два подключишь свою систему модулей, хрена с два настроишь какой-то сторонний парсер, хрена с два прилично поотлаживаешь интерполируемые выражения, он слишком жирно замыкает все на себя и на свой «ангуляр-вей», который хочется расстрелять со временем из двустволки.
Да там даже рутинг строится почти всегда на встроенном, чтобы совсем кастомный сделать — это надо ой как постараться.
Дело не в кривой обучения, даже через большое время работы с ангуляром разработчики так или иначе продолжают держаться «лучших практик», потому что знают, что шаг вправо-шаг влево карается
Кому-то это нравится — что за него все решают, кто-то хочет свободы. Это примерно как айфоны и андроиды — одни красивенькие, но хрена с два что сделаешь, у других не такой классный интерфейс, но они чувствуют себя владельцем устройства (ну, если человек разбирается, конечно).
В общем-то определение достаточно верное: библиотеке ты говоришь, что делать, фреймворк — говорит тебе.
Если глянуть на jQuery, что считается библиотекойСчитается, да, но существует мнение, что jQuery это фреймворк. Я лично считаю, что это библиотека, которая стоит близко к грани, по которой можно определять фреймворк. Вот граничный пример: в jQuery есть метод remove, служит для удаления нод из DOM. Помимо удаления, собственно, ноды, он удаляет некоторые связанные с ней состояния — собственный объект, инкапсулирующий события и объект, инкапсулирующий набор связанных data-атрибутов. При попытке удалить ноду с помощью DOM API, а не через специализированный метод jQuery, произойдёт утечка, если были использованы jQuery events или связанные данные.
Таким образом jQuery навязывает нам определённое API.
Преобладающее большинство остальных функций jQuery носят библиотечный характер.
Так это API jquery. Тот факт, что jquery проксирует к DOM не означает, что библиотека вдруг стала фреймворком.
Допустим вы напишите обретку для localstorage, которая будет хранить в внутреннем объекте измененные данные, кеш своеобразный. Если вы, во время использования библиотеки, обратитесь к localstorage напрямую, никто далее не гарантирует, что библиотека будет работать корректно. Но вы же не назовете такую библиотеку фреймворком?
В большинстве своем библиотеки так или иначе являются прокси к более низкоуровневому API, если вы начнете действовать в обход — возможны проблемы.
Допустим вы напишите обретку для localstorage, которая будет хранить в внутреннем объекте измененные данные, кеш своеобразный. Если вы, во время использования библиотеки, обратитесь к localstorage напрямую, никто далее не гарантирует, что библиотека будет работать корректно. Но вы же не назовете такую библиотеку фреймворком?
В большинстве своем библиотеки так или иначе являются прокси к более низкоуровневому API, если вы начнете действовать в обход — возможны проблемы.
Вы противопоставляете паттерны и фреймворки, но фреймворки, в первую очередь — это готовое архитектурное решение. А задача любой архитектуры и есть удачные ограничения, некая композиция паттернов.
Опытные специалисты знают о паттернах и прекрасно используют их во фреймворках, а новичкам никто и не даст разрабатывать с нуля архитектуру.
И я уверена, что если уж с готовой архитектурой человек потратит на что-то там неделю, то без нее он просто будет строить велосипед годами и все равно придет туда же.
Опытные специалисты знают о паттернах и прекрасно используют их во фреймворках, а новичкам никто и не даст разрабатывать с нуля архитектуру.
И я уверена, что если уж с готовой архитектурой человек потратит на что-то там неделю, то без нее он просто будет строить велосипед годами и все равно придет туда же.
А если шарит, то он может и свою архитекуру быстро сделать.
Архитектуру, реализацию с тестами, версиями, документацию, сообщество, поддержку…
Конечно, может кому-то это и не нужно, если в одиночку пилить свой маленький проект, в других случаях, имхо, без перечисленного никак.
Зачем?
Почему вообще этому человеку не начать с разработки ядра ОС, ежели он, как вы говорите, «шарит»?
Если есть достаточно хороший и надёжный инструмент в любой области нет причин его не использовать.
Почему вообще этому человеку не начать с разработки ядра ОС, ежели он, как вы говорите, «шарит»?
Если есть достаточно хороший и надёжный инструмент в любой области нет причин его не использовать.
Все это конечно так. Но хотел бы ответит на цитату
Так же очень старым правилом — «Реюзайте код» и «используйте уже отлаженные модули». Зачем чесать там где уже за тебе почесали.
Реализовывать всё самому это мечта и высший пилотаж разработчика. Но на этой ой как часто не хватает время.
Хотя и сам не понимаю когда на небольшой странички с 5 контролами вешают тяжеловесы типа ангуляра…
Помните старый программистский принцип – каждый модуль должен выполнять одну функцию. Если он выполняет две или более – его нужно разбить на части.
Так же очень старым правилом — «Реюзайте код» и «используйте уже отлаженные модули». Зачем чесать там где уже за тебе почесали.
Реализовывать всё самому это мечта и высший пилотаж разработчика. Но на этой ой как часто не хватает время.
Хотя и сам не понимаю когда на небольшой странички с 5 контролами вешают тяжеловесы типа ангуляра…
Джорж, перелогинься.
Интересная статья, сам с недавних пор начал задумываться о том, что лучше — комплексное решение или набор маленьких модулей?
Вообще склоняюсь к тому, что набор маленьких модулей куда гибче. Рассмотрим тот же react — маленькая по функциональности библиотека, которая предоставляет лишь view слой вашего приложения. И ему по сути все равно как именно вы получаете, храните или обрабатываете данные. То есть мы вправе выбирать сами как мы будем управлять данными, главное в нужны момент отдать их реакту для отрисовки.
Но, есть и обратная сторона, вам нужно решать все остальные вопросы самостоятельно, как делать роутинг? как отправлять ajax запросы и прочее…
По этому мне кажется, что комплексные решения(как например angular) подходят для менее опытных разработчиков, для тех кому не хватит опыта выстроить свое окружение.
Теперь зайдем с другой стороны — поддержка кода!
В случае выбора комплексного решения, вам придется сделать выбор один раз Ember/Angular/Backbone? То есть если на проект приглашают нового человека, то ему говорят прямо — мы используем вот ЭТО! И он уже примерно знает с чем столкнется.
Если же мы выбрали путь отдельных маленьких библиотек, то, мне кажется, объяснить человеку с чем ему придется столкнутся куда сложнее, да и въезжать проект наверное тоже.
Хотя я думаю, что мир все таки пойдет именно таким путем(маленьких библиотек), и со временем будут выбраны лучшие практики и библиотеки, а значит стек технологий все таки будет более-менее стандартизирован.
Но это все чистое ИМХО =)
Вообще склоняюсь к тому, что набор маленьких модулей куда гибче. Рассмотрим тот же react — маленькая по функциональности библиотека, которая предоставляет лишь view слой вашего приложения. И ему по сути все равно как именно вы получаете, храните или обрабатываете данные. То есть мы вправе выбирать сами как мы будем управлять данными, главное в нужны момент отдать их реакту для отрисовки.
Но, есть и обратная сторона, вам нужно решать все остальные вопросы самостоятельно, как делать роутинг? как отправлять ajax запросы и прочее…
По этому мне кажется, что комплексные решения(как например angular) подходят для менее опытных разработчиков, для тех кому не хватит опыта выстроить свое окружение.
Теперь зайдем с другой стороны — поддержка кода!
В случае выбора комплексного решения, вам придется сделать выбор один раз Ember/Angular/Backbone? То есть если на проект приглашают нового человека, то ему говорят прямо — мы используем вот ЭТО! И он уже примерно знает с чем столкнется.
Если же мы выбрали путь отдельных маленьких библиотек, то, мне кажется, объяснить человеку с чем ему придется столкнутся куда сложнее, да и въезжать проект наверное тоже.
Хотя я думаю, что мир все таки пойдет именно таким путем(маленьких библиотек), и со временем будут выбраны лучшие практики и библиотеки, а значит стек технологий все таки будет более-менее стандартизирован.
Но это все чистое ИМХО =)
Но, есть и обратная сторона, вам нужно решать все остальные вопросы самостоятельно, как делать роутинг? как отправлять ajax запросы и прочее…Зачастую, роутинг, ajax запросы и прочее, уже решались на предыдущих проектах (например с jQuery), и взять наработанное решение будет быстрее чем изучать новое.
Например паттерн Наблюдатель, он используется в моделях Backbone, в дата-биндинге Angular и Knockout, и производит довольно большое “Вау!”. Но это всего лишь известный давным-давно паттерн, который можно реализовать на JavaScript за 30 строк кода или скачать один из тысяч готовых вариантов
Увы, для того чтобы реализовать так понравившуюся всем возможность «связки данных» — потребуется не только подписка на события, но и отображение данных в шаблоне (иначе обсерверы-то и не нужны), а это чуть более 30 строк кода. Но реализовав ещё и свой крутой шаблонизатор — внезапно обнаруживается, что код почти полностью копирует Knockout, т.е. его (кнокаута) исходники содержат ровно то, что нужно, ни больше, ни меньше, а дальше, то как разработчик этим воспользуется — дело разработчика.
… В отличие от ануглара, который имеет чуть больше всего, включая то, что зачастую не нужно.
И очень радует, что Knockout при своем минимуме функционала отлично расширяем. Побольше бы таких фреймворков.
Читая статью, об этом же и задумался. Собрать knockout из кусочков, как и реализовать свою собственную версию в с нуля, безусловно, можно. Но времени на это уйдёт очень много. А потом ещё сиди отлавливай утечки, производи оптимизации, наворачивай велосипеды… В то время как можно просто взять Knockout, который всё это уже умеет, и не навязывает почти ничего лишнего. Да мы сталкиваемся с определёнными ограничениями, спору нет, но целесообразность реализации такого вот двустороннего binding-а и наблюдателя самому, весьма спорный вопрос.
Обратная сторона медали: не понимая этих паттернов и устройство Knokout-а, очень легко наворотить такого убожества, что впору будет начать всё с нуля.
Обратная сторона медали: не понимая этих паттернов и устройство Knokout-а, очень легко наворотить такого убожества, что впору будет начать всё с нуля.
Ограничениями при использовании knockout? Какими, если не секрет?
Опуская тот момент, что шаблонизатор уничтожает DOM, а не перемещает в память, из-за чего надо быть с ним аккуратным, используя ссылки на конкретный элемент (особо актуально при работе с audio\video\canvas). Единственный его недостаток, по-моему.
Опуская тот момент, что шаблонизатор уничтожает DOM, а не перемещает в память, из-за чего надо быть с ним аккуратным, используя ссылки на конкретный элемент (особо актуально при работе с audio\video\canvas). Единственный его недостаток, по-моему.
Ну, к примеру, knockout не предназначен для огромных наборов данных. Система начнёт загибаться и помирать ещё на сравнительно небольших объёмах, в то время как реализация без observable и со своим примитивным render-ом выдаст результат на несколько порядков больший. Но не для всех это очевидно. Многим может показаться, что любая магия даётся бесплатно, потому что реализована не ими :)
Observable-подход позволяет легко навязать такой клубок взаимосвязей, что никакой сборщик мусора его никогда не уберёт. И реализуя на knockout-е более менее сложные велосипеды, стоит это учитывать. Также стоит учитывать вопрос производительности и проводить те или иные оптимизации. В наиболее критичных местах не городить лишних отслеживаний, уже хотя бы потому, что легко добиться ситуации, когда 1 и тот же computed будет вызываться 100+ раз подряд без разумной на то причины, и выдавая 1 и тот же результат. На самом деле, используя knockout, легко прострелить себе ногу.
Observable-подход позволяет легко навязать такой клубок взаимосвязей, что никакой сборщик мусора его никогда не уберёт. И реализуя на knockout-е более менее сложные велосипеды, стоит это учитывать. Также стоит учитывать вопрос производительности и проводить те или иные оптимизации. В наиболее критичных местах не городить лишних отслеживаний, уже хотя бы потому, что легко добиться ситуации, когда 1 и тот же computed будет вызываться 100+ раз подряд без разумной на то причины, и выдавая 1 и тот же результат. На самом деле, используя knockout, легко прострелить себе ногу.
Судя по опыту — вёрстка (html+css) имеет отношения к тормозам намного более близкие, нежели конкаут. Да и по-моему вполне очевидно, что для какого-либо оверхеда лучше всего минимизировать затраты, а не использовать ядро общего назначения.
А по поводу второго — зависит от опыта общения. Ангулар не позволяет сильно разгуляться и не терпит безумия в коде, но с другой стороны он столь сильно ограничивает область действия, что зачастую просто мешается.
З.Ы. Я ожидал услышать информацию о каких-либо ограничениях, когда эта библиотека не даёт реализовать какую-нибудь нужную логику, а не наоборот — информацию о том, что он помогает опытным разработчикам, считая их умными и грамотными, не делая никаких ограничений в использовании оного.
А по поводу второго — зависит от опыта общения. Ангулар не позволяет сильно разгуляться и не терпит безумия в коде, но с другой стороны он столь сильно ограничивает область действия, что зачастую просто мешается.
З.Ы. Я ожидал услышать информацию о каких-либо ограничениях, когда эта библиотека не даёт реализовать какую-нибудь нужную логику, а не наоборот — информацию о том, что он помогает опытным разработчикам, считая их умными и грамотными, не делая никаких ограничений в использовании оного.
Плохие советы, 99% не смогут нормально реализовать функциональность фреймворков, особенно всякие браузер специфик фичи. Не говоря уже о том, чтобы документировать это для работы в команде. Когда ваши 30 строк превращаются в 300+, приходит понимание, что ты что-то делал не так, потому фреймворки нужно не только изучать на уровне АПИ, но и лезть во внутрь, чтобы понять, как реализуется эта архитектура без набивания своих шишек и багов на проекте.
Основная ваша идея, что нужно изучать не фреймворк, а архитектуру очень правильная.
Но аргументация слабая, с чего вы взяли что Backbone это фреймворк? Заходим на оф. сайт и читаем «Backbone is a library, not a framework, and plays well with others». Это действительно так: в нем несколько библиотек, каждая, делает одну задачу. Их легко расширять, легко с помощью них, придумать свою архитектуру.
Идем дальше… Knockout. Разве это фреймворк? он делают одну, простую задачу — data-binding. В документации пишут «Knockout is a JavaScript library that helps you to create rich, responsive display and editor user interfaces with a clean underlying data model».
Angular — фреймворк, конечно.
Вобщем, посыл статьи хороший, но кажется вам не хватает опыта работы с так нелюбимыми вам фреймворками, для хорошей аргументации.
Очень важно при выборе библиотек/фреймворка учитывать долгосрочные проблемы, например если продукт будет развиваться, новым сотрудникам компании врядли понравится, что он создан на самописном фреймворке. И нужно учесть, что после вашего ухода из компании, он превращается в черный ящик, к которому все бояться прикоснуться, т.к. не понимают как он работает.
Но аргументация слабая, с чего вы взяли что Backbone это фреймворк? Заходим на оф. сайт и читаем «Backbone is a library, not a framework, and plays well with others». Это действительно так: в нем несколько библиотек, каждая, делает одну задачу. Их легко расширять, легко с помощью них, придумать свою архитектуру.
Идем дальше… Knockout. Разве это фреймворк? он делают одну, простую задачу — data-binding. В документации пишут «Knockout is a JavaScript library that helps you to create rich, responsive display and editor user interfaces with a clean underlying data model».
Angular — фреймворк, конечно.
Вобщем, посыл статьи хороший, но кажется вам не хватает опыта работы с так нелюбимыми вам фреймворками, для хорошей аргументации.
Очень важно при выборе библиотек/фреймворка учитывать долгосрочные проблемы, например если продукт будет развиваться, новым сотрудникам компании врядли понравится, что он создан на самописном фреймворке. И нужно учесть, что после вашего ухода из компании, он превращается в черный ящик, к которому все бояться прикоснуться, т.к. не понимают как он работает.
Зачем же так сходу вентилятор марать? Принцип же куда более прост — типовое на типовом.
Писать свою собственную 1Ску с блекджеком — в кащенко.
Писать на 1Ске сложное кастомное веб-приложение — туда же.
Аналогично где угодно — проблема типовая? Фреймворком ИКС покроется? Используй его! Плюсы фреймворков — модули/расширения/меньше кривая въезда.
Когда же у нас что-то сугубо своё, то и используем уже набор библиотек. Просто спускаемся на уровень ниже к текущим абстракциям.
Ах, какой был вентилятор!
Писать свою собственную 1Ску с блекджеком — в кащенко.
Писать на 1Ске сложное кастомное веб-приложение — туда же.
Аналогично где угодно — проблема типовая? Фреймворком ИКС покроется? Используй его! Плюсы фреймворков — модули/расширения/меньше кривая въезда.
Когда же у нас что-то сугубо своё, то и используем уже набор библиотек. Просто спускаемся на уровень ниже к текущим абстракциям.
Ах, какой был вентилятор!
Самописные решения хороши до тех пор, пока есть их автор. Ни документации, ни ответов на SO/списках рассылки как правило не будет — только самому разбираться в коде. С другой стороны — обычно фреймворки жестко ограничивают тем, что было в задумке авторов. Мне кажется, что золотая середина где-то в районе «набора» приложения из проверенных и известных библиотек — есть и гибкость и нет вендор лока.
Люди не понимали, как можно реализовать роутинг с переключением страниц, сложные интеактивные элементы и другое за такое время без фреймворков
Рискну предположить, что собеседование закончилось отрицательно?
В проекте, плотно написанном на одном из фреймворков, при прочих равных будут отдавать предпочтение разработчику, хорошо с ним знакомому.
Спорное утверждение. Очевидно что учить архитектуру и паттерны невероятно полезно и необходимо. Но далеко не все смогут самостоятельно создать правильную архитектуру для более менее большого проекта. К тому же, если приложение большое, в конечном счете вы получите тот же фреймворк со своим набором модулей, компонентов и других структурных единиц (и костылей, ага).
Но как уже упомяналось выше, при необходимости подключения нового человека, вы уже не сможете написать в вакансии «программист со сзнанием {{frameworkJs}}». Я считаю именно это основным приемуществом фреймворков, а не ускорение разработки. Да и фрейморки как раз сами по себе и являются наглядным пособием по применению паттернов и архитектурных решений.
Мой совет — учите фреймворки, но без фанатизма! Все хорошо в меру…
Но как уже упомяналось выше, при необходимости подключения нового человека, вы уже не сможете написать в вакансии «программист со сзнанием {{frameworkJs}}». Я считаю именно это основным приемуществом фреймворков, а не ускорение разработки. Да и фрейморки как раз сами по себе и являются наглядным пособием по применению паттернов и архитектурных решений.
Мой совет — учите фреймворки, но без фанатизма! Все хорошо в меру…
Если фреймворки пишут и пишут, значит это кому-нибудь нужно. Зачем писать код с нуля, если уже есть готовое? Ведь так же получится быстрее. Или это только кажущееся ускорение? Мне кажется, в статье не хватает конкретики.
Скрытый текст
Всю статью можно свести к одному предложению — фреймворки это лишь скопления готовых решений (обертка над готовыми решениями), которые хороший программист должен знать в голом виде (без фреймворка).
Даже не нашёл того, с чем бы я не согласился с автором. Для типовых задач фреймворки рулят. Но сопрягать фреймворк к чему-то специфическому я бы точно не стал. В своем коде я даже jquery не применяю, если этого не просят сторонние библиотеки.
Фреймворки, паттерны… это все только для тех, кто хочет поговорить о программировании как об эстетически красивом объекте. Все это не более чем инструменты для достижения цели, а красота решения к цели не приводит. Вся правда в том, что чик-чик и в продакшн…
Если под «всей правдой» вы подразумеваете что все так делают, или что это наиболее приемлемое решение в современных реалиях, то я с вами не соглашусь.
Вы можете не соглашаться если у вас есть достаточно ресурсов, чтобы не соглашаться со «всей правдой» и делать «свою правду»
Так зачем же обобщать и называть говнокодинг — всей правдой?
а дело не в говнокодинге. в компании, которая делает деньги только на продукте, приходится соблюдать баланс поддерживаемости и скорость разработки, я думаю, что автор об этом
Я понимаю о чем автор, но он описывает говнокод и называет его «вся правда», как будто другого нет.
«Хуяк-хуяк и в продакшн» — это не обязательно говнокод.
«Хуяк-хуяк и в продакшн» — это говнокод.
Вы же, как я понимаю, имеете ввиду профессионалов, которые способны за очень короткое время выполнить некоторую задачу хорошо. Это уже не говнокод и никак не «хуяк-хуяк и в продакшен».
Вы же, как я понимаю, имеете ввиду профессионалов, которые способны за очень короткое время выполнить некоторую задачу хорошо. Это уже не говнокод и никак не «хуяк-хуяк и в продакшен».
Это описание процесса, а не качества, когда уже на автомате делаешь. Если у профессионала все действия свелись именно к «хуяк-хуяк» (или по крайней мере со стороны так выглядит), то совершенно не обязательно это будет говнокод.
Предлагаю для случаев, когда точно получится говнокод, использовать выражение «пиздык-хуяк».
Предлагаю для случаев, когда точно получится говнокод, использовать выражение «пиздык-хуяк».
Спасибо, именно об этом. Молоток должен стучать по наковальне четко, громко и быстро, а не иметь в себе ядерный реактор. Говнокод тут не причем.
Спасибо, именно об этом. Молоток должен стучать по наковальне четко, громко и быстро, а не иметь в себе ядерный реактор. Говнокод тут не причем.
Спасибо, именно об этом. Молоток должен стучать по наковальне четко, громко и быстро, а не иметь в себе ядерный реактор.
Как вы думаете, в какой БД хранятся данные в Амазон?
Как вы думаете, в какой БД хранятся данные в Амазон?
«чик-чик и в продакшн» годится только для одноразовых (и заведомо элементарных) проектов, или для людей, которым плевать на остальных, или для людей, которым еще не пришлось поддерживать свой же говнокод.
Фууу, как можно было так испоганить фразу? Что называется, почувствуй разницу: брутальное «хуяк-хуяк и в продакш» и инфантильное «чик-чик и в продакшн».
Фреймворки достаточно хорошо сказываются на поддерживаемости проекта. Если есть порох нормально отдукоментировать и протестировать yet another router, то хорошо, а вот угроза горы плохо поддерживемых велосипедов, в которых без вдумчивого чтения кода не въедешь — реальная проблема.
У нас крайне положительный опыт использования knockout, и некого тиражируемого скелета приложения с его использованием, роутеры, кнопки и прочие компоненты — самописные.
Knockout берет на себя привязку атомов моделей к DOM, и является модулем который, как написано выше, выполняет одну функцию и выполняет ее хорошо. Для него даже понятие фреймворк стало применимо где-то с третьей версии, где появились обертки (крайне гибкие и удобные) для веб компонентов, то есть хотспоты для кода в рамках фреймворка.
Еще есть штука, которую я называю init-cycle, как приложение запускается, подтягивает конфигурацию, обслуживает зависимости, производит discovery частей приложения, вводит и выводит свои компоненты из активного состояния, можно воспринимать его как позвоночник каркаса. Мне вот крайне не нравится, когда его навязывают так, как это делает angular, для начинающих разработчиков это, наоборот, хороший способ избежать фатальных факапов.
У нас крайне положительный опыт использования knockout, и некого тиражируемого скелета приложения с его использованием, роутеры, кнопки и прочие компоненты — самописные.
Knockout берет на себя привязку атомов моделей к DOM, и является модулем который, как написано выше, выполняет одну функцию и выполняет ее хорошо. Для него даже понятие фреймворк стало применимо где-то с третьей версии, где появились обертки (крайне гибкие и удобные) для веб компонентов, то есть хотспоты для кода в рамках фреймворка.
Еще есть штука, которую я называю init-cycle, как приложение запускается, подтягивает конфигурацию, обслуживает зависимости, производит discovery частей приложения, вводит и выводит свои компоненты из активного состояния, можно воспринимать его как позвоночник каркаса. Мне вот крайне не нравится, когда его навязывают так, как это делает angular, для начинающих разработчиков это, наоборот, хороший способ избежать фатальных факапов.
А если честнее – потому что не видят альтернативы. А альтернатива есть, просто о ней забыли.
Яростно плюсую, именно то, о чём я постоянно говорю коллегам. А альтернатива есть — "Backbone без фантиков", когда на единственном принципе строится вся библиотека. Как его повернёшь — то и получишь: наследование, привязки, наблюдателе, всё прочее… Просто, компактно.
Полезная статья, буду отсылать на неё несогласных.
Эээ, ну давайте посмотрим:
Вы уж простите, но Sqimitive — никакая не альтернатива, на виду это просто мертвый велосипед.
- Backbone — тесты, только за месяц 73 комита от 18 авторов, огроменное сообщество, куча мануалов, скринкастов, расширений… много всего
- Sqimitive — тестов нет, последнее обновление 5 месяцев назад, точнее это дата добавления на github, сообщества нет, «документация», лично мне, сломала глаза
Вы уж простите, но Sqimitive — никакая не альтернатива, на виду это просто мертвый велосипед.
Несколько лет назад выбирали базу для своего фреймворка, который отдаем сторонним разработчикам. Выбрали в итоге Dojo получив тем самым из коробки: модульность AMD, life circle виджетов, MVC, шаблоны виджетов, Promises, общий подход к вотчерам и т.д. Тем самым мы сразу смогли разрабатывать наш специфический функционал не тратя время на сочинение философии разработки и прикручивание друг к другу отдельных деталей: RequireJS, knockout, какой-нибудь шаблонизатор, «десятистрочные promises» и т.п. В будущем мы не раз были этому благодарны, т.к. все части системы, даже сложные модули не из серии «еще один виджет», получились единообразны и реализованы в соответствии с одним и тем же подходом, не выбиваясь из общей строгой системы, что обычно нарушается в системах придуманных самостоятельно, т.к. достаточно сменится архитектору или девлиду — и сразу начинает внедрятся совершенно новый подход.
+ как показывает опыт, чем меньше библиотека, чем больше вероятность, что ее сделали и бросили. Особенно это актуально для пакетов из NPM.
В общем как обычно все сводится к не в паданию в крайности: не надо складывать числа jQuery, но и не надо тратить время на свои велосипеды, даже если вы их собираете из готовых запчастей.
+ как показывает опыт, чем меньше библиотека, чем больше вероятность, что ее сделали и бросили. Особенно это актуально для пакетов из NPM.
В общем как обычно все сводится к не в паданию в крайности: не надо складывать числа jQuery, но и не надо тратить время на свои велосипеды, даже если вы их собираете из готовых запчастей.
Совет изучать архитектуру, а не фреймворки, в принципе правильный. Но не нужно забывать про кроссбраузерность. У готового фреймворка большинство детских болячек будет исправлено, или будут известны обходные решения. А с набором библиотек на довольно сложных проектах придется по граблям-таки пройтись)
а кто-нибудь, покажите пример с хорошей архитектурой без фрэймворков. Я серьезно, хотелось бы расширить горизонты, поучится у мастеров ножевого боя…
Из модулей всё равно получится фреймворк, но только свой :) https://github.com/iammerrick/the-frankenstein-framework
Начав читать статью и встретив упоминания о JavaScript я решил, что их взяли для примера… их взяли… нет. Это статья о JS-фреймворках.
О них я ничего ни сказать, ни написать не могу. Мой скудный опыт в плане JS распространяется лишь на JQuery и на ajax GET/POST и более ничего.
Но, если взять то, что скрыто на бекенде, скрыто от пользователя — тут я процитирую автора:
Я никогда не использовал фрейворки на бекенде (речь о Java) для реализации проектов и уж тем более не начинал свое изучение с них (в то время их просто не было, так что не было шанса :) ).
Но даже, если бы я начал изучать язык с фреймворка, бы себя чувствовал нестабильно и не в своей тарелке. Сейчас повсюду облака, и всем фиолетово, как оно работает, что оно использует. Но, черт возьми, когда ты знаешь, что скрывается вон за тем выражением, что оно использует для реализации, то спать намного спокойнее, когда на твой проект наплывает очередная волна пользователей.
Писать программы, писать динамику, писать грамотный код без использования фреймворков — вот что нужно. Дороже. Сложнее. Зато ты понимаешь сонными фибрами как это работает.
Но я не отвергаю использования «проверенных библиотек» (кавычки потому, что они сейчас жиреют до размера фреймворка и не ровен час, завтра проверю какой-нибудь проект и «бац!» они именуют себя «Framework») для реализации какого-либо конкретного, «особого» функционала (к примеру poi hssf). Но не писать на нем весь проект от начала и до конца, использую псевдо-выражения под особую псевдологику «а после этого пиши вот это и там хвостик еще… и здесь забыли, иначе не взлетит!».
О них я ничего ни сказать, ни написать не могу. Мой скудный опыт в плане JS распространяется лишь на JQuery и на ajax GET/POST и более ничего.
Но, если взять то, что скрыто на бекенде, скрыто от пользователя — тут я процитирую автора:
Не учите фреймворки, учите архитектуру
Я никогда не использовал фрейворки на бекенде (речь о Java) для реализации проектов и уж тем более не начинал свое изучение с них (в то время их просто не было, так что не было шанса :) ).
Но даже, если бы я начал изучать язык с фреймворка, бы себя чувствовал нестабильно и не в своей тарелке. Сейчас повсюду облака, и всем фиолетово, как оно работает, что оно использует. Но, черт возьми, когда ты знаешь, что скрывается вон за тем выражением, что оно использует для реализации, то спать намного спокойнее, когда на твой проект наплывает очередная волна пользователей.
Писать программы, писать динамику, писать грамотный код без использования фреймворков — вот что нужно. Дороже. Сложнее. Зато ты понимаешь сонными фибрами как это работает.
Но я не отвергаю использования «проверенных библиотек» (кавычки потому, что они сейчас жиреют до размера фреймворка и не ровен час, завтра проверю какой-нибудь проект и «бац!» они именуют себя «Framework») для реализации какого-либо конкретного, «особого» функционала (к примеру poi hssf). Но не писать на нем весь проект от начала и до конца, использую псевдо-выражения под особую псевдологику «а после этого пиши вот это и там хвостик еще… и здесь забыли, иначе не взлетит!».
Кто мешает изучить исходники фреймворков, принципы их работы, используемые паттерны и понимать сонными фибрами, как это работает?
лень
Свои велосипеды интереснее:)
И не только интереснее. Я вот нашел старую программу, очень старую… студенческую, дипломную, как раз, когда было первое знакомство с Java. Открыл его и ужаснулся :)
А вот если бы тогда были фреймворки и я бы изучал синтаксис фреймворка, то за десяток лет мало бы что изменилось. Добавили бы новых функций, оставив совместимость со старыми и я так же уверен, что я бы практически не стал улучшать исходный код на том же фреймворке, так как за одинаковое время фреймворк осваивается быстрее и знаний за тот промежуток времени хватило бы, чтобы писать не говнокод на Java, а вполне-себе-код на одном из фрееймворков.
Но вот, годы прошли, я узнал много нового, версии языка сменились, появились новые вкусности и я узрел, что код был просто категорически не идеален и крив. И каждый раз, когда я вижу кривость своего или чужого кода на языке as is, я испытываю гордость за себя. В то же время каждый раз, когда мне указывают на кривость я тоже чувствую гордость за себя и за того человека, который знает данную область лучше меня и показывает мне что поменять и, главное, почему.
Вот, например, очень долгое время у меня стояли стандарты 6 версии… и тут, свет выше, переходим на 7ую. Я жутко рад!
Для себя посмотрел на 8ую… вероятно, почему бы и… но нет, раз 7ая используется, так пусть будет 7-ая.
Я согласен, что фреймворки тоже расширяют от версии к версии, но я 100% уверен, что количество изменений, с которыми сталкивается программист при переходе от версии языка к версии оно много выше чем то, с каким он столкнется при смене версии фреймворка.
В то же время я не говорю, что делать жизнь сложнее это значит делать ее лучше. Но, Работа != Жизнь. И если в один прекрасный день весь интернет и все веб-и-около технологии накроются медным тазом, я открою в пустоши свой магазинчик, где буду продавать резные изделия из дерева или кости (пустошь же..), это будет дело, которое я люблю и понимаю сонными фибрами.
А вот если бы тогда были фреймворки и я бы изучал синтаксис фреймворка, то за десяток лет мало бы что изменилось. Добавили бы новых функций, оставив совместимость со старыми и я так же уверен, что я бы практически не стал улучшать исходный код на том же фреймворке, так как за одинаковое время фреймворк осваивается быстрее и знаний за тот промежуток времени хватило бы, чтобы писать не говнокод на Java, а вполне-себе-код на одном из фрееймворков.
Но вот, годы прошли, я узнал много нового, версии языка сменились, появились новые вкусности и я узрел, что код был просто категорически не идеален и крив. И каждый раз, когда я вижу кривость своего или чужого кода на языке as is, я испытываю гордость за себя. В то же время каждый раз, когда мне указывают на кривость я тоже чувствую гордость за себя и за того человека, который знает данную область лучше меня и показывает мне что поменять и, главное, почему.
Вот, например, очень долгое время у меня стояли стандарты 6 версии… и тут, свет выше, переходим на 7ую. Я жутко рад!
Для себя посмотрел на 8ую… вероятно, почему бы и… но нет, раз 7ая используется, так пусть будет 7-ая.
Я согласен, что фреймворки тоже расширяют от версии к версии, но я 100% уверен, что количество изменений, с которыми сталкивается программист при переходе от версии языка к версии оно много выше чем то, с каким он столкнется при смене версии фреймворка.
В то же время я не говорю, что делать жизнь сложнее это значит делать ее лучше. Но, Работа != Жизнь. И если в один прекрасный день весь интернет и все веб-и-около технологии накроются медным тазом, я открою в пустоши свой магазинчик, где буду продавать резные изделия из дерева или кости (пустошь же..), это будет дело, которое я люблю и понимаю сонными фибрами.
Писать интереснее, чем читать, есть такая тенденция…
Я думаю что стоит придерживаться принципов изучения языка в таком направлении:
Используя такой подход мы, в большинстве случаев, будем выбирать инструмент для решения задачи правильный.
p.s. субъективное мнение.
- язык;
- его паттерны (архитектура типичных приложений);
- подводные грабли (ниша языка, предназначение, недостатки);
- нативные библиотеки;
- нативные фреймворки;
- расширения языка (для js к примеру, coffeeScript, typeScript, которые облегчают жизнь с пониманием, во что превратится код после компиляции);
- написание своих реализаций, если нет готового.
Используя такой подход мы, в большинстве случаев, будем выбирать инструмент для решения задачи правильный.
p.s. субъективное мнение.
Судя по комментам, очень многие даже сути не поняли.
Автор пишет не о том, что писать нужно исключительно и только велосипеды. Автор призывает вместо одного готового решения использовать набор готовых решений, которые в совокупности ничего не навязывают и не накладывают ограничений.
Сам бы с радостью такой подход использовал, но
1) Нужно больше опыта. Проблема в использовании набора решений как раз в том, что их еще надо найти нормальные. А фреймворк выбрал — и все, радуешься достоинствам, смиряешься с недостатками, с okay-face ковыряешь.
2) Если проект большой (100+ человек), то обычно есть бригадир, который за всех решает. Ну и в этом плане решение использовать какой-то фреймворк выглядит для него как правило безопаснее. Хотя согласен, очень часто в плане выбора стреляют мимо, особенно с Angular, который просто сильно распиарен.
Автор пишет не о том, что писать нужно исключительно и только велосипеды. Автор призывает вместо одного готового решения использовать набор готовых решений, которые в совокупности ничего не навязывают и не накладывают ограничений.
Сам бы с радостью такой подход использовал, но
1) Нужно больше опыта. Проблема в использовании набора решений как раз в том, что их еще надо найти нормальные. А фреймворк выбрал — и все, радуешься достоинствам, смиряешься с недостатками, с okay-face ковыряешь.
2) Если проект большой (100+ человек), то обычно есть бригадир, который за всех решает. Ну и в этом плане решение использовать какой-то фреймворк выглядит для него как правило безопаснее. Хотя согласен, очень часто в плане выбора стреляют мимо, особенно с Angular, который просто сильно распиарен.
Не хочется холиварить ни с кем, поэтому скромно напишу свое мнение:
- Толком не знать сам язык, но умело пользоваться jQuery, модными фреймворками — зло
- Использовать фреймворки там, где они как собаке пятая нога — зло
Мне однажды перепала работа, очень простая, но… выяснилось, что категорически нужен PHP. В итоге это сделал другой программер.
Суть: 1 модуль, прием и добавление заявок от пользователей (несколько позиций, заявки, текст и картинка к заявке), потом их обрабатывают и после оплаты крутят как рекламу (баннеры). Нагрузка — мизер, «полтора инвалида». Второй модуль — админка.
Я открыл html, которые сие генерирует: таблицы повсюду и «1-пиксельный секс», я тоже не дизайнер, но для веба всегда ищу готовые стили и решения (макет html и css к ней). Тут парень сделал сам…
Я открыл «капот», благо его не закрыли: adodb, qooxdoo, smarty, xajax, json-rpc. Вот это все, чтобы сделать: принял текст и картинку -> проверил ссылку на целевую страницу -> добавил в базу… + небольшая админка написанная на PHP и MySQL как БД!
Суть: 1 модуль, прием и добавление заявок от пользователей (несколько позиций, заявки, текст и картинка к заявке), потом их обрабатывают и после оплаты крутят как рекламу (баннеры). Нагрузка — мизер, «полтора инвалида». Второй модуль — админка.
Я открыл html, которые сие генерирует: таблицы повсюду и «1-пиксельный секс», я тоже не дизайнер, но для веба всегда ищу готовые стили и решения (макет html и css к ней). Тут парень сделал сам…
Я открыл «капот», благо его не закрыли: adodb, qooxdoo, smarty, xajax, json-rpc. Вот это все, чтобы сделать: принял текст и картинку -> проверил ссылку на целевую страницу -> добавил в базу… + небольшая админка написанная на PHP и MySQL как БД!
В основе статьи — ложная дихотомия: «либо фреймворки, либо архитектура».
На самом деле они дополняют друг друга: паттерн — это абстрактное описание типового решения определенной типовой задачи; фреймворки, как правило, — набор конкретных реализаций паттернов. То есть теория + практика.
Понятие «фреймворк» — это сам по себе паттерн уровня архитектуры системы. Соответственно и фреймворк не обязательно должен быть «монолитным» куском кода — даже если это набор типа разных, независимых библиотек, но по счастливой случайности (или, например, потому, что писались одним автором и подгонялись друг под друга) хорошо работающих друг с другом и покрывающих существенную часть приложения, то простое соглашение использовать именно их в проекте и создает фреймворк.
Так что, когда автор пишет, что использует один и тот же набор библиотек, написанных пять лет назад, это и значит, что он использует свой фреймворк.
На самом деле они дополняют друг друга: паттерн — это абстрактное описание типового решения определенной типовой задачи; фреймворки, как правило, — набор конкретных реализаций паттернов. То есть теория + практика.
Понятие «фреймворк» — это сам по себе паттерн уровня архитектуры системы. Соответственно и фреймворк не обязательно должен быть «монолитным» куском кода — даже если это набор типа разных, независимых библиотек, но по счастливой случайности (или, например, потому, что писались одним автором и подгонялись друг под друга) хорошо работающих друг с другом и покрывающих существенную часть приложения, то простое соглашение использовать именно их в проекте и создает фреймворк.
Так что, когда автор пишет, что использует один и тот же набор библиотек, написанных пять лет назад, это и значит, что он использует свой фреймворк.
Часто сталкиваюсь с людьми, которые пошли дальше. Они знают фреймворк, но не знают язык. В общем, я согласен с автором статьи. Но мне думается он довольно радикально все описывает. Фреймворки часто помогают не задумываться о решении типичных проблем, а сконцентрироваться на реализации задачи. Плюс ограничения зачастую дают дополнительные плюсы процессу разработки. Т.к. только через ограничения можно выработать хорошу архитектуру. Фреймворк — это чужой взгляд на подход к проблематике целевого продукта. А уж соглашаться с ним или нет — решать пользователю фреймворка. От себя скажу, что больше люблю небольшие и микро-фреймворки, и недолюбливаю многомегабайтных монстров. Хотя они по-своему хороши в лейте (Late). И да, я считаю, что писать велосипеды еще большее невежество, чем использовать фреймворки-гиганты. Я бы подумал, прежде чем брать на работу человека, который гордо называет себя начальником велосипедного завода.
Почему-то в статье не упомянут старый добрый jQuery. Это радует, по крайней мере меня.
Потому что Jquery никаким образом не относится к архитектуре проекта. Это только библиотечка по управлению DOM в императивном стиле с кроссбраузерной поддержкой. А фреймворки, в общем понимании — позволяют писать целостные приложения — смотреть на приложение более широко, а не выполнять какую-то единичную рутинную операцию.
Суть статьи: я не использую фреймворки так как собрал свою собственную коллекцию велосипедов
Изучайте и архитектуру, и фреймворки.
Я вот в жизни не писал ничего на js серьезного, но пошел посмотреть, что это за ангуляр, просто потому что знаю, что фреймворк с хорошей архитектурой может сэкономить огромное количество сил и времени.
Я вот в жизни не писал ничего на js серьезного, но пошел посмотреть, что это за ангуляр, просто потому что знаю, что фреймворк с хорошей архитектурой может сэкономить огромное количество сил и времени.
Автор пишет о насущном. Я пользуюсь фреймворками и относительно недавно начал мыслить в сторону, изложенную в этой статье. Было бы здорово увидеть продолжение данной в статьи на реальных примерах, например реализация роутинга или promises и т.п. Это будет очень поучительно. Считаю, что важно и инужно развивать в себе способность к live coding.
Отвечу Вам в Вашем стиле:
Призыв изучать архитектуру, сам по себе, хорош, но отрицание фреймворков это регресс. Ваши велосипеды, ни что иное, как машина времени, которая везет только в прошлое. Я и, я надеюсь, многие хорошие программисты, придерживаются принципа: «эта задача уже была решена до меня, мне следует уделить все внимание на те задачи, решения для которых еще нет или они, решения, не совершенны.» Готовые решения могут и должны использоваться, в том числе огромное количество модулей и расширений для фреймворков. Естественно, не все то хорошо, что блестит, и в модулях и расширениях тоже надо разбираться, чтобы не поставить что-то уродливое, но это справедливо абсолютно для любого чужого решения.
В статье есть явная подмена понятий:
Что это вообще значит? Модель и VM — разные вещи, если Вы, конечно, имели ввиду VM, когда говорили о модели, если же нет, то почему модель это только состояние? Более того, тот же VM имеет методы для представления, а уж совмещение контроллеров и VM для меня дикость, это что за паттерн? MVVMC? Методы — контроллеры, совершенный абсурд. Я понимаю что речь про JavaScript, но не все то контроллер что имеет методы. И боже упоси писать методы только для контроллера, я не представляю как потом разбирать этот бардак.
Итого:
Я понимаю, что для реализации пары формочек обратной связи можно обойтись чем то вроде:
а потом привязать этот объект к HTML форме через контроллер, но для чего-то серьезного стоит выбрать инструмент и пользоваться им. Для каждого винтика своя отвертка, ну вы должны понимать что именно я имею ввиду. Совсем не правильно молиться на ангуляр, но отрицать его существование ради несколько проектов, где он проявит себя отлично, просто глупо.
Серебрянной пули нет, а в мире кроме нечисти существует и много других существ, для которых нужно свое, уникальное оружие, если Вы, конечно, понимаете метафору.
Призыв изучать архитектуру, сам по себе, хорош, но отрицание фреймворков это регресс. Ваши велосипеды, ни что иное, как машина времени, которая везет только в прошлое. Я и, я надеюсь, многие хорошие программисты, придерживаются принципа: «эта задача уже была решена до меня, мне следует уделить все внимание на те задачи, решения для которых еще нет или они, решения, не совершенны.» Готовые решения могут и должны использоваться, в том числе огромное количество модулей и расширений для фреймворков. Естественно, не все то хорошо, что блестит, и в модулях и расширениях тоже надо разбираться, чтобы не поставить что-то уродливое, но это справедливо абсолютно для любого чужого решения.
В статье есть явная подмена понятий:
например реализуя MVP в рамках небольшого компонента просто мысленно разделять, что эти методы – это контроллер, эти свойства – модель и т.д…
Что это вообще значит? Модель и VM — разные вещи, если Вы, конечно, имели ввиду VM, когда говорили о модели, если же нет, то почему модель это только состояние? Более того, тот же VM имеет методы для представления, а уж совмещение контроллеров и VM для меня дикость, это что за паттерн? MVVMC? Методы — контроллеры, совершенный абсурд. Я понимаю что речь про JavaScript, но не все то контроллер что имеет методы. И боже упоси писать методы только для контроллера, я не представляю как потом разбирать этот бардак.
Итого:
Я понимаю, что для реализации пары формочек обратной связи можно обойтись чем то вроде:
function Feedback() {
var name;
var email;
var request;
}
// методы feedback.
а потом привязать этот объект к HTML форме через контроллер, но для чего-то серьезного стоит выбрать инструмент и пользоваться им. Для каждого винтика своя отвертка, ну вы должны понимать что именно я имею ввиду. Совсем не правильно молиться на ангуляр, но отрицать его существование ради несколько проектов, где он проявит себя отлично, просто глупо.
Серебрянной пули нет, а в мире кроме нечисти существует и много других существ, для которых нужно свое, уникальное оружие, если Вы, конечно, понимаете метафору.
Чрезвычайно актуальная и правильная во всех отношениях статья. Неофитам на заметку!
Странно, что никто не добавил эту ссылку.
Набор маленьких библиотек на все случаи жизни — microjs.com
Набор маленьких библиотек на все случаи жизни — microjs.com
После нескольких проектов среднего уровня начинают посещать мысли, что часто фреймворки больше ограничивают чем облегчают разработку. Полное понимание «Как это работает» только помогают в работе с теми же фреймворками да еще и повышает уровень знаний. Считаю, что разрабочики уровня senior как раз должны исповедовать такой подход.
Иностранные компании часто приглашают на финальное собеседование, на котором приходится решать тестовое задание и чем меньше вы гуглите и чем больше пишете с полным пониманием и с головы, тем шире зрачки у работодателя. Такой уровень очень ценится.
Иностранные компании часто приглашают на финальное собеседование, на котором приходится решать тестовое задание и чем меньше вы гуглите и чем больше пишете с полным пониманием и с головы, тем шире зрачки у работодателя. Такой уровень очень ценится.
Мне знакомы два способа учить архитектуру. Первый — через теорию (разные учебники шаблонов и их абстрактные описания). Второй — через примеры реализации (в чужих системах, приложениях, документации к фреймворкам и библиотекам, а так же через реализацию с их помощью тех самых шаблонов). Вообще-то они хорошо дополняют друг-друга и один способ не исключает другой.
Так что я воспринимаю статью автора не как «бегите от фреймворков», ведь он не поленился взять и изучить angular.js (и даже использовать его). На мой взгляд — основная мысль: «смотрите дальше фреймворков, на архитектуру, на шаблоны, которые фреймворки реализуют».
в этом смысле хорошо было бы показать более детально, какие именно шаблоны реализованы в популярных фреймворках. Это бы работало на мысль «учите архитектуру», в том числе «используя фреймворки».
Так что я воспринимаю статью автора не как «бегите от фреймворков», ведь он не поленился взять и изучить angular.js (и даже использовать его). На мой взгляд — основная мысль: «смотрите дальше фреймворков, на архитектуру, на шаблоны, которые фреймворки реализуют».
в этом смысле хорошо было бы показать более детально, какие именно шаблоны реализованы в популярных фреймворках. Это бы работало на мысль «учите архитектуру», в том числе «используя фреймворки».
И, что интересно, в комментах мало кто понял статью
А она не против фреймворков. Она за изучение паттернов вместо зацикливания на фреймворке (как правилом одном-двух).
Автору респект!
А она не против фреймворков. Она за изучение паттернов вместо зацикливания на фреймворке (как правилом одном-двух).
Автору респект!
Можно отказаться от веб-фреймворка, если проект достаточно прост или знаешь, как реализовать нужную логику на базе сторонних или самописных библиотек.
Тут расписал, оформил задачи и способы решений табличкой: Какие задачи возникают в результате отказа от использования веб-фреймворков?. Помогает аргументировать, почему для трёх-страничных визиток или лэндингов не надо Ruby-on-Rails или Angular. И когда всё же придётся переписывать на фреймворк.
Тут расписал, оформил задачи и способы решений табличкой: Какие задачи возникают в результате отказа от использования веб-фреймворков?. Помогает аргументировать, почему для трёх-страничных визиток или лэндингов не надо Ruby-on-Rails или Angular. И когда всё же придётся переписывать на фреймворк.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Не учите фреймворки, учите архитектуру