Хабр Курсы для всех
РЕКЛАМА
Большая витрина: от крупнейших школ до частных авторов. Сравнивайте по цене, длительности, формату и выбирайте самый подходящий курс!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 14
Началось за здравие… Кончилось за реакт… Очень надеюсь, что светлое будущее наступит с vue или svelte…
Большое человеческое спасибо за статью. Если хоть еще один человек в мире что-то узнает об MVC и о том, что не надо всё запихивать в компоненты — мир уже станет лучше.
>> не надо всё запихивать в компоненты
А у JS-фанов нет выбора. Компоненты в других языках программирования давно и прочно стали эффективным способом понижения сложности. И вот этот общепризнанный подход в его весьма скромной части нашёл путь в мир JS. В результате понижать сложность захотелось с помощью тех инструментов, которые показали JS-кодерам, как можно писать программы гораздо проще. Ну и далее пошло по стандартному пути — теперь у нас есть молоток, значит мы можем забить даже ломик в совершенно неподходящее для него отверстие! И не беда, что долго, сложно, неудобно, ведь главное — у нас есть молоток!
В целом в мире JS нет инструментов с вменяемой гибкостью. Гибкость же даётся не за красивые глаза (броскую рекламу), а за изучение более зрелых языков и способов разработки. И пока сообщество JS будет продолжать игнорировать давно существующий опыт, он так и будет забивать своим молотком тот самый неудобный ломик. Просто потому, что ломик в проекте должен быть, а из способов его включения в проект — лишь молоток.
Альтернативный путь сложен — надо изучать другие языки и их экосистему. В итоге можно будет использовать, например, GWT, дающую возможность очень гибко моделировать реальность при помощи гораздо более подходящего для этого языка и с использованием всех накопленных для этого языка архитектурных подходов. Но да, при этом нужно уходить от привычного JS и учить что-то новое…
А у JS-фанов нет выбора. Компоненты в других языках программирования давно и прочно стали эффективным способом понижения сложности. И вот этот общепризнанный подход в его весьма скромной части нашёл путь в мир JS. В результате понижать сложность захотелось с помощью тех инструментов, которые показали JS-кодерам, как можно писать программы гораздо проще. Ну и далее пошло по стандартному пути — теперь у нас есть молоток, значит мы можем забить даже ломик в совершенно неподходящее для него отверстие! И не беда, что долго, сложно, неудобно, ведь главное — у нас есть молоток!
В целом в мире JS нет инструментов с вменяемой гибкостью. Гибкость же даётся не за красивые глаза (броскую рекламу), а за изучение более зрелых языков и способов разработки. И пока сообщество JS будет продолжать игнорировать давно существующий опыт, он так и будет забивать своим молотком тот самый неудобный ломик. Просто потому, что ломик в проекте должен быть, а из способов его включения в проект — лишь молоток.
Альтернативный путь сложен — надо изучать другие языки и их экосистему. В итоге можно будет использовать, например, GWT, дающую возможность очень гибко моделировать реальность при помощи гораздо более подходящего для этого языка и с использованием всех накопленных для этого языка архитектурных подходов. Но да, при этом нужно уходить от привычного JS и учить что-то новое…
А у JS-фанов нет выбора.
Вы немного не о том. «Выбор» в огромном количестве случаев нафиг никому не сдался, интерфейсы писать — это не rocket science и банальный квадратно-гнездовой ООП с этим прекрасно справляется.
Под «компонентами» нынче мало кто понимает компоненты в широком смысле слова, а гораздо чаще — в самом что ни на есть конкретном понимании: что вот этот class MyGreatApp extends React.Component — вот это и есть компонент.
Лично я, например, в гробу видел этот ваш GWT или еще более другие языки вместе с их экосистемами: от того, что какой-нибудь фронтэндщик возомнит себя звездой и начнёт писать интерфейсы с переподвывертом, обычно только лишь появляется много боли для других программистов (которым это разгребать) и очередное легаси, в которое никто даже палкой тыкать не хочет.
Речь тут о том, что используя какой-то подход (объектный, компонентный, что угодно) — надо его использовать. А не читать какой-нибудь туториал о том, как сделать to do list, а потом пытаться точно так же писать код в проекте на десятки тысяч строк.
Компоненты в других языках программирования давно и прочно стали эффективным способом понижения сложностиМне интересно — в каких? Я пока-что не слышал, чтобы компоненты за пределами геймдева были общепризнанным подходом.
Частный случай компонентов — классы. Но в более общем (и часто используемом) виде это набор классов, слабо связанных с другими наборами. Слабость связи обычно реализуется на интерфейсах (чего нет в JS), а за интерфейсом может стоять тот самый набор классов, ничего не знающий о других наборах, то есть явно выделенный компонент, хоть и разбитый на несколько классов.
Мда, видимо компонентный подход за пределы геймдева все еще не вышел в том виде, в котором он там(
Там компонент — это небольшой объект с данными или функционалом, который в любое время можно добавить в список объекта-контейнера, либо удалить из него. Комбинирую компоненты в объекте-контейнере, получаем нужный итоговый объект. При таком подходе и интерфейсы в большинстве случаев излишни. Без них получается слабая связь.
Компоненты на миксины в старом react похожи, только не мержатся с объектом-контейнером, а являются самостоятельными объектами. Да и в объекте-контейнере нет логики в отличие от компонентов react.
Там компонент — это небольшой объект с данными или функционалом, который в любое время можно добавить в список объекта-контейнера, либо удалить из него. Комбинирую компоненты в объекте-контейнере, получаем нужный итоговый объект. При таком подходе и интерфейсы в большинстве случаев излишни. Без них получается слабая связь.
Компоненты на миксины в старом react похожи, только не мержатся с объектом-контейнером, а являются самостоятельными объектами. Да и в объекте-контейнере нет логики в отличие от компонентов react.
>> небольшой объект с данными или функционалом, который в любое время можно добавить в список объекта-контейнера
В куче языков именно так можно работать с простыми классами или структурами. Просто кидаем их в список и получаем то, что вы называете «компонентный подход». Но это всего лишь один из способов использования классов/структур.
В куче языков именно так можно работать с простыми классами или структурами. Просто кидаем их в список и получаем то, что вы называете «компонентный подход». Но это всего лишь один из способов использования классов/структур.
>>> не надо всё запихивать в компоненты
>> А у JS-фанов нет выбора.
У JS-фанов компонент — это View. У них своя терминология и ветвь эволюции с неизвестными корнями. То что десятилетиями было очевидно в зрелых языках, они осознают только сейчас.
>> А у JS-фанов нет выбора.
У JS-фанов компонент — это View. У них своя терминология и ветвь эволюции с неизвестными корнями. То что десятилетиями было очевидно в зрелых языках, они осознают только сейчас.
В целом в мире JS нет инструментов с вменяемой гибкостью.
Есть.
GWT, дающую возможность очень гибко моделировать реальность при помощи гораздо более подходящего для этого языка
Речь о Java? И чем же она более подходящая?
А с какими типами архитектур вы ещё работали, кроме Backbone и React/Redux?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Архитектура веб-интерфейсов: деревянное прошлое, странное настоящее и светлое будущее