Comments 19
С Реактом сравнили, ок. А с веб-компонентами? А с Полимером?
т.е. я правильно понимаю, что в первом примере (который «тута» в буфер никакие данные мышкой скопировать уже нельзя? удобно, чо уж там…
UFO just landed and posted this here
Но если к нам приходит «просвещённый» заказчик с простеньким проектом и как бы намекает, что он (проект) должен быть на базе Angualr или ReactJS
И заказчик совершенно прав, потому что во-первых вы можете не захотеть его дальше поддерживать, и где он будет искать разработчиков со знаниями вашего велосипеда?
Во-вторых, а что если проект маленький, но будет расти? У известных фреймворков предсказуемый путь масштабирования, готовая экосистема. А что делать с вашим случаем — непонятно
UFO just landed and posted this here
Я бы не был столь категоричен. Да и нет здесь предмета спора.
Я особо не идеализирую решения, за которыми стоят (далее список) крупные команды и/или компании. От них сюрпризы случаются совсем нередко. Не стоит их идеализировать. То версию обновят так, что интерфейсы изменятся; то методы отрубят, которые раньше вполне себе работали. В результате для некрупного проекта, версия той или иной библиотеки попросту «замораживается», потому что переделывать все под очередное обновление выходит слишком дорого. В npm можно найти далеко не одно решение для каких-нибудь нужд, например, на базе react. Хорошие решения, грамотные. А запускаешь с последней версией react’a и сыплются в консоль «this method deprecated».
Поэтому если приходит заказчик и мы видим, что он сам еще толком не знает на какой именно результат ему рассчитывать, до конца не понимает (а порой и не верит) в успех своего проекта – да, мы настоятельно рекомендуем делать проще (не в ущерб бизнес-модели), чтобы как минимум посмотреть, пощупать и понять, как оно там будет. И чаще всего заказчик с нами соглашается.
Что же до топика, то описанный шаблонизатор как раз и задумывался как максимально упрощенный. Никакого дополнительного синтаксиса кроме стандартного HTML и JS. Как раз для того, чтобы сопровождение и/или мелкая коррекция проекта не вызывала особых трудностей.
Я особо не идеализирую решения, за которыми стоят (далее список) крупные команды и/или компании. От них сюрпризы случаются совсем нередко. Не стоит их идеализировать. То версию обновят так, что интерфейсы изменятся; то методы отрубят, которые раньше вполне себе работали. В результате для некрупного проекта, версия той или иной библиотеки попросту «замораживается», потому что переделывать все под очередное обновление выходит слишком дорого. В npm можно найти далеко не одно решение для каких-нибудь нужд, например, на базе react. Хорошие решения, грамотные. А запускаешь с последней версией react’a и сыплются в консоль «this method deprecated».
Поэтому если приходит заказчик и мы видим, что он сам еще толком не знает на какой именно результат ему рассчитывать, до конца не понимает (а порой и не верит) в успех своего проекта – да, мы настоятельно рекомендуем делать проще (не в ущерб бизнес-модели), чтобы как минимум посмотреть, пощупать и понять, как оно там будет. И чаще всего заказчик с нами соглашается.
Что же до топика, то описанный шаблонизатор как раз и задумывался как максимально упрощенный. Никакого дополнительного синтаксиса кроме стандартного HTML и JS. Как раз для того, чтобы сопровождение и/или мелкая коррекция проекта не вызывала особых трудностей.
UFO just landed and posted this here
Ваш подход абсолютно верен — вы видите конкретного заказчика, вы видите его задачу, вы знаете как ее решать
Примером задачи в этой статье является простейшая таблица. Решить ее на React или любом другом фреймворке никак не сложнее:
Кроме того заказчик получает решение, которое может потом поддерживать любой другой разработчик. Фрилансеров с навыками React намного больше, чем желающих разбираться во Flex.Patterns.
Банально это или не банально, но в типовых проектах нужно использовать типовые решения, а не изобретать свой велосипед.
Извините, Борис
Но я никак не могу понять, что вы хотите сказать/доказать?
Конечно, специалистов по react много. Очень много. И эта вот заветная надпись в CV: react или angular, она прибавляет в стоимости специалиста (о чем вы не упомянули). Но… Могу сказать из опыта нашей команды. Мы, как бы это сказать, «побаиваемся» супер-спецов в react / angular / [вписать нужное]. Потому что за тем «комфортом», который создается фреймвоком теряется сам язык и сама платформа. Может, когда-нибудь в будущем pure JS будет чем-то вроде asm сегодня. Но сейчас, мне больно видеть, как «программисты» по JQ теряются и не знают, как сделать ajax вызов без оного. Или супер-спецы по react не понимают, что такое void 0 или элементарные bind, call и apply.
Еще раз, у спора должен быть предмет. Я его не вижу. Вы во всем совершенно правы. Но говорите вы не о конкретном решении, приведенном в этой статье, то есть говорите вы не о Flex.Patterns (он же виновник) и даже не о react вы говорите, а говорите вы о том, как в вашей компании ведут бизнес, то есть вы говорите о вашей бизнес-модели. Но статья то не об этом.
То, что шаблон на react смотрится не сложнее шаблона на Flex.Patterns – очевидно. Я и не говорил нигде, что он смотрится проще. Я лишь делал акцент, что в Flex.Patterns нет никакого дополнительно синтаксиса, кроме стандартного, что делает его доступным для понимания любому человеку знакомому с JS и HTML.
Спасибо.
Но я никак не могу понять, что вы хотите сказать/доказать?
- Что react знает больше людей? Очевидно.
- Что я покусился на святое? Я уже ответил Вам ниже, что никто react «уделывать» не собирается.
- Что react и подобное нужно использовать везде (даже в до безобразия маленьких проектах)? Весьма и весьма спорный тезис.
- Что не нужно / нельзя / запрещено искать собственные решения для тех или иных задач? А как же тогда тот же react на свет появился? До него, что не было альтернатив? А как быть с нашим Яндексом? Уж сколько он «пилит» своих решений. Он тоже плохой?
- Или может вы считаете, что если некий проект сделан на react, то его с ходу «прочитает» любой сторонний разработчик? Да, нет. Все также придется какое-то время сидеть и разбираться, что к чему.
Конечно, специалистов по react много. Очень много. И эта вот заветная надпись в CV: react или angular, она прибавляет в стоимости специалиста (о чем вы не упомянули). Но… Могу сказать из опыта нашей команды. Мы, как бы это сказать, «побаиваемся» супер-спецов в react / angular / [вписать нужное]. Потому что за тем «комфортом», который создается фреймвоком теряется сам язык и сама платформа. Может, когда-нибудь в будущем pure JS будет чем-то вроде asm сегодня. Но сейчас, мне больно видеть, как «программисты» по JQ теряются и не знают, как сделать ajax вызов без оного. Или супер-спецы по react не понимают, что такое void 0 или элементарные bind, call и apply.
Еще раз, у спора должен быть предмет. Я его не вижу. Вы во всем совершенно правы. Но говорите вы не о конкретном решении, приведенном в этой статье, то есть говорите вы не о Flex.Patterns (он же виновник) и даже не о react вы говорите, а говорите вы о том, как в вашей компании ведут бизнес, то есть вы говорите о вашей бизнес-модели. Но статья то не об этом.
То, что шаблон на react смотрится не сложнее шаблона на Flex.Patterns – очевидно. Я и не говорил нигде, что он смотрится проще. Я лишь делал акцент, что в Flex.Patterns нет никакого дополнительно синтаксиса, кроме стандартного, что делает его доступным для понимания любому человеку знакомому с JS и HTML.
Спасибо.
А в чем преимущества перед Angular 1.5? По размеру он полегче и вроде большинство перечисленного он умеет. В чем так сказать ваша киллер-фича?
Почему должна быть киллер-фича?
Ну на самом деле – это верный подход. Должны быть некие свойства/характеристики, которые отличают продукт от его конкурентов/аналогов.
Другое дело момент применения этого подхода. Когда продукт готов, его производитель не просто должен, а обязан выделять те самые «киллер-фитчи». Но вот на стадии разработки в этом нет острой необходимости.
Сейчас как раз она и есть, стадия разработки. Поэтому я могу дать (и даю) перечень идей, лежащих в основе продукта. Я могу повторить:
Вот три идеи, которые на данный момент формируют вектор развития проекта. Но, а о «киллер-фитчах» мне пока говорить преждевременно.
Спасибо за ваш вопрос.
Другое дело момент применения этого подхода. Когда продукт готов, его производитель не просто должен, а обязан выделять те самые «киллер-фитчи». Но вот на стадии разработки в этом нет острой необходимости.
Сейчас как раз она и есть, стадия разработки. Поэтому я могу дать (и даю) перечень идей, лежащих в основе продукта. Я могу повторить:
- Избегание дополнительного окружения (библиотек, тулзов и прочего). Полная самодостаточность и возможность расширения функционала внутри решения со стороны разработчика. Это уже во многом реализовано. Flex.Patterns легко позволяет добавлять свой функционал к тому, что уже есть. Скажем вы «прицепились» к узлу, Flex.Patterns даст вам основной набор инструментов (ну там события прицепить, размеры снять, стили переопределить, анимацию применить и прочее). Но на ряду с этим у вас есть простой интерфейс для добавления своих инструментов к данному функционалу и, что очень важно, интегрировать эти вот свои инструменты внутрь Flex.Patterns – то есть делать свою собственную сборку конечного продукта.
- Только стандартный синтаксис. Ну об этом я уже очень много говорил.
- Хранение шаблонов и их ресурсов на клиенте.
Вот три идеи, которые на данный момент формируют вектор развития проекта. Но, а о «киллер-фитчах» мне пока говорить преждевременно.
Спасибо за ваш вопрос.
Насколько я понял из вашей статьи и комментариев, ваша цель – уделать React за счет простоты использования.
Вот пример с таблицей, переписанный на React. Никаких дополнительных инструментов, библиотека с CDN и мой код:
И не сказал бы, что получилось сложнее, чем у вас.
Кроме того, непонятно, как у вашего решения обстоят дела с минификацией. Все приведенные примеры загружют стили и шаблоны компонентов отдельными запросами. Как собрать из них один большой бандл для продакшена?
У меня, конечно, то еще самомнение, но в одиночку противопоставлять себя замечательным, талантливым и умным ребятам, создавшим react?
Нет, я никого не хочу «уделывать». И если вы посмотрите на мой предыдущий пост об этом шаблонизаторе, то увидите, как яростно я отказывался сравнивать шаблонизатор вообще с чем-либо. Во-первых, не время – не все еще готово из задуманного. Во-вторых, и концепция от части может поменяться.
Что бы как-то ответить на ваш вопрос, я расскажу (и от части повторюсь) о том, с чего все началось.
Какое-то время назад на паре проектов (админки) была необходимость отображать куски (порой большие) HTML. Особенностью было то, что эти элементы (хотя по объему это были порой страницы) нужны были далеко-далеко не всегда. Ну кто ж его знает пользователя, клацнет он по заветной кнопке или нет. Выделять под это дело адрес отдельный (новую страницу) – не выход; а держать в разметке (на тот случай если таки клацнет пользователь) – дорого. Решения были не наши (мы их лишь дорабатывали, а не переделывали, поэтому ни о каких react или чем-то еще и речи быть не могло) и прежняя реализация была через фреймы (тут даже мужчины имеют право на слезу). Тогда возникла идея написать небольшую тулзу (она и была небольшой в самом начале ~2000 строк), которая бы умела грузить HTML файл, проверять его ресурсы (JS, CSS), грузить и их, делать какие-то вставки, все это аккуратно собирать и бережно хранить на клиенте. Вот в этом моменте и был зачат проект. Реализация никаких нареканий не вызвала, все работало (и работает) прекрасно, а версальщик так вообще был очень доволен, ибо получал в работу обычную HTMLшку, которую мог открыть локально и отладить все что нужно. Так вот это все и зародилось. Я же свою идею решил не оставлять, а «повозиться» с ней еще «немного». По мере движения и прикручивания «тулзы» в разные другие проекты она стала обрастать мясом и в итоге вы видите то, что есть сейчас.
Иными словами, в момент «зачатия» проекта никто ни о каком react’е не думал и тем более о том, чтобы его уделывать.
Что же касается минификации, то этот вопрос все еще открыт. Думаю, над ним. Технически объединение шаблонов не проблема. Но есть ряд иных вопросов, связанных с тем, как вставляет контент в разметку шаблонизатор, что мешает идти, скажем так, простым и накатанным путем.
Спасибо за ваш вопрос и ваше время на эксперимент )
Нет, я никого не хочу «уделывать». И если вы посмотрите на мой предыдущий пост об этом шаблонизаторе, то увидите, как яростно я отказывался сравнивать шаблонизатор вообще с чем-либо. Во-первых, не время – не все еще готово из задуманного. Во-вторых, и концепция от части может поменяться.
Что бы как-то ответить на ваш вопрос, я расскажу (и от части повторюсь) о том, с чего все началось.
Какое-то время назад на паре проектов (админки) была необходимость отображать куски (порой большие) HTML. Особенностью было то, что эти элементы (хотя по объему это были порой страницы) нужны были далеко-далеко не всегда. Ну кто ж его знает пользователя, клацнет он по заветной кнопке или нет. Выделять под это дело адрес отдельный (новую страницу) – не выход; а держать в разметке (на тот случай если таки клацнет пользователь) – дорого. Решения были не наши (мы их лишь дорабатывали, а не переделывали, поэтому ни о каких react или чем-то еще и речи быть не могло) и прежняя реализация была через фреймы (тут даже мужчины имеют право на слезу). Тогда возникла идея написать небольшую тулзу (она и была небольшой в самом начале ~2000 строк), которая бы умела грузить HTML файл, проверять его ресурсы (JS, CSS), грузить и их, делать какие-то вставки, все это аккуратно собирать и бережно хранить на клиенте. Вот в этом моменте и был зачат проект. Реализация никаких нареканий не вызвала, все работало (и работает) прекрасно, а версальщик так вообще был очень доволен, ибо получал в работу обычную HTMLшку, которую мог открыть локально и отладить все что нужно. Так вот это все и зародилось. Я же свою идею решил не оставлять, а «повозиться» с ней еще «немного». По мере движения и прикручивания «тулзы» в разные другие проекты она стала обрастать мясом и в итоге вы видите то, что есть сейчас.
Иными словами, в момент «зачатия» проекта никто ни о каком react’е не думал и тем более о том, чтобы его уделывать.
Что же касается минификации, то этот вопрос все еще открыт. Думаю, над ним. Технически объединение шаблонов не проблема. Но есть ряд иных вопросов, связанных с тем, как вставляет контент в разметку шаблонизатор, что мешает идти, скажем так, простым и накатанным путем.
Спасибо за ваш вопрос и ваше время на эксперимент )
за стиль повествования мне понравилось)
Молодцы, так и надо!
Обычно же ещё забывается, что React, Twitter Bootstrap и прочие — это артефакт конкретных компаний, которые во-первых писали их для себя, а значит эти фреймворки являются в том числе решением каких-то их внутренних задач, и по совместительству ещё и общественно полезные и довольно универсальные инструменты. Поэтому там вполне себе много решений, нерелевантных для других конкретных компаний и проектов.
Обычно же ещё забывается, что React, Twitter Bootstrap и прочие — это артефакт конкретных компаний, которые во-первых писали их для себя, а значит эти фреймворки являются в том числе решением каких-то их внутренних задач, и по совместительству ещё и общественно полезные и довольно универсальные инструменты. Поэтому там вполне себе много решений, нерелевантных для других конкретных компаний и проектов.
Sign up to leave a comment.
Как мы всех на юх послали (ну или продолжение истории про шаблонизотор)