Прогрессивное улучшение для JavaScript?

Question

Большинство людей говорят о прогрессивном улучшении прямо сейчас как о браузерах с javascript (улучшенная версия) и браузерах без javascript (простая версия).

Но существует большая разница в производительности javascript между браузерами, поэтому может быть полезно применить этот термин для поддержки выбора между функциями на основе javascript между браузерами.

В сложном веб-приложении с многочисленными не совсем необходимыми функциями (и анимациями) стоит задуматься о том, чтобы их отключить, скажем, эти наборы функций должны работать во всех браузерах, а эти наборы функций только Chrome и Safari, а также Firefox, Chrome, Safari и Opera и т. Д., Поскольку включение определенных функций в определенных браузерах будет слишком медленным.

Иногда мне кажется, что пользовательский интерфейс улучшился бы, если бы у него не было доступа к некоторым несущественным функциям. Например, запретить пользователям IE изменять размеры определенных панелей, которые смогут изменять пользователи Chrome.

Answer 1

Я сам этого не делал, но вижу, что это имеет смысл, если ваш бюджет это позволяет (а вы не можете контролировать выбор браузера своего пользователя)

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

Приложение, которое быстро для 99% ваших пользователей, несомненно, лучше, чем приложение, которое быстро только для 30% ваших пользователей. Единственный вопрос - что важнее - пользовательский опыт или время разработки (и примите во внимание, что через несколько лет средний пользователь будет запускать более быстрые браузеры на более быстрых компьютерах)

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

Кроме того, Lombardi Blueprint имеет очень интересный подход, хотя, вероятно, нецелесообразный за пределами GWT. У них есть алгоритмы компоновки, написанные на Java, написанные так, что их можно запускать как на стороне клиента (через GWT), так и на стороне сервера (через стандартную jvm). Следовательно, основываясь на тестируемой производительности вашего браузера, они могут динамически переключаться между макетом на стороне клиента (для быстрых браузеров) и макетом на стороне сервера (для медленных браузеров).

Answer 2

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

Другими словами, присвойте своему сайту уровни функций, первый уровень - это базовый html, второй уровень - улучшение юзабилити javascript, третий уровень - анимация javascript.

Затем сделайте комбинацию, позволяющую пользователям переходить на более низкий уровень, когда они захотят, «Нажмите, чтобы отключить анимацию!», «Нажмите, чтобы включить анимацию!», «Нажмите, чтобы просмотреть базовый HTML», и выберите по умолчанию для определенных категорий скорости на основе браузера по причинам скорости (например, если кажется, что IE7 проявляет проблемы со скоростью при полной анимации, установите по умолчанию второй уровень «улучшения удобства использования javascript»).

Answer 3

Допустим, вы создаете приложение приличного размера. У вас есть изобилие браузера, чтобы определить, какие функции будут включены, а какие отключены. Вы понюхали Opera 9.x, и теперь (на самом деле сегодня) Opera 10 выходит. Вы должны пойти и обновить каждый сниффер на каждой странице. А потом скоро выйдет еще один браузер ... и еще один. Вы будете тратить все свое время, определяя, какие браузеры вы поддерживаете и какие функции для них поддерживают.

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

Кроме того, скорость работы JavaScript зависит не только от браузера. У меня все еще есть старый Pentium под управлением Firefox 3.5. Иногда это может быть мучительно медленно.

Answer 4

Я согласен с Энди. Предоставление разных версий приложения для разных браузеров - потенциальная проблема в будущем. Я всегда считал лучшим вариантом предоставить одну версию приложения, которая работает во всех браузерах. Например, я стараюсь избегать снифферов браузера. Приложение может быть не самым классным, но оно работает для всех и его легче поддерживать.

Такого рода вещи теперь стали проще благодаря всем изящным библиотекам Javascript, которые абстрагируют некоторые различия браузера. Кроме того, вы можете делать много вещей в старых браузерах. Это просто сделано "по-другому";)

Answer 5

Что я делаю, так это пишу основной файл javascript, который имеет общую функциональность и идет к наименьшему знаменателю (javascript 1.5). Затем у меня есть другие файлы для более поздних версий javascript, и они заменят функции в моих объектах javascript, чтобы я мог постепенно добавлять больше поддержки.

Если я хочу использовать тег canvas, я могу добавить его в другой файл, поскольку IE и Firefox / Opera / Safari отличаются тем, как они создают элемент canvas.

Это не радость от обслуживания, но если я захочу использовать новые функции html / javascript, то это, похоже, лучшая модель.

Answer 6

Две разные проблемы с браузерами в эти дни:

1. Speed. Мой опыт показывает, что IE 7 работает нормально, только намного медленнее, чем остальные. Мое решение состоит в том, чтобы предоставлять пользователям более частые обновления прогресса пользовательского интерфейса. Поскольку обновление пользовательского интерфейса требует времени, я минимизирую обновления в более быстрых браузерах. Например, в IE я обновляю экран большим количеством отзывов после обработки еще 50 событий. Для других браузеров после обработки 200 событий.

2. Отсутствие функции. Например, холст. Но это много, чтобы построить несколько сайтов. И проверить их тоже. Поэтому я трачу свой бюджет на 1 версию для всех текущих настольных браузеров. И сделать дополнительные сайты для мобильных телефонов esp iPhone.

НТН,

Larry

Answer 7

Звучит как кошмар обслуживания.

Я понимаю, что есть некоторые веб-приложения, в которых просто нет смысла иметь HTML-версию. Тем не менее, если это возможно, я бы начал с создания HTML-версии каждой страницы, а затем использовал JavaScript, чтобы улучшить пользовательский опыт.

IE менее эффективен, чем Safari, Chrome и FF, когда дело доходит до JS - но разве вы действительно разработали страницу, которую нельзя использовать в IE с включенным JS? Я просто не видел этого - в дикой природе я думаю, что различные реализации JS достаточно быстры.