Как некоторые здесь уже знают, я изучаю ASP.NET MVC. До этого был простым спецом по платформе 1С.
Сравнивая платформы 1С и фреймворк ASP+MVC, я все время поражаюсь, сколько же приходится писать на JS и html, чтобы создать обычные простые элементы управления и ввода.
К примеру - аналог поля ввода 1С с ссылочным типом данных. Справа есть кнопка выбора, нажатие на которую открывает форму выбора из списка целевых элементов. Это замечательно.
В ASP+MVC же мне приходится нарисовать поле ввода, прилепить скрытый input, который хранит в себе идентификатор выбранного объекта, на джаваскрипте обрабатывать начало выбора, выбор, открытие формы списка и окончание выбора, запрашивать данные целевых объектов с сервера ajax'ом.
Я не жалуюсь, что работы и кода очень много. Это не является проблемой. Меня не покидает ощущение того, что результат всего этого мартышкиного труда крайне ненадежен, трудно поддерживаем, не является универсальным для всех решений в будущем.
Разумеется, так как сейчас я учусь, я "зарылся". В следующем проекте, на основе полученных знаний, я начну эти элементы, части кода и верстки стандартизировать для себя, отделять зерна от плевел. Но опять же, ощущение, что все не так, что-то не то. Что есть либо готовые решения, либо более надежный способ создания фронт-енда для реляционных информационных баз.
Если вкратце - что лучше подходит из фронтенд-фреймворков для реляционных ИБ?

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

(1) Ну, собственно, я и описал проблему с "позвать бек и показать полученные данные". Разумеется, фронт и бэк разделены друг от друга и выполняют свои задачи. Но если в бэкэнде все четко, по военному надежно, то на фронте творится какое-то лгбт.

(0) фреймворки

(2) В данном случае роль играют много факторов.

1. Под простые задачи типа CRUD существуют генераторы кода, которые нагенеривают заготовку фронта и бекенда. Я далек от С# но под джаву есть https://www.jhipster.tech/
2. Как правило на 1с и на C# делают решение разных ценовых сегментов, и судя по всему один однотипный дизайн на всех как в 1с ни сильно интересен более серьезным заказчикам
3. Если набить руку, то окажется, что не так уж и долго делать вами описанные операции.

(0) Клиента с сервера вызвать можешь ?

(0) вы теперь фронтендер. Стили , разметка и тд.
Это отдельное направление. А хранимки в базе данных ( которые надо дергать)
напишут другие проги. Проги БД. Но есть и плюсы.
Если с 1с элемент  на форме кривоватый в браузере- ждем новый релиз платформы.
А вы быстренько поправите .

(6) за хранимки в БД сейчас уже ругают. По архитектурным феншуям, бизнес-логика должна быть в доменном слое архитектуры, а не в слое БД. Иначе образуется жесткая привязка к определенной СУБД

(7) ну если ругают …. Тогда фронтендеру скажут какие таблички дергать и
, куда апдейтить и какие тексты запросов должны быть . А скажут все теже проги БД

(7) Фронту должно быть абсолютно пофигу, хранимки у тебя там или запросы в цикле. Он свой жисон (условный) получил и рисует.

(9) не совсем так. Это бизнес-логике должно быть пофигу, с какой БД или облачной хрени в неё данные прилетают, и какой интерфейс у неё данные забирает. Фронт далеко не главный, главный слой доменной (бизнес) логики

(0) ….. уже три в команде … фронтендер, тот кто фронтендеру собирает xml или json и прог БД .
Так что все не так плохо доя фронта.

(10) О том и речь. фронт получил жисон. А от кого он его получил... МОжет, сегодня он с локалхоста берёт, а завтра на амазон полезет.
Речь о том, что фронт, хранимки и прочие дб - как-то фиолетово. Должно быть.

(12) ладно, так тоже можно сказать. Фронт ничего не должен знать, как и откуда данные были получены

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

Фронт конечно лучше делать на слвременном фреймворке : реакт, вью, ангулар. Реакт из них самый популярный в коммерческой разработке

Вспыл в памяти пример, как жесткая привязка архитектуры к БД вышла боком. Одно предприятие написало под себя нетленку (не на 1с, на этих ихних тру-языках). Нетленка очень понравилась руководству, и её было решили продавать другим предприятиям. Но вот беда, в нетленке много бизнес-логики сидело в хранимках oracle. На том и встали продажи. Не много нашлось желающих покупать нетленку и попутно дорогущие лицензии oracle. А сделали бы по-человечачи, сосредоточили разработчики бизнес-логику в доменном слое, клиенты сами могли бы выбрать, какую СУБД им использовать. Хошь постгрю, хош мускуль, хошь монгу. Потребовалась бы лишь небольшая переработка слоя взаимодействия с БД

