prgmdelphiТо как строится клиентская часть - не очень.
Форумом, по-моему немного ошиблись.

prgmdelphiРассмотрим, на примере "1С:Бухгалтерия" (у них сейчас появилась интернет-версия) - так вот если зайти в это приложение и с помощью функции "Просмотр кода" в Google Chrome посмотреть html-код сгенерированной страницы (см. вложение), то мы увидим массу сплошных div'ов.
Лет 10-15 назад компоновку страниц делали на таблицах. Это было крупным и массовым заблуждением. В отличие от таблиц, div позволяет задать только иерархию элементов. А через CSS для них можно отдельно задать любую компоновку. Поэтому огромное количество современных инструментов интенстивно использует div-ы для создания HTML.
В данном примере мы видим таблицу реализованую на div-ах. Это, конечно, клиника с перегибом в другую сторону. Но многие радикальные css евангелисты этим увлекаются.

prgmdelphiХотелось бы понять как происходит генерация подобных страниц.

Почему именно "генерация"?

prgmdelphiПравильно ли я понимаю, например, берут Java и Swing-компоненты проектируют клиентскую часть приложения, по сути как в Delphi, а затем это все каким-либо фреймворком превращается в код html, сгенерировав файлы *.css, *.js и т.п?
Нет. Это один из немногих способов, который уже отмирает. И Swing к этому отношения не имеет.

Сначала был HTML - обычная разметка страниц.
Потом появился JavaScript и DHTML. Которые позволяли менять DOM страницы на стороне клиента.
Этими возможностями никто долго не пользовался особо. Так как компьютеры были медленными, JavaScript интерпретаторы тормозными. А другие браузеры кроме IE - экзотикой.
HTML полностью генерировался на сервере лишь с небольшими скриптами.
Потом произошло два принципиальных прорыва в клиентском программировании - первый это альтернативные браузеры Opera и Firefox. Которые показали что JS и бразуер вообще может работать намного быстрее. А значит на клиенской стороне высвобождается большое количество вычислительных ресурсов.
Вторым прорывом стал jQuery с его селекторами. Который позволил отделить JavaScript логику от HTML разметки и попытался скрыть специфику разных браузеров.
Это всё дало возможность из тонкого клиента сделать толстый (rich). Так как эта революция произошла после уже прорыва в Java Opensource, в Google задумались как использовать существующий opensource на клиенте. И придумали компилятор Java->JavaScript, который называется GWT. В Java всегда было много фреймверков и с развитием JavaSctipt многие из них стали добавляться максимальную поддержку AJAX/DHTML. Поэтому помимо GWT в Java используются Java Server Faces, Wicket и другие. GWT и JSF имеют всяческие надстройки, поэтому это скорее группы фреймверков, а не отдельные фреймверки.
И для GWT и для JSF существуют WYSIWYG инструменты, которые вы называете "как в Delphi".
На данный момент эти технологии развиваются слабо и отмирают. Причиной тому стало развитие pure JavaScript фреймверков таких как jQuery, AngularJS, Knockout.js, Bootstrap, Mustache и множество других. К сожалению сам JavaScript как платформа ещё не достаточно развился и сформировался для промышленной разработки. Ведь за ним не стоят крупные комании, как за Java. Поэтому помимо фреймверков, очень мало других наработок. Но тенденции уже наметились.
Для HTML и без Java существует масса визуальных дизайнеров, таких как Dreamweaver или дизайнер в Wordpress.

prgmdelphiПравильно ли я понимаю, что клиентские части подобные "online 1С:Бугхлтерии" (скриншот топика) создается на основе GWT, JSF, jQuery и т.п.? Т.е. по сути берут некий WYSIWYG-инструмент, поддерживающий GWT или JSF или jQuery и в нем ведут разработку дизайна и некого бизнес-кода связывающийся с сервером для обмена данными? При этом итоговый html-код на выходе, с помощью WYSIWYG, получается автоматом? или все же иначе, например стоит задача разместить на странице кнопку (Button), с помощью инструмента WYSIWYG я это делаю, а дальше как - код, отвечающий за местоположение, стиль, и т.п. этого контрола, прописывается вручную?

У 1С есть свой CRM - Битрикс. Возможно у них есть и свои собственные наработки по клиентской части. Судя по коду, HTML генеренный, а не рукописный. GWT/JSF отдельно, jQuery отдельно. В одну группу их записывать не стоит. WYSIWYG для Web используют, но не так часто. Это имеет смысл только если вы пишете какой-то ERP с кучей форм вроде того же 1C. В противном случае, намного полезнее писать DHTML руками. Так как HTML возможности HTML/CSS намного шире чем узкие рамки выбранного WYSIWYG дизайнера.


prgmdelphiP.S. Я не в коем случае не претендую на то, чтобы меня тут обучали всем тонкостям - просто хочу уловить суть построения клиентской части. На Delphi все понятно, если примитивно рассказать, то разработка корпоративных-приложений, работающих с БД, делается так: проектирования интерфейса выполняется через набор стандартных компонентов (VCL) или сторонних (например, DevExpress если стоит задача получить стальный дизайн), пишется ORM (собственно иерархия классов для связи с БД) и пишется промежуточный слой, где закладывается бизнес логика нашего приложения и через который и будет происходить обмен интерфейса и наших объектов.
Напоминаю, что вы слегка ошиблись форумом: http://www.sql.ru/forum/html-javascript-css
Если хочется понять. То я бы рекомендовал изучить обзорно jQuery, ExtJS и AngularJS. Почитать туториалы, узнать что они вообще умеют. Тогда, ИМХО, вопросов станет меньше.

prgmdelphiПока понял одно - клиентская часть в Web'e не прозрачно.
Чей-то не прозрачно? JavaScript вот же он, перед глазами весь.

prgmdelphiЕсли с серверной части (экосистема вокруг J2EE) мне суть понятна, то с клиентом как-то не очень - десятки разных способов, нет четкого алгоритма в проектировании клиента.
Точто так же как и в Java, помимо JEE есть десятки альтернативных фреймверков.

prgmdelphiИли все же еще не прозвучал ответ от клиента, работающий в этой стези, который мог бы пояснить суть.
Это та самая проблема, о которой я упомянул в первом ответе. Скачок в развитии JavaScript произошел относительно недавно. Единого ведущего вендора для JS нет. Разве что jQuery и ExtJS как-то двигают на переводой. Нет никаких выработаных способов организации кода, слоёв, модульности и много чего другого. Поэтому архитектуру зачастую каждый пишет как ему нравиться.
По поводу паттернов - всё то же самое что и на любом толстом клиенте. MVVM, биндинг, DTO, Rich Domain Model. Правда, недо-ООП в JavaScript слегка напрягает. Но это компенсируется функциональными средствами. Серьезной проблемой для крупных проектов является динамическая типизация. Это одна из причин, по которой, Google, например разрабатывает Go, как альтернативу JS.

BlazkowiczЭто одна из причин, по которой, Google, например разрабатывает Go, как альтернативу JS.
Это я тупанул. Dart - альтернативый язык на замену, а не Go.

Хочу заметить что комбинация Java + ручной продвинутый JavaScript явление довольно редкое.
Если проект JEE, то, зачастую это ынтырпрайз и как следтсвие JSF. Там поминимум JS уже готовый.
Даже если это не клинические ынтырпрайз, то это Java и ExtGWT, так как прогерам было влом учить JS.

А вот в комбинции с современным продвинутым JavaScript именно Java встречается реже. Так как стартапы открыты к альтернативным языкам и платформам и часто выбирают Node.js, Scala, Python и т.п.