Helios Javascript framework and libraries

Продавать нет, спасибо :) я работаю прогером, пока вроде хватает. На счёт придумывания профита я не запаривался, надо подумать. По идее, целевая аудитория - это такие же программисты, которые мб смогут придумать приложение вместе с профитом к нему. У меня просто есть какие-то идеи, которые я нигде до этого не встречал, я их попытался скомпилить в одном проекте и теперь хочу посмотреть что из этого получится. И, да, мне интересно программировать а не заморачивать себе голову коммерциализацией. Тем более что я с трудом себе представляю коммерциализацию моего проекта, едва ли...

>Продавать нет, спасибо :)

Эээ. Вы не так поняли, я не о деньгах =) Я всмысле продавать=подавать. То есть о том, как заинтерисовать других людей.

>На счёт придумывания профита я не запаривался

Ээ. Вы предпочитаете сначала сделать, потом придумать кому это надо?

> я старался сделать как можно более аналогичным образом с обычным инклюдом, по-моему в моём варианте всё куда проще.

А какой он, обычный инклуд? В "С" и php — первое, что приходит в голову, — это инструкция, которая копипастит исходник из указанного файла на место вызова. ))

В helios это неплохо иммитируется. Тут модули, при помощи функции инициализации, срут всем своим нутром в глобальное пространство имен, либо в глобальные объекты, до которых способны дотянуться. Тут я поддерживаю антиглобализм. :)

В приведенной спеке предлагается более изящное решение. У них модули, это именованные объекты. При таком подходе, общими будут лишь имена модулей, а все содержимое модулей связывается только с самим объектом.

> если нужна всего одна функция из модуля, то да, так удобнее. а если больше

очевидно, так:
// -- some_module.js --

// use assync load
preload('desk.js').ready(function() {
    // build environment
    var desk = require('desk.js');

    // return module instance
    return {
        calc: new desk.Calculator(),
        getTax: function(value) {
          return new desk.Money(value).calulate(this.calc);
        }
    }

}
всего один общий идентификатор "'desk'".

читал-читал коменты, но так и не понял - чем это лучше GWT(+Ext GWT)?

> Эээ. Вы не так поняли, я не о деньгах =) Я всмысле продавать=подавать. То есть о том, как заинтерисовать других людей.

Не догнал :)

>>На счёт придумывания профита я не запаривался

>Ээ. Вы предпочитаете сначала сделать, потом придумать кому это надо?

Я немножко по-другому рассуждал. Я старался сделать среду, в которой мне было бы удобно работать, старался исключить все недостатки веб-платформы, которые лично мне мешали. Что-то получилось, теперь чтоб вызвать интерес у публики, оказывается :) нужно ей (публике) объяснять, почему им это мб интересно. В общем-то очевидно, конечно. Я подумаю =)

А вообще, какой может быть профит, например, у какого-нибудь компилятора? По идее, его можно использовать для создания приложений. Более узко, имхо, не сказать. Так и тут.

> Тут я поддерживаю антиглобализм. :)

В обычном (сишном) инклуде ведь тоже так. Я продолжил аналогию, дабы не усложнять. От проблем спасают неймспейсы и некоторые соглашения об именовании объектов в подключаемом исходнике. Я старался следовать такому соглашению в либах для гелиоса. При таком подходе проблем с засиранием главного неймспейса не должно появиться, по-крайней мере, я не замечал. А что касается проектирования спецификации намеренно таким образом, чтоб "глупому программисту было сложнее засирать корневой неймспейс", это смысла не имеет, на мой взгляд. Как ни спроектируй язык/либу/спецификацию/фреймворк - всегда найдётся способ писать корявый код, и всегда будут на свете гики, которые так и будут поступать (по неграмотности или же преднамеренно).

>> если нужна всего одна функция из модуля, то да, так удобнее. а если больше

>очевидно, так:

>// -- some_module.js --

> (далее кусок кода)

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

> читал-читал коменты, но так и не понял - чем это лучше GWT(+Ext GWT)?

Мой подход отличается в частности от GWT отсутствием трансляции кода из джавы в JS, вместо этого предлагается писать код непосредственно на JS. Лучше это или хуже - оценит сообщество и покажет время.

Небольшой офтопик

>    // return module instance
>    return {
>        calc: new desk.Calculator(),
>        getTax: function(value) {
>          return new desk.Money(value).calulate(this.calc);
>        }
>    }

Если не ошибаюсь, внутри анонимной функции, которая помещается в слот getTask возвращаемого объекта, идентификатор this ссылается на саму функцию, а не попадает в замыкание. Поправьте меня, если это не так, мне даже интересно :) В качестве солюшна можно сделать так (ещё менее читаемо):

var result = {
    calc: new desk.Calculator()
}

var calc = result.calc;
result.getTax = function( value ) {
    return new desk.Money( value ).calculate( calc );
}

return result;


Тогда локальная переменная calc попадёт в замыкание и будет ссылаться как раз на result.calc, и всё должно заработать.

>Мой подход отличается в частности от GWT отсутствием трансляции кода из джавы в JS, вместо этого предлагается писать код непосредственно на JS. Лучше это или хуже - оценит сообщество и покажет время.