Собственно, поэтому в 1с и никогда не завезут NoSQL. В 1сных конфах много бизнес-логики жестко врезалось в запросы к БД

(16) если нужна производительность то всяко придется затачивать под бд

(15) "на слвременном фреймворке ... ангулар"
дядя, а вы Ленина видели?

вроде ТС о другом спрашивал, если какие то инструменты упрощающие работу с фронтом, как то так я его понял

(19) конечно есть. Готовых компонент полно.
Писать на реакте под бутстрап да с компонентами совмем не сложно. Практически ни о чем думать не надо

(17) заточка во имя производительности это индексы таблиц, оптимальная структура таблиц, гранулярность блокировок и вот это всё. К бизнес-логике оно не имеет отношения

(21) ага кто поддерживает коррелированные запрсы, а кто-то нет. А ты их юзаешь ибо удобно

(21) или языковые индексы как в постре у ыузинв

(22) ты сейчас смотришь на работу с БД глазами 1сника. 1сники в этом плане весьма своебразные. Дали нам пакетные запросы, а мы и рады писать километровые портянки. В тру-бэкенде так не принято, там стараются обходиться простыми CRUD-операциями. И живут же нормально, пишут сложные системы

(21) Приложение состоит не только из безнес логики. Естественно затачивать бизнес логику под БД не стоит, но слой слой инфраструктуры/адаптеров будет сложнее. Думаю об это речь.

еще многое зависит и от самой задачи, вот вы делаете решение гибким, поддерживающим множество СУбд, с мультиплатформенностью и т.д. А заказчику нужна просто приложуха с простеньким назначением. Зачем тратить кучу времени на создание такой гибкости, которой никто не воспользуется? Может это и не тру, но для узконаправленных проектов вполне нормальная практика такой привязки. Это экономит время разработки, а заказчику сумму работ.

(26) Применение так называемой чистой архитектуры оправдано для монолитных интерпрайз приложений. Иначе довольно рано наступит момент, что поддержка станет адом, если порезать приложение на сервисы/микросервисы, то такая архитектура позволяет применять простенькие архитектурные подходы и не париться. Но бизнес логика в БД - это слабый подход и в плане поддержки и в плане производительности

Значит, реакт? У меня на очереди был ангулар, потому что на слуху часто всплывает. Здесь двое отметили, что реакт для бизнеса. Значит, реляционная база данных + реакт + бустрэп = само то?

(25) от переноса логики с одного места в другое приложение меньше не становится. Если нужно тебе написать зубодробительный алгоритм расчета себестоимости, то он в любом случае будет зубодробительным. Мало того, когда идёт умышленное разбиение на слои, количество кода несколько увеличивается. Но эта жертва во имя облегчения жизни в будущем

(26) принятие преждевременных решений тоже зло. Например, можно нашинковать сотню микросервисом, уграбливая кучу усилий на взаимодействие между ними. Всё во имя гипотетической возможности сложной децентрализации приложения. Но если децентрализации приложения так и не настанет, то все усилия окажутся мартышкиным трудом

(30) вот и я про это же. Надо здраво оценивать задачи и ее перспективы.

(0) Ты бы ещё голосовой ввод к окошку прикрутил... А у 1С скоро так и будет. Говоришь "они опять продали эту кривую фигню и ту зеленую вчерашним дебилам за наличку." А тебе сразу накладные и эсф  и кассовый чек сами оформляются.

(32) Ну вообще то, когда к нам на работу приходила важная шишка из чиновников, ее попросили сказать мнение о 1С. Она как раз и отметила, что очень удобная программа - мышкой наводишь, хочешь что то выбрать, а 1С сама уже подставляет то, о чем она подумала. Ей это очень понравилось и отложилось в памяти. 1С знает путь к сердцу женщин

(33) А ещё там котик есть!

(33) А с Украины не приходили? Белый цвет на синий поменять в такси?

(0) Я когда игрался, на vue делал. Там все просто. Связываешь элемент с данными, пишешь метод, забирающий эти данные с сервера, vue тебе сам все отрисует как надо.
Ну с простотой в 1С конечно не сравнить, но MVC - это те же яйца, только в профиль.