Обратитесь к автору http://visual-t.ru/ с просьбой убрать весь доступ к локальным дискам без разрешения пользователя и более чётко специфицировать(сертификаты, шифрование и проч.) связь с внешним миром по сети и получите браузер, только принимающий не html+js а XML+DieselPascal(суржик).

И кстати я серьёзно. Я не удивлюсь, если узнаю, что автор сам об этом задумывался. При наличии востребованности по просить автора о (Nginx или Tarantool) + DieselPascal со стороны сервера.

И у кого сомнения, что это не будет круче html5+js <-> node.js? При серьёзных человеческих и финансовых вложениях естественно.

p.s. "суржик" - это авторская терминология. И если бы всё не было замкнуто на одном человеке а появился бы коллектив единомышленников без снобизма со стороны широко известных инструментов лично я с удовольствием с прикладной точки зрения писал на суржике :)

p.p.s. Если вы что то придумали, загляните в соседнюю ветку того же форума, может вы уже как минимум второй. Кто не знает автора можно найти на http://www.sql.ru/forum/delphi

"крутость" это я легкомысленно конечно слово применил, и точно не ради холивара.
Просто наблюдая за ростом страниц в теме " Локальная сеть: web-браузер или десктоп " думаю о более широком понятии корпоративная сеть(т.е. не обязательно локальная), а значит нет препятствий обязать не конкретный браузер в обще принятой терминологии иметь а нечто работающее по тем же принципам, а именно интерпретирующее нечто полученное от сервера:
тонкий клиент 1с <--> Сервер 1с
"Суржик" <--> Предполагаемый сервер "Суржик"
.....
.....
Прочие аналоги, где диалект алгоритмизации на клиенте и сервере аналогичен и клиент всегда готов завтра что то новое получить от сервера и начать полученное интерпретировать по аналогии с html+js

А браузеры с html+js остаются только для случаев, когда заставить клиента устанавливать себе что либо для работы с "нашим" сервером не реально или как минимум сложно.

дополню...
Имхо. Ели меня поставить перед выбором для корпоративного проекта между
традиционный браузер html+js (и следом за этим проблемы мультибраузерности или вау изменилась политика подключения плагинов, или ещё что то внезапно поменялось в api,abi,......)
или нечто выбранное по сути аналогичное(клиент интерпретирует контент полученный от сервера), но подконтрольное мне в развитии,
Я на 101% выберу второе.
С оговоркой: имею достаточное количество ресурсов на ведение проекта сегодня и в перспективе.

skyANAexperience"крутость" это я легкомысленно конечно слово применил, и точно не ради холивара.
Просто наблюдая за ростом страниц в теме " Локальная сеть: web-браузер или десктоп " думаю о более широком понятии корпоративная сеть(т.е. не обязательно локальная), а значит нет препятствий обязать не конкретный браузер в обще принятой терминологии иметь а нечто работающее по тем же принципам, а именно интерпретирующее нечто полученное от сервера:
тонкий клиент 1с <--> Сервер 1с
"Суржик" <--> Предполагаемый сервер "Суржик"
.....
.....
Прочие аналоги, где диалект алгоритмизации на клиенте и сервере аналогичен и клиент всегда готов завтра что то новое получить от сервера и начать полученное интерпретировать по аналогии с html+js

А браузеры с html+js остаются только для случаев, когда заставить клиента устанавливать себе что либо для работы с "нашим" сервером не реально или как минимум сложно.
Вы заметили, что начали с "нет препятствий обязать", а закончили на "заставить клиента устанавливать себе что либо... не реально или как минимум сложно"?
Вкупе с "это я легкомысленно конечно слово применил" забавно выглядит :)

Совершенно верно. Я о корпоративной среде. Что в корпоративной среде есть препятствия определить стандарты софта на компах сотрудников? Просто клиент в терминологии софта и клиент-человек перепутаны )))