@martin_eden_msk

Объясните, плиз зачем нужен react и vue?

Несколько раз пытался разобраться и понять, зачем нужен реакт и вуи.
Но начиная изучать документацию, я начинаю нервничать.
Сам кодер PHP, знаю html, css jquery.
вот объясните плиз, зачем реакт или вуи?
Если мне надо вывести hello world на странице, пусть даже динамически заменяя заголовок.
<h1>this is it</h1>
Зачем весь этот лишний код в десятки строк? если на том же jquery можно заголовок вывести как$('h1').text('hello world');
и еще в продолжении часть вопроса. как я вижу, большинство сайтов на реакте или вуи, нельзя открыть вне браузера.
т.е. get запрос вернет что-то, но не сайт. какой толк тогда от этой всей технологии?
  • Вопрос задан
  • 601 просмотр
Решения вопроса 1
Kozack
@Kozack Куратор тега Vue.js
Thinking about a11y
Уже задавали этот вопрос не раз и не два. Правильный ответ один: если вы не понимаете зачем это вам нужно, значит оно вам и не нужно.

Инструменты создаются, чтобы решать определённые проблемы. Если вы с этими проблемами не сталкивались, то и понять смысла инструментов не сможете.

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

UPD:
вопрос был о практической легкости внесения изменений.


martin_eden_msk, Вот, набросал простенькую демку:


Поклацайте, попробуйте повносить изменения.

Обратите, внимание, здесь нет ни файлов-шаблонов, ни jsx, ни препроцессоров, ни webpack, ни чего-то ещё. Этот код можно просто вставить в любой документ, хоть в сайт на php и он будет работать.

Я даже больше скажу, многие воспринимают Vue, как маленький, простенький фреймворк, для написания таких вот сложных виджетов, которые потом будут интегрированы в сайт написанный на чем-то ещё.
Ответ написан
Пригласить эксперта
Ответы на вопрос 7
yarkov
@yarkov Куратор тега Vue.js
Проект "Жизнь после смерти" - lifeafterdeath.ru
Ну раз вам проще сделать $('h1').text('hello world') чем this.title = 'hello world', то продолжайте манипулировать DOM-ом. Вы пока не доросли до фронтенд фреймворков.
Ответ написан
zoonman
@zoonman
CEO @ LinuxQuestions.ru
Когда-то я писал на PHP. Писал много. Сначала это было месиво из кода на PHP и HTML, потом появились всякие шаблонизаторы, стало чуть чище.
Проекты росли, кода становилось все больше и хотелось некоторые кусочки переиспользовать. Так я пришел к управлению кодом через Composer.
На каком-то этапе разработки я столкнулся с тем, что у меня было 2 разных веб-интерфейса делающих одно и то же. Вдобавок нужно было часть данных отдавать в систему логистики. Причем это должно было быть автоматизировано. Тогда я уже знал, что есть такая штука - автоматизированные программные интерфейсы (API).
Наскоро было что-то написано и оно заработало. По итогу, оба веб-интерфейса и система логистики использовали одни и теже функции. Но поддерживать 2 разных интерфейса было очень геморно. В те времены был jQuery самым главным. Очень сложно было добиться правильного отображения, посколько Javascript код был в перемешку с HTML, часть которого генерировалась из PHP. Возникали ошибки. Данных было много, разных скриптов было много (сотни), части скриптов были копиями друг друга с небольшими отклонениями. По итогу, на решение простых задач вроде редактирования строчки в таблице с обновлением на сервере уходило много времени, дни, иногда даже недели.
Потом я увидел Mustache.js, это был предок Ангуляра и Реакта. Что-то вроде шаблонизатора, но только на стороне клиента. Работало оно только в одну сторону, отображало данные в HTML, но потом была та же жесть из jQuery.
Затем я познакомился с Angular1. Идея была простая - пишешь шаблон, подставляешь в него данных. Оно отображается, само! Никаких тебе извращений, найди класс или идентификатор, или еще какая-нибудь ерунда.
Кодить стало проще. Стало можно создавать библиотеки компонентов и просто редактировать стили. Можно было сделать компонент для ввода и проверки почты, и использовать его сразу во всех проектах и исправлять ошибки в одном месте, а не бегать по сотням скриптов и искать в каждом этот повторяющийся косяк.
Поначалу я тоже относился к Ангуляру с предубеждением, столько траблов, стоят ли они того. Но как только я стал чаще сталкиваться с задачами, когда мне понадобились разные интерфейсы для отображения одних и тех же данных, это стало сходить на нет.
Пока вы пилите простые штуки, всякие фреймворки вам не втарахтели. Даже jQuery не нужен. Но иногда начинается жопа, когда одному уже проект не вытащить, ибо охеренеть, как сложно, а еще и делать надо быстро. Поэтому лучше разделиться, кто-то делает бэкенд, кто-то фронт. Так просто удобнее, а общаться через API. Вначале вы вместе просто пишите спецификацию для API, это занимает день или два. А потом вы бомбите месяц в параллель. Причем фишка такого подхода в том, что есть инструменты, которые просто выдают заглушки для кода на фронте. Т.е. если фронт пишется быстрее, то его проще тестить и все такое. Аналогично с бэкендом. Его тоже можно тестить даже если фронт не готов. Причем эти все фишки особенно круты, когда вас не двое, а например 20, да и живете вы по всему миру в разных часовых поясах и т.д.
Ответ написан
Ответ на вопрос "почему" заключается в одной емкой фразе: потому что сложно синхронизировать интерфейс и состояние.

