К сожалению, доля web-ui растет, а альтернатив js в этом плане практически не предвидится. Я думаю для многих js разработчиков наступал момент, когда код превращается в некого монстра, навигация по которому представлялась нетривиальной задачей, а запоминание методов и их параметров у используемых классов превращалось в нехилую тренировку памяти. Немного помогают хорошие IDE с интелисенсом, но только немного.
[javascript]
function f(x) {
x. // интелисенс?
}
[/javascript]
А в групповой разработке все осложняется тем, что код непрерывно правят несколько человек и время от времени неизменно затрагиваются публичные инфтерфейсы. На всех серьезных рефакторингах практически ставится крест, а это означает одно — либо стоимость внесения фич идет по экспоненте либо фичи просто перестают добавляться и проект начинает медленно умирать или переписываться с нуля.
Вполне логичный постулат — "тесты нас спасут" тоже работает плохо. Потому, что в вышеописанной функции надо тестировать не поведение с f("hello world"), а вызывать ее по всему коду с реальными параметрами. Потому, что тесты сильно увеличивает кодовую базу которую тоже требуется поддерживать. Потому, что тестировать код на асинхронных событиях сама по себе сложная задача.
Сейчас стали как грибы появляться компиляторы всего чего угодно в javascript: Java, C#, F#, IL и т.д.
Несмотря на то, что явно декларируемой целью является написание клиентского кода на то же языке, что и серверного, основным преимуществом тут является статическая типизация, которая позволяет управлять бОльшими объемами кода.
Все это была вводная, пора и к делу. Мне тут подумалось, что гораздо лучше проблему решил бы язык очень близкий к js, но хорошим синтаксисом (a la coffescript, который уже делает код читабельнее) и возможностью статической типизации. Причем типизации структурной и с мощным глобальным выводом типов, с которым сами типы придется указывать лишь в исключительных случаях. Динамику тоже можно будет использовать на полную как, например, в C#.
Чем он будет лучше того же websharper? Да тем, что скомпилированный js будет практически идентичен исходному коду (просто рассахареный исходник). Тем, что интеграция с любыми внешними js фреймворками будет абсолютно прямой и прозрачной. Для чего-то типы можно будет описать (типа хидера в C), для чего то забить на типизацию.
Какие основные проблемы вы видите у такого подхода? Может он принципиально невозможен?
Здравствуйте, Ziaw, Вы писали:
Z>Какие основные проблемы вы видите у такого подхода? Может он принципиально невозможен?
Теоретически возможен, только это чудо уже не будет яваскриптом, и, следовательно, будет совместимо только с самим собой, да и то частично
Кроме того, у нас всё равно останется тонна проблем, начиная с отсутствия стандартных библиотек/UI-фреймворка (только давайте не будем про canvas и меню на css) и заканчивая привязкой к принципиально нетипизируемому DOM.
А если мы явно разделим язык для логики и язык для декларативного описания ui/привязки к логике, то результат будет слишком сложным для большинства веб-дизайнеров, и, наоборот, слишком примитивным по сравнению с "взрослыми" явой и дотнетом.
Здравствуйте, Ziaw, Вы писали:
Z>[javascript] Z>function f(x) { Z> x. // интелисенс? Z>} Z>[/javascript]
Зачем вы передаете большие объекты?
Если таки надо передать большой объект -- пишите JsDoc-и, знакомый говорил что смог нормально настроить еклипс -- он подсвечивал поля как надо (у меня не получилось )
Z>Несмотря на то, что явно декларируемой целью является написание клиентского кода на то же языке, что и серверного, основным преимуществом тут является статическая типизация, которая позволяет управлять бОльшими объемами кода.
Ограничение областей видимости (куча маленьких файлов и все в псевдомодулях). Сборка джаваскриптовых файлов при сборке приложения и подключение уже результата (не всегда простая задача).
Z>Все это была вводная, пора и к делу. Мне тут подумалось, что гораздо лучше проблему решил бы язык очень близкий к js, но хорошим синтаксисом (a la coffescript, который уже делает код читабельнее) и возможностью статической типизации.
CoffeeScript, Cappuccino, GWT -- чего только не придумают люди лишь бы не учить JavaScript. Кстати, тот же CoffeeScript не решает проблему с динамической типизацией, а просто прячет некоторые приемы которые приходится писать вручную, то есть фактически просто синтаксический сахар.
Z>Какие основные проблемы вы видите у такого подхода? Может он принципиально невозможен?
Помимо "детских проблем" (не эффективная трансляция) и не понятный код-результат (переменные с подчеркиваниями и индексами или просто однобуквенные):
Код не нативный -- в сложных ситуациях будет сложно внести изменения и переносить их. То есть написание JavaScript-кода, скорее всего исключаеться. Уменьшается контроль над кодом.
Ухудшается возможность оптимизаций под каждый браузер: код может быть оптимизирован там где не надо и не оптимизирован там где надо.
Еще Один Язык, который прийдется выучить разработчикам, при том далеко не факт что он будет понятен кому-то кроме автора языка (проблема ДСЛ-ей). JavaScript учить все равно прийдется, ибо "философски" разработка на JavaScript и той же Java или C# очень отличается.
Что забавно, даже изобретая "правильный" язык, автор упорно топчется по граблям скриптовых языков. Из оф. документации:
class C {
static var x : Int;
var x : Int;
function new() {
{
// x at this point means member variable this.x
var x : String;
// x at this point means the local variable
}
}
}
Здравствуйте, Ziaw, Вы писали:
Z>Все это была вводная, пора и к делу. Мне тут подумалось, что гораздо лучше проблему решил бы язык очень близкий к js, но хорошим синтаксисом (a la coffescript, который уже делает код читабельнее) и возможностью статической типизации. Причем типизации структурной и с мощным глобальным выводом типов, с которым сами типы придется указывать лишь в исключительных случаях. Динамику тоже можно будет использовать на полную как, например, в C#.
Z>Чем он будет лучше того же websharper? Да тем, что скомпилированный js будет практически идентичен исходному коду (просто рассахареный исходник). Тем, что интеграция с любыми внешними js фреймворками будет абсолютно прямой и прозрачной. Для чего-то типы можно будет описать (типа хидера в C), для чего то забить на типизацию.
Z>Какие основные проблемы вы видите у такого подхода? Может он принципиально невозможен?
Гораздо лучше проблему решил бы стандартизированный байткод, вроде джавовского, в который браузеры бы компилировали джаваскрипт (ну и была бы возможность писать на своём любимом языке, компилируемом в этот же байткод).
Джаваскрипт в роли языка ассемблера по-моему тонкий троллинг над всей абсурдностью сегодняшних веб-технологий.
Я Haxe использую для компиляции во Flash. Очень приятный язычок, а компилятор значительно лучше, чем ActionScript'овский (как по скорости получаемого кода, так и по скорости компиляции). IDE с автокомплитом и прочими плюшками уже есть (FlashDevelop).
Отличная идея по моему.
Незнаю как там haxe — а в любом случае сейчас любой приличный фреймворк имеет свой собственный недо-js-компилятор (google-closure, dojo). Да и сам этим озаботился для своего fw. Правда пока что всё забросил подальше.
Z>К сожалению, доля web-ui растет, а альтернатив js в этом плане практически не предвидится. Я думаю для многих js разработчиков наступал момент, когда код превращается в некого монстра, навигация по которому представлялась нетривиальной задачей, а запоминание методов и их параметров у используемых классов превращалось в нехилую тренировку памяти. Немного помогают хорошие IDE с интелисенсом, но только немного.
Z>[javascript] Z>function f(x) { Z> x. // интелисенс? Z>} Z>[/javascript]
InteliJ'ные продукты неплохо справляются с интеллисенсом (до определенного момента, естественно).
Z>Все это была вводная, пора и к делу. Мне тут подумалось, что гораздо лучше проблему решил бы язык очень близкий к js, но хорошим синтаксисом (a la coffescript, который уже делает код читабельнее) и возможностью статической типизации. Причем типизации структурной и с мощным глобальным выводом типов, с которым сами типы придется указывать лишь в исключительных случаях. Динамику тоже можно будет использовать на полную как, например, в C#.
Было бы неплохо иметь в JS не обязательно статику, но type hints или type specs, имхо.
Здравствуйте, Sinix, Вы писали:
Z>>Какие основные проблемы вы видите у такого подхода? Может он принципиально невозможен? S>Теоретически возможен, только это чудо уже не будет яваскриптом, и, следовательно, будет совместимо только с самим собой, да и то частично
Да нет же, это будет просто сахар для js. Типы для которого будут заданы либо выведены и проверены на этапе компиляции. Выполняться будет обычный js без проверок на тип.
S>Кроме того, у нас всё равно останется тонна проблем, начиная с отсутствия стандартных библиотек/UI-фреймворка (только давайте не будем про canvas и меню на css) и заканчивая привязкой к принципиально нетипизируемому DOM.
И в чем проблема? Принципиально нетипизируемый DOM прекрасно обрабатывается jquery со вполне типизируемым АПИ.
S>А если мы явно разделим язык для логики и язык для декларативного описания ui/привязки к логике, то результат будет слишком сложным для большинства веб-дизайнеров, и, наоборот, слишком примитивным по сравнению с "взрослыми" явой и дотнетом.
Не надо этих наворотов. Язык для декларативного описания UI это html, привязать его к логике уже умеет куча фреймворков и еще большая куча появится.
Здравствуйте, vsb, Вы писали:
vsb>Гораздо лучше проблему решил бы стандартизированный байткод, вроде джавовского, в который браузеры бы компилировали джаваскрипт (ну и была бы возможность писать на своём любимом языке, компилируемом в этот же байткод).
Если бы, да кабы. Я не вижу даже движения в эту сторону.
vsb>Джаваскрипт в роли языка ассемблера по-моему тонкий троллинг над всей абсурдностью сегодняшних веб-технологий.
+1 только никто не желает отливать против ветра и я их понимаю.
Здравствуйте, Ziaw, Вы писали:
Z>Да нет же, это будет просто сахар для js. Типы для которого будут заданы либо выведены и проверены на этапе компиляции. Выполняться будет обычный js без проверок на тип.
? Ну, тогда это не тру — как же ошибки приведения типов?
Z>И в чем проблема? Принципиально нетипизируемый DOM прекрасно обрабатывается jquery со вполне типизируемым АПИ.
В языке со строгой типизацией — это тонна писанины и прооверок, спасает или паттерн-матчинг, или поздний биндинг, вы же сами пишете:
Именно. Ни о какой полной статике речь идти не может, динамика должна быть в шаговой доступности. Нужны и type hints и type specs и мощный вывод.
Кроме того, как насчёт библиотек? Будем их все вызывать через dynamic? Писать к ним врапперы? Портировать? Воистину,
Джаваскрипт в роли языка ассемблера по-моему тонкий троллинг
Z>Не надо этих наворотов. Язык для декларативного описания UI это html, привязать его к логике уже умеет куча фреймворков и еще большая куча появится.
А вот тут я категорически не согласен. В HTML даже лэйауты документов не всегда нормально можно описать — когда у нас был последний холивар div vs table? Если речь пойдёт о нормальном UI — где контейнеры, докинг, контролы, биндинг, драг-дроп, декларативное описание анимаций и прочее-прочее-прочее? Пока что html как язык описания UI не дотягивает даже до ранних дельфи/vbasic-а. И, такими темпами, ещё лет 10 дотягивать не будет.
Единственное преимущество html — то, что веб-браузеры сейчас не пихают только в чайники (хотя в разделочную доску уже засунули). И нет, это не делает html+js хорошим средством для разработки UI.
Посмотрите сами: весь успешный веб-софт занимается одним и тем же — развлекает несколько сотен миллионов людей, которым скучно на работе. Редкие исключения сильны в первую очередь уникальным контентом или серверной составляющей.
Скажете, гугль, wolphram|alpha, wiki, слешдот, твиттер и прочая-прочая популярны из-за html-я? Зачем играть в культ карго и упорно тащить html туда, где ему делать нечего?
Здравствуйте, Ziaw, Вы писали:
Z>Сейчас стали как грибы появляться компиляторы всего чего угодно в javascript: Java, C#, F#, IL и т.д.
Z>Несмотря на то, что явно декларируемой целью является написание клиентского кода на то же языке, что и серверного, основным преимуществом тут является статическая типизация, которая позволяет управлять бОльшими объемами кода.
Существование и достаточная популярность таких же трансляторов для питона:
Показывает что дело не только и не столько в динамической типизации.
Скорее виноваты другие особенности JavaScript и его общая далекость от мейнстримных языков вообще.
Здравствуйте, Sinix, Вы писали:
S>Единственное преимущество html — то, что веб-браузеры сейчас не пихают только в чайники (хотя в разделочную доску уже засунули).
Здравствуйте, Sinix, Вы писали:
Z>>Да нет же, это будет просто сахар для js. Типы для которого будут заданы либо выведены и проверены на этапе компиляции. Выполняться будет обычный js без проверок на тип.
S>А, типа такого
? Ну, тогда это не тру — как же ошибки приведения типов?
Сейчас с ними тоже никак. Ты смотришь с точки зрения ортодоксальной типизации. А я хочу ее использовать только там, где она меньше мешает, чем помогает. Проверки на соответствие типу для выполнения в рантайме придется писать явно.
Z>>И в чем проблема? Принципиально нетипизируемый DOM прекрасно обрабатывается jquery со вполне типизируемым АПИ. S>В языке со строгой типизацией — это тонна писанины и прооверок, спасает или паттерн-матчинг, или поздний биндинг, вы же сами пишете:
Настолько строгой типизации не нужно. Dom узел это dom узел, а не div|table|h1.
S>
S>Именно. Ни о какой полной статике речь идти не может, динамика должна быть в шаговой доступности. Нужны и type hints и type specs и мощный вывод.
S>Кроме того, как насчёт библиотек? Будем их все вызывать через dynamic? Писать к ним врапперы? Портировать? Воистину, S>
S>Джаваскрипт в роли языка ассемблера по-моему тонкий троллинг
S>
Еще раз. Динамика никуда не девается, она остается в шаговой доступности. Джаваскрипт тут не в роли ассемблера, а в роли основного языка. Просто припудрен сахаром и конструкциями помогающими выводу типов. Если ты хочешь описать сигнатуру метода $.ajax() — пожалуйста, если не хочешь, компилятор попробует вывести сам либо переделает в динамику.
S>А вот тут я категорически не согласен. В HTML даже лэйауты документов не всегда нормально можно описать — когда у нас был последний холивар div vs table? Если речь пойдёт о нормальном UI — где контейнеры, докинг, контролы, биндинг, драг-дроп, декларативное описание анимаций и прочее-прочее-прочее? Пока что html как язык описания UI не дотягивает даже до ранних дельфи/vbasic-а. И, такими темпами, ещё лет 10 дотягивать не будет.
Тем не менее в очень большом сегменте альтернативы ему не предвидится. Не надо сгущать краски. Далеко не всем требуется UI в стиле десктопа (контейнеры, докинг), это вообще годится только для ентерпрайз оперденей. А контролы, биндинг и драг-дроп существуют вполне приличные.
) и заканчивая привязкой к принципиально нетипизируемому DOM.
)
