Комментарии 58
А так же интересен был бы тест VueJS
Nexus 5 и iPhone 5S? Нет, это неадекватно. Если вы хотите выпускать действительно массовое приложение, то надо тестировать на 2-ядерных смартфонах с 512 МБ ОЗУ, вдобавок с установленным (и работающем в фоне) среднестатистическим набором приложений (например, Facebook, VK, какой-нибудь антивирус, сервисы Google, несколько игр с сервисами оповещений и пр. и пр.)
P.S. Спасибо большое за статью, может быть, хоть кому-нибудь она откроет глаза на нынешнее JS-безумство.
P.S. Спасибо большое за статью, может быть, хоть кому-нибудь она откроет глаза на нынешнее JS-безумство.
Vanilla-vanill-ой, все нужно примерять к задачам, к команде людей которые работают с этим кодом.
Есть профессионалы, которые могут написать структурированный Vanilla-код, который будет хорошо работать, но когда к одному и тому же коду причастно большое количество людей разного проф. уровня — фреймверки являются необходимой абстракцией, которая в большинстве случаев не даст сделать приложение тормознутым (я сейчас о реакте, у разработчика забирают возможность напрямую манипулировать DOM, отдают эту работу виртуальному дереву и реакту — он и принимает решение что обновлять, а что нет). Используя VanillaJS ты обязательно должен помнить о множестве мест, где может упасть производительность, или есть соблазн обновить весь контейнер, а не всего несколько элементов в нем.
Я за VanillaJS, но когда уверен, что для задачи этого достаточно или необходимо, когда код будет сопровождаться компетентными людьми.
Есть профессионалы, которые могут написать структурированный Vanilla-код, который будет хорошо работать, но когда к одному и тому же коду причастно большое количество людей разного проф. уровня — фреймверки являются необходимой абстракцией, которая в большинстве случаев не даст сделать приложение тормознутым (я сейчас о реакте, у разработчика забирают возможность напрямую манипулировать DOM, отдают эту работу виртуальному дереву и реакту — он и принимает решение что обновлять, а что нет). Используя VanillaJS ты обязательно должен помнить о множестве мест, где может упасть производительность, или есть соблазн обновить весь контейнер, а не всего несколько элементов в нем.
Я за VanillaJS, но когда уверен, что для задачи этого достаточно или необходимо, когда код будет сопровождаться компетентными людьми.
которая в большинстве случаев не даст сделать приложение тормознутым
Хочу добавить, что не только не дадут сделать приложение тормознутым, а еще помогут структурировать код.
Поэтому и нужно искать компромис между скоростью Vanilla, структурированностью и безопасностью, либо красотой, для некоторых лаконичностью. Каждый фреймверк решает что то одно хорошо, другое так себе, а с третьим все совсем плохо.
Обучение фреймверку — это не плохо. Это уже написанная документация и сообщество разработчиков. А кто сделает документацию к вашему VanillaJS?
Всеми руками за! Отличная статья! Давно пора трезво смотреть на эту моду! Подпишусь под каждым словом!
Именно! Лично я предпочитаю изучению хода мыслей других разработчиков, изучение основ самого web-a!
И причём ты ни когда не сможешь сказать со 100% увереностью что ты отлично разбираешься в этом фреймворке,
если ты его только сам не разрабатываешь.
На доскональное изучение уходят месяцы. Лучше открыть w3c.org и понять где корни ошибок и т.п.
Хочу добавить что каждый фреймворк накладывает свой угол зрения и он уже того, что можно создать с помощью нативного web-а(который еще и гибче)
Справедливости ради скажу, что я не участвую в проектах со 100+ количеством разработчиков, для которых создаются данные фреймовки. Но они создаются для узкого круга задач (Да, да, а вы думаете гугл/телеграм заботиться о ваших архтектурах?) И в тех проектах где действительно прменим фреймворк стоит задуматься о написании своей системы.
Слишком сильно Angular & React размаркетингован!
Но я не могу отделаться от мысли, что лучше вложиться в собственные знания и навыки в рамках самой веб-платформы.
Именно! Лично я предпочитаю изучению хода мыслей других разработчиков, изучение основ самого web-a!
Изучение.
Снова изучать.
И причём ты ни когда не сможешь сказать со 100% увереностью что ты отлично разбираешься в этом фреймворке,
если ты его только сам не разрабатываешь.
На доскональное изучение уходят месяцы. Лучше открыть w3c.org и понять где корни ошибок и т.п.
Хочу добавить что каждый фреймворк накладывает свой угол зрения и он уже того, что можно создать с помощью нативного web-а(который еще и гибче)
Справедливости ради скажу, что я не участвую в проектах со 100+ количеством разработчиков, для которых создаются данные фреймовки. Но они создаются для узкого круга задач (Да, да, а вы думаете гугл/телеграм заботиться о ваших архтектурах?) И в тех проектах где действительно прменим фреймворк стоит задуматься о написании своей системы.
Слишком сильно Angular & React размаркетингован!
НЛО прилетело и опубликовало эту надпись здесь
Конечно я согласен, что где применим, там надо применять!
Но, уж слишком тонкая грань между удобством первого старта и жёсткостью разросшегося приложения.
Надо уметь их готовить. А на это уходит время не одного проекта. А за это время мода успеет поменяться.
(Backbone->Angular->React)
На моей практике либо приложение на столько маленькое, что тянуть ради него фреймворк как из пушки по воробьям, либо она такое большое, что со всеми фреймоврками и библиотеками порог входа несколько месяцев для ознакомительного изучения их всех. А когда начинают появляться в них баги… или заказчик хочет того, что с фреймворком ой как сложно сделать. (Например Lazy-loading для Angular 1.2) вот тогда сильно задумываешься о том, стоит ли оно того?
Но, уж слишком тонкая грань между удобством первого старта и жёсткостью разросшегося приложения.
Надо уметь их готовить. А на это уходит время не одного проекта. А за это время мода успеет поменяться.
(Backbone->Angular->React)
На моей практике либо приложение на столько маленькое, что тянуть ради него фреймворк как из пушки по воробьям, либо она такое большое, что со всеми фреймоврками и библиотеками порог входа несколько месяцев для ознакомительного изучения их всех. А когда начинают появляться в них баги… или заказчик хочет того, что с фреймворком ой как сложно сделать. (Например Lazy-loading для Angular 1.2) вот тогда сильно задумываешься о том, стоит ли оно того?
Предлагаю не гоняться за модой, которая изменчива, а сосредоточиться на базовых принципах, которые в современных фреймверках практически идентичны, только пишутся по-разному.
В основном, в UI-фреймверках типа Angular все вертится вокруг дата-биндинга. В React+Flux это тот же дата-биндинг только вид сбоку. Есть Store, есть Component — задача программиста правильно прикрутить компонент к стору чтобы данные из стора правильно выводились в компонентах, а любые изменения в компонентах сразу попадали в стор.
Исключительно мое мнение, что в Ангуляре этот процесс максимально пытаются скрыть от разработчика, в чем и кроется дьявол. :)
Тоже самое можно наблюдать и в Backbone — те же компоненты, тот же биндинг, только описывать связи и контролировать поведение компонентов сложнее.
На данный момент для меня золотой серединой является Реакт. Пока что для работы приятнее не нашел. Смотрел и Riot и VueJS (конечно на каждом из них сделал пару мелких поделок).
В основном, в UI-фреймверках типа Angular все вертится вокруг дата-биндинга. В React+Flux это тот же дата-биндинг только вид сбоку. Есть Store, есть Component — задача программиста правильно прикрутить компонент к стору чтобы данные из стора правильно выводились в компонентах, а любые изменения в компонентах сразу попадали в стор.
Исключительно мое мнение, что в Ангуляре этот процесс максимально пытаются скрыть от разработчика, в чем и кроется дьявол. :)
Тоже самое можно наблюдать и в Backbone — те же компоненты, тот же биндинг, только описывать связи и контролировать поведение компонентов сложнее.
На данный момент для меня золотой серединой является Реакт. Пока что для работы приятнее не нашел. Смотрел и Riot и VueJS (конечно на каждом из них сделал пару мелких поделок).
НЛО прилетело и опубликовало эту надпись здесь
«видел» и «вообще мрак» — это вы хватили — повторное использование кода как бы вполне нормальная практика ;-)
Хороший пример: Есть Вася и есть Петя. Вася знает почему этот тег не применим в данном месте, а Петя не знает. Но например Петя знает то, что не знает Вася. Фреймверки позволяют Васе и Пети не сидеть и разбираться во всех нюансах применения тех или иных тегов или стилей. (Я конечно не спорю, что знать все — очень и очень хорошо.) Но кушать что-то нужно, поэтому берут прослойку, которая убирает пробелы в знаниях Васи и Пети, и предлагает решать задачи более высокого уровня, например заняться логикой добавления товаров. И в этом нет ничего плохого. Тем более, что любой другой, например Женя прийдет и у него будет с чего начать (документация, stackoverflow, код разбит на общепринятые сущности).
Согласен! WordPress, Drupal хоть и не фреймоврки, но очень удобные инструменты для Вась и Петь!
А вот с Женей вопрос спорный. Будет ли написан код Васей и Петей так, как этого предлагают разработчики фреймворков? Сколько времени нужно Жене на изучение всех фреймворков и библиотек? А хватит ли запала и т.п.
Соглашусь еще раз для менеджеров фреймворки могут быть и выгодны. но для кода и для разработчика, как специалиста, вряд ли.
А вот с Женей вопрос спорный. Будет ли написан код Васей и Петей так, как этого предлагают разработчики фреймворков? Сколько времени нужно Жене на изучение всех фреймворков и библиотек? А хватит ли запала и т.п.
Соглашусь еще раз для менеджеров фреймворки могут быть и выгодны. но для кода и для разработчика, как специалиста, вряд ли.
Почему вы так уверены, что один человек способен написать идеальный код? Нет, конечно для этого человека этот код будет идеальным, в меру его способностей и гениальности, но поймут ли этот код другие разработчики, которым вдруг прийдется поддерживать его код?
А вот насчет Жени, разве ему будет проще разбираться с кодом у которого нет ни документации и структура, и компоненты в каком-то самобытном формате, который не описан в интернете?
А вот насчет Жени, разве ему будет проще разбираться с кодом у которого нет ни документации и структура, и компоненты в каком-то самобытном формате, который не описан в интернете?
Как раз для разработчика как для специалиста фреймворки выгоднее. Вася и Петя с Angular/React смогут есть и наконец-то думать о такой возвышенной материи, как выполнение непосредственной задачи. Женя же придумывает так или иначе свой фреймворк на ваниле и остается единственным специалистом в нем. Хорошо если работодатель будет не против того, что бы он поделился им на github.
Для ловкого менеджера ситуация выглядит иначе: порог вхождения в наш BicycleEnterpriseFramework высок, зато куда потом от нас денется разработчик с опытом разработки в нем? И ситуация в такой компании конечно же не здоровая.
Для ловкого менеджера ситуация выглядит иначе: порог вхождения в наш BicycleEnterpriseFramework высок, зато куда потом от нас денется разработчик с опытом разработки в нем? И ситуация в такой компании конечно же не здоровая.
НЛО прилетело и опубликовало эту надпись здесь
Да все верно, я о том что компания выбравшая такой путь нездорова (либо имеет большие ресурсы). С точки зрения программиста работа там не несет профитов, если только не хочется набить руку в низкоуровневой разработке на своем языке. Но если рынок хочет React-разработчика (с 10 летним опытом желательно :)), то у того программиста просто отнимают время. Как опыт хорошо, как индустрия — не каждому автозаводу нужны изобретатели колеса на должность проектировщика приборной панели.
Это 5 :)
Сложность изучения любого велосипеда многократно меньше сложности изучения крупного приложения. Иными словами знание фреймворка тут мало чем помогает так как есть груда кода написанного абы как без документации и тп. Если же вы сейчас возразите, что надо код приложения хорошо структурировать, комментировать, документировать, то «свой велосипед» как часть этого приложения будет также хорошо структурирован и документирован. А если вы загляните в потроха популярных «готовых фреймворков», то ужаснётесь как там всё запутано и неподдерживаемо. Собственно, хороший программист сделает хороший фреймворк под задачу. А плохой и на готовом фреймворке наговнокодит так, что разобраться будет невозможно. Фреймворки — не серебрянные пули, а всего-лишь набор подходов. Иногда удачный, иногда не очень, и зачастую пишутся они не слишком квалифицированными программистами.
Окей, фреймверки — набор паттернов, это да. Иногда этот набор помогает писать, если программист читает документацию и хотя бы немного понимает что там написано. Ну и помогает писать в таком духе, как пишет другой программист на том же фреймверке.
Да есть такие, которые пишут свои решения, например у нас есть подобный пример. Но здесь все зависит от человека, «хорошего программиста». Он написал свой велосипед, и он вполне неплох. Но так как это разработка фирмы, и фреймверк и код фреймверка, то возникает большой соблазн менять код ядра, вместо правки модулей. Так вот когда фреймверк общественный и мэйнтайнеры не дураки — они твой код завернут и пошлют куда подальше.
Я к чему, написать это одно — а как жить с этим добром одному?
Да есть такие, которые пишут свои решения, например у нас есть подобный пример. Но здесь все зависит от человека, «хорошего программиста». Он написал свой велосипед, и он вполне неплох. Но так как это разработка фирмы, и фреймверк и код фреймверка, то возникает большой соблазн менять код ядра, вместо правки модулей. Так вот когда фреймверк общественный и мэйнтайнеры не дураки — они твой код завернут и пошлют куда подальше.
Я к чему, написать это одно — а как жить с этим добром одному?
На самом деле это замечательно, когда можно менять код ядра, а не ждать по пол года принятия пул реквеста, потом ещё пол года следующей стабильной версии. И то далеко не факт, что примут, ведь изменение может сломать совместимость с каким-нибудь матёрым ынтырпрайзом. В этом как раз плюс своего решения — если видишь, что что-то сделано плохо — просто берёшь и делаешь хорошо. А чтобы не бояться рефакторинга рекомендую писать тесты ;-)
Я ещё не видел двух похожих приложений на ангуляре сложнее приветмира. Где-то всё в один шаблон сваливают, где-то его приправляют директивами меняющими дом, где-то на компоненты разбивают, где-то скопы изолируют, а где-то мучаются с их наследованием, где-то состояния хранят в сервисах, где-то прямо в контроллерах, а где-то велосипедят модель с ленивой загрузкой. Вы нигде не найдёте туториала как на ангуляре запилить большое сложное приложение, но когда такое пилишь, сталкиеваешься с проблемами, которые в данном фреймворке либо не решены, либо решены криво. Вот и костыляют кто во что горазд.
Я ещё раз подчеркну: коробочные фреймворки (где «всё включено») позволяют человеку с низкой квалификацией быстро создать что-то типовое. Но для профессионала они являются лишь обузой, так как ставят ему не типовые задачи. И для этих задач куда важнее гибкость, чем жёсткие рамки.
Я ещё не видел двух похожих приложений на ангуляре сложнее приветмира. Где-то всё в один шаблон сваливают, где-то его приправляют директивами меняющими дом, где-то на компоненты разбивают, где-то скопы изолируют, а где-то мучаются с их наследованием, где-то состояния хранят в сервисах, где-то прямо в контроллерах, а где-то велосипедят модель с ленивой загрузкой. Вы нигде не найдёте туториала как на ангуляре запилить большое сложное приложение, но когда такое пилишь, сталкиеваешься с проблемами, которые в данном фреймворке либо не решены, либо решены криво. Вот и костыляют кто во что горазд.
Я ещё раз подчеркну: коробочные фреймворки (где «всё включено») позволяют человеку с низкой квалификацией быстро создать что-то типовое. Но для профессионала они являются лишь обузой, так как ставят ему не типовые задачи. И для этих задач куда важнее гибкость, чем жёсткие рамки.
Случаи когда мэйнтайнер личного фреймверка забухал или сроки прижали и в ядро пропихнули откровенную ересь? Постепенно в закрытых фреймверках ядро обрастает кучей мусора. Что со временем снижает разработку, если процессы в команде не налажены или дали сбой.
Что хотел сказать, что разработка своего решения, хорошего решения — всегда сопряжено с культурой, принятой в команде. И если в команде высокая культура кодирования — большой шанс получить на выходе хороший фреймверк для внутреннего использования. Но чаще всего получается так что мейнтайнер сменяет мейнтайнера, в ядро льется откровенный мусор, файловая структура теряет былую красоту и изящность. Это кстати может случится и с командами, работающими с открытыми решениями. Все упирается в интеллектуальный и культурный уровень людей.
Но фреймверки — это как пример более цивилизованной разработки, сборник решений опять же от людей с какими то культурными ценностями. Не все фреймверки одинаково хороши, но и игнорировать их не стоит.
Что хотел сказать, что разработка своего решения, хорошего решения — всегда сопряжено с культурой, принятой в команде. И если в команде высокая культура кодирования — большой шанс получить на выходе хороший фреймверк для внутреннего использования. Но чаще всего получается так что мейнтайнер сменяет мейнтайнера, в ядро льется откровенный мусор, файловая структура теряет былую красоту и изящность. Это кстати может случится и с командами, работающими с открытыми решениями. Все упирается в интеллектуальный и культурный уровень людей.
Но фреймверки — это как пример более цивилизованной разработки, сборник решений опять же от людей с какими то культурными ценностями. Не все фреймверки одинаково хороши, но и игнорировать их не стоит.
Когда смотришь в исходные коды многих фреймворков складывается ощущение, что мейнтейнеры не просто бухали, а постоянно устраивали оргии с индусами :-)
Welcome, продемонстрируйте здесь или здесь индусов и бухих мейнтайнеров.
Лично мое мнение, что код вполне ясен и можно даже пробовать самому слать PR.
У меня впечатление, что вы сложили мнение о ВСЕХ фреймверках по какому-то одному продукту, но их даже не два, их гораздо больше.
Например, во Флюксе я понял что к чему буквально в первый же день. Это достаточно банальный ивент-деспетчер. Но конечно, если я ощущаю трудности с пониманием как оно работает, то скорей всего это или действительно не-внятно написанный код фреймверка или просто не тот фреймверк, который мне нужен, ну или конечно я сам виноват, что не мой уровень.
Лично мое мнение, что код вполне ясен и можно даже пробовать самому слать PR.
У меня впечатление, что вы сложили мнение о ВСЕХ фреймверках по какому-то одному продукту, но их даже не два, их гораздо больше.
Например, во Флюксе я понял что к чему буквально в первый же день. Это достаточно банальный ивент-деспетчер. Но конечно, если я ощущаю трудности с пониманием как оно работает, то скорей всего это или действительно не-внятно написанный код фреймверка или просто не тот фреймверк, который мне нужен, ну или конечно я сам виноват, что не мой уровень.
Пожалуйста:
Первый дриньк: https://github.com/facebook/react/blob/master/src/isomorphic/classic/element/ReactDOMFactories.js
Второй дриньк: https://github.com/facebook/react/blob/master/src/renderers/dom/client/ReactBrowserEventEmitter.js#L84
А теперь на брудершафт:
https://github.com/facebook/flux/blob/master/examples/flux-todomvc/js/actions/TodoActions.js
https://github.com/facebook/flux/blob/master/examples/flux-todomvc/js/stores/TodoStore.js
Сон разума рождает чудовищ. Но вы правы, конкретно эти две библиотеки не так плохи как многие другие фреймворки. А флюкс — вообще нечто тривиальное.
Первый дриньк: https://github.com/facebook/react/blob/master/src/isomorphic/classic/element/ReactDOMFactories.js
Второй дриньк: https://github.com/facebook/react/blob/master/src/renderers/dom/client/ReactBrowserEventEmitter.js#L84
А теперь на брудершафт:
https://github.com/facebook/flux/blob/master/examples/flux-todomvc/js/actions/TodoActions.js
https://github.com/facebook/flux/blob/master/examples/flux-todomvc/js/stores/TodoStore.js
Сон разума рождает чудовищ. Но вы правы, конкретно эти две библиотеки не так плохи как многие другие фреймворки. А флюкс — вообще нечто тривиальное.
В реакте есть что то от божественного объекта, при работе с DOM, но могу заверить, что функция перерендера дерева и поиск дифа с изменениями это не совсем тривиальная, но идея проста и работает как часы, поэтому это я реакту простил. В противовес могу сказать, что в достаточно сложном коде практически не работаю на прямую с DOM, а реакт вполне эффективен при работе с большим деревом.
Я и не говорил, что реакт тривиален. Я бы сказал, что реакт сильно переусложнён и мог бы быть реализован куда проще. Например: https://github.com/patrick-steele-idem/morphdom
Концепция «перерендериваем всё дерево на каждый чих» — порочна. Даже если это «легковесное» дерево. Собственно бенчмарки на простом идеоматичном примере не радуют: http://nin-jin.github.io/todomvc/benchmark/
И да, я в курсе про костыли типа shouldComponentUpdate. Не от хорошей жизни они добавлены.
Концепция «перерендериваем всё дерево на каждый чих» — порочна. Даже если это «легковесное» дерево. Собственно бенчмарки на простом идеоматичном примере не радуют: http://nin-jin.github.io/todomvc/benchmark/
И да, я в курсе про костыли типа shouldComponentUpdate. Не от хорошей жизни они добавлены.
Написали свой фреймворк. Как раз напоминал Реакт, только компоненты назывались контролами(наследие WebForms :)) ну и без jsx, просто фрагментами дом втыкал. Потом поняли, что ресурсов уйма нужна. Выкинули и переписали все на Ангуляре. Проще, быстрее, решает задачи, которые стоят(админская консоль сервера), плюс для фул стек разработчиков знакомый DI. Смысла писать своё не вижу, если фреймворк решает ваши задачи.
Возникает неувязка: с одной стороны — удобство и комфорт разработчиков, с другой — пользовательские нужды.
Не возникает. Удобство и комфорт разработчикам нужны, чтобы быстро и качественно удовлетворять пользовательские нужны. По крайней мере в коммерческой и близкой к ней разработке.
Да в деньги всё упирается. Если есть деньги — пишут своё. Денег нет — используют тот фреймворк, который знают.
НЛО прилетело и опубликовало эту надпись здесь
А из чего следует, что если есть деньги, то их тратят в ускорение работы приложения или другие оптимизации? Больше не на что потратить? Это к вам.
А Pilat, кстати, утверждает другое вообще, что если есть деньги, то пишут свои абстракции, а не используют чужие.
А Pilat, кстати, утверждает другое вообще, что если есть деньги, то пишут свои абстракции, а не используют чужие.
Я имел ввиду вот что: написать приложение, на своём фреймворке или на чужом, — разница не такая большая. Проблемы наступают потом, когда всё это надо поддерживать. И если нет денег на поддержку, то единственный выбор — использование чужого фреймворка, возможно принимая в нём участие. А поддержка — это развитие, исправление ошибок, оптимизация для новых устройств с новыми возможностями или ограничениями, обучение специалистов. Вот тут нужны деньги.
Ну а писать свой фреймворк вообще приятное занятие для программиста. Я одних ORM'ов столько на перле встречал…
Ну а писать свой фреймворк вообще приятное занятие для программиста. Я одних ORM'ов столько на перле встречал…
Но до той поры я бы предпочёл использовать обходиться без фреймворков, по крайней мере в мобильном сегменте.
Если кому-то так важна производительность в мобильном сегменте, то нужно не js-фреймворк выбирать, а писать мобильное приложение на соответствующем языке. В противном случае, пофиг на чем писать. 200—500 мс, даже 1 с это не те цифры над которыми нужно задумываться. Тем более js развивается, а производительность мобильных устройств неуклонно растет.
Какой-то мрачный вывод у статьи. В общем, используйте, что хотите и не думайте над производительностью. Лучше над качеством своего кода подумайте.
1 секунда на UI то не те цифры над которым надо задумываться, да правда что-ли?
Согласен. 250-500, пофиг. На сетевые задержки уходит больше всего времени.
А вы сеть на UI гоняете?
Странный вопрос. Мой ответ звучит так. Оптимизация 100мс — цена этому, отказ от фреймворка, как я понял из статьи. Результат самописной выдумки намного страшнее в будущем. И эти 200-500мс блекнул на фоне задержек сети
Мой посыл: 200-500мс на мобилке не могут блёкнуть — это серьёзный продолб, если на UI. А кто сказал про 100мс? Даже фрэймворки иногда не обязательно использовать, чтобы увидеть адские тормоза. Например, можно заюзать на одной View под WinPhone 5-8 стандартных WPF-конвертеров и наслаждаться лютыми тормозами на UI. Иногда не то что фрэймворки тормозят, иногда то, что из пакета тормозит.
Если решились на самописное, то писать надо правильно. Кто по вашему разрабатывает фрэймворки, не люди? Нормальная команда может осилить практически любой фрэймворк (в пределах разумного).
Если решились на самописное, то писать надо правильно. Кто по вашему разрабатывает фрэймворки, не люди? Нормальная команда может осилить практически любой фрэймворк (в пределах разумного).
Такое чувство что человек который пишет статью работает один. Как быть если это не мобильная версия сайта, а команда фронтов из 15 человек? Хотя знаю! Нужно чтоб на проект пришёл очередной выдумщик и написал свой уникальный Фреймворк, уволился через год, и все остальные остались жить с этим дерьмом!
Не удивительно, что он уволился, раз остальные разработчики не просто не участвовали в разработке фреймворка, но даже считали это занятие «дерьмом». Думаю, если бы вы больше обсуждали друг с другом подходы к разработке, то смогли бы выработать решение, которое бы устраивало всех или хотя бы все понимали что как и почему работает, а ему не пришлось бы искать других попутчиков.
То есть заказчик говорит: ну где проект, а команда из 15-ти человек сидит в это время и решает что выбрать:
Если проект и время позволяет, а инвестор готов платить за развитие своего фреймверка и понимает за что платит, то да. Но обычно заказчик не понимает зачем убивать огромное количество времени на изобретение такого же инструмента, которым пользуется его конкурент.
Да и не весь опенсорс отвратителен, можно за пол года перепробовать с пяток решений, последить за сообществом и принять решение что использовать.
Я это к чему, что не любой бизнес готов платить, и не всему бизнесу нужно делать собственный велосипед.
Это как болезнь молодых стартапов, у них нет прибыли, а они уже тратятся на большой офис и на огромную команду девелоперов, и сидят обсуждают какие у кого обязанности, вместо того чтобы пилить продукт который будет приносить деньги.
Пусть пишут те, которые уже получили деньги и у кого есть время на разработку своего решения, если их что то не устраивает в текущем. Я бы не советовал всем подряд писать свои решения.
for или map?Если проект и время позволяет, а инвестор готов платить за развитие своего фреймверка и понимает за что платит, то да. Но обычно заказчик не понимает зачем убивать огромное количество времени на изобретение такого же инструмента, которым пользуется его конкурент.
Да и не весь опенсорс отвратителен, можно за пол года перепробовать с пяток решений, последить за сообществом и принять решение что использовать.
Я это к чему, что не любой бизнес готов платить, и не всему бизнесу нужно делать собственный велосипед.
Это как болезнь молодых стартапов, у них нет прибыли, а они уже тратятся на большой офис и на огромную команду девелоперов, и сидят обсуждают какие у кого обязанности, вместо того чтобы пилить продукт который будет приносить деньги.
Пусть пишут те, которые уже получили деньги и у кого есть время на разработку своего решения, если их что то не устраивает в текущем. Я бы не советовал всем подряд писать свои решения.
На «изобретение» такого же инструмента время тратить не стоит, а вот изобретение инструмента лучше, чем у конкурента позволяет его обогнать. И наём ещё большего числа людей ему не поможет. Вы ошибаетесь, полагая, что написание своего фреймворка — это дополнительная большая трата денег, потому как не учитываете сколько денег уходит в трубу из-за использования неэффективных инструментов. Далеко ли вы уйдёте в неудобных сапогах?
А я бы советовал не бояться, а писать свои решения. но только если это свои оригинальные решения насущных проблем, а не повторение уже существующих решений.
А я бы советовал не бояться, а писать свои решения. но только если это свои оригинальные решения насущных проблем, а не повторение уже существующих решений.
Написание своего фреймворка и своего приложения на нём вместо написания приложения на нативном джсе всегда будет дольше и дороже.
Вообще садиться целенаправленно писать свой фреймворк имеет смысл в коммерческой разработке исключительно в ситуации, когда планируется непосредственно с помощью фреймворка (а не приложений на нём) зарабатывать деньги. Это необходимое условие. В иных случаях свой фреймворк должен не целенаправленно писаться, а выкристаллизовываться из существующих приложений как способ устранения дублирующегося кода.
Вообще садиться целенаправленно писать свой фреймворк имеет смысл в коммерческой разработке исключительно в ситуации, когда планируется непосредственно с помощью фреймворка (а не приложений на нём) зарабатывать деньги. Это необходимое условие. В иных случаях свой фреймворк должен не целенаправленно писаться, а выкристаллизовываться из существующих приложений как способ устранения дублирующегося кода.
Написание любого приложения сопряжено с написанием фреймворка (набор правил, соглашений, библиотек). Даже если вы используете в качестве базиса уже существующий фреймворк, вы его будете дополнять, расширять, строить свои более высокоуровневые абстракции. А вот «целенаправленно писать фреймворк» в отрыве от написания приложения (да хотя бы даже демонстрационного в случае разработки фреймворка как самостоятельного продукта) — это очень странный кейс.
И да, я всегда стараюсь писать обобщённые решения. Полноценная библиотека для работы с домом пишется за вечер, занимает не более 500 строк, имеет простое лаконичное апи и хорошо структурированный код. Это не такая уж сложная задача как может показаться при взгляде на кошмарный код jQuery.
А без энтропии, постоянных мутаций и горизонтального переноса генов не будет эволюции ;-)
И да, я всегда стараюсь писать обобщённые решения. Полноценная библиотека для работы с домом пишется за вечер, занимает не более 500 строк, имеет простое лаконичное апи и хорошо структурированный код. Это не такая уж сложная задача как может показаться при взгляде на кошмарный код jQuery.
А без энтропии, постоянных мутаций и горизонтального переноса генов не будет эволюции ;-)
Не путайте разработку приложения с нуля и разработку приложения с использованием стороннего для приложения (пускай и собственной разработки той же команды) обобщенного фреймворка. Как минимум, если какое-то решение было неудачным, то вносить синхронные изменения нужно будет в два проекта. А если вы называете «написанием фреймворка» создание архитектуры приложения в принципе, то у нас очень большая разница в терминах. В любом проекте крайне желательно разделять обязанности по модулям, слоям, прочим архитектурным и языковым сущностям и т. п., но созданием фреймворка является вынос в отдельный проект инфраструктурных и прочих модулей и еже с ними, которые будут вызывать основной код приложения, передавая ему свои абстракции над средой выполнения.
И не путайте библиотеки и фреймворки — фреймворк вызывает ваше приложение (максимум нужно самому написать загрузку, инициализацию и запуск фреймворка, запустить бутстрап процесс), а ваше приложение вызывает библиотеки (вызов коллбэка, переданного фреймворком в приложение или приложением в библиотеку, за полноценный вызов не считаем, это детали апи полноценного вызова). Иными словами, фреймворк диктует какие апи должно приложение реализовывать, а библиотека — какие использовать.
И не путайте библиотеки и фреймворки — фреймворк вызывает ваше приложение (максимум нужно самому написать загрузку, инициализацию и запуск фреймворка, запустить бутстрап процесс), а ваше приложение вызывает библиотеки (вызов коллбэка, переданного фреймворком в приложение или приложением в библиотеку, за полноценный вызов не считаем, это детали апи полноценного вызова). Иными словами, фреймворк диктует какие апи должно приложение реализовывать, а библиотека — какие использовать.
Вы всегда пишете свою операционную систему и свою библиотеку для работы с DOM?
Я предлагаю думать головой, когда стоит задача выбрать фреймверк. И начинать писать только после того как все попробовал и есть понимание что тебе необходимо. Да и например тот же Флюкс и Реакт это взаимозаменяемые штуки, чего не скажешь о монолитном Ангуляре. Есть хорошие и плохие решения.
Если смотреть на всю массу прогоаммистов, то наверное процентов 20 действительно неплохо понимают что происходит и смогут написать более изящное решение, чем может предложить рынок. Предлагать каждому писать свое решение — предложение увеличить энтропию.
Я предлагаю думать головой, когда стоит задача выбрать фреймверк. И начинать писать только после того как все попробовал и есть понимание что тебе необходимо. Да и например тот же Флюкс и Реакт это взаимозаменяемые штуки, чего не скажешь о монолитном Ангуляре. Есть хорошие и плохие решения.
Если смотреть на всю массу прогоаммистов, то наверное процентов 20 действительно неплохо понимают что происходит и смогут написать более изящное решение, чем может предложить рынок. Предлагать каждому писать свое решение — предложение увеличить энтропию.
Прорекламирую свой недавний доклад на тему сложности в ui через призму конечных автоматов. В этом докладе я обстоятельно и подробно разбираю тему «зачем нужны фреймворки» www.youtube.com/watch?v=SduoWEXqeAg&feature=youtu.be&t=4h53m26s
Очень интересная точка зрения, много справедливо в той или иной мере. Но мне кажется иногда переводчики слишком цеплялись за иронию Пола :)
Добавлю важную штуку существует огромное множество фремворков/библиотек и многие стремятся холиварить Angular 1/2/N лучше Backbone 1/N но есть еще лучше React 1/N вот с ним «заживем то». Они все хороши. Главное в них мне кажется, если немного добавить идеологии Пола:
Добавлю важную штуку существует огромное множество фремворков/библиотек и многие стремятся холиварить Angular 1/2/N лучше Backbone 1/N но есть еще лучше React 1/N вот с ним «заживем то». Они все хороши. Главное в них мне кажется, если немного добавить идеологии Пола:
Используя фремворк/библиотеку мы находим сильные/слабые ее стороны улучшаем/используем best practice (лучшие практики) и за счет них технология эволюционирует, а с ней и мы. Ну и конечно если технология эволюционирует то и продукты наши тоже. Все остаются в выигрыше не только разработчики но и конечные пользователи.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Цена использования фреймворков