Это интересно. Сразу идею shambho не понял. Спасибо

В смысле повесились :)

Мне сказали, что модуль FileUtils, по понятным причинам, не включен в rtl. Ну и на серваке настроена компиляция dpr. Завтра, сказали, настроят компиляцию lpr.

Lazarus просто не пробовали. Вышлите проект, если это возможно. Я обещаю попробовать

а как же работа в браузере?

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

спасибо, учтем

мы же клиентскую программу делаем? А если я правильно понимаю node js это server side

мне кажется это планируется

Промышленные программные продукты не создаются, а «прорастают». Они растут годами, под влиянием множества программистов, разной квалификации. Ну и в какой-то момент может возникнуть идея — а что если все это выбросить и начать заново. Например, на каком-нибудь современном продвинутом языке. Сколько таких попыток видел — все неудачные. Почему? Да фиг знает. Медицинский факт. Наверное, потому что бизнес-логика никуда при этом не девается, а заменятся но новый вариант с новыми багами, после чего дерево нужно опять начинать растить.

>интересно как тут происходит работа с базой данных
сервер приложений принимает soap-запросы в которых передается sql или ХП с параметрами. Обратно возвращается ответ сериализованный в json. Такой вот сетевой аналог JDBC.

>И конечно хочется тестов производиельности
Пока плохо

>А нет ли смысла перейти с delphi на java а там и GWT есть,
может когда-нибудь?

Мы четко разделяем компоненты и приложения, которые из этих компонентов состоят. Для библиотек мы делаем js-обертки ручками, поэтому работаем с Ext не напрямую (так как, согласен, Sencha — любители dom). Сами приложения у нас «тупенькие». Никакой многопоточности, сокетов, win api и др. изысков. Единственная заморока — модальные диалоги. Над ними долго трудились.

С датасетами все отлично. Просто у нас собственный сервер приложений, который обеспечивает доступ к данным. С ClientDataSet тоже хорошо получилось. Сделали на js — скорость неплохая (сами удивились).

>жаль на самом Delphi так делать нельзя.
Над этим не думал. Поразмышляю на досуге

>Delphi кода, это просто невозможно в полной мере.
Да все прекрасно работает, не сомневайтесь. И dfm мы разбираем и var|оut аргументы. И события и все все…
Вы, наверное, путаете синтаксис языка и runtime library? Синтаксис поддерживается в полной мере.

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

Я лично этой задачей не занимался, но по разговорам в курилке могу предположить что весились все

если честно, нет. Вся контора начинает на меня недобро смотреть :)

для коммерческого использования. Пока тут коммерции нет

дико извиняюсь, что такого языка не знал. А на haxe можно desktop приложение написать? И если можно, то как нас это продвинет к идее перевода pascal->js?

фишка в том, чтобы сохранить desktop, т.е. придется поддерживать 2-а исходных кода

да, все координаты указываются абсолютно, да и в delphi layout'ов нет(разве что в каких-то спец.компонентах)

Это точно. Оптимизация еще предстоит

все три примера рабочие. Проверено в chrome, ff, opera

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

А конструкция современного моста, как и в 19 веке рождается в
творческих муках, а не муках от запора :)