Самый лучший бесплатный вариант - использовать штатные компоненты + jquery. С ними можно всё.

hVosttЕщё более лучший вариант -- ассемблер. С ним можно вообще всё!
- Хочу наклейку на свой мерседес.
- Забей, без наклейки и так едет неплохо.
- Без наклейки? Тогда садись на запорожец!

P.S. Занавес.

hVosttТы по ходу аналогию не понял. Покажи мне грид на jQuery, с фильтрацией, с сортировкой, с поддержкой OData/REST/API, с пейджингом, с группировкой, с сортировкой подгрупп, с итогами, с CRUD операциями, с поддержкой адаптивности, с экспортом в PDF/Excel/Word.
Ты тоже не совсем понял суть. Идея из лопаты сделать бульдозер - не нова, на этом зарабатывают деньги. Но.
1. Фильтрация, сортировка, пейджинг и группировка делается с помощью родного WebGrid.
2. OData/REST/API не нужна на клиенте, всё происходит на сервере, никаких проблем.
3. Подгруппы, итоги и прочие сводные штуки не нужны в UI, для этого есть мощная система отчетов SSRS (локальная или серверная), любые диаграммы и выкрутасы
4. Адаптивности и прочие вещи - вопрос дизайна и верстки, никаких проблем.
5. Экспорты в PDF и прочие форматы - из тех же систем отчетности, всё в коробке.

hVosttВ один экран уместится?
А не надо. Экран должен быть легкий и ненагроможденный. А функционал и навороты - отдельные слои и сервисы, отделенные от несчастного грида или что там у тебя.

hVosttУ меня с компонентами я это всё получаю в несколько строк кода. Так что я не знаю, что там у тебя имеется в виду фразой "с jQuery можно всё". Потому что и с ассемблером можно всё.
Не надо, спасибо. А потом орут, почему сайт колом встал :)

hVosttМСУ1. Фильтрация, сортировка, пейджинг и группировка делается с помощью родного WebGrid.
Всё это без обновлении страницы будет работать? НЕсколькими строками кода?
На WebGrid это будет работать с обновлением страницы, никакого ужаса в этом не вижу. Если нужна интерактивность, можно взять клиентский jqGrid (jQuery Grid Plugin). Кода не особо много, да и какая разница, ты качество работы строками кода измеряешь?

hVosttМСУ2. OData/REST/API не нужна на клиенте, всё происходит на сервере, никаких проблем.
Оно итак не на клиенте, оно дёргается с клиента.
Сторонние сервисы не нужны. Есть модель, есть контроллер, есть JSON (если аякс).

hVosttМСУ3. Подгруппы, итоги и прочие сводные штуки не нужны в UI, для этого есть мощная система отчетов SSRS (локальная или серверная), любые диаграммы и выкрутасы
НУ путай с отчётами. Хотя если ты завёл речь об отчётах, нужен веб-дизайнер отчётов, в SSRS есть такое? А у компонентов есть.
Это ты не путай с отчетами. Грид - это сетка данных, не нужны никакие выкрутасы. Всё остальное решается отчетами. Дизайнер есть в SSRS, называется Report Designer, доступен по URL. Можно разрабатывать в нём или в студии.

hVosttМСУ4. Адаптивности и прочие вещи - вопрос дизайна и верстки, никаких проблем.
Т.е. мы плавно переходим к тому, что не смотря на то, что в jQuery всё есть, надо ещё много чего написать и сделать, чтобы получить то, что я с компонентами получу несколькими строками кода без вопросов дизайна и верстки. Получу сразу нечто полностью функциональное и рабочее, без написании кучи вёрстки, CSS, JS и бехайнда.
Кнопка "сделать всё" утопична. Так или иначе нужно накатывать бутсрап, верстать, делать шрифты, глифы и так далее. Если ты думаешь, что дизайн телерика способен решить все вопросы, то это не так.

