Підписуйтеся на Telegram-канал «DOU #tech», щоб не пропустити нові технічні статті.
Наткнулся на форуме на:
современный веб такой, что mvc на сервере уже никому не нужно.
Кто что скажет на эту тему?
ПК становятся ведь всё мощнее, всё не очень секьюрное можно отдать клиенту, пусть компьютер греет комнату, тем более отопительный сезон ещё не начался.
Ещё вопрос такой:
1.Будет ли достаточно работы asp.net mvc разработчику в Украине в ближайшие
2.Стартуют ли у нас сейчас новые проекты на asp.net MVC или у нас в аутсорсе почти всё — поддержка старых?
3.Какого типа эти проекты?
стартуют, фронтовые mvc js расширения сейчас очень удачно уживаются дотнетовскими RESTful WebApi контроллерами. Рзвитие asp происходит с учетом новомодных трендов. Активно используеться в аутсорсе в качестве сервеной части и для мобильных решений и для веб сайтов на ваших mvvm js фреймворках.
Если речь идет об «отдать клиенту чистые данные и пусть он из них сам строит таблицу», то это разумно. Юзер купил железо, которое во много раз перекрывает потребности браузинга, так пусть оно работает вместо _далеко не_ бесплатной процессорной утилизации на сервере, которому пришлось бы заниматься monkey business, генерируя одни и те же страницы (с разными данными) по тысяче раз в секунду.
Но впасть в крайность и перенести вообще всю логику на клиента, общаясь с сервером как с репозиторием — это путь неискушенных разработчиков, которые представляют интернет сияющим облаком без хакеров и размножающихся багов. )))
Вобщем, мое мнение такое, что решать, что принимать и что отдавать должен сервер в любом случае. Рендерить представления — однозначно клиент.
Могу «гарантировать», что потратив месяц плотной работы с любым из современных фреймворков (нокаут, бекбонмарионет, энгулар...), любой разработчик будет с легкостью представлять клиента неотъемлимой частью системы. А код обработки данных на клиенте вылетать как из пулемета. Там нет ничего сложного (есть «ньюансы», но где их нет?). И простого функционального джаваскрипта за глаза хватает для реализации любых идей. Практически любой паттерн может быть реализован. Жизнь есть и вне ООП -)
Это если кто-то боится, что без его любимого С#/Java ничего не получится.
Мало того, осознавая в этом потребность, MVC 4 «из коробки» идет с минимальным набором компонентов. По желанию они доустанавливаются из репозитория.
node.js — это просто тренд. Нет, ну, может, он идеален в связке с nginx, не знаю... Но отдать json данные может любая тулза... Тот же python, например.
И потом, если вашему клиенту нужен только json, то это съэкономит _массу_ времени и денег, если прийдется мигрировать со, скажем, ColdFusion, на ASP.NET (как это было актуальным лет 7 назад), переписывая вообще все!
Хотя... Если хотите привязать кастомера к своим скилам, то — пожалуйста )))
Начнем с «далеко не бесплатной процессорной утилизации на сервере». Это настолько абсурдно противоречит реальности, насколько это вообще возможно. Для начала — генерить html дешево, во вторых генерить JSON не всегда дешевле, и в третьих — чтобы нагрузить генерацией темплейтов (не базой, не расчетами, а именно шаблонами) 100 долларовый дедик, надо столько трафа, что он монетизируется в космические деньги, плюс к этому наработанный инструментарий кэширования на нескольких слоях.
Бэкбонмарионеты, ангуляры и нокауты СЫРЫЕ почти все, ДОРОЖЕ в разработке и генерят трэш гораздо чаще ибо область молода.
Перфоманс клиент сайд рендера это тот же миф
Практически все с кем говорил сурово зафакапили первый проект на этих фреймворках, и когда перестают шуметь о базвордах, то признают удорожание и боль
При этом я с большим интересом наблюдаю за прогрессом клиент сайд аппов, но браццы прогресс не в том чтобы закрывать глаза на недостатки, а в том что бы их разруливать (для этого не помешает их признать для начала)
Приправим это все мобилизацией интернета и отсутствием предпосылок к существенному росту JS-performance на мобильных процессорах.
чуть не забыл — вспомним еще и pjax, который дает снижение трафика, времени рендера, и имеет все шансы откусить у SPA жирный кусок
Для начала — генерить html дешево, во вторых генерить JSON не всегда дешевле
Только с тем отличием что клиент может загрузить JSON один раз, а потом нажимать 10 окошек, панелей и подобного, который потом закончится еще одним POST JSON напиример. На практике в SPA просто меньше интеракций с сервером.
Перфоманс клиент сайд рендера это тот же миф
Что видим непосредственно у себя на компьютере, то и говорим. Достаточно часто отзывчивость как у десктопного на С++.
Потом появляются темы на доу, как сделать пополняшку из базы счетов на своем андроиде.
А, вообще, скоро будет обязаловом свободное владение English & JS, т.к. халявные чужие ресурсы жиреющих гаджетов никому покоя не дают.
Так и вижу загаловки вакансий: fluent javascript, senior english speaker.
В резюме:
Russian, JS: native,
English: pre-intermediate
современный веб такой, что mvc на сервере уже никому не нужно.Чепуху написали. Пока есть любая логика на бэкэнде нужно ее как-то организовывать. Пока что лучше не придумали, чем разделять бизнес-логику и логику представления. Даже если представление у вас это json_encode.
Альтернативный вариант комментария:
вброс защитан.
json определенно лучше чем хтмл возвращать на клиент, но все же из-за открытости фронтенд кода и того обстоятельства, что более менее нормально js начал работать только в
энтерпрайз к этому совершенно не готов само собой)
Какое там мвц, вы шо? Это уже прошлый век, ретроградство и анархия. Сейчас нормальные пацаны (в очках, с айфончиком, зеркалочкой и аккаунтом в инстаграмме) ставят ноду c редисом и пишут свой тёплый и ламповый коллбек-хелл и угорают по хардкору в start.js, прописывая в крон ребут сервера раз в сутки.
То есть? В node.js утечки памяти, что приходится сервер перезагружать так часто?
Утечка пряморукости тех, кто узнал jquery и возомнил себя гуру js, даже не подозревая, что такое контроль памяти и череда выполнения обратных вызовов, что кстати в той-же ноде ещё более усложняет работу приложения, чем, например, в java.
В node.js утечки памяти, что приходится сервер перезагружать так часто?ага. из того что лично меня коснулось — у пацанов из ноды отличное от пацанов из linux понимание стека тсп, поэтому хэндлы текут (пинками в либах можно немного полечить, но не всегда)
пинками в либах можно немного полечить
Можно для неграмотных ни в linux, ни в node.js пояснить, что это значит?
Колбек-хелл это вчерашний день. Промисы ж.
Прально, hmvc же есть.
єм. а чем заменить mvc ? если кашей , то лучше пусть mvc
Просто сейчас очень модными стали Single Page Application. Когда весь UI генерится на клиенте джаваскриптом. Т.е. MVC на клиенте, а не на сервере.
Но это не от хорошей жизни, а в попытках «выкрутиться». Ведь разных мобильных устройств сейчас тува хуча, и писать под каждый нативное UI приложение — накладно. А так: вроде как приложение, но на HTML5 — поэтому плюс-минус везде работает.
всё не очень секьюрное можно отдать клиентуТолько потом юзеры начинают жаловаться что у них на телефоне сие приложение тормозит, постепенно сжирает всю память и батарею и т.д. И начинаются шаманские пляски с минификацией, оптимизацией, «урезанием», попытками угадать что у юзера за девайс и что он потянет и «впихнуть невпихуемое».
лол. ну сингл spa предполагает всё-таки только логику представления на клиенте.
ну то-есть если у вас MVP — то рестфул апи вместе с сущностью вроде model в backbonejs — это презентер, то что rest api врапит — это модель.
если у вас какой-нибудь mvvm — то на клиенте только view model и model.
с другой стороны вы можете рассматривать restful api как mvc приложение с вырожденной вью в виде json
Спорить что есть SPA: MVC, MVP, MVVM и что в них модели а что вью не вижу смысла.
Вот здесь это все называют MVC:
todomvc.com
На мой взгляд сделать сайт на любом из этих фреймвоков минимум в 2 раза сложнее чем на чистом ASP.Net MVC.
с одинаковым функционалом RIA проще всё-таки сделать проще без серверных view engine.
ну еще можно списать сложность на отсутствие опытных людей на рынке + на костыльность жаваскрипта
с запретом на навигацию
Такое бывает?
Поясню в чем «трюк с SPA»:
On iOS, as part of optimizing your web application, have it use the standalone mode to look more like a native application.developer.apple.com/...0002051-CH3-SW3
А, не знал, спасибо
Переход по любому линку (не «закладке» с # а именно другому URL) вызывает «переоткрытие» страницы уже в браузереНу не всегда, если переход выполнить с помощью js, даже на другой домен, то переход осуществляется в рамках приложения.
Тут смотря для какого проекта. Иногда нужно отдавать разный ХТМЛ, под ПК один, под мобайл более упрощенный. Ещё, к примеру, интернет-магазины отдают брендированые страницы для определенных товаров. А ещё — поисковики пока больше любят ходить по отдельным страницам. И наконец — ИЕ 6/7/8 все ещё жив и это не малая часть аудитории, которая будет страдать от обилия скриптов на клиенте .
ИЕ 6 — МЕРТВ!
Забудьте о нем.. как и о юзерах без js!
Это не пользователи, это боты и идиоты)
з.ы. лучшее вообще о ИЕ забыть =) но пока не выйдет...
Забудьте о нем.. как и о юзерах без js!без заигрывания з гуглеботом популярности не будет
Это не пользователи, это боты и идиоты
Он же умеет JSя не заметил , может в каких-то редких случаях гуглебот может «прокликать» все кнопки в тех же одноклассниках :)
Доля правды тут мааааааааааленькая есть, конечно, с позиции asp.net: mvc framework в Microsoft начали разрабатывать потому, что вебформы просто загибались под своей тяжестью, что давало лишний трафик, и порой это было критично, особенно тогда, когда трафик — платный. А mvc framework — это просто надстроечка, торчащая в asp.net pipeline, и позволяющая очень красиво делать кристально чистый html.
p.s. Так можно дойти до того, что «современные сервера такие, что можно гвнокодить как угодно, и не следить за утечками памяти — ее там хоть ж... ешь» :)
Я бы перефразировал:
«современный веб такой, что <название любого шаблона проектирования> уже никому не нужно»
Судя по топику «трезвая работа», это состояние не только веба...
«Современный X такой, что Y уже никому не нужно» — от создателей «А вот мы в ваши годы Ооо!»
современный веб такой, что mvc на сервере уже никому не нужно.Если под МВЦ подразумевают формирование ХТМЛ, то скорее не нужен чем нужен.
ПК становятся ведь всё мощнее, всё не очень секьюрное можно отдать клиенту, пусть компьютер греет комнату, тем более отопительный сезон ещё не начался.
Нужно учитывать mobile (он очень быстро растет и по некоторым параметрам обогнал уже ПК), а также специфику этого mobile:
sealedabstract.com/...-apps-are-slow
Нужно учитывать mobileА тут так же зачастую формирование ХТМЛ на клиенте может быть эффективнее, ибо:
Да, мой комментарий больше к тому, чтобы не злоупотреблять этим «ПК становятся ведь всё мощнее» и «пусть компьютер греет комнату».
Остальное можно померять, быстрее или нет (или даже «достаточно ли быстро и хорошо работает»).
Twitter вот по разному пробовал:
blog.twitter.com/...ance-twittercom
А может быть и не эффективнее, ибо:
— Вся подгонка под экран девайса происходит на клиенте (медиаселекторы, расчет ширины элементов скриптом и т.д.).
— Десяток параллельных конекшинов к серверу за данными может быть хуже чем одна загрузка HTML.
— Рендеринг статического HTML с сервера происходит быстрее, чем рендеринг десятка «кусочков» вставленных в ДОМ скриптом.
— Все нарисованное скриптом надо не забывать «чистить» перед показом нового.
— Джаваскипт однопоточный, в то время как загрузка и рендеринг асинхронные. Поэтому при простой перегрузке страницы даже отлаженное приложение будет давать ошибку 1 раз из 100 (в лучшем случае) — просто из-за другого порядка вызова функций.
— Обновление страницы или переход по ссылке убивает все загруженное и нарисованное. А кнопочку «назад» надо поддерживать самому.
— Вся подгонка под экран девайса происходит на клиенте (медиаселекторы, расчет ширины элементов скриптом и т.д.).А на сервере вы ее (подгонку) сделать просто не можете :)
— Десяток параллельных конекшинов к серверу за данными может быть хуже чем одна загрузка HTML.Не десяток, а 2 — данные + шаблон. При том шаблон кешируется, поэтому не 2n, а (n+1), для n __уникальных__ сущностей.
— Рендеринг статического HTML с сервера происходит быстрее, чем рендеринг десятка «кусочков» вставленных в ДОМ скриптом.Рендеринг
— Все нарисованное скриптом надо не забывать «чистить» перед показом нового.А на сервере криворукость программистов не влияет на результат?
— Джаваскипт однопоточный, в то время как загрузка и рендеринг асинхронные. Поэтому при простой перегрузке страницы даже отлаженное приложение будет давать ошибку 1 раз из 100 (в лучшем случае) — просто из-за другого порядка вызова функций.И снова же, проблема кривых рук.
— Обновление страницы или переход по ссылке убивает все загруженное и нарисованное. А кнопочку «назад» надо поддерживать самому.Если я вас правильно понял, то это уже давно не проблема (Банальный backbonejs.org/#Router или его аналоги). К слову, кнопку «Назад» и на сервере поддерживать надо.
А может быть и не эффективнееЭто таки правда: __может__ быть все что угодно. Но в
Антон Харуйманов
Дмитро
shadow
Dmytro Shchurov
Andriy Tyurnikov
Igor Petruk
Апполинарий Эмануилович
Ivan Pomidorov
Апполинарий Эмануилович
Paul C
Дмитро
двадцатитрёхлетний сениор
Павел Борисов
proger
Dmytro Lapshyn
Michael P
Павел Борисов
Beaver Green
Dmytro
Beaver Green
Aleksey Bober
Aleksey Bober
Andrey Tkachenko
св Антоний
Dmitry Vovk
Дмитрий Пинский
Bogdan Shyiak
Sergii Voloshyn
Bogdan Shyiak
Sergii Voloshyn
45 коментарів
Додати коментар Підписатись на коментаріВідписатись від коментарів