Jump to content

Почему мы до сих пор не используем React.JS по умолчанию?


abrahadabra
 Share

Recommended Posts

Ладно, пусть не react, а angular или ещё какой фреймворк, кому какой больше нравится. Но суть от этого не меняется.

Ведь насколько проще было бы разрабатывать, насколько качественнее результат бы получался.

 

Мысль посетила по мотивам недавно выполненного проекта. Вроде как обычный лэндинг, ничего особенного. Несколько форм для обратной связи, и всё. Но было пожелание со стороны заказчика задействовать более традиционные решения, поскольку что-то новое и прогрессивное программист-бэкендщик может не знать.

И даже на этом проекте посещали странные мысли.

 

Вот примеры задач:

  • Форма обратной связи. На странице форма из трёх полей, но по нажатию на кнопку открывается всплывашка, а там ещё несколько. И это надо отослать на сервер. Аяксом, разумеется;
  • Среди прочего в форме выбор интервала дат;
  • а также динамические поля, которые создаются/удаляются нажатием на кнопку;
  • разумеется, формам требуется валидация;
  • разумеется, некоторые элементы формы имеют кастомное оформление. Селекты, чекбоксы всякие;
  • а ещё кастомно оформленное поле количества. С кнопочками, увеличивающими/уменьшающими значение. И у него тоже валидация;
  • форма в несколько шагов. От текущего шага зависит контент основной области, набор кнопок внизу, шкала прогресса;
  • меню со скроллингом по странице;
  • и это меню прибивается к верху, как только страница докручивается до такого положения, что меню касается верхнего края окна;
  • слайдеры всякие, вкладки.

В общем, всё достаточно обычно. Но в итоге получился довольно объёмный скрипт. Получилось подключение чуть ли не десятка jquery-плагинов, каждый из которых работает по своему. А наладить взаимодействие этих плагинов — отдельная песня.

 

В случае же использования того же реакта получилось бы куда более стройно.

Скрипт был бы ровно один. Каждый компонент содержал бы в себе свой функционал, а с другими взаимодействовал бы через api.

 

К примеру:

$("body").on("click", ".number_field .action_button", function(){            var $numberField = $(this).closest(".number_field"),                $input = $numberField.find(".value"),                value = parseInt($input.val());            if(isNaN(value) || value < 1) value = 1;            if($(this).hasClass("increase")){                value++;                $input.val(value);            }            if($(this).hasClass("decrease")){                value--;                if(value > 0) $input.val(value);            }        })

это же, откровенно говоря, жесть.

Когда можно в коде писать:

<NumberField value={form.some} min=1 />

… а все детали реализации внутри компонента.

 

а вот это:

    function getTourSetStep(stepNumber) {        var stepIndex = stepNumber - 1,            $popupGetTourSteps = $("#popup_get_tour_steps"),            $popupGetTourContent = $("#popup_get_tour_content"),            $popupGetTourButtons = $("#popup_get_tour_buttons")            ;        $popupGetTourSteps.find(".step").removeClass("active");        $popupGetTourSteps.find(".step:lt("+stepNumber+")").addClass("active");        $popupGetTourContent.find(".step:lt("+stepIndex+")").removeClass("active").addClass("completed");        $popupGetTourContent.find(".step:eq("+stepIndex+")").addClass("active").removeClass("completed");        $popupGetTourContent.find(".step:gt("+stepIndex+")").removeClass("active completed");        $popupGetTourButtons.find(".step:lt("+stepIndex+")").removeClass("active").addClass("completed");        $popupGetTourButtons.find(".step:eq("+stepIndex+")").addClass("active").removeClass("completed");        $popupGetTourButtons.find(".step:gt("+stepIndex+")").removeClass("active completed");    }

— это же лютый трэш.

Ведь можно

<div className={classnames('part', {'active': $index==currenrStep, 'completed': $index < currentStep})}>…</div>

а вот:

    function setMainMenuPosition() {        var scrollTop = $(window).scrollTop();        if(scrollTop >= mainMenuDefaultPos) {            if(!mainMenuFixed){                $mainMenu.addClass("fixed");                mainMenuFixed = true;            }        } else {            if(mainMenuFixed){                $mainMenu.removeClass("fixed");                mainMenuFixed = false;            }        }    }

— приходится вводить глобальную переменную, чтобы не обращаться лишний раз к DOM, а не то тормозить начнёт.

Но в том же реакте это автоматизировано, и о такой рутине можно вообще не задумываться.

 

 

Может я чего не понимаю в жизни?

Почему так?

При всех очевидных плюсах современных фреймворков до сих пор продолжаем пользоваться тем, что хорошо разве что для того, чтобы один слайдер прикрутить.

Что с нами?

  • Like 1
Link to comment
Share on other sites

Вы сами ответили на вопрос - 

 

Но было пожелание со стороны заказчика задействовать более традиционные решения, поскольку что-то новое и прогрессивное программист-бэкендщик может не знать.

Это относится к большинству заказчиком СНГ региона.

Link to comment
Share on other sites

да как бы не совсем всё так.

Во-первых, это было несколько непривычно, поскольку такого рода пожелания со стороны заказчика на самом деле довольно редко встречаются. Обычно технологии отдаются полностью на откуп исполнителю. То есть, важен результат, а как его добьёшься, заказчика не волнует. Но тут заказчик немного необычный. Это не конечный заказчик, а студия, отдавшая фронтэнд на субподряд.

А во-вторых заказчики если называют конкретные технологии, то ведь именно те, которые на слуху, которые популярны и часто используются. Так что от нас самих многое зависит.