hVosttМСУ5. Экспорты в PDF и прочие форматы - из тех же систем отчетности, всё в коробке.
Я хочу получить данные в PDF и Excel ровно в том виде 1 к 1, как это выглядет в гриде. С теми фильтрами, сортировкой и группировкой, которую я применил в гриде.
Да причем тут грид? В отчете может намного больше информации содержаться, чем в гриде. Вот там и применяй группировки свои, фильтры, мультики и прочие вещи.

hVosttЭто довольно частый кейс в нашей практике, клиенты хотят, и клиенты платят за это много денег. Если мы их начнём убеждать, что это не правильно и надо заказывать отчёты в SSRS на каждый чих, они от нас отвернуться и уйдут к тому, кто может это сделать прям на гриде без каких-то левых отчётов. На месте прям. Прямо сейчас.
Не фантазируй. Клиент платит за конкретный функционал, а не за то, чтобы из грида что-то грузилось. Всё в грид не затащищь, особенно если это кубы, процессинг которых занимает длительное время. С OLAP'ом вообще знаком? Какие в жопу группировки в гриде? :) Еще раз, отчеты - это отдельный слой, их много, они подчиняются правилам ролевой или групповой безопасности, отчеты могут быть тяжелыми, интерактивными со всякими дриллами и так далее. Твой грид просто нервно курит в сторонке. Выкинь его.

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

hVosttТак к чему ты клонишь? Выкинуть компоненты и колбасить всё вручную? А если что-то из желаний клиента не укладывается в твою парадигму того «как всё должно быть», слать таких клиентов нафиг?
Клиента нельзя слать куда-то. Просто правильно выбирай технологии и инструменты.

hVosttОбъём работы, дорогой, объём. Ужаса никакого нет, да. Дело в затраченных усилиях и времени. Можно взять jqGrid -- но это же чужой КОМПОНЕНТ! Слегка противоречит тому, что ты ранее писал про нативные компоненты и jQuery, не находишь?
Да какой объем работы, о чем ты. Копипаст и тюнинг на месте ничем не сложнее притаскивания за уши тяжелых компонентов и их конфигурация. Усилия тратятся такие. Ты это бизнесу голову морочь, а не мне :) А по поводу jqGrid - это если принципиально нужен клиентский грид. Мне он точно не нужен, так как хватит обычного хелпера MVC.

hVosttМСУСторонние сервисы не нужны. Есть модель, есть контроллер, есть JSON (если аякс).
Ну это не тебе решать. Клиенту нравится когда страница не перезагружается при операциях с гридом. На ОДате это делается офигенно быстро, офигенно качественно и офигенно просто. Зачем я должен страдать какой-то муйнёй, не пойму? Если есть всё готовое? Я лучше потрачу время на бизнес-логику, чем дрочить аякс вручную.
Как это не мне решать? Именно мне, потому что я архитектуру определяю. Клиенту нравится не страница, которая перезагружается, а функционал, который удовлетворяет требованиям. А там хоть ты пляши на голове, бизнес не волнует, какой там джейсон и куда уходит. Да я, собственно, тоже потрачу время на логику и ничего дрочить там не собираюсь - возьму WebGrid или свой хелпер html table.

hVosttМСУЭто ты не путай с отчетами. Грид - это сетка данных, не нужны никакие выкрутасы. Всё остальное решается отчетами. Дизайнер есть в SSRS, называется Report Designer, доступен по URL. Можно разрабатывать в нём или в студии.
Ещё раз, это не тебе решать. Если ты всё решаешь за заказчика, ради бога. Ищи себе таких заказчиков, которым ты сам будешь диктовать правило как все должно быть и как оно должно выглядеть. Тогда может ты не разработкой должен заниматься, а впариванием тех решений которые именно ты решаешь правильными, отметая все остальные.
Еще раз - мне решать. Заказчику нужен функционал, а не грид. И причем тут впаривание и архитектура? Ты там на солнышке перегрелся.

hVosttА в реале хотят крутой грид, а не убогую сетку + отчёты. Хотят и крутой грид и крутые отчёты и дизайнер прям в вебе.
Сотый раз говорю, никто не хочет крутой грид и большую кнопку "Сделать всё". Хотя конкретный функционал. А как ты сделаешь его, дело десятое. Ты из какого детского сада вылез? :)

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

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

hVosttДля олапов тоже есть визуальные компоненты. В чём проблемы то?
Да, есть. Excel называется.

hVosttМСУКлиента нельзя слать куда-то. Просто правильно выбирай технологии и инструменты.
Я про это же и говорю. Если надо, берёшь компоненты, если не надо, не берёшь. Или берёшь другие. В чём проблема опять? В том, что они платные, да?
Так я ж и говорю, не нужны они в большинстве случаев. Жквери за глаза.

И вообще, давай закроем тему компонентов :) В чем отличие тебя от меня? Вот отбери у тебя игрушки типа телериков с решарперами, ты не сможешь сделать и шагу. А я смогу в любое время за короткий срок поднять каркас решения на нативе, которое объединяет в себе штатные технологии и инструменты, отчётность, безопасность, гуй и так далее. Чистыми руками без шума и пыли.

hVosttКогда мы выкатывали новую версию ПО для клиента, где мы заюзали компоненты, клиент искренне радовался и без раздумий расплатился по счёту, куда была включена цена за эти компоненты.
Клиент всегда будет радоваться, если требования все реализованы и функционал работает. А как это сделать, в гриде или через космические лучи света - не суть.

hVosttАрхитектуру ты определяешь, да. Но то, как это будет работать согласовывается до разработки архитектуры. Работа отдельных (или даже всех) страниц без перезагрузки у нас согласовывается и железно прописывается в ТЗ. Будет глупо, если бы мы клиенту сказали, извините, но у нас МСУ против такого, у него другие принципы построения приложения, так что будет так как будет, а не так как вы хотите ))
Если есть прям какое-то жесткое требования по аяксу, без проблем. Прикрутим тот клиентский легкий jquery грид. Повторюсь, если есть жесткие пожелания. Но как правило, это большая редкость.

hVosttМСУСотый раз говорю, никто не хочет крутой грид и большую кнопку "Сделать всё". Хотя конкретный функционал. А как ты сделаешь его, дело десятое. Ты из какого детского сада вылез? :)
Из реалий. Крутой грид часто хотят, это факт.
Сказки :)

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

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

hVosttМСУДа, есть. Excel называется.
Гугл давно доказал, что можно сделать excel прямо на странице без ОЛЕ-внедрения, средствами JavaScript.
Так и у MS есть Office Web Apps. Это всё детские шалости по сравнению с возможностями Excel. Про производительность вообще молчу, в Excel загнать в несколько миллионов строк для аналитики какого-нибудь Power Query или Power Pivot, вообще не вопрос. Для кубов и аналитики это вообще единственный валидный клиент, равному которому вообще нет на планете. Html и javascript тут просто отсасывает, ты чего :)

hVosttМСУТак я ж и говорю, не нужны они в большинстве случаев. Жквери за глаза.
В нашей работе нужны, мы активно их используем.
Я не против :)

hVosttМСУИ вообще, давай закроем тему компонентов :) В чем отличие тебя от меня? Вот отбери у тебя игрушки типа телериков с решарперами, ты не сможешь сделать и шагу. А я смогу в любое время за короткий срок поднять каркас решения на нативе, которое объединяет в себе штатные технологии и инструменты, отчётность, безопасность, гуй и так далее. Чистыми руками без шума и пыли.
Дык чай не в лесу живём. У меня большие требования к комфорту, у тебя маленькие.
Почему маленькие? Такие же, если не больше. Просто инструменты разные.

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

hVosttтакие вещи, как группировка по колонке мышкой осилишь? настройка отображения колонок клиентом, какие показывать, какие скрывать, сохранение состояния грида на клиенте? и т.д.
Если будет такое требование, то данная настройка выносится на отдельную форму настроек, где пользователь сам выбирает себе нужные колонки. А в рабочей форме с гридом пользователь видит уже настроенный под себя грид. Сохранение состояния колонок на клиенте вообще нахер не упало. В итоге у меня UI не перегружен всяким хламом, который нафик не нужен 99% пользователям. UI чистое, легкое, быстрое.

