>>Помните, с чего вы начали диалог?
Субъективно jsx хорошо продуман и автор не понимает React записав jsx в против
а не с
>>Я так понимаю вы сравниваете методом «у кого больше»?
Я не стану продолжать, вы видите только то, что вам нравится.
>>Поделитесь с общественностью, пожалуйста.
Создаются файлы начиная с ru_RU.js, с объектом внутри. В программе лишь ссылки. Далее дело только за переключением на нужный объект по событию. Что может быть сложного в создании файла на язык или переключателе на 2 строки?
Из вышеперечисленного только Роутинг меня беспокоит.
Мне не нужны:
— чужое представление какими должны быть Формы (в т.ч. валидация),
— ваше представление о моделях данных,
— шаблонизация мне совершенно не сдалась т.к. React предоставляет удобное расширение и повторное использование компонентов.
— Интернационализация делается удивительно простым способом.
Вы пытаетесь навязать мне свою точку зрения совершенно напрасно. Аргументы настолько незначительны, что даже не стоят обсуждения. Предлагаю закончить холивар в силу отсутствия желания понимать друг друга у оппонентов.
>>Это не фреймворк, а слой представления.
Ваше право использовать React как слой.
Lots of people use React as the V in MVC
Моё право использовать React как фреймворк. Если код используется как каркас, то это фреймворк. React+Flux вполне себе фреймворк. Рассматривать React отдельно от Flux не имеет смысла, как и делить его на более мелкие части.
>>Правда, остается непонятным, зачем вообще React было включать в этот обзор.
Читаете только то, что нравится?
>>В принципе, когда вы добавите к нему фейсбучный flux, он уже может считаться фреймворком.
>>Это ведь уже не сам React, а сторонняя библиотека.
Это то, что приходиться использовать при росте приложения на React, как и Flux, который тоже не React. Это демагогия. Разговор об удобстве и адекватном сравнении, которого в статье нет.
Субъективно jsx хорошо продуман и автор не понимает React записав jsx в против, что свойственно всем новичкам. jsx — за! До момента его использования я написал аж 3 минифреймворка для работы с DOM, с навешиванием и обработкой событий аля mvc. Благо хватило ума спохватиться и не пилить очередной велосипед. React вполне себе фреймворк.
В jsx очень мало отличий для валидности, зато много вкусных плюшек ;)
Лично у меня сложности возникли при применении роутера, не столько в его работе, сколько в подходе. Нужна была специфическая реализация.
А спрайты разве не устарели? Много возни, а экономия на спичках.
base64 проще при сборке проекта и не нужно сидеть и тыркаться с размерами и позиционированием. Сам недавно заметил, что спрайты неудобны и муторны и чем больше нужно в них запихать, тем тяжелей становится с ними работать. Профит пропадает напрочь.
>> сборка дольше 3 секунд
Вот по этой причине я и пришел к выводу, что прекомпиляция по частям и нормальные компьютеры спасут мир. Болтовня про скорость — чушь! Я таких разговоров ещё 10 лет назад наслушался. Прошло 10 лет, частота процессоров выросла на тысячи, появились SSD, а разговоры не изменились. Прямо маркетинговые лозунги — мой инструмент умеет быстро*.
На первом месте стоят возможности инструментов, скорость только на втором. Попробуйте SSD, может вам полегчает.
>>Не дай бог ты задал повторный вопрос
Зачем задавать повторный вопрос, если на первый не ответили? Чтобы быть посланным? Думаете вам кто-то должен? Хотите поговорить об этом?
>>так сразу наживаешь себе врагов
Вас нужно любить за то, что вы задаете много одинаковых вопросов?
Хм, однако. Ну как желаете.
Вас нужно любить за то, что вы задаете много одинаковых вопросов? Зачем задавать повторный вопрос, если на первый не ответили? Чтобы быть посланным? Думаете вам кто-то должен? Хотите поговорить об этом?
>>пока я буду переводить основной проект с тысячами файлов на webpack пройдут недели
Не знаю почему, но вам видней. Расскажите в чем проблема? webpack.github.io/docs/comparison.html
>>насколько быстро он успевает все подхватить и перестроить для средних размеров проекта? Для меня важно, чтобы инструмент успевал отработать за то время, пока я переключаюсь из редактора в браузер и пока обновляется страница.
У меня успевает, нареканий не было, проект большой и растет, но не вижу смысла обсуждать скорость webpack.
Любой инструмент упрется в скорость при росте проекта. Поэтому всегда использую вотчеры, которые сильно ускоряют процесс сборки. Считаю это оптимальным решением.
Как можно обсуждать скорость, не зная мощности компьютера, других инструментов, технологий и т.д. Абстрактные кони в вакууме и то нагляднее.
Вы же понимаете, что пока не попробуете сами ничего не узнаете наверняка?!
Если вы не хотите использовать watcher-ы, то это ваши проблемы. Можете не использовать.
Можно компилировать наживую, через watcher-ы, через watcher wabpack или запускать webpack для сборки. Как настроите так и будет.
Я совсем не использую requirejs т.к. это устаревшая технология, уже можно использовать es6 и es6 модули. Если проект новый и нет предрассудков и каких-то страхов, то зачем использовать устаревшие инструменты, когда есть современные?
>>Всё и сразу пока не работает.
Убило наповал. Зачем статья?
Зачем тащить было в проект Backbone и requirejs? Обоснование отсутствует. Вы не понимаете Flux, поэтому притащили в проект Backbone? Или в нем есть необходимость, потому что Flux не устраивает этим и этим?
React + Flux + 6to5 + webpack избавляет от прошлого века requirejs.
Фига себе прозрачность в контроллерах Backbone находятся компоненты React.
//language
import lang from '../../lang/init';
var langComment = lang.comment;
далее использование
langComment.firstName содержит 'Имя:'
Субъективно jsx хорошо продуман и автор не понимает React записав jsx в против
а не с
>>Я так понимаю вы сравниваете методом «у кого больше»?
Я не стану продолжать, вы видите только то, что вам нравится.
>>Поделитесь с общественностью, пожалуйста.
Создаются файлы начиная с ru_RU.js, с объектом внутри. В программе лишь ссылки. Далее дело только за переключением на нужный объект по событию. Что может быть сложного в создании файла на язык или переключателе на 2 строки?
Мне не нужны:
— чужое представление какими должны быть Формы (в т.ч. валидация),
— ваше представление о моделях данных,
— шаблонизация мне совершенно не сдалась т.к. React предоставляет удобное расширение и повторное использование компонентов.
— Интернационализация делается удивительно простым способом.
Вы пытаетесь навязать мне свою точку зрения совершенно напрасно. Аргументы настолько незначительны, что даже не стоят обсуждения. Предлагаю закончить холивар в силу отсутствия желания понимать друг друга у оппонентов.
Я так понимаю вы сравниваете методом «у кого больше»? Можно тогда просто сравнить в кб-мб.
>>Ок, React это V, Flux это C, а что тогда использовать как M?
Store не?
Ваше право использовать React как слой.
Lots of people use React as the V in MVC
Моё право использовать React как фреймворк. Если код используется как каркас, то это фреймворк. React+Flux вполне себе фреймворк. Рассматривать React отдельно от Flux не имеет смысла, как и делить его на более мелкие части.
>>Правда, остается непонятным, зачем вообще React было включать в этот обзор.
Читаете только то, что нравится?
>>В принципе, когда вы добавите к нему фейсбучный flux, он уже может считаться фреймворком.
Это то, что приходиться использовать при росте приложения на React, как и Flux, который тоже не React. Это демагогия. Разговор об удобстве и адекватном сравнении, которого в статье нет.
В jsx очень мало отличий для валидности, зато много вкусных плюшек ;)
Лично у меня сложности возникли при применении роутера, не столько в его работе, сколько в подходе. Нужна была специфическая реализация.
base64 проще при сборке проекта и не нужно сидеть и тыркаться с размерами и позиционированием. Сам недавно заметил, что спрайты неудобны и муторны и чем больше нужно в них запихать, тем тяжелей становится с ними работать. Профит пропадает напрочь.
Отказался.
Вот по этой причине я и пришел к выводу, что прекомпиляция по частям и нормальные компьютеры спасут мир. Болтовня про скорость — чушь! Я таких разговоров ещё 10 лет назад наслушался. Прошло 10 лет, частота процессоров выросла на тысячи, появились SSD, а разговоры не изменились. Прямо маркетинговые лозунги — мой инструмент умеет быстро*.
На первом месте стоят возможности инструментов, скорость только на втором. Попробуйте SSD, может вам полегчает.
*, зато не имеет ещё 100500 нужных возможностей.
Зачем задавать повторный вопрос, если на первый не ответили? Чтобы быть посланным? Думаете вам кто-то должен? Хотите поговорить об этом?
>>так сразу наживаешь себе врагов
Вас нужно любить за то, что вы задаете много одинаковых вопросов?
Хм, однако. Ну как желаете.
Вас нужно любить за то, что вы задаете много одинаковых вопросов? Зачем задавать повторный вопрос, если на первый не ответили? Чтобы быть посланным? Думаете вам кто-то должен? Хотите поговорить об этом?
Не знаю почему, но вам видней. Расскажите в чем проблема?
webpack.github.io/docs/comparison.html
У меня успевает, нареканий не было, проект большой и растет, но не вижу смысла обсуждать скорость webpack.
Любой инструмент упрется в скорость при росте проекта. Поэтому всегда использую вотчеры, которые сильно ускоряют процесс сборки. Считаю это оптимальным решением.
Как можно обсуждать скорость, не зная мощности компьютера, других инструментов, технологий и т.д. Абстрактные кони в вакууме и то нагляднее.
Вы же понимаете, что пока не попробуете сами ничего не узнаете наверняка?!
Можно компилировать наживую, через watcher-ы, через watcher wabpack или запускать webpack для сборки. Как настроите так и будет.
Я совсем не использую requirejs т.к. это устаревшая технология, уже можно использовать es6 и es6 модули. Если проект новый и нет предрассудков и каких-то страхов, то зачем использовать устаревшие инструменты, когда есть современные?
Убило наповал. Зачем статья?
Зачем тащить было в проект Backbone и requirejs? Обоснование отсутствует. Вы не понимаете Flux, поэтому притащили в проект Backbone? Или в нем есть необходимость, потому что Flux не устраивает этим и этим?
React + Flux + 6to5 + webpack избавляет от прошлого века requirejs.
Фига себе прозрачность в контроллерах Backbone находятся компоненты React.