Link to comment
Share on other sites

привычные (традиционные) библиотеки проще в обслуживании, значит меньше затраты. Это же очевидно. Попробуйте найти фронтенд-программиста на ЗП тысяч 20-25, а оптом еще загрузить его работой, что на мелком проекте у вас не получится. А вот тот же jQuery даже многие контент-менеджеры знают и брать программиста даже не требуется, тем более если проект это лендинг с двумя формами.

 

Вот если проект большой, там берут и используют то о чём вы говорите. Хотя даже там зачастую тоже не пытаются экспериментировать, а решают поставленные задачи с помощью тех средств которые давно себя зарекомендовали.

Link to comment
Share on other sites

Так ведь тот же реакт тоже давно себя зарекомендовал. Или ангуляр (ничуть его не умаляю, просто его толком не знаю).

 

А вот про фронтэндщика на 25тыщ не совсем понятно. И зачем контент-менеджеру jQuery — тоже не совсем ясно.

Да и одно другого ведь не исключает. Если уж прям действительно надо контент-менеджеру воткнуть скрипт на jQuery в текст статьи, то если сайт на реакте, делается это точно так же, как и на сайте без оного. Непонятно только зачем.

Речь в первую очередь не об этом, а о процессе разработки.

Link to comment
Share on other sites

не стоит равняться на веб-студии и крупные компании (у которых зачастую все очень плохо с кадрами). Взять среднестатистическое ООО, вы там не найдете фронтендщиков на 20-25к вот о чем я говорю, jquery проста для понимания и по скорости освоения, плюс со знанием именно её найти кадры проще, хотя в тех же ООО никто вообще в принципе не понимает что это и чем отличается, вопрос в том что мастера-фронтендщики их вакансии даже не смотрят. Не ужели не ясно. А большая часть сайтов в рунете обслуживается как раз веб-мастерами в таких вот ООО.

Link to comment
Share on other sites

jquery проста для понимания и по скорости освоения

спору нет. Можно за несколько минут освоить, как прикрутить слайдер. Но дальше-то что?

 

У дизайнеров, да и у заказчиков уже, стала за норму всякая интерактивность на странице. В каталогах фильтры, работающие без перезагрузки страницы. Те же формы становятся довольно сложными, и это уже за норму. Скрипт в несколько сотен строк для лэндинга вообще никого не удивляет, так ведь?

 

А тем временем jQuery дико бороздит DOM, проверяются условия наличия классов или дата-атрибутов у элементов. Сами данные где попало, взаимодействие — как ЛММ на душу положит. Это же самому разработчику неудобно, я об этом. И ладно бы за это неудобство платили огромные деньги. Так ведь именно что большие деньги за нашу работу в принципе не особо часто платят.

Link to comment
Share on other sites

 Ну так в приведённых тобой примерах jQuery ничего полезного кроме делегирования не делает. С таким же успехом можно было всё написать на пьюр  JS /

 

 

 

Каждый компонент содержал бы в себе свой функционал

  

 

 А компонентный подход на jQ ?

Edited by andrey7287
Link to comment
Share on other sites

Ну так в приведённых тобой примерах jQuery ничего полезного кроме делегирования не делает. С таким же успехом можно было всё написать на пьюр  JS /

Можно. Но смысл? В случае pure js то же самое: либо архитектуру выстраивать своими руками под проект, что в большинстве случаев не оправдывается никак и ничем, либо будет непотребная каша из кода.

Я же о том, что вместо этого можно брать фреймворк и выкидывать головную боль. Использовать архитектуру, разработанную умными людьми. 

 

 

А компонентный подход на jQ ?

а подробнее?

Link to comment
Share on other sites

Я же о том, что вместо этого можно брать фреймворк и выкидывать головную боль. Использовать архитектуру, разработанную умными людьми.

 

Система плагинов в jQuery по сути и образует компонентную архитектуру, код каждого плагина находится в конкретном месте. Чем это хуже компонента о котором ты говорил?

Link to comment
Share on other sites

вообще-то всем.

Попробую ещё раз. Что-то плохо у меня пока получается мысль донести видимо :(

 

Во-первых, есть колоссальная разница между декларативным и императивным стилем.

В случае jquery-лапши мы каждый раз напрямую в лоб пишем обработчики на всё-всё-всё. Там изменить класс у DOM-элемента, там изменить сортировку элементов в списке, там изменить список значений в селекте, и всё это не забыть.

А можно всё это прописывать в состояниях, и каждый элемент, зависящий от состояния, логику содержит в себе. Да и та чаще описывается декларативно.

Во-вторых, сама идея отделения данных от представления. Это же идея хорошая и правильная.

Link to comment
Share on other sites

На самом деле это бессмысленный разговор, и на вопрос

 

Почему мы до сих пор не используем React.JS по умолчанию?

 

Я лично отвечу так:

 

Потому-что мы все носим одежду от разных изготовителей, едим разную еду, ездим на разных марках автомобилей и т.д.

 

Я лично не хочу есть постоянно одну овсянку только потому что она кому-то очень нравится =)

Link to comment
Share on other sites

 

… только потому что … кому-то очень нравится =)

чушь ведь. Именно об этом первое предложение заглавного поста. Вы же его прочитали, не так ли?

 

конечно прочел. Но в моем последнем сообщении под "кому-то" подразумевается не заказчик или работодатель (их хотелки всегда приоритетны).

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

 Share

×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue. See more about our Guidelines and Privacy Policy