hVosttверю, что ты это всё сможешь сделать. только сколько времени ты на это убьёшь? и зачем это делать? если можно взять готовое?
Время самое минимально. Просто задача будет решаться не в лоб, как ты это себе видишь, а из-под другого угла. У каждой задачи есть несколько вариантов решения.

hVosttМСУЕсли есть прям какое-то жесткое требования по аяксу, без проблем. Прикрутим тот клиентский легкий jquery грид. Повторюсь, если есть жесткие пожелания. Но как правило, это большая редкость.
так у нас не редкость.
Сомневаюсь. Просто ты сам себя убеждаешь в том, что нужно дать пользователю. А оно нафик на самом деле не нужно.

hVosttне правда. если у нас предусмотрена отчётная система, то будут отчёты, всё по феншую. но в ином случае мы не будем делать левые отчёты, если всё можно показать в гриде с экспортом в PDF/Excel.
Да иных случаев и нету. Есть отчеты, есть сетка. Крутой грид тут не нужен.

hVosttну тя понесло. естественно Excel круче любого веб-аналога. но excel платный, при чем для платный для каждого конечного клиента. а веб работает везде, теоретически даже на пылисосе и кофеварке. поэтому нужны компромисы. хотя в рамках одной организации можно развернуться, но у нас часто проекты разрабатываются для использования как в интранете, так и в интернете. и с течением времени перекос в облака.
Разумеется Excel платный. Но есть есть лицензии на SSAS, то о чем речь? Ты где-нибудь выдел такого упоротого клиента, который купил себе BI от майкрософта, но на Excel сэкономил? Ну бред же. Облака идут лесом, уже писал тут, и в форуме Java. Энтерпрайзу не нужны облака, у него они и так есть, свои. А в свете санкций и прочего унылого говна от пендостана, хер кто захочет хостить свой бизнес в облаках.

hVosttЭто очень неудобно. Даже сам как пользователь скажу, какая-то отдельная форма. Зачем? Настроил грид под себя, если надо сохранил настройки. Всё прям на месте, без открывания лишних форм.
Почему неудобно? Вполне себе удобно, в настройках настроил и забыл. Не нужен водителю автомобиля под носом бардачок, люк бензобака и клеммы от аккумулятора для быстрой смены полярности прямо на ходу. Водителю нужно самое необходимое для вождения. А конфигурация выносится на задний план, не мешая основной работе. Это и называется оптимизация труда пользователя, основное правило которого - не перегрузи UI лишним.

hVosttМСУВремя самое минимально. Просто задача будет решаться не в лоб, как ты это себе видишь, а из-под другого угла. У каждой задачи есть несколько вариантов решения.
Так я согласен! Компоненты не всегда нужны. Иногда и бюджет не позволяет, и в наворотах клиент не нуждается.
Вопрос в другом. Можешь ли ты принять тот факт, что в зависимости от задач и бюджета можно воспользоваться компонентами, или ты железно упёрся в "не нужны"?
Да дело даже не в бюджете. Их себе могут позволить даже нищеброды, не говоря уже про какие-то компании. Суть в том, что компоненты вообще не нужны в 99% случаев, т.к. хватает всего штатного + тот же jquery, который к тому же предлагает не только компонентную клиентскую модель, но и наикрутейший апи для работы с html, dom и прочий ajax. Телерик тут точно не нужен.

hVosttТак и не надо отказываться от екселей. Пусть будут. Но переносить решение задачи на плечи клиента с экселем, когда это же самое можно сделать прям в вебе, тоже какая-то вафля.
При работе с SSAS только эксель. Ну в крайнем случае SSRS, но тогда теряется ряд функционала. Гриды сразу идут лесом.

