Как стать автором
Обновить

Комментарии 14

Хотел посмотреть исходники, и скажите — вы и вправду весь код держите в одном файле js/jriapp.js? 1.5К строк можно было бы и по классам разложить, а потом собирать…
Не знаю, я раньше создавал другой меньший Фреймворк — его разбивал на отдельные скрипты — это было неудобно перелезать из файла в файл.
Потом я стал использовать JetBrains WebStorm — в нем очень удобно работать и в таком формате, он все модули схлопывает и я
просто выбираю тот который мне нужен и раскрываю его.
Просто, если есть нормальный инструмент, то и кажущееся
неудобным становится удобным.

P.S. -к стати там где — то около 15 K строк (не 1.5 K).
Да, там много строк :) Просто, я более чем уверен, что в WebStorm не менее удобно и по файлам «прыгать». А преимущества налицо — видно сразу структуру проекта, но самое главное — изоляция модулей, а без этого покрывать тестами проект очень сложно. Ну и сборки можно разные делать.

А так, я вижу, проект уже не маленький, и в след. раз можно статью тоже побольше написать — с примерами, особенностями… Удачи!
Спасибо.
Это был топик для инвайта и я его писал около 12 ночи.
Думаю потом написать что-то поподробнее про него.
Хотел еще отметить почему один файл для меня удобней.
1) Над этим проектом работал один человек — нет конкуренции за файл.
2) Если в программе происходит ошибка — я знаю номер строки и мне легче найти источник ошибки.
3) Мне легче искать по тексту, чем по файлам если я ищу где используется функция.
4) Изоляция в отдельный файл, это не тоже самое, что изоляция модулями. Весь проект состоит из модулей (где — то около 20). Помещены они в один файл или в 20 не имеет значения для изоляции.
5) Такое расположение модулей в одном файле не мешает тестированию. Пишите тест, используйте модуль- какая разница в каком он файле?
6) По поводу сборок — если вы заметили, то в одном файле только core modules (ключевые), пользовательские модули (как в демо) все имеют отдельный файлы. Возможно, это только мешает замене одного модуля на сторонний. Но, все равно вы его соберете потом в один файл. Модули написанные для ядра неизвестно кем могут все порушить, поскольку модули ядра работают с внутренним API, который может меняться- а сторонний модуль ничего не знает о внутренних изменениях. Да и смысл сборок здесь какой — например, оставить только Data Binding, а остальное отбросить? Только это ядро фреймворка, и там некоторые части могут зависеть одна от другой.
То что, уже добавляется над ядром, то это можно комбинировать как угодно.

1) Ну вы же дотнэтер, я так понимаю, и не мне вас убеждать, что для бизнес лейэр: один класс — один файл. Хорошо, javascript — не c#, но как минимум один модуль — один файл.
2) Можно для дебага и модули отдельно грузить — и вы не только номер строки видите, но и названия модуля/класса/файла, — и это уже плюс.
3) Сугубо субьективная оценка.
4,5) Файл-Модульная изоляция нужна для тестов, что бы тестировать внутренний апи который скрыт от внешнего доступа. Ведь вся библиотека в основном находится за замыканием, то как из тестов достать эти самые классы/модули?
6) Модульность вам же улучшает разработку. Решили создать другую реализацию для модуля — создали новый файл, создали модуль, собрали проект с новым модулем — вот и у вас уже новая бета, а человек решит — или хочет stable пользоваться, где ещё старый модуль, или взять бетку. Или другой пример — модуль с разными реализациями. Один только для современных браузеров, другой кроссбраузерный — с кучей polyfills и другими вещами. Разрабатывая мобильное приложение, я бы взял более легкую сборку.
OK — во многом вы правы. Если бы я изначально решил публиковать проект на GitHub, то
я бы так и сделал. Это все по историческим причинам.
Я вообще хочу его перевести полностью на typescript, чтобы была готовность к любой версии EcmaScript в будущем.
И внутри легче рефакторинг делать, перенес часть кода, и сразу видно, что перестает компилироваться.
Скорее всего в этом месяце начну его переводить на другой язык.
О, typescript — отличная вещь, желаю вам всяческих успехов, надеюсь скоро ещё «услышимся». И главное не бросайте начатое!
В чем сакральный смысл делать видео демку HTML5 фреймворка?
В том, что это показывает его возможности по работе с данными.
Намного проще посмотреть 4 минутный ролик, чем скачивать демо и запускать у себя на компе.
А выкладывать демо в онлайн? Так за хостинг платить надо.
Попробуйте хостинг на appharbor.com. Там все просто, удобно и бесплатно.
В любом случае, это не совсем решает проблему.
В демо используются база данных, что вынуждает при публикации демо сделать его в режиме только для чтения.
(Не могу же я дать каждому возможность менять записи в базе)
Если я сделаю хранение данных в сессии, то это приведет, к тому, что будет использоваться много памяти на сервере- и провайдер не даст ее сколько хочешь за бесплатно.
Поэтому, пока только youtube.
P.S.-
К стати, опубликовал только, что продолжение этого топика.
Сегодня начал переводить этот фреймворк на typescript.
Не знаю сколько это займет времени. Но первые результаты меня впечатляют.
Рефакторинг становится простой задачей. Доступ ко всем классам с полным intelisense и
ошибки теперь отлавливаются сразу. Жаль, что пока typescript в альфа версии, но опыт показывает,
что работать с ним можно.
Сегодня опубликовал TypeScript версию на github.
Зарегистрируйтесь на Хабре , чтобы оставить комментарий

Публикации

Истории