Web-Framework, позволяющий забыть о мерзком HTML?

Я не понимаю, зачем они тогда вообще нужны?

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

*думая

Вот ты и жрёшь говно, которое стало смердеть ещё в конце 90-х.

А я - не хочу его жрать.

потому что вёрстку верстают верстальщики, код кодят кодеры

Скольким идиотам, кроме тебя самого, нужно говно, описанное в первом посте?

Дык кто же против того, чтобы фреймворк предоставлял инструменты для дизайнера приложения в виде тех же form builder'ов? Пусть оно сгенерирует XML с описаниями настроек виджетов, а фреймворк это подхватит и будет предоставлять программисту в виде какого-нибудь if ( checkBox1->checked() ) inputText1->enabled=true

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

Причём тут дизайн? дизайнят дизайнеры

Не надо создавать проблемы сразу всем, пусть все делают как им нравятся

А потом парой сядите и натравите шаблонизатор на шаблоны

Ты хочешь такое?

Вот это маняфантазии.

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

Посмотри БЭМ от Яндекса.

Вам нужен веб-фреймворк, в котором уже встроены шаблоны для вывода в форматах HTML, PDF, XML, JSON, SVG, JPEG, MKV и TEX? Их всё равно придётся кому-то писать и редактировать (дизайнеру?), но как только все шаблоны есть, View останется только выбрать нужный шаблон и передать ему извлечённый из базы и обработанный бизнес-логикой контент.

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

contentBlock1.addInfoBlock().addContent("foo, bar" + mainContent)

Программирование то, оно ведь не о том, чтобы пользоваться готовыми абстракциями, а о том, чтобы реализовывать свои. а то о чем ты говоришь, можно было бы назвать «секретуирование», имея в виду, что секретутка вполне себе может использовать всякие ексели и аксессы.

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

Сава богу ASP и GWT закопали, остальные фреймворки «разрабочик-вебни-не-обязан-знать-js-html» тоже начинают пахнуть. Чудес, не бывает, так-то.

Веб-фреймворки заточены на веб, ну офигеть теперь.

extjs

есть такие системы, но они настолько не гибки и ограничивает полет фантазии что не пользуются популярностью.

Как пример на питоне http://pyjs.org

У тебя просто батхерт от того, что за несколько лет ты научился клепать визитки, а твердого фундамента и основ так и не уловил, ибо легаси и гонки «технологий». Нанырялся, теперь говно от фреймворка отличить не можешь, бывает, это ж вебдев :D

А потом сайты открываются по минуте, выжирая батарейку. Отличная идея, тупица от девелопмента. Еще ты видимо не в курсе, что кроме твоих влажных низкоуровневых абстракций есть бизнес-логика, на которой часто нужно полностью сосредоточиться. Но разжевывать тебе это как объяснять корове арифметику.

Ну так а разве базовый HTML - это сложно?

Можно все еще больше упростить, используя бутстрап. Да ещё и нестрашно сразу будет.

Везде тот же хтмл - это гуд. Стандарты и все такое.

Тебе всегда казалось неправильно.

Какой манямирок десктуха.

но совершенно не решают проблему абстрагирования

а где ты был последние 10 лет? такие фреймворки были, но все сдохли по понятным причинам, т.к. leaking abstraction + не могу угнаться, в итоге победило разделение труда на фронтенд и бекенд разработчиков

а твои мечты слава богу в прошлом

Как пример на питоне http://pyjs.org

You can write web applications in Python - a readable programming language - instead of in HTML and JavaScript, both of which become quickly unreadable for even medium-sized applications

Это было неправдой уже даже на момент создания этого недоразумения. Модульный фронт давным давно перестал быть фантастикой, ТС, оторви свою жопу наконец.

Теоретик моде он

Grails + custom taglib?

Ты хочешь что-то типа сенчи (бывший екстжс) или что?

.net mvc

Видел такое в Oracle Application Express.