hVosttЯ не понимаю, а почему ты это решаешь. Это решается клиентом что ему нужно, как это должно выглядеть. Если он не хочет отдельную форму, ты что откажешься от разработки? Или упрёшься рогом, не пойму?
С какого перепуга это должен решать клиент? Клиент заказывает функционал на основе бизнес требований. Почему я должен отказывать клиенту в форме? Ровно как и зачем клиенту заказывать форму? Клиент попросит функционал. А я ему дам форму, формы, тетрадь с ручкой или полотно с красками. Клиенты часто даже два слова не могут связать и объяснить, что им нужно. А ты их про гриды будешь спрашивать Для этого есть аналитика, после обследования предметной области рождается функциональная спецификация с требованиями. Какие гриды? Какие формы? Функциональная спецификация вообще далека от архитектуры и реализации. В идеале по этой спеке можно вообще на чем угодно запилить решение.

hVosttНужен, потому что телерик предлагает такой функционал, который ты в одиночку с наикрутейшим jQuery не сделаешь и за год пыхтения.
"Клиенту это не нужно" -- извини, аргумент крайне ущербный.
Если клиенту нужно - сделаем, не проблема. Но чаще это нужно - более абстрактно, чем ты себе представляешь. Ты и сам прекрасно понимаешь, что твои фантазии о том, что клиенты заказывают себе гриды - хрень на постном масле Ну может, на луне они такие, эти клиенты.

hVosttТы уж позволь клиенту самому решать, что ему нужно, а что нет.
Так и происходит. Но клиент не опускается до уровня "гридов и настроек". Он обще описывает, что ему нужно для процесса. Мы даем инструмент. Какие еще "требования гридов"? Ты как из космоса.

hVosttОбычно клиент хочет богатый, отзывчивый интерфейс с кучей возможностей, а не ущербный тупой WebGrid с отдельной настроечной формой -- это прошлый век.
Обычно клиент вообще не знает, что такое интерфейс, отзывчивость и WebGrid. Он хочет чего-то такого, что можно на чем угодно запилить.

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

hVosttМСУ,
вообще, не надо рассуждать голословно, достаточно посмотреть и пощёлкать
http://demos.telerik.com/kendo-ui/grid/index
Я знаю телерик еще по веб формам, когда ты еще в школе учился :)

hVosttи представить сколько надо труда вложить, чтобы нечто подобное получить на WebGrid.
Так что вопрос только в том, нужно ли это твоему клиенту. Если твоему это всё не надо, тогда ок, спорить не о чем.
Я ж тебе повторяю, не нужно ничего такого в WebGrid. Настройки и прочие танцы выносятся в отдельный пул, основной - это рабочее пространство, минимально захламленное, только основные инструменты, ничего лишнего. Быстро и просто решаются задачи, усложнять ничего не нужно.

hVosttА теперь давай представим, что тебе жутко не повезло, и тебе попался заказчик, который хочет такой функционал, как у телериковских компонентов.

Что ты будешь делать?

Вариант 1. Вступить в дискуссию с заказчиком, и убедить его, что он тупой, и что он не прав, и ему это не надо.
Вариант 2. Послать такого дебила к чёрту.
Вариант 3. Не ипсти никому мозг, и воспользоваться готовыми компонентами, чтобы епстись самому по пустякам.
Если есть требования по телерику от заказчика, мы купим компоненты и сделаем так, как хочет заказчик. В бюджете будет прописан пункт по лицензированию компонентного слоя. Никаких вопросов. Но % таких "пожеланий" практически нулевой.

hVosttТы просто очень далёк.


hVosttЯ не знаю с какими ты там телерик веб формами ты имел дело, но когда-то давно я их тоже щупал, и они мне не понравились, тогда мы делали одно решение на DevExpress на WinForms.
Обычные телерик под web forms, что тебя удивляет? Даже на SharePoint 2007 умудрялись натягивать, где-то даже рецепт есть. Очень тормозные и неповоротливые, особенно RadGrid и RadScheduler. Жирное гавно. У меня даже целая телериковская категория есть http://codearticles.ru/catalogs/90

hVosttСегодня ты рассуждаешь так, что либо твои задачи примитивные, либо ты яростный любитель кодинга и с наслаждением стучишь по клавишам. Но компоненты (не важно, телеркиовские или ещё какие-то) решают большой объём задач для реализации UI логики
Да причем тут кодинг, ярость и примитив? Просто я уже вышел из твоего возраста, когда хочется выкатить на проспект не самокат для тихих вечерних прогулок, а танк - для "а вдруг пользователь захочет". Есть требования, есть реализация. Всё остальное идёт в топку. Производительность труда прльзователя и проработка удобного UI - на первом месте. Нагромождение UI идет на свалку.

