XULRunner — это и есть Firefox без кода собственно браузера. Система обновлений работает точно так же (обновление ядра, обновление расширений). Сами обновления качаются с сервера разработчика. Хелперы (проверки версий, настройки частоты проверки, etc) тоже встроены в XULRunner. Все не сложно. Сложности могут быть только при рассинхронизации версии клиента и версии сервера, но это очевидным образом решается на уровне протокола авторизации. Ну, как устаревание js библиотек в кеше, в общем-то :)
А у них у всех производительность примерно одинаковая. Самое узкое место — это в любом случае запросы по сети, а никаких монструозных ExtJS не используется за полной ненадобностью.
> что не привязывает нас к одному конкретному браузеру
Зато привязывает к runtime :)
Без разницы — ставить runtime AIR или runtime XULRunner. Это не браузер.
Но ежели вдруг у юзера есть Firefox — у него уже есть runtime XULRunner. Так что именно дело вкуса, а не ограничений.
С остальным согласен, конечно. Обсуждать проблему вне контекста не имеет смысла. Я как раз за контекст и выступаю, с основной идеей, что браузер нужен для «публичных» приложений с неконтролируемой аудиторией, а для решения задач типа складских программ или админок сайтов юзать браузер как платформу — очень плохой выбор.
Конечно, точка зрения. Но хорошо аргументированная, если учесть, что мы говорим не о приложениях, рассчитанных на милионную аудиторию, а о специальном софте масштаба предприятия. Я там выше кое-какие аргументы привел, но их сильно больше (в основном из области usability и скорости работы). А браузер «с возможностями, выходящими за рамки браузера» — уже не браузер, согласитесь, а приложение, предоставляющее возможности браузера. От перемены мест слагаемых многое меняется :)
> централизованное обновление
Это проблема, да. Она в целом нормально решается на базе того же XULRunner. С обновлением Firefox ведь нет проблем? Хотя следует признать, что при неграмотном подходе тут можно поймать грабли.
> Свобода в плане UI
Ну, тут мы переходим на мое поле :) XULRunner — это как раз и есть XML+JS+CSS! Даже если вы не знакомы с нюансами XUL, опыта разработки на HTML+JS вполне достаточно. Только там очень неплохо все продумано для нужд быстрой разработки GUI, есть всякие XBL, позволяющие писать наворочаные виджеты повторного использования опять же на XML+JS+CSS, низкоуровневые компоненты хоть на JS, хоть на C++, которые умеют с осью общаться и т.п. Принципиальное отличие от HTML+JS — гораздо удобнее, поскольку XUL? как следует из названия, заточен под функциональный интерфейс GUI (в отличие от pure HTML). И, да, удобнее WPF, хотя последнее тоже сугубо imho of course.
>> не надо использовать категоричных утверждений вроде «абсолютно не разбираясь»
Извините, в данном случае — надо.
Ибо, если бы Вы разбирались в теме, то знали бы, как минимум, о существовании складских и бухгалтерских программ на платформе XULRunner, о существовании в MDC странички со списком приложений под платформу, а также дали бы себе труд задуматься о том, что количество расширений к Firefox (чем он и знаменит) говорит о хорошей архитектуре и удобстве разработки.
Приложений таких (известных) довольно много. Вы про Тандерберд, к примеру, слышали чего-нибудь?
Во вторых, распространенность Firefox побольше Chrome :)
В третих, не надо использовать категорических утверждений, абсолютно не разбираясь в вопросе. Сорри, ничего личного.
Перемещений в веб — оно конечно. Только откуда следует, что веб-проложения должны браузер использовать?
Опять же, приложения приложениям рознь. Если вам надо, чтобы доступ к нему имел люой и из интернет-кафе — тогда, действительно, не альтернативы браузеру. Но и кроссбраузерности тоже :)
А для бизнес-задач, не выходящих за рамки компании браузер как платформа — абсолютное зло. Как в смысле разработки, так и в смысле удобства использования.
Для таких задач использовать браузер — решение как минимум странноватое :). Зачем заниматься имитацией десктоп GUI приложений в среде, изначально предназначенной для просмотра гипертекста, причем не имея никаких серьезных для того оснований? Это что, интернет-стартап с милионной аудиторией, которую невозможно напрячь установкой специальных плагинов? Что, операторы склада не в состоянии поставить спец. софт?
Если вы выбрали браузер как платформу — извольте обеспечить кроссбраузерность, а не плакать, что какой-то браузер не обеспечивает производительности на уровне десктоп-приложения при загрузке мегабайтных скриптов. А уж если вы ограничиваете юзера каким-то одним браузером — так вообще смысл веб-интерфейса потерян сразу и безвозвратно. Что, специальный браузер проще поставить, чем специальное приложение?
Вам не приходила в голову идея сделать сие не с веб-интерфейсом, а в виде расширения Firefox или standalone XULRunner приложения? Попробйте на досуге… Вас ожидает изрядное изумление производительностью, даже по сравнению с Chrome/WebKit :) А уж об удобстве разработки и доп. возможностях, в веб-интерфейсе не реализуемых принципиально или реализуемых через задницу и говорить не приходится.
ИМХО, VDS для задач мелкого хостинга собственных клиентов оптимален — с одной стороны нет нужды нанимать админа, с другой — почти все можно настроить самому по ssh или через панель, и есть гарантированный минимум всех ресурсов. Перестают клиенты влезать на один vds — покупаете там же следующий…
Как вариант — VDS от rusonyx или firstvds. Первый подороже, второй подешевле, по совокупности плюсов-минусов примерно равны.
Вы удивитесь, но нужда в чате с посетителем корреляции с количеством этих посетителей не имеет :) Если вы продаете товар десяток килобаксов — то нужно увешаться чатами, чтобы обхаживать каждого зашедшего…
Парсер был очень неплохим выбором как альтернатива PHP4 (за счет "объектоориентированности" и отличной поддержки XML/XSLT). После появления PHP5 целесообразность использования Парсера в более-менее сложных проектах сомнительна. Хотя для начинающих осваивать ООП + XML (и веб-программирование вообще) это, имхо, по прежнему отличный выбор, несмотря на несколько нетрадиционный синтаксис.
В общем понятно, что необязательно xml, но суть от этого, имхо, не меняется. Программист выдает в какой-то форме данные, которые используются шаблоном (версткой). Если у программиста появляется задача думать на уровне "h1 с классом block" - это, согласитесь, просто отсутствует отделение данных от представления. Эрго, проблема не в распределении обязанностей и ответственности, а в отсутствии нормальных технологий.
Зато привязывает к runtime :)
Без разницы — ставить runtime AIR или runtime XULRunner. Это не браузер.
Но ежели вдруг у юзера есть Firefox — у него уже есть runtime XULRunner. Так что именно дело вкуса, а не ограничений.
С остальным согласен, конечно. Обсуждать проблему вне контекста не имеет смысла. Я как раз за контекст и выступаю, с основной идеей, что браузер нужен для «публичных» приложений с неконтролируемой аудиторией, а для решения задач типа складских программ или админок сайтов юзать браузер как платформу — очень плохой выбор.
> централизованное обновление
Это проблема, да. Она в целом нормально решается на базе того же XULRunner. С обновлением Firefox ведь нет проблем? Хотя следует признать, что при неграмотном подходе тут можно поймать грабли.
> Свобода в плане UI
Ну, тут мы переходим на мое поле :) XULRunner — это как раз и есть XML+JS+CSS! Даже если вы не знакомы с нюансами XUL, опыта разработки на HTML+JS вполне достаточно. Только там очень неплохо все продумано для нужд быстрой разработки GUI, есть всякие XBL, позволяющие писать наворочаные виджеты повторного использования опять же на XML+JS+CSS, низкоуровневые компоненты хоть на JS, хоть на C++, которые умеют с осью общаться и т.п. Принципиальное отличие от HTML+JS — гораздо удобнее, поскольку XUL? как следует из названия, заточен под функциональный интерфейс GUI (в отличие от pure HTML). И, да, удобнее WPF, хотя последнее тоже сугубо imho of course.
Извините, в данном случае — надо.
Ибо, если бы Вы разбирались в теме, то знали бы, как минимум, о существовании складских и бухгалтерских программ на платформе XULRunner, о существовании в MDC странички со списком приложений под платформу, а также дали бы себе труд задуматься о том, что количество расширений к Firefox (чем он и знаменит) говорит о хорошей архитектуре и удобстве разработки.
Во вторых, распространенность Firefox побольше Chrome :)
В третих, не надо использовать категорических утверждений, абсолютно не разбираясь в вопросе. Сорри, ничего личного.
Опять же, приложения приложениям рознь. Если вам надо, чтобы доступ к нему имел люой и из интернет-кафе — тогда, действительно, не альтернативы браузеру. Но и кроссбраузерности тоже :)
А для бизнес-задач, не выходящих за рамки компании браузер как платформа — абсолютное зло. Как в смысле разработки, так и в смысле удобства использования.
Для таких задач использовать браузер — решение как минимум странноватое :). Зачем заниматься имитацией десктоп GUI приложений в среде, изначально предназначенной для просмотра гипертекста, причем не имея никаких серьезных для того оснований? Это что, интернет-стартап с милионной аудиторией, которую невозможно напрячь установкой специальных плагинов? Что, операторы склада не в состоянии поставить спец. софт?
Если вы выбрали браузер как платформу — извольте обеспечить кроссбраузерность, а не плакать, что какой-то браузер не обеспечивает производительности на уровне десктоп-приложения при загрузке мегабайтных скриптов. А уж если вы ограничиваете юзера каким-то одним браузером — так вообще смысл веб-интерфейса потерян сразу и безвозвратно. Что, специальный браузер проще поставить, чем специальное приложение?
Вам не приходила в голову идея сделать сие не с веб-интерфейсом, а в виде расширения Firefox или standalone XULRunner приложения? Попробйте на досуге… Вас ожидает изрядное изумление производительностью, даже по сравнению с Chrome/WebKit :) А уж об удобстве разработки и доп. возможностях, в веб-интерфейсе не реализуемых принципиально или реализуемых через задницу и говорить не приходится.
Как вариант — VDS от rusonyx или firstvds. Первый подороже, второй подешевле, по совокупности плюсов-минусов примерно равны.