Меня поражает до глубины души тот факт, что мега-чудо фреймворки наподобие Mojolicious, Django, Catalyst и т.д. (миллионы их) заставляют своих пользователей впечатывать всё тот же мерзкий HTML-код, да ещё сбоку прибабахивать к нему JavaScript.

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

Есть другой подход (но это подходит только для приложений, т.к. противоречит текстовой верстке хтмл+цсс) когда ты делаешь лейоут, накидываешь в него элементы и вообще не думаешь про оформление, т.к. компоненты всегда выглядят одинаково.

Есть такие. Называется, кажется, Visual Scada. При изменении состояния, сервер транслирует на любой объект рисования (sdl, opengl, <canvas>, GDI, vnc) картинку, представляющую текущее состояние системы. И принимает сырой ввод с мыши/клавиатуры/.. Абстрактнее только стриминг-видеоигры. Для действительно серьезных проектов. Очень советую, кек

Так абстракции для этого и строятся, чтобы сосредоточиться на предметной области, корова тут по ходу — это как раз ты. И насчет перформанса ты тоже че-то кукарекнул, но не обосновал, почему это динамическая отрисовка куска HTML длолжна там много жрать.

А чойта это HTML мерзкий?

Ту путаешь динамическую отрисовку хтмл и абстракции.

но это подходит только для приложений

Не является веб-приложением разве что статичная HTML-страница без JS. Всё остальное - это итак веб-приложение. А в том, что веб-приложения выглядят аляповатым «кто во что горазд» - не вижу ничего хорошего. Мало того, разработчики сайтов для любых крупных серьёзных компаний думают аналогично, поэтому корпоративные порталы не похожи друг на друга разве что темами оформления.

Так никто не мешает делать не «по веянию моды», а «когда это действительно нужно». Вот и всё.

разделение труда на фронтенд и бекенд разработчиков

Как тогда объяснить существование такой священной коровы «крупных проектов» (а-ля mail.ru :) ) как «шаблонизарторство», когда прямо внутри HTML+JS вписываются ещё и куски кода на очередном птичьем языке, обращающиеся к структурам данных из основного кода приложения?

На самом деле хаки в CSS+JavaScript - это плохо, очень плохо, это омерзительно. Собственно, сам HTML не так плох, ведь он изначально оперировал осмысленными абстракциями наподобие «списка», «таблицы», «радио-переключателя». Невменяемой бредятиной его сделали именно CSS+JavaScript.

Объективно HTML сейчас хуже скомпилированного ассмеблерного кода: ведь если «дизассемблировать» байт-код вполне можно даже вручную, то понять, как будет выглядеть то или иное нагромождение тегов - можно только запустив всю эту галиматью в браузере и вооружившись каким-нибудь Firebug'ом.

Тот же JS, например, это позволяет легко.

Нужно, чтобы код одного приложения не разделялся на «клиентский» и «серверный». Пока это позволяет разве что Node.JS

Визуальных фреймворков под JS действительно много, из них полно весьма продвинутых, вот только все они в любом случае:

1) «Анимируют» ранее чем-то «высраный» HTML-код

2) По определению будут генерировать GUI-виджеты на клиенте, что не всегда оправдано

Не является веб-приложением разве что статичная HTML-страница без JS. Всё остальное - это итак веб-приложение.

Нет. Отделяй сайты от приложений. Да сайт может быть перегружен скриптами и бессмысленными элементами оформления, но сайтом от этого быть не перестаёт.

А чем сайт - не программа? По-моему вполне себе программа, и у неё есть своя логика взаимодействия с пользователем, свои состояния автомата, свои события и обработчики событий (в том числе те, которые мы не программируем, но они тем не менее есть, захардкодены в движке браузера - для тех же интерактивных элементов типа комбобоксов или кнопок отправки формы, созданных чистым HTML'ем).

А как вам GUI-приложение, которое по даблклику на изображении в файловом менеджере - просто рендерит картинку и показывает её, не предоставляя никакого интерактивного интерфейса. Это типа больше приложение, чем сайт jsfiddle? :)

Границу тут следует (она размытая но следует) прокладывать по назначению. Т.к. именно назначение определяет характер размещения элементов. Дело не во взаимодействии а именно в размещении элементов.

Т.е. сайт предоставляет юзеру контент. Текст. И для его этого хтмл хорошо подходит: отступы, обтекания и т.п.

Приложение обменивается с юзером данными (обычно забирает) и тут для нормального размещения элементов ввода приходиться прыгать с бубном и скриптами ибо хтмл и цсс не подходят для этого.

Как результат появляются наборы хаков (фреймворки) для эмуляции нормального лейоутинга на хтмле. А потом их притаскивают в текстовую верстку. Но понять в этой каше как в результате будет выглядеть приложение становится невозможно, поэтому и происходит возврат к каше в стиле пхп/асп/жсп. Что б на первом этапе можно было выкатить формочку без привязки к данным.

Из майкрософт(р) ворд(р) хтмлки экспортируй.

Про vaadin еще не говорили? В теории там можно ничего не знать про html, javascript, css, gwt.

Приложение обменивается с юзером данными

Положение курсора мыши - не данные? А клик мышью или драг-н-дроп - разве не ввод данных? По-моему вполне себе ввод.

А насчёт статичных ГУИ-приложений - написал выше.

Если отказаться от концепции «это просто текст с обтеканиями, который ещё просто так умеет рассчитать траекторию полёта на Луну», то можно было бы уже давно сделать сайты просто формами с накиданными на них виджетами, в том числе текстовыми, где есть картинки и обтекания.

HTML когда-то был стандартом объектной логики «сайтов» (DOM).

Но поскольку реально нужно в 100500 раз больше классов объектов и вариантов их поведения - был придуман «хитрый план» в соответствии с которым любой инстанс класса HTML может мутировать хоть в рыбу, хоть в планету Транай.

Этот подход - принципиально крив и убог: нужно было эволюционировать HTML в сторону нормально расширяемого набора виджетов с объектной логикой. Но мы имеем то, что имеем и поэтому хотелось бы хотя бы эмулировать желаемое на базе того, что уже есть.

vaadin - это очень круто и, похоже, именно то, что нужно.

Я одного не понимаю: почему в таком случае не добавить ему возможность компилировать приложение в его веб-форму, пригодную для запуска на tomcat'е ИЛИ в десктопную форму, которая будет запускаться автономно от браузера.

Такое впечатление, что до этого им остался всего один шаг...

Положение курсора мыши - не данные? А клик мышью или драг-н-дроп - разве не ввод данных? По-моему вполне себе ввод.

Выкини формализм, я тебе уже описал.

Я, в свое время занимался разработкой коммерческих фреймверков, для внутреннего использования, под конкретные нужды клиента. Практически, все как ты хочешь, чтобы любая секретарша могла пилить веб не зная нихрена, кроме самого фреймверка, прямо так и писалось, если юзер мышкой клац, хтмлформа всплыви!!! только на английском. Никакого HTML, а уж тем более JS, что ты, что ты. И гуй прилагался с админкой. Там не надо даже знать, где сервер, где клиент, о том что есть какая-то сеть, которая что-то куда-то пересылает, можно только догадываться. Если есть лишние 5-7 лямов, можем обсудить.

«шаблонизарторство», когда прямо внутри HTML+JS вписываются ещё и куски кода на очередном птичьем языке

Это ж для верстальщиков, чтобы они делали на энтом «птичьем языке» и не лезли в основной код.

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

А в чём здесь в таком случае суть «разделения обязанностей»?

Вы когда-нибудь читали пьесы? Помните как там действующих лиц и обстановку описывают перед самим действием?

Вот именно это и есть View, я всё остальное - это грубое нарушение логики MVC!