hVosttПросто ты не в теме, и застрял на студенческом WebGride. А то, что WebGrid студенческая поделка, никаких сомнений и быть не может. Примитивная, деревяная поделка. Сегодня нужен рич.
Просто я знаю, что такое требования и их реализация. Мне пофиг, какая там поделка WebGrid, главное одно - оно в коробке, оно легковесно и просто до безобразия. Воткнул и заработало, никаких педалей.

hVosttМСУДа причем тут кодинг, ярость и примитив? Просто я уже вышел из твоего возраста, когда хочется выкатить на проспект не самокат для тихих вечерних прогулок, а танк - для "а вдруг пользователь захочет". Есть требования, есть реализация. Всё остальное идёт в топку. Производительность труда прльзователя и проработка удобного UI - на первом месте. Нагромождение UI идет на свалку.
Да бред какой-то ты несёшь. Точнее, у тебя юношеский максимализм: нет -- и всё тут. А я говорю, в зависимости от задач и обстоятельств, я-то себя возможностей не лишаю, а ты упёрся как обычно лишь в один идеальный, расово верный, подход. Но мир сложнее, чем требования заточенные под твой любимый WebGrid
Я никуда не упирался, просто обвешивать ёлку колёсами от танка в большинстве случаев не нужно, поверь мне. Когда это реально потребуется - вообще не вопрос. WebGrid не панацея, хоть на своём html хелпере запилю.

hVosttНу вот видишь, тебе тоже нравится "воткнул - и заработало". Только мне как-то параллельно коробочность, особенно с учётом вектора развития .NET-а, кода остаётся только Core + твои библиотеки.
Уже не первый раз ловлю себя на мысли, что используя стандартные компоненты обретаешь мир и равновесие.

hVosttТак и никто и не заставляет. У нас визуальные компоненты используются в одном из 10 проектов.
Так о чем и речь. Зачем их пихать туда, где они реально избыточны.

hVosttПросто я к тому, что нет одного универсального способа. Но когда нужен очень быстро собрать богатый энтерпрайз-рич и много-много форм, то визуальные компоненты это то што доктор прописал.
Когда надо собрать богатый энтерпрайз-рич, веб выбрасывается на помойку, берется WPF и делается чудо. Универсального способа, конечно, нет. Но есть способ, который выстреливает на 99% - это нативностная нативность.

hVosttНекогда возиться с вебгидами, делать свои фильтры и прочее гумно. Можно взять всё из коробки и повесить на ODatу и будет счастье.
А чего с ними "возиться", взял и работает.

hVosttМСУУже не первый раз ловлю себя на мысли, что используя стандартные компоненты обретаешь мир и равновесие.
Просто у тебя наверное нет разнообразия в проектах и клиентах. Ты нашёл гавань и тусишь там.
А нахер мне горящая жопа и безумные сроки. Энтерпрайз adhoc та самая гавань. А в интеграторах и прочем консалте пусть молодежь качается, плавали :)

hVosttУ нас нет заказов на энтерпрайз на WPF уже очень давно. Only web, очнись уже от спячки старичёк!
Онли веб - удел гавноделов. Для планшетов - онли десктоп.

hVosttЧудо на WPF не делается, а делается поделка с очень сложным сценарием использования. Так что в топку WPF.
Да, в топку WPF, я уже давно об этом говорю. Даёшь Java решения!

hVosttИнтеграторы и косалт это другое, ты что-то путаешь. Я говорю про разработку на заказ.
Просто песня :) А интеграторы и консалт не делают разработку "на заказ"?

hVosttКлиенты: банки, сети магазинов, сотовые операторы, компании нефтегазовой промышленности, брокерские компании, телекомпании, государственные учреждения, социальные проекты, застройщики, холдинги... И у всех абсолютно разные задачи.
Ну вот, о чем и речь. Типичная девелоперская помойка, интегратор и консалт в одной роже.

hVosttП.С. и WPF нах никому не сдался, даже в приближении. Если морда, то только веб, или мобильные приложения, ничего другого даже не обсуждается ни в каком приближении. Так что просыпайся-просыпайся ))))
Так я не агитирую писать на WPF. Я говорю, что рич WPF и рич веб - это как медведь и страусиное яйцо. Ублюдочный веб не везде приемлем.

hVosttПри чём тут планшеты?
Видимо, тренд.

hVosttМСУДа, в топку WPF, я уже давно об этом говорю. Даёшь Java решения!
Шило на мыло. Одно говно заменил на другое говно под другой маркой. Смысл?
Инвестиции в своё будущее.

hVosttМСУПросто песня :) А интеграторы и консалт не делают разработку "на заказ"?
Нет, ты упал что ли?
Вроде не падал. А что?

[quot hVostt]
МСУНу вот, о чем и речь. Типичная девелоперская помойка, интегратор и консалт в одной роже.
Ты попутал интеграторов и разработку ПО на заказ.[quot МСУ]
"Разраб ПО на заказ" может быть интегратором и консалтом. Так уж и быть, открою тебе правду.

hVosttМСУТак я не агитирую писать на WPF. Я говорю, что рич WPF и рич веб - это как медведь и страусиное яйцо. Ублюдочный веб не везде приемлем.
Где не приемлем? Примеры?
На планшетах же. Примеры? Возьми планшет, запусти ублюдочный веб и поработай. Не, не почитай новости, а поработай в браузере. Осознание придет быстро.

Алексей КМСУУблюдочный веб не везде приемлем.Что это было?!
Кто здесь?

AxeleronТак это планшет маловат и неудобный, да и интернет медленный - вот и результат.
Ты предлагаешь сотруднику в командировке взять тяжелый PC и начать привыкать к фитнесу? Да и интернет в случае планшета не нужен. В этом вся прелесть отсоединенного режима.

AxeleronВэбу-то за что так досталось от тебя?
Я всегда вещал: вебу - вебово. Я не против веба, веб - счастье. Но за уши тянуть его во все дыры - беспощадная утопия.

hVosttМСУВидимо, тренд.
Так и к чему ты клонишь? Что на планшетах веб не работает, или что?
Я клоню к тому, что на планшетах веб приложения для работы - мерзкое смердящее дерьмо и 100% деградация производительности пользователя. Только десктоп! На планшете в вебе можно, разве что, новости читать. И то отстой.

hVosttМСУ"Разраб ПО на заказ" может быть интегратором и консалтом. Так уж и быть, открою тебе правду.
Ну и что, разраб на заказ может ещё и бухгалтерию вести, и детей нянчить, и на субботниках листья убирать. Зачем ты про интеграторов вообще говоришь? Мы часто сотрудничаем с интеграторами, которые тоже делают нам заказы. Что с того?
Ну пусть нянчит детей, ходит в сад и водит хороводы. Вы вообще о чем говоришь? Я свою мысль выразил еще в начале. Ты прицепился к тому, что интегратор не может разрабатывать софт. Что за чушь?

hVosttМСУНа планшетах же. Примеры? Возьми планшет, запусти ублюдочный веб и поработай. Не, не почитай новости, а поработай в браузере. Осознание придет быстро.
Поработать на планшете... не потреблять контент, а именно работать... угумс...
Что смущает? Классический пример - ревизия. Приходит проверяющий, отмечает факты нарушения на планшете, заполняет чек-листы, на лету фотографирует объекты, пишет замечания. Всё это работает в нормальном отсоединенном режиме, на объектах может отсутствовать вайфай или интернет. Человек объезжает все закрепленные объекты на карте, отрабатывает чек-поинты. Туда же можно закинуть задачку коммивояжера, которая определяет оптимальные маршруты для проверки объектов. Когда появляется интернет, нажимается одна кнопка и все отработанные задачи синхронизируются с центром. Всё, задачи на сегодня выполнены. И всё это на легком и удобном планшете. Какой в жопу веб, клоуны?

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

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