Представьте, что у вас есть простой UI какого-нибудь ToDoApp. Вам всего-то нужно сделать так, чтобы при вводе новой задачи она появлялась в списке, а при нажатии на крестик напротив удалялась бы. Проще простого!

Но когда начнете решать проблему на нативном JS или на б-гомерзком jQuery, вы столкнетесь с необходимостью писать очень много шаблонного кода. Прежде всего на обслуживание DOM. Найти элемент, вставить элемент, добавить элементу класс, атрибут... в итоге у вас получится портянка на десятки строк для такой элементарной задачи, а ведь мы еще не добавили много кульных штук, без которых ToDoApp совсем не ToDoApp, как-то: возможность создавать разные списки, расписания, галочка, чтобы зачеркивать задачу и т.п. С реализацией всего этого ваша простыня будет расти, вы будете в ней путаться.

На этом этапе вы можете начать велосипедить. Писать какие-то утилиты для работы с DOM. Разделите index.js на несколько файлов, сообразно DDD или хотя бы единой ответственности. Допустим даже, что вашим приложением внезапно стали пользоваться, у вас куча бизнес-идей. Вы начинаете наваливать фичи, структура становится все запутаннее, кода становится все больше, а еще приложение начинает тормозить. Вы проводите небольшой анализ и понимаете, что проблема в излишне частом обращении к DOM - вы дергаете его на каждый чих, ведь с jquery это так просто! И что делать? Писать еще один велосипед, чтобы обновлять DOM пакетно? А как отслеживать изменения в данных с сервера? Это ж сколько работы!

К счастью, все вышеописанное, и даже гораздо больше, уже решено в Google, Facebook, а также некоторыми талантливыми энтузиастами. И у нас есть Angular, Vue, React, Svelte, которые предлагают вам возможность создавать быстрые, поддерживаемые приложения с минимумом шаблонного кода и продуманной архитектурой.
Ответ написан
approximate_solution
@approximate_solution
JS Developer. Angular\React\Vue\Ember
Сам кодер PHP

Кодер PHP не мог бы задать такой вопрос, ИМХО. Скорее всего вы говнокодер на PHP, т.к у PHP тоже есть фреймворки, и если вы умеете в PHP, то должны быть наслышано по YII2, Laravel, Symfony и тд. И примерно должны понимать для чего люди разрабатывают фреймворки, и какие проблемы фреймворки и их модули решают.

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

То же самое применимо и к JS фреймфоркам, т.е в нем уже есть готовые инструменты для разработки.
5f83ef095d0c4903243659.png
Ответ написан
dimonchik2013
@dimonchik2013
...а ну-ка пыль сдуй отсюда...
скорость

переучивайся в сеошники, о*еешь как в Гугле летят сайты на таком
правильные сайты, конечно

один раз код загрузил и дальше обмен по АПИ - да со сжатием - моментальный
Ответ написан
kirbi1996
@kirbi1996
Могу сказать про реакт
Нет перезагрузок страниц
Быстрее работает
Удобный компонентный подход
Легко поддерживать
Ответ написан
tundramani
@tundramani
на самом деле это нужно в первую очередь для стандартизации разработки
для любого капиталиста одинаково важно независеть от работников - для этого они должны работать в одном шаблоне

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

и это похоже на секту и религию айтишную - эти люди внушают себе и другим что такие инструменты облегчают жизнь

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

выбирай - или работаешь так как тебе удобно
или страдаешь как все и принимаешь эту веру, и веришь в то что это облегчает работу и в этом счастье

на самом деле в айти царит безумие и неэффективность - на хабре полно статей об этом
главное деньги - поэтому всё так плохо

пойми - главное в капитализме это выжимание денег из людей
для этого все рабы должны веровать в it-религию и быть стандартными и работать в одном стандартном неудобном сложном инструменте
и поэтому тебя зачморят фанатики и сожгут на костре если ты будешь говорить что это неэффективно сложно и безумно
Ответ написан
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы