новый подход к веб-разработке: запрос на инструменты и рекомендации компонентов
Я ищу лучшую возможность записать веб-приложения, которые нагружены JavaScript. Таким образом, я хотел бы представить Вас мои идеи и попросить Ваши мнения и альтернативы на этом, :)
1 год назад я начал искать возможности для веб-разработки помимо PHP. Я нашел JSP и Django. Я решил пойти с Django. После запуска некоторых проектов с Django это приводит меня приходить к заключению, что Django, для меня, не обеспечивает возможность для легкой веб-разработки. Я должен волноваться о слишком многих функциях и особенно потребности сохранить код клиента и сервера в балансе.
Таким образом, я начал искать снова и нашел CouchDB, который обеспечивает своего рода прохладный бэкенд для приложений Ajax. Таким образом, моя идея состояла в том, чтобы использовать CouchDB в качестве сервера базы данных, который только обеспечивает подтверждение правильности данных и устройство хранения данных и сохранил все остальное клиенту. Который, по-видимому, не является новой идеей вообще, но я еще не нашел хорошего примера на этом. Вы знаете кого-либо?
Я хотел бы иметь архитектуру со следующими компонентами:
- хранение данных и проверка (CouchDB)
- веб-сервер: который обрабатывает файлы и WebSockets или Опрашивающий (Tornado или Eventlet)
- клиентский JavaScript для обработки всего остального (fav: сам записанный MooTools)
- клиентский язык шаблонной обработки (Вы знаете, что кто-либо охлаждается?)
У Вас есть какие-либо предложения для другого программного обеспечения для использования для тех точек?
Который обрабатывает запросы как следующее:
Начальный запрос отправляет файлы JavaScript и основной HTML (только и теги) Клиенту. Загруженные функции JavaScript создают HTML-код и вставляют его в тег. С этого времени вся навигация на веб-сайте только запрашивает JSON, который обеспечивается через Websocket и обрабатывается клиентским JavaScript.
Профессионалы:
- Весь код написан в JavaScript на клиентском
- Анимация на обновлениях может быть реализована действительно легкая
- Логика страницы была бы очень легка и прозрачна
- Вероятно, никакие проблемы масштабирования на серверной стороне
- Очень быстрая производительность приложения из-за превосходных клиентских возможностей кэширования. Например, использование Webstorage
Недостатки:
- Шаблонная Обработка могла бы быть очень медленной на низких Аппаратных машинах?!
- Код приложения общедоступен ко всем
Вопросы
- Вы знаете какое-либо доступное решение для этого вида веб-разработки?
- Вы думаете, пишущий веб-приложения, этим путем была бы заводная рукоятка?
Также взгляд на Ответ 2
3 ответа
Знаете ли вы какое-либо доступное решение для такой веб-разработки?
Взгляните на couchapps . Это написали ребята, стоящие за couchedb. Он основан на jquery, но его не так сложно преобразовать для работы с mootools. Существует также хороший шаблонизатор JavaScript под названием mustache . Движок шаблонов будет работать с обеих сторон, в браузере и couchdb.
Будет ли молодежь писать таким образом веб-приложения ненормальной?
Нет. Так работает большинство приложений Google (почта, документы, электронные таблицы), есть также множество фреймворков, таких как sproutcore или cappuccino.
веб-сервер: который обрабатывает файлы и WebSockets или опрос (Tornado или Eventlet)
Думаю, couchdb тоже справится с этим
Я использовал Trimpath Javascript Templates для пары последних крупных проектов и очень им доволен.
Пара других частей моего рабочего процесса, без которых я не мог жить сейчас:
процесс сборки как для javasscript, так и для CSS. Оооочень лучше иметь возможность систематизировать мои файлы js и css, как я хочу, разбивая их на самые мелкие части, как мне хочется, и автоматически объединять в один большой файл
LessCSS - - улучшение по сравнению с обычным синтаксисом CSS. Вы пишете свои таблицы стилей, используя синтаксис LessCSS, который похож на css, но позволяет использовать такие вещи, как переменные, математика, миксины, вложенные классы. Затем движок LessCSS компилирует его в обычный CSS.
Хотя eskimoblood ответил на большинство вопросов, все еще существует одна большая проблема с "моим" описанным подходом к разработке веб-приложений: Язык шаблонов
Как упоминалось выше, существует множество они работают на стороне клиента с помощью Javascript. Но, на мой взгляд, для всех языков шаблонов, которые я обнаружил до сих пор, отсутствует одна большая функция: Функция обновления
Я не имею в виду перерисовку всего шаблона при обновлении, но я бы хотел увидеть язык шаблонов, который обновляет только мои переменные, изменился.
Пример использования:
Представьте, что я сейчас читаю блог, который содержит 25 переменных JSON и большой шаблон для их рендеринга. Вдруг где-то на другом конце планеты какой-то храбрый человек оставляет крутой комментарий. Теперь есть разные возможности представить текущим читателям «живое обновление»:
- Наихудший случай: Сбрасывается вся страница. Необходимо переделать 26 переменных Json и всю обработку шаблона.
- Плохой случай: Обновляется вся часть текущей страницы, посвященная блогу. Необходимо переделать 15 переменных Json и большую часть обработки шаблона.
- Наилучший вариант: Обновляется только часть комментариев на текущей странице. Необходимо переделать 5 переменных Json и немного обработки шаблона.
- Рекомендации: новый комментарий вставляется в начало списка комментариев. Необходимо переделать 1 переменную Json и очень небольшую обработку шаблона.
Теперь вы можете подумать, что это не проблема с небольшим количеством сценариев Java. Но мне нужен язык шаблонов, который делает это автоматически.Язык шаблонов, который знает свой текущий статус и обновляет только заголовок при изменении заголовка. Или переходит от старого к новому дразнящему образу.
Таким образом мы могли бы сэкономить много пользовательских сценариев обновления. Не нужно было бы беспокоиться об анимации при изменении структуры страницы, и мы могли бы оптимизировать сетевой трафик за счет обслуживания только обновлений, а не уже известной части данных текущего документа.
Вопросы:
- Что вы думаете о таком подходе на языке шаблонов?
- Знаете ли вы какой-либо язык шаблонов, обеспечивающий аналогичную обработку?
- Можно ли заставить это работать без большого количества проблем с производительностью?