однако вы забыли сказать, что при этом ещё теряется вышеозвученное "Рефакторинг, валидация, комплишн". Можно, кстати, даже сравнить размер кода на тот же калькулятор в случае GWT+extGWT vs Helios

> однако вы забыли сказать, что при этом ещё теряется вышеозвученное "Рефакторинг, валидация, комплишн".

однако я так и не получил ответа на мой вопрос, относительно того, каким образом всё упомянутое теряется в гелиосе. с рефакторингом я не вижу проблем. про валидацию я не очень понимаю, что имеется в виду в данном контексте. вопрос комплишна решается генерацией тегфайла, нет?

> Можно, кстати, даже сравнить размер кода на тот же калькулятор в случае GWT+extGWT vs Helios

да, это было бы интересно, это поможет найти кривые места в апи, если они есть. хотя это скорее вопрос не helios vs gwt, а JS vs Java имхо.

> с рефакторингом я не вижу проблем.

В языке типа джаваскрпит нельзя полностью вывести типы за исключением тривиальных случаев => невозможно всё перечисленное (включая рефакторинг). Твоя библиотека - не тривиальный случай, потому при использовании её и не будет всего перечисленного.

>не helios vs gwt, а JS vs Java

Кстати, ещё лучше не с джава, а с groovy - там всё это можно, но код будет заметно компактнее. (оно позволяет инициализацию в стиле JSON при статической типизации). И если проигрыша почти не будет (а вариант груви думаю даже будет короче) - вариант когда нет всех перечисленных бонусов не имеет профита.

> В языке типа джаваскрпит нельзя полностью вывести типы за исключением тривиальных случаев => невозможно всё перечисленное (включая рефакторинг).

То есть, это недостаток языка? Выходит, по-вашему, мне ничего не остаётся, кроме как забить на проект? :)

> Выходит, по-вашему, мне ничего не остаётся, кроме как забить на проект? :)

Да, это недостаток любого языка с динамической типизацией.

Нет, я предлагаю путь LOP, и либо писать на MPSе, либо генерить, например, из груви.

Идея у вас хорошая, я не понимаю почему вы так держитесь за JS - это многое портит, но вы так и не сказали что даёт взамен. И другие люди вас вроде тоже не очень понимают в этом выборе.

И да, напишите статью на хабре - там большая аудитория, будет куча мнений, наверняка будут и дельные советы.

>Выходит, по-вашему, мне ничего не остаётся, кроме как забить на проект? :)

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

ответили выше: js - динамический язык.

в случае GWT, кстати, ещё и серверсайд-методы вызывать удобнее.

>Ну, проектов на питоне и раби с тойже проблемой дофига, и люди вроде терпят.

люди вон и на перле пишут, и jruby пилят... ;)

>jruby пилят... ;)

Это потому что java как язык слишком бедный. была бы она как Java FX Script | Groove - не нужно было бы =)

дык я клоню к тому, что при наличии groovy jruby - ненужен ;)

Почитал про разные штуки, и, в частности, наткнулся на проект под названием qooxdoo (http://qooxdoo.org/), его для создания клиентской части использует упомянутый Вами Eclipse RAP. Странно, что я его раньше не заметил, поскольку он очень похож на то, чем занимаюсь я :) Отсюда в голову приходит мысль ещё одного профита для гелиоса - точно так же генрить в него код из любимой всеми нафиченной джавы :) хотя, мне эта идея, почему-то не нравится.

Почитал так же про декомпозицию, валидацию и комплишн: понятия мне оказались знакомы, но я особо не пользовался фичами IDE, которые это упрощают. Наверное, из-за того, что я не профессионал, а может, потому что мне более по душе емакс и консоль нежели чем Visual Studio или маковский XCode (с другими IDE пока не имел дела, к сожалению).

Вот я приведу некоторый юзкейс про рефакторинг, поправьте меня плз, если я неправильно понял суть вещей. Например, я меняю интерфейс некоторого класса (для JS - объекта, там нет классов). Умная IDE прямо в исходниках, где этот интерфейс юзается, подсветит мне и скажет, что он изменился, соответственно, вызов мне тоже нужно передлать. Для JS, умная IDE не может делать никаких предположений относительно интерфейса объекта, т.к. он может меняться в рантайме, и вызов может быть и валидный. Но ведь если я меняю что-то в интерфейсе (скажем, метод переименовал), разве я не должен буду и в том и в другом случае пробежать поиском по всем исходникам проекта, найти старый вызов и переправить его? Или в первом случае умная IDE сделает это сама?

> найти старый вызов и переправить его? Это будет не так просто - это ещё один минус. мне моя иде сразу показывает где есипользуется метод, поле или ещё что. А у вас кроме лексического поиска ничего не будет. а то что два метода называются одинаково, ещё совсем не значит, что это методы одного класса.

>нежели чем Visual Studio

Visual Studio на фоне IDEA, Eclipse выглядит как Notepad.exe ;) Вы не знаете что даёт качественная ИДЕ если их не видели. После них обоих я (для разработки на С++, Java) смотрю на вим как на <нужно подставить>