Вы знаете о новейшем усилении HTML5, игнорирующей наследие платформе JavaScript?
Какова лучшая платформа (вид jQuery, extjs, и т.д. как), чтобы использовать, если я хотел бы интенсивно использовать все самые новые технологии стека HTML5, обеспеченного современными браузерами (Firefox 7, Safari 5, Chrome 14) и не иметь абсолютно никакой потребности поддерживать какие-либо браузеры прежней версии (включая никакую потребность в поддержке IE вообще и никакую потребность в Firefox или Chrome до последних стабильных версий)? Я хотел бы получить все новейшее доступное совершенство, не имея (даже абстрагированный слоем библиотеки) строки кода, предназначенной просто передняя совместимость с прежними системами или имея в виду любые вызванные наследием вещи.
Для смягчения фильтра, беря очень скромную надежду на такую идеально новую платформу существовать, наименьшее количество (максимальный уровень поддержки прежней версии), который я хотел бы согласовать, не поддерживает версии IE, более старые, чем IE8, или лучше просто не поддерживает IE вообще.
5 ответов
Мне действительно трудно примирить эту идею после серьезной мысли. Предполагая, что такая структура существует, она будет так же хороша, как и текущий статус реализации в любом браузере. Предположим, что есть только два браузера, и статус реализации HTML5 выглядит следующим образом:
Browser | Feature X | Feature Y
-------------------------------
A | ✔ | ✘
B | ✘ | ✔
Тогда ваше самое передовое приложение HTML5 может иметь либо X, либо Y, но не оба. Если функции, необходимые вашему приложению, доступны в последних версиях большинства основных браузеров, то эта функция не является передовой. Год назад это было бы на переднем крае.
Таким образом, в зависимости от объема и целей проекта, большинство приложений B-E, которые могут быть написаны, будет соответствовать одному браузеру (тому, который предлагает все / большинство функций, необходимых для вашего приложения).
Если вы пишете для одинокого браузера и не хотите исправлять какие-либо отклонения реализации от спецификации (поскольку спецификация еще не завершена), то это в основном написание кода для выбранного браузера независимо от каких-либо спецификаций.
Если это так, то каркас - это в основном дополнительный багаж для переноски. Вместо этого ярлыки для наиболее часто используемых API и других общих упрощений были бы лучшим способом.
Тем не менее, если вы хотите иметь фреймворк, который значительно упрощает HTML5 API, не обращая внимания на то, где сегодня находятся браузеры, то я хотел бы внести свой вклад в этот проект.
Sproutcore - это еще один проект, который в какой-то степени соответствует вашему вступительному описанию "Как нам создавать молниеносно быстрые веб-приложения настольного класса?". Apple заинтересована в нем, и я слышал хорошие отзывы.
Другой подход - Apples Dashcode. Он использует html(5) css(3) и JavaScript для создания как виджетов для Mac, так и сайтов на базе Web. По сути, поскольку он практически не наследуется, он будет эффективно работать только в Safari и Google Chrome, менее эффективно в Firefox и совсем не будет работать в IE.
Для использования Cappuccino (упомянутого в другом ответе и являющегося хорошей идеей для рассмотрения) и Sproutcore вы будете более продуктивны на Mac, а для Dashcode определенно нужен Mac, так как вам нужно установить Xcode, чтобы получить Dashcode
.А как насчет капучино? Я действительно не знаю, сколько HTML5 / CSS3 он поддерживает, но для этого требуется как минимум IE7. Он ориентирован на разработку веб-приложений, а не на создание сайтов, поэтому может оказаться не тем, что вам нужно в этом отношении.
Не совсем ответ, но я думаю, что это будет полезно для обсуждения:
Подход GWT (кросс-компиляция Java в JavaScript с отложенным связыванием ) соответствует вашей точке зрения о получении минимального количества JS-кода, без бремени создания всех абстракций браузера в коде на стороне клиента и переноса всего веса этого кода плюс вес устаревшего кода поддержки браузера.
Я не уверен, что текущий уровень детализации, с помощью которого он производит оптимизированные версии для каждого браузера, является тем, о котором вы говорите, но технология позволяет это.
Кроме того, я не уверен насчет встроенной поддержки новейших функций HTML 5, но, опять же, можно было бы написать такие библиотеки (если их еще нет), и они получат выгоду от того же механизма отложенного связывания. , и вы можете скомпилировать только те изменения браузера, которые хотите поддерживать.