Усі статті, обговорення, новини про Front-end — в одному місці. Підписуйтеся на телеграм-канал!
Доброго времени суток, уважаемые форумчане.
Хочу спросить старожилов IT. Какова вероятность, что для небольших веб-приложений классические языки ООП (Java, C#) превратятся в слой DAO ввиду появления всяких там Ангуляров 2/4?
Если речь идет о небольших приложениях (условно CRUD), то там backend уже давно превратился в то, что вы называете слоем DAO.
Для больших и сложных enterprise-приложений такой тенденции нет и не может быть. То, что SPA на себя перетянули часть функционала — это отдельное ограниченное в масштабах движение. Во-первых, на фронтенд ушла только логика отображения, которую более удобно и логично держать как раз на фронтенде. Во-вторых, backend стал менее обременен малосвойственной ему задачей.
Дальше переносить бизнес-логику на фронтенд нет смысла. Причин много. Например, мы этим ничего не добиваемся — приложение в браузере станет работать медленнее, количество запросов не уменьшится... это к вашему утверждению
Наличие логики на фронте позволяет в разы уменьшить количество рест запросов
только вместо бизнес-объектов будут передаваться «сырые» данные. На backend вам нужно оставлять сложную авторизацию, с иерархией ролей — а это требует близости к той части бизнес-логики, которая связанна с пользователями. Следующее — валидация, которую можно и нужно дублировать на фронтенде, но нельзя убрать с backend — она тоже требует близости всей доменной области, которую нужно валидировать. Далее огромная часть приложения, которая не связанна с контекстом пользователя. Например, нужно по крону что-то синхронизировать или проверять, интеграции со сторонними сервисами, да куча еще всего, из чего состоят современные приложения — это в принципе никак нельзя вывести с backend. Не забываем про тяжелые вычисления.
На последок не нужно забывать про безопасность. Делать всю бизнес-логику доступной для анализа — не самое лучшее решение для бизнеса. Например, на основе некоторых данных нужно строить рейтинг или статус посетителя. Пока это на backend — оно закрыто.
Короче, нет никаких предпосылок опасаться, что интересное вам проектирование и object oriented design будут ущемлены развивающимся фронтендом — эти два мира совсем никак не связанны.
Я бы сказал, что «угроза» раздутому ООП идет со стороны микросервисной архитектуры и «простых» языков, типа Go. Сложные архитектуры и объектный дизайн — это из мира больших монолитных приложений. Микросервисы уменьшат их использование, но не знаю насколько масштабно.
Не должно быть нигде никакой логики. Ни на бекенде, и на фронтенде. Логика — это грубая сила мужчины-угнетателя. Вместо логики нужно переходить к женственной чувственности, к эмоциям. Код должен любить, страдать, жаждить, пылать страстью, заниматься саморазвитием, читать Коэльё и пить розовое шампанское. Насколько мне известно, такой код умеет писать Елена Бобкина
Не должно быть нигде никакой логики. Ни на бекенде, и на фронтенде. Логика — это грубая сила мужчины-угнетателя. Вместо логики нужно переходить к женственной чувственности, к эмоциям. Код должен любить, страдать, жаждить, пылать страстью, заниматься саморазвитием, читать Коэльё и пить розовое шампанское. Насколько мне известно, такой код умеет писать Елена Бобкина
Ну есть ряд приложений, которые пытаються конкурировать с десктопными приложениями, всякие рисовалки, редакторы, составители диаграмм, упомянутое расписание, и прочее, где действительно фронт тянет в себе большую часть логики. Однако это отличаеться от того что делают в энтерпрайзах.
Spring must die. Spring убил дракона в виде J2EE, но и сам стал монстро драконом. А теперь превратился в диназавра.
Spring — это офигенный конструктор, который вывел Java на новый уровень. Сейчас это лучшая платформа для больших Java-приложений.
И если раньше, собирая приложение из библиотек, их надо было старательно обработать напильником, то теперь все заводится с полпинка. Интеграция сторонних модулей занимает не месяцы, а дни или даже часы. Это светлое будущее программирвания, наступившее сегодня.
Long live Spring!
Если б от этого конструктора потерять 2/3 деталей — ото було б щастя. А так, тащится за ним куча древнего навоза, со всем присущим ему идиотизмом, который надо знать и помнить где грабли.
Не используйте Spring Boot вот и все. Делайте просто java config и будет счастье легковесное.
Так за подобными детками франкенштейна и будущее. Они как тектонические плиты, просто медленно подминают одна другую.
Сказал человек, все время строчащий комментарии на ДОУ. Ваше мнение очень важно для нас.
Кстати, его основная проблема — то самое MVC. Сильно «он» уж под «него» заточен. А вот чтобы он-она, хрен реализуешь, приходится органы пришивать.
В отличие от дракона, он сам умеет снимать старую шкуру. А драконом стала сама Jaba которая вместо того чтобы заспонсорить Пружынку — начала разрабатывать свои похожести, без блек-джека но с трансвеститами.
— В княжеском совете, — неуверенно начал Ярре, — в Элландере, значит, говорили, что победа в этой гигантской войне важна потому, что... Что это великая война, которая положит конец всем войнам.
Шелдон Скаггс фыркнул и оплевал себе бороду пивом. Золтан Хивай зарычал во весь голос:
— Вы так думаете, господа?
Теперь пришел черед фыркнуть Деннису Кранмеру. Ярпен Зигрин хранил молчание, глядя на юношу внимательно и как бы соболезнующе.
— Сынок, — сказал он наконец очень серьезно. — Глянь. Вон там, у стойки, сидит Евангелина Парр. Она, надо признать, довольно велика. Да что там, даже огромна. Однако при всех своих размерах она, несомненно, отнюдь не такая курва, которая в состоянии перекурвить всех остальных курв.
превратятся в слой DAO
Для бизнес-приложений точно не превратятся. Да и вообще для любых приложений, где требуется безопасность (в смысле, права доступа и всё такое) или комплексная логика (изменение в одном объекте тянет за собой какие-то изменения в других). Нести бизнес-логику на фронт вообще глупость по-моему. На фронте должны быть только UI. Почему я так считаю:
— всё что работает в браузере никак не защищено от непредусмотренных манипуляций
— тяжелый клиент с кучей логики может медленно работать, и вообще скорость работы будет зависеть от того на каком ПК откроют веб-апп
— когда есть много связей между разными частями системы и объектами, на бэкэнде это проще реализовать, и намного надежнее, имхо
Этот слой DAO будет таким хитрым DAO, что даже REST :)
Кто читает данный топик, есть ли сторонники моей точки зрения ?
Давайте к нам — у нас есть печеньки!
Для небольших приложений такое возможно. А в энтерпрайзе — нулевая. Вся логика на ФЕ, которая ложится на ангуляры — логика отображения и валидации.
БЕ отвечает за совсем другие аспекты: авторизация, аутентификация, бизнес-логика, взаимодействие с другими внутренними подсистемами, преобразование бизнес-данных во вью-модель для ФЕ.
Но это не значит, что знать JS/TS/Angular/React не будет полезно бекендщикам.
Если речь идет о небольших приложениях (условно CRUD), то там backend уже давно превратился в то, что вы называете слоем DAO.
Для больших и сложных enterprise-приложений такой тенденции нет и не может быть. То, что SPA на себя перетянули часть функционала — это отдельное ограниченное в масштабах движение. Во-первых, на фронтенд ушла только логика отображения, которую более удобно и логично держать как раз на фронтенде. Во-вторых, backend стал менее обременен малосвойственной ему задачей.
Дальше переносить бизнес-логику на фронтенд нет смысла. Причин много. Например, мы этим ничего не добиваемся — приложение в браузере станет работать медленнее, количество запросов не уменьшится... это к вашему утверждению
Наличие логики на фронте позволяет в разы уменьшить количество рест запросов
только вместо бизнес-объектов будут передаваться «сырые» данные. На backend вам нужно оставлять сложную авторизацию, с иерархией ролей — а это требует близости к той части бизнес-логики, которая связанна с пользователями. Следующее — валидация, которую можно и нужно дублировать на фронтенде, но нельзя убрать с backend — она тоже требует близости всей доменной области, которую нужно валидировать. Далее огромная часть приложения, которая не связанна с контекстом пользователя. Например, нужно по крону что-то синхронизировать или проверять, интеграции со сторонними сервисами, да куча еще всего, из чего состоят современные приложения — это в принципе никак нельзя вывести с backend. Не забываем про тяжелые вычисления.
На последок не нужно забывать про безопасность. Делать всю бизнес-логику доступной для анализа — не самое лучшее решение для бизнеса. Например, на основе некоторых данных нужно строить рейтинг или статус посетителя. Пока это на backend — оно закрыто.
Короче, нет никаких предпосылок опасаться, что интересное вам проектирование и object oriented design будут ущемлены развивающимся фронтендом — эти два мира совсем никак не связанны.
Я бы сказал, что «угроза» раздутому ООП идет со стороны микросервисной архитектуры и «простых» языков, типа Go. Сложные архитектуры и объектный дизайн — это из мира больших монолитных приложений. Микросервисы уменьшат их использование, но не знаю насколько масштабно.
Все что надо скрыть — не проблема обработать на сервере, вернуть и показать json, т.е. на любом enterprise — rest — с головой хватит, и никакой ни бизнес логики на фронте ни mvc не будет, так что Angular, React, и остальное — рулит, mvc = legacy
на любом enterprise — rest — с головой хватит
Ах-ха-ха ты не видал энтерпрайза, а если так мыслишь то даже больших приложений. Ибо реста хватает на совсем простые приложения. Типичный эффект Даннинга — Крюгера.
Видел все, и enterprise и не один и mvc и кучу всего остального, не видел бы — не писал
Какие технологии используете сейчас в своей работе ?
И сколько лет проекту ?
Это тут причем? Или по вашему энтерпрайз это древний проект? ))
В большинстве своём да :)
С моим опытом в энтепрайзе? Или с энтепрайзе в общем и целом ?:)
Это тут причем? Или по вашему энтерпрайз это древний проект?
вопросы ни о чем :) интересна конкретика, или просто ответить нечего ? :)
Ни о чем это твои вопросы по поводу технологии и возраста проекта.
Скільки бачу — стільки знаю, да ? :)) Тема то как раз про технологии :)
Так REST != CRUD. Можено инициировать бизнес локику по запросам на API endpoints. POST запрос — команда и процессит соответсвующий компонент с логикой. А где рендерить html вообще пофиг. На клиенте удобнее, наверное.
Хмм, недавно реализовывал на AngularJS что то навроде школьного расписания со всеми итерациями, проверками на синхронность(наличие itemодновременно в двух местах), + полный CRUD. От Java потребовалась только itemService.save(item). Для безопааности был использован JWT. Java от всего кода занимала не более 20%
Это уровень школьных проектов, такое на java и c# редко пишут.
Посмотрим сколько java кода будет при написании CRM.
И что помешает послать post запрос с неверными данными на
itemService.save(item)
если на сервере нет аналогичных проверок? А если есть, то зачем дергать лишние данные и хранить их на стороне пользователя?
Ок, добавим на каждый item по валидатору, я больше о том, что элементарная логика MVC убегает на фронт
Сугубо мое, неквалифицированное мнение диванного аналитика, фронту просто дали возможность побаловаться с mvc, но скорее всего, это будет как формы в с#, которые тоже пытались тянуть одеяло на себя, только с другой стороны )
Это уже проходили в 90х. Есть в банках такой монстроподобный комплекс как «опердень». Чтобы понять его суть, поставь ударение. Переписывать приходилось долго и мучительно.
Вот с СRUD ты не прав. Наоборот, бэкенд станет крутиться и извиваться, становиться всё более многозвенным, чтобы не ограничитвать тебя, Ангулярщика, какими-то привязками к Spring.
Мне кажется HATEOAS является ответом на данный вопрос. На фронте не должно быть бизнес логики.
Наличие логики на фронте позволяет в разы уменьшить количество рест запросов, а иначе на изменение каждой запятой придется апелировать к серверу.
И это нормально. А наличие логики на фронте снижает безопасность приложения до нуля.
Ни в коем случае не хочу сказать, что фронтенд не нужен в принципе. Но мне кажется, что вы пытаетесь, по какой то причине, «перетянуть на него все одеяло» и свести на нет важность бекенда.
А наличие логики на фронте снижает безопасность приложения до нуля.
Вы, кажется, не о той «логике» рассуждаете- никто в здравом уме не дергает бд прямиком с клиента или через «тупую» бекенд прослойку, это как бы должно само собой быть понятно. Но с каждой логики бекенда можно выделить ее публичную часть, которую можно и нужно продублировать на фронте для уменьшения отклика интерфейса и придания ему асинхронности работы, как у приложений. Банальная валидация форм определенно должна производится и на клиенте, и на сервере. Благо, если сервер тоже на js, то вообще можно использовать один и тот же код местами.
и свести на нет важность бекенда.
важность бекенда никуда не испаряется, он как был, есть и будет- все изменения лишь в том, что бекенд больше не должен заниматься рендерингом данных в html шаблон (ну кроме как plain html представление для SEO), а рендерить в json, т.е CRUD. ИМХО это ведь отлично- на бекенде надо сосредоточится на безопасности, надежности и скорости отклика, раз почти весь рендеринг перекочевал. Кроме того, бекенд тогда по своей сути уже реализовывает и внешний api, не надо отдельный код писать, когда нужда появится для мобильных приложений или
P.S. Ни в коем случае не хочу сказать, что бекенд не нужен в принципе ;)
Просто вопрос ТС поставил так, как будто бэкэнд становится просто такой себе удаленной БД :)
Какова вероятность, что для небольших веб-приложений классические языки ООП (Java, C#)
Для хеллоуворлдов бэкэнд не нужен. Но никому не нужны хэллоуворлды
Вы, кажется, не о той «логике» рассуждаете
Если речь про валидацию, или логику по типу «должна ли сейчас эта кнопка быть активной или нет», то да, конечно она должна быть продублирована(!) на интерфейсе. Но даже это не отменяет ее на бекенде. Кстати, что бы этого дублирования не было, и что бы клиент/фронтенд даже не должен был бы знать о ней, для этого и существует HATEOAS. Про бизнес логику, которую, я так понимаю, автор подразумевает и говорить нечего. Она должна быть на бекенде.
не должен заниматься рендерингом данных в html шаблон
Разве этим кто то еще занимается в 2к17? :)
P. S. Не хочу никого обидеть, но мне все это видится так. Фронтенд разработчики с выходом NodeJS решили, что теперь будут править миром и скинут с плоской земли всех бекендщиков ибо больше нет смысла ни в микросервисах, ни в Java, ни в Spring ни в других непонятных словах. Все перенесем на фронт, а на крайняк заюзаем NodeJS — аля бекенд.
Но что то среди всех комментариев я не увидел примеров серьезной бизнес логики, которую вы могли бы перенести на фронт. Все что было упомянуто — это валидация (что по здравому смыслу так же должно быть и на фронте) и подгрузку items, что не особо то с какой либо бизнес логикой и вяжется.
Фронтенд разработчики с выходом NodeJS решили, что теперь будут править миром и скинут с плоской земли всех бекендщиков ибо больше нет смысла ни в микросервисах, ни в Java, ни в Spring ни в других непонятных словах.
Будут, если вкурят node и станут бекендщиками или фулстеками. А вот nodejs разрабы уже свято верят, что они будут править миром бекенда со своей платформой, которая для этого и создана изначально и что тут старенький универсальный java им не конкурент :) Насчет выделенных фронтендщиков- ну побалуются со своими клиентскими фреймворками, которые стучаться к бд чуть ли не напрямую, да и выучат node- язык то один, а микросервисы или нет, то уж там будет видно...
я не увидел примеров серьезной бизнес логики, которую вы могли бы перенести на фронт
Хм, а какая вообще есть серьезная бизнес логика на бекенде? Это весьма расплывчатое понятие. Так сразу и не придумать что то сложнее, чем высчитать на клиенте стоимость доставки/кредита по тех же формулах, коэффициентах с бд и входных данных от юзера что вычисляет бекенд в процессе оформления заказа...
Будут, если вкурят node и станут бекендщиками или фулстеками.
Удачи!
Хм, а какая вообще есть серьезная бизнес логика на бекенде?
Вот такие вопросы и дают мне повод думать, что для фронтендщиков в этом топике все приложения кажутся либо магазинами, либо блогами.
Возьмем банковсвую сферу. Как бы вы написали процессинг на клиенте? Или алгоритм определения достаточного баланса на счету для перевода средств? На клиенте? Серьезно?
Впрочем я уже знаю ответ: «Нет, именно такую логику мы бы написали на NodeJS».
Но много ли можете предоставить примеров подобных сервисов на NodeJS?
Удачи!
Чувствую какую то неискренность, но ни как не могу понять чем она вызвана... ©
А то я уже подумал что мне почудилось что ПриватБанк года полтора назад искал нодедж разарабов, это видно специально чтобы заявить что вы здесь нафик не нужны, у нас ведь есть java и spring, остальное происки формошлепов! ;)
Вот такие вопросы и дают мне повод думать, что для фронтендщиков в этом топике все приложения кажутся либо магазинами, либо блогами.
А джавистам в ентерпрайз все есть банковские транзакции?
Возьмем банковсвую сферу.
неожиданно то как :)
Как бы вы написали процессинг на клиенте?
А зачем его писать на клиенте? Это чисто задача бекенда и никакой пользы для клиента тут нет и быть не может.
Или алгоритм определения достаточного баланса на счету для перевода средств? На клиенте? Серьезно?
Определения? Ну может быть и да. А что такого? Или более логично слать запрос чтобы сервер прокапитанил что у вас на счете 0 либо меньше допустимого остатка? Благо синхронизировать данные фронтенда с бекендом, в случае если денюжка поступит на карту, когда фронт уже загружен нынче не сложно.
«Нет, именно такую логику мы бы написали на NodeJS»
ШТА? какую такую? какую это логику нельзя написать на node, или что?
Но много ли можете предоставить примеров подобных сервисов на NodeJS?
в ентерпрайз? В ентерпрайз все древнее как Г. мамонта, пока работает его не трогают, допиливают легаси чуть ли не с конца
так то есть у меня опыт работы в банке как раз на проекет где пили процессинг.
Все так как ты говоришь, все легаси и конца и края этому не видно.
сейчас , пока еще, продолжаю рабоать в этой же сфере и ± ситуация такая же, если еще мордочку переделывюат с использованием современных технологий, то вся изнанка остается все тем же древним, как говно мамонта, кодом
Чувствую какую то неискренность, но ни как не могу понять чем она вызвана... ©
Сарказм вызван вашей наивной верой в то, что в будущем вы сможете все писать на javascript. Конечно нас рассудит время, но уже можно отчетливо понять, что это не так. Как вы думаете почему появляется специализация? Например, зачем гугл придумала еще один язык — Go? Взяли бы да и напилили все что им надо на js. Или они глупее вас?
А то я уже подумал что мне почудилось что ПриватБанк года полтора назад искал нодедж разарабов . . .
А вы наверное подумали, что ПБ нанял этих NodeJS девелоперов что бы все начисто переписать наконец на праведный javascript? =)
А джавистам в ентерпрайз все есть банковские транзакции?
Вы не могли придумать примера сложной логики, поэтому я и помог вам взяв за пример банковские операции. К чему тут удивление?
А зачем его писать на клиенте? Это чисто задача бекенда и никакой пользы для клиента тут нет и быть не может.
Но при этом суть обсуждения собственно в том, что всю логику можно вынести на клиента.
Или более логично слать запрос чтобы сервер прокапитанил что у вас на счете 0 либо меньше допустимого остатка?
Вы наверное опечатались и хотели написать не «прокапитанил», а «достоверно проверил»? Тогда все в порядке. Или вы такие мелочные операции с деньгами предпочтете проверять на клиенте, который даже школьники уже умеют править?
ШТА? какую такую? какую это логику нельзя написать на node, или что?
Вы меня не правильно поняли. Я смотрю, что ваша точка зрения заключается в том, что всю логику можно вынести на фронтенд. Но когда вам показываешь явные примеры где это не допустимо, вы, как и все остальные евангелисты js прикрываетесь NodeJS.
В ентерпрайз все древнее как Г. мамонта, пока работает его не трогают
Вот прям одно говно плавает и новое ничего не пишется? Вы серьезно? Говорите так, как будто с конца
Если тут разговор сместился с фронта vs бек к nodejs vs java то это уже бессмысленное занятие.
Честно говоря я думал что этот топик сдохнет еще в самом его начале, ибо уже только обсуждать возможность вынесения бизнес логики на фронт это какой то сюр.
что в будущем вы сможете все писать на javascript.
Да можно то и сейчас писать «все», только будет ли это эффективной реализацией для каждой из задач :) Для веба клиент-сервер вполне, тут он лучше джавы, ибо это есть та область, для чего он и создан, писать ли критическое ядро банковского ПО на js- наверно нет... это можно, но не нужно и лучше плюсов тут нет :)
Например, зачем гугл придумала еще один язык — Go?
так можно говорить в контексте любого ЯП. Ну зачем С++, если придумали джаву или C#? и наоборот... или вообще зачем плодятся десятки и сотни ЯП- наверно чтобы иметь выбор.
А вы наверное подумали, что ПБ нанял этих NodeJS девелоперов что бы все начисто переписать наконец на праведный javascript? =)
Ну разумеется, и при этом вывести голых, больше ненужных джавистов коридором, через толпу продвинутых джаваскриптеров, кричащую «позор! позор!! позор!!!», ну а сзади ангулярщик, верхом на гироскутере, фигачит их хлыстом :)
Не вижу я особой разницы между тем что сейчас написано на джаве, а могло быть и на с++ (+) джаваскрипт. Все ровно подозреваю особо важные и древние компоненты в банках написаны на плюсах.
Но при этом суть обсуждения собственно в том, что всю логику можно вынести на клиента.
и кто же такое говорил, что можно всю логику вынести на клиент? Если всю логику вынести на клиент, то это будет уже не клиент, а практически ферма серверов, в котором ПО с графическим интерфейсом.
Или вы такие мелочные операции с деньгами предпочтете проверять на клиенте, который даже школьники уже умеют править?
и опять же, речь шла о дублировании проверки, валидации и прочих операций на стороне клиента, которые позволяют сократить количество запросов и/или повысить отзывчивость, а не отказ валидации на сервере и перенос ее на клиент. На чем написан бекенд не суть важно, хотя если он на ноде то позволяет переиспользовать некоторый код.
От того что клиент сам посмотрит что баланс недостаточный и не пошлет запрос к серверу и выведет какой то alert, не отменяет что на стороне сервера на этот запрос все ровно будет происходить тоже валидация. Правь клиентский код или нет, суть бекенда не меняется, а клиент, грубо говоря, дополняется собственными дублирующими механизмами.
Я смотрю, что ваша точка зрения заключается в том, что всю логику можно вынести на фронтенд.
как то не очень хорошо смотрели. Тогда мы тут даром простыни накатали, ибо своим верхним комментом на ваше
А наличие логики на фронте снижает безопасность приложения до нуля.
я ответил... ну если в сокращенной форме- что никто не работает с бд с клиента напрямую или через тупой бекенд, т.е без валидации данных и без все той же логики. А дальше вы скатились в разговор что бекенд это дело джавы, и если бекенд написан на Node, то тут что то не так и опять про фронтенд. Я даже решил был спросить точно ли вы в курсе что Nodejs к фронту не имеет никакого отношения, но забил.
Ну разумеется, и при этом вывести голых, больше ненужных джавистов коридором, через толпу продвинутых джаваскриптеров, кричащую «позор! позор!! позор!!!», ну а сзади ангулярщик, верхом на гироскутере, фигачит их хлыстом :)
Огонь! =)
Не вижу я особой разницы между тем что сейчас написано на джаве, а могло быть и на с++ (+) джаваскрипт.
Я же и говорю. Не понимаете, почему появилась специализация.
Я даже решил был спросить точно ли вы в курсе что Nodejs к фронту не имеет никакого отношения, но забил.
Да, точно. И поэтому следующие доводы
хотя если он на ноде то позволяет переиспользовать некоторый код.
вгоняют в ступор. Я в фронте не силен, но даже мне валидация на фронте видится как нечто подобное
material.angularjs.org/latest/demo/input
<input required type="email" minlength="10" maxlength="100" ng-pattern="/^.+@.+\..+$/" />
но уж никак не набор if () then alert, которые, я так понимаю вы и собрались переисопльзовать.
как то не очень хорошо смотрели. Тогда мы тут даром простыни накатали. . .
Не даром. Я был рад принять участие в конструктивной беседе с вами без скатывания в 18+
А, мне, знаете ли, пора. Пойду учить javascript, а то как тут верно заметили
Я топлю за идею, что если есть желание покушать завтра хлеба с маслом, то стоит потихоньку JS подтягивать
Не хочу завтра вместо езды на автомобиле автостопить в надежде, что меня подберет и довезет домой javascript девелопер на своем гироскутере =)
но уж никак не набор if () then alert, которые, я так понимаю вы и собрались переисопльзовать.
Есть фреймворки кроме ангулара и более гибкие способы валидации , чем привзка правил прямо к полям формы. К вашему вниманию, например, validatejs.org, github.com/hapijs/joi. Эти библиотеки можно использовать как в node, так и в браузерах, и валидируют они объекты, а не отдельные поля формы. Поэтому конфиг можно копировать оттуда сюда. Другой вопрос что это особо выгодно только фуллстаку. Когда разработчики переднего и заднего конца разные, то скорей всего каждый будет валидировать удобным ему способом и писать конфиг сам.
Не хочу завтра вместо езды на автомобиле автостопить в надежде, что меня подберет и довезет домой javascript девелопер на своем гироскутере =)
Вас будто джаваскриптеры в детстве побили
Есть фреймворки кроме ангулара и более гибкие способы валидации
Я поэтому сразу и написал, что в фронтенде мало компетентен.
Другой вопрос что это особо выгодно только фуллстаку.
Только фуллстеку, который и фронт и бек пишет на js. Но как по мне возможность дублирования кода валидации довольно не значительный аргумент в пользу написания бекенда на nodejs.
Вас будто джаваскриптеры в детстве побили
Даже если и так, у меня после этого осталось чуство юмора, в отличие от вас =)
Но как по мне возможность дублирования кода валидации довольно не значительный аргумент в пользу написания бекенда на nodejs.
Есть ещё один — если пишешь один (что конечно актуально лишь для фриланса на небольших проектах или для пет-проектов), то удобнее когда синтаксис одинаковый — меньше ресурсов тратишь при переключении с одного конца на другой.
Но есть люди, которые выбирают node, хотя работают бэкендщиками.
Я не спорю, что nodejs вполне годная технология для бекенда так же, как и не спорю с
лишь для фриланса на небольших проектах или для пет-проектов
Но есть люди, которые выбирают node, хотя работают бэкендщиками.
Вот было бы интересно почитать отзывы этих людей и причины, по которым они выбрали nodejs для бекенда. С какой технологии они перешли на nodejs и почему? И т.п. вопросы.
Я же и говорю. Не понимаете, почему появилась специализация.
Часом не замечаете иронии?)
Джава, которая в былые времена была создана для всего сразу, но в основном для кросс платформенных десктоп приложений под свою виртуальную машину, у вас же как ЯП по умолчанию и для бекенда веб сервисов, хотя есть специализированные, и нода в их числе. Выходит то же самое, и Вашу же цитату можно легко подправить на «...что в будущем вы сможете все писать на java.» Что Java, что Node обе виртуальные машины с разными ЯП, но изначально ориентированные на разные задачи, хотя обе покрывают задачи друг друга, но с разной эффективностью.
мне валидация на фронте видится как нечто подобное
ng-pattern
О, ну так Вы как настоящий фронтендер, у которого нынчне уже нигде не обходится без ng-
но уж никак не набор if () then alert
Ага, только тру ангулярские директивы в html, обычный код уже никак не катит, не модно. Я слишком стар для этого :)
Да, точно. И поэтому следующие доводы ... вгоняют в ступор
Какой тут ступор? Node под js, клиент под js, валидацию и полезный публичный код оформляешь в отдельные модуля, и юзаешь на обеих концах. Тогда не будет ситуации типа маску поля поменял на фронте, а не бек стороне она другая, ну это самый примитивный случай.
что меня подберет и довезет домой javascript девелопер на своем гироскутере =)
Ох, что то в этом есть тревожное :)
что по здравому смыслу так же должно быть и на фронте
Вы имели ввиду на сервере?
Фронтенд разработчики с выходом NodeJS решили, что теперь будут править миром и скинут с плоской земли всех бекендщиков
Я знаю двоих бэкэндщиков, которые пишут на ноде и не занимаются (и вероятно не занимались) профессионально фронтом.
Единственное что вообще связывает node.js и браузерный js — синтаксис языка и V8. Но это не значит что можно прыгать с фронта в бэк и обратно несколько раз в день. Задачи разные, API разные и если нет опыта работы с бэкэндом/фронтэндом, то его нет.
Но это не значит что можно прыгать с фронта в бэк и обратно несколько раз в день.
Да как бы можно, но да нужно знать оба.
Наличие логики на фронте нужно ровно в той степени, в которой она помогает работать интерфейсу. Всю бизнес-логику, до последней запятой, необходимо вести в бек-енде, на фронте она лишь частично дублируется.
Не поверишь, сколько раз в стуки логируются попытки проверить эту логику на вшивость.
наличие логики нужно , например для валидации ввода пользователя в UI
нет смысла посылать на сервер ошибочные данные , такие попытки должны отсекаться в самом UI
Это не бизнес-логика, это часть UX. И всё равно данные нужно проверять и на бэкэнде (то есть эта часть дублируется), потому что js никак не защищён от изменений пользователем.
Мало того, немало «бесплатных прокси» сливают инфу хакерам, и те по реальным пользовательским ссылкам потом пытаются куда-то там войти.
Типичный пример: локгику поменяли, имя обработчика изменилось. А роботы продолжают долбиться в старые. Тогда-то и видишь, сколько этого счастья. В основном Россия, кстати.
Сечас клиент становится настолько жирным, что скоро жир с монитора потечет и это только логика для UI и прибамбасы для революционных фреемверков, а вы туда еще хотите бизнес логику перенести.
ХЗ как там у остальных, на .NET уже давно перешли на SPA и UI часть это лишь верхушка айсберга на типичном .NET проекте, бэк-эндщикам там работы хватате с головой.
То что перестали писать на MVC с разором, это только слава богу — баба з возу кобилi легше.
Продолжаю писать на MVC c Razor , отстал по ходу)
Ну есть люди до сих пор и веб формы пилят.
Я топлю за идею, что если есть желание покушать завтра хлеба с маслом, то стоит потихоньку JS подтягивать, хотя душа лежит к ООП.
Вот только бэкэндщиков на проект всегда в разы больше чем юайщиков, а проект на стадии поддержки может вообще без них обходиться, обычно бэкэндщики правят UI, часто с матюками )))
обычно бэкэндщики правят UI, часто с матюками
ну потом и соответсвующий UI и получают... ну такое ((
Поглядел бы я на FP в embedded
C++ более-менее стабильно юзают. Хотя таки-да, ООП обычно мало.
Ну и да, в ядре линукса настоящий полиморфизм везде.
На текущий день без джаваскрипта прям совсем почти не обойтись. Однако это вообще не значит что на джаве нет работы, или что тренд идет на спад.
Наверное зависит от того, что писать.
Type Script позволяет осуществлять ООП на фронте, не превратится ли классические ООП языки в скучный DAO layer ?
Трудно сказать, есть ли далёкое будущее именно у Spring MVC, но будущее у backend-разработки и backend-языков точно есть, всё-таки сложная логика на фронте, работающая даже со сравнительно небольшими данными, заметно замедляет работу. Но для небольших веб приложений это нормальный подход, я даже видел достаточно крупные проекты, на которых 80% всего что написано на бэкэнде —
скучный DAO layer
Хмм, но ведь можно реализовать подкачку по 15 items на страничку, и адльше поставить слушатель на scroll. А от бэка требуется только отвечать на рест запросы
Эту «подкачку» реализовать не трудно, тут важнее вопрос что это за items и как их нужно рендерить — объекты которые приходят из бека бывают разные и не всегда достаточно простые, маленькие и «готовые к употреблению» на фронте, т.е. их нужно как-то преобразовывать, что может быть весьма затратно на фронте, как показывает практика.
А можно сразу отдать 900 айтемов и не выйожываться. Угадай, у кого скорее купят?
Може натяк на не зручну пагінацію на Розетці...
Мне трудно проследить связь с розеткой, особенно если учесть, что на розетке сервер-сайд рендеринг.
Та там ті порції по 32 товари реально бісять
Могу. Когда ты заходишь в реальный магазин одежды, ты видишь сразу все сотни предложений. Когда на сайт — почему-то только по 15 шутк, а дальше надо клацать и ждать пока отрендерится страница.
При этом в магазине реализация требует немалых вложений. Их делают. Потому что очевидно, что иначе не купят. Для веба — это стоит понты. Пагинация обходится в разы дороже по трафику и его обеспечению. Что мешает предлагать товар БОЛЬШИМИ порциями? Я знаю только одно объяснение: заказчик не понимает, что за реализацию процесса покупок через жопу — надо давать не денег, а по морде.
Обваливать продажи даже джуну непозволительно. Назвался UI — делай UI.
Ну например где-то на тысяче товаров браузер начнет тормозить из-за большого дома. Да и неудобно это всё скролить.
Да ну? Когда ты это сам последний раз проверял?
Скажи уже когда сам покупаешь, то начинаешь тормозить при наличии вариантов > 1
Тысяча многовато. 200 оптимально. И пожалуйста убейте того кто придумал отображение плиткой.
Не многовато, если действительно есть выбор.
Насчёт плитки — есть любители, не отрицай. Убейте лучше того, кто делает куки отображения хранящимися до закрытия окна. А не 20 лет, как положено.
Ну зависит от того что в результате нарендеришь. Рендер много итемов не проверял уже очень давно. А вот например рендер pdf проверял в этом году, одновременно безопасно показывать до 20 страниц. Больше уже может барузер не выдержать. 90+ страниц зависает. Хотя по сути из дома там — одни только канвасы. А зависает именно когда их скролишь, не на этапе загрузки файла
Скажи уже когда сам покупаешь, то начинаешь тормозить при наличии вариантов > 1
Если я что-то покупаю в интернете, то это обычно техника и выбирать я иду сразу на розетку. И мне как-то 32 товаров на странице хватает. После фильтров их часто меньше 32 остается, потому что я знаю с какими характеристиками я хочу товар и до какой цены
выбирать я иду сразу на розетку
Почитай случаи за [не]исполнение гарантии. И громко, с выражением, перед зеркалом повтори: «я не лох». Тогда хоть один человек тебе поверит.
А кто исполняет? Это не повод идти покупать железки на олух или ещё куда в неизвестные места. А выбирать там удобно, даже если купишь в другом месте.
Ну так не обязательно совать их все сразу в DOM, можно рендерить и убирать из DOM чанками в процессе скрола, это ведь давний финт, когда нужен бесконечный скрол... давно на чате юзал, вместе с подгрузкой и удалением данных, чтобы десятки тысяч сообщений, иногда с медиаконтентом, скролить. Нынче в виде библиотек примерно этот подход есть, недавно случайно натыкался... так что тут нет особых проблем.
Вы читали сообщение Алексея? Он хочет чтобы сразу все товары были видны, а не клацать. Я наоборот не люблю бесконечный скрол, я сторонник постраничного вывода.
Он хочет чтобы сразу все товары были видны
У него монитор с футбольное поле? Или как это все?
а не клацать.
Так и не клацать, речь идет о прокрутке, которая для пользователя выглядит как совсем обычная нативная (ну или не совсем, у кого как), а под капотом это вставка и удаление узлов с подменой на заполнитель, которые вышли за область скрола, от чего количество одновременно вставленных DOM узлов резко сокращается.
Или Вы знаете какой либо еще способ впихнуть невпихуемое, кроме как постранично или со скролом?
Я наоборот не люблю бесконечный скрол,
ИМХО идеально это объединение обеих- то есть бесконечный скрол- который имеет разделители/флажки с номером страниц, и кнопочки с номерами, похоже как у вк.
сразу все товары были видны
вот только что нагуглил библиотеку, как я понимаю, работающую на примерно этом же принципе. Демка: clusterize.js.org Либо о ней и ей подобных мало кто знает, и вообще о таких же финтах, либо я не знаю где взялось непонимание :)
Люблю доу за то, что тебе начинают рассказывать как решить проблемы, которых у тебя нет :)
Зависит от количества данных в айтеме. Если айтемы большие и интернет медленный, то пользователь может и не дождаться когда они загрузятся.
Если для тебя это так важно — замерь эту самую скорость и сделай адаптацию. Лично я предпочту дать юзеру купить, даже если он подождёт минуточку пока загрузится всё предложение.
Если есть товар — его надо продавать, иниипёт. Все кто считает иначе — ПНХ из отрасли, займитесь лучше боулингом.
Еще какихто 12 лет назад в джаве были аплеты, свинг, и веб старт.
Где это все сейчас ?
ООП, не ООП в контексте популярности технологии — значения не имеет.
Нормальные приложения давно уже так и пишутся. Цель MVC — разделение этих самых MVC на независимые компоненты. И кстати говоря, это далеко не единственный вариант, IMHO и не лучший.
Dmytro Vasylchenko
Albert Kokoshin
Dmitry Zozulya
Grez
Sergiy Doroshenko
Дмитрий Вежнин
Олексій Пєніє
Oleksandr Burchak
Maksym Ogorodnikov
Gennady Dogaev
Dmytro Vasylchenko
Bot Bot
Oleksii Pavlov
Андрей Литвинов
One dev army
Александр Шевченко
Kastor Driver
Kastor Driver
Dmitriy Mozgovoy
Gennady Dogaev
Albert Kokoshin
Victor Mikhaylov
Bot Bot
Vladislav Landcovschi
NewOne NewOne
And riy
Denys Poltorak
Александр Шевченко
Anthony Haman
Іван Пащенко
Олексій Пєніє
Найкращі коментарі пропустити