Vadim VashkevichДостаточно сложный CRUD интерфейс

Тут противоречие в самой фразе. Вы лучше кусок ERP покажите как будет выглядеть.

Ну и JavaScript ИМХО ужасный язык, чтобы писать всю логику на нем. Лучше бы наоборот было, скажем что нить типа Delphi или Visual Basic и там и там.

Ну и desktop без трехзвенки мало нужен. А на одном вебе с его задержками в сложном приложении не уедешь.

В общем маловато кейсов, да и те что есть какие то сомнительные.

МСУ,

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

Но как основной язык для написания в том числе бизнес-логики, это жесть.

МСУ,

Тут просто вопрос целевой аудитории.

Если простые, но "вывернутые" решения аля мониторинга транспорта (с картами, плавающими окнами), то это одно.

Но если сложные (сопоставимые с ERP) решения (для которых используются платформы SAP, Axapta, 1C и т.п.), то лучше повеситься чем их на джаваскрипте писать.

МСУ,

Я считаю, что наследование через прототипы это бред. И что классы, наследование и явная типизация для сложного проекта важнее, чем функциональщина в том виде, в котором она есть в javascripte'е.

И для кастомизации сложных проектов функции рефакторинга (переход к объявлению, поиск использований (с учетом function overloading), подсветка ошибок для классов) в сто тысяч раз важнее чем тонны синтаксического сахара, и хитрые подвыверты браузера. И у javascript'а с этим существенно хуже чем у той же Java (я не говорю что совсем плохо, просто существенно хуже).

МСУNitro_JunkieМСУ, Я считаю, что наследование через прототипы это бред. И что классы, наследование и явная типизация для сложного проекта важнее, чем функциональщина в том виде, в котором она есть в javascripte'е.
Для кастомизации штатного функционала срать на наследование и уж тем более через прототипы. Моя задача, изменяя нативный UI и логику, не ссать кипятком от наследований и полиморфизма, а быстро выполнить задачу. Всё.

Nitro_JunkieИ для кастомизации сложных проектов функции рефакторинга (переход к объявлению, поиск использований (с учетом function overloading), подсветка ошибок для классов) в сто тысяч раз важнее чем тонны синтаксического сахара, и хитрые подвыверты браузера. И у javascript'а с этим существенно хуже чем у той же Java (я не говорю что совсем плохо, просто существенно хуже).
Ну про "кастомизациюю сложных проектов" ты можешь в институте детишкам рассказать, а для меня кастомизация - и в африке кастомизация. Есть точка входа, есть api, есть язык - этого достаточно, чтобы сделать свою работу. А сложный там проект или средний, мне фиолетово. Есть задача, есть инструменты - есть выхлоп.

"А то пишут, пишут… Конгресс, немцы какие-то… Голова пухнет. Взять всё, да и поделить…"

Для того чтобы что-то кастомизировать, вам нужно понять как это работает, и что можно изменить, чтобы не повалить половину других веток. А для этого нужно уметь быстро посмотреть где используется данный кусок кода, какие интерфейсы еще есть и т.п. Или вы как ежик в тумане, пишете наугад, а потом смотрите запускается ли и не отвалилось ли что-то еще. При нормальных инструментах можно условно незнакомую систему на лету менять, и сразу в продакшн запускать. А что с кучей процедурного лапше-кода делать?

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