Спешите на сторону клиента в веб-разработке

В последние несколько месяцев я узнал большой восторг от сценариев на стороне клиента в веб-разработке. Но в то время как серверные технологии являются зрелыми, стабильными и хорошо приняты бэкэнд-разработчиками, клиентские технологии являются незрелыми (то есть по сравнению с крупной серверной средой) и не нравятся многим давно разработанным разработчикам. Тем не менее, в наши дни все занимаются разработкой на стороне клиента. Я лично ожидаю, что эти большие серверные инфраструктуры исчезнут через 2-5 лет, следя за текущей тенденцией.

Почему это так? Как может новая и «рассеянная» разработка на стороне клиента в HTML5 / JS превзойти большие и продуманные решения на стороне сервера?

Это правда:

Спешите на сторону клиента в веб-разработке

Но это не ограничивается стороной клиента, это движение полного стека.

Я знаю, что это может быть удивительно. Пожалуйста, выслушай меня.

Почему это так? Как может новая и «рассеянная» разработка на стороне клиента в HTML5 / JS превзойти большие и продуманные решения на стороне сервера?

Прежде всего, оба хорошо продуманы.

Во-вторых, потому что это лучше.

Хороший вопрос.

Но «лучше» субъективно, поэтому ответ на ваш вопрос, что конкретно лучше?

Повторно посетите вопрос:

Как "рассеянная" разработка на стороне клиента в HTML5 / JS может превосходить большие решения на стороне сервера?

Because small is nimble.
And big is clunky.

Это гибкость.

Не похоже на большое дело. Является ли? Гибкость.

Однако гибкость лежит в основе всего. Одно улучшение гибкости - все улучшается.

Ремонтопригодность. Расширяемость. Масштабируемость. Модульность. Юзабилити. UX.

И это быстрее реализовать. Это реальность. Быстрее и лучше

This is why Windows 8 made JS a first-class citizen.

HTML5 - JS, это не увлечение, и оно не исчезнет. Мы видим только семена технологии, которая будет развиваться, чтобы обеспечить вычислительный контент и взаимодействие с планшетами. Таблетки.

Смартфоны стали самым популярным средством массовой информации со времен телевидения в 1950-х годах. Теперь у нас есть не только смартфоны, но и планшеты.

Уже в разработке в Mozilla и Windows ОС, которая будет работать на будущих устройствах на их рынках -> HTML / JS.

Многие решения и инновации остаются.

Появляется полный стек JS, основанный на гибкости.

Надеюсь, это поможет.

Эта история всегда имела две стороны; как на стороне сервера, так и на стороне клиента есть свои плюсы и минусы.

Преимущества сценариев на стороне клиента включают в себя:

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

Но серверный скрипт также имеет много преимуществ:

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

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

Наблюдаемый обман происходит от комбинации двух недавних событий:

1. HTML5 и его корона связанных технологий. Это заняло слишком много времени, но теперь у нас наконец-то появился стандарт, который содержит все необходимое для создания динамических настольных веб-приложений без накапливания хаков и основные браузеры, которые их правильно реализуют.
2. Доступная вычислительная мощность. Современные обычные настольные ПК столь же мощны, как и веб-сервер начального уровня, мобильные телефоны потребительского уровня практически являются настольными компьютерами 2005 года, а современные реализации javascript достаточно эффективны, чтобы изменить баланс производительности: в настоящее время ресурсы на стороне клиента дешевле, чем серверные. Ресурсы.

Фактически, ничего не изменилось с точки зрения того, в чем хороши серверно-ориентированный и клиент-ориентированный подходы; Что изменилось, так это то, что клиент-ориентированное решение теперь проще и дешевле и работает лучше, чем несколько лет назад, что делает его жизнеспособным выбором для гораздо большего количества приложений, чем раньше.

Серверная сторона всегда будет рядом. Вы не можете сидеть на стороне клиента для всего. Например, вы не хотите использовать дизайн MVC Backbone.js для своего микроконтроллера, отправляющего вам параметры в реальном времени с мостового крана на производственном этаже.

Не верьте обману.

В 2009 году я перешел с серверной PHP-платформы на клиентское ExtJS-решение, привязанное к серверным веб-сервисам.

Причины миграции для меня были:

1. Повышенная безопасность за счет уменьшения количества конечных точек и кода на сервере.
   Переходя на веб-службы, вы проверяете ввод на границе веб-службы и получаете более точный контроль над вводом / выводом вашего сервера. Не существует уровня пользовательского интерфейса на стороне сервера, чтобы запутать вашу архитектуру безопасности.
2. Повышение производительности благодаря уменьшению количества обращений к серверу
   . Архитектура меняется, поэтому выборка данных может происходить реже, а данные могут кэшироваться локально, при этом для рендеринга пользовательского интерфейса вообще не требуется двустороннего обращения. Раунд-трипы - вот что убивает производительность веб-приложений.
3. Повышение производительности благодаря возможности кэширования пользовательского интерфейса.
   Уровень пользовательского интерфейса может быть полностью размещен в CDN. Я даже создавал автономные веб-приложения, помещая код пользовательского интерфейса в кеш приложений HTML5.
4. Более высокая точность пользовательского интерфейса (богатый клиентский контроль)
5. Сторонние разработчики могут использовать тот же API, что и мой собственный интерфейс, и я могу легко использовать API в разных модулях, если они совместно используют функции.
   Это означает меньше разработки, контроля качества, документации, ...
6. Я люблю программировать на JavaScript лучше, чем PHP, Python или Java

Но, не заблуждайтесь, то, что происходит сейчас, является обманом. Он взорвется, и многие веб-приложения снова будут использовать архитектуру пользовательского интерфейса на стороне сервера.

Другим фактором, который стимулирует энтузиазм в отношении клиентских решений, является рост мобильных приложений. Если вы делаете веб-сайт в значительной степени на основе клиентского JavaScript и AJAX, а также создаете нативные приложения для iOS и Android, есть большая вероятность, что все три могут использовать одни и те же REST-сервисы, чтобы обрабатывать все свои данные и отправлять их туда и обратно. ,

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

Большой и мощный серверный хостинг довольно дорогой. Гораздо дешевле реализовать некоторую логику (кроме проверки) на стороне клиента. Таким образом, вы можете использовать меньший (а значит, более дешевый) серверный хостинг, так как он не будет загружен так сильно

По этой причине, несмотря на нестабильность, клиентские технологии приобретают все большую популярность. Кроме того, JS и HTML / CSS поддерживаются (почти) всеми современными браузерами.

Эти две части приложений не могут существовать отдельно. И Интернет, похоже, никуда не денется в ближайшем будущем.
Я не думаю, что они big server-side frameworksтоже могут исчезнуть. Всегда будут компании, которые могут их себе позволить, и будут использовать их значительные преимущества.

Веб-разработка на стороне клиента тесно связана с веб-браузерами и изменениями в них с течением времени. Решение, которое вы предлагаете сейчас, может не сработать через пару месяцев из-за значительных изменений в механизмах рендеринга страниц в веб-браузерах. Некоторые браузеры были / были несовместимы со стандартами и поэтому требовали от разработчиков еще больше усилий только для достижения ожидаемого результата.

Есть несколько решений, пытающихся решить эту проблему. Например, если вы используете jquery, вы уверены, что ваш скрипт будет работать в браузерах, поддерживаемых этой конкретной библиотекой jquery. Но только его авторы могут предоставить вам совместимость с некоторыми / большинством / всеми браузерами. Вопрос в том, какая команда поддержит вас лучше. Это будет команда motools, команда jquery, другая команда? Если они не обеспечивают поддержку определенного веб-браузера, ваш проект может не работать в этом браузере.

Волнение, которое вы, кажется, испытывали уже давно. Я видел это, когда были представлены Shockwave и его преемник Flash, когда были поставлены сложные js-библиотеки, «большое возвращение» богатых пользовательских интерфейсов, сначала с motools, а затем с jquery (я начал использовать их в таком порядке). Был Flex и JavaFX. Но никто из них не может получить большую долю на рынке. Некоторым требуются плагины, которые со временем часто подвергают конечного пользователя уязвимостям безопасности, другие могут не работать на стороне клиента из-за некоторых пользовательских настроек (например, JavaScript отключен в браузере клиентов).

С другой стороны, решение на стороне сервера обычно пишется только один раз. Вам не нужно беспокоиться о том, что все закончится неудачей, и вам придется переписать его, как только будет выпущен новый Firefox / Chrome / IE / Opera. Вам также не нужно беспокоиться о том, что клиент попытается взломать ваше приложение и / или испортить данные.

Абсолютно согласен с вашими чувствами. Я также считаю, что помимо того, что вы говорите, мы увидим резкое падение REST и резкий рост количества веб-сокетов, поскольку мы видим, как сайты взаимодействуют со своими серверами. Vert.x, Node.js и т. Д. Вся сторона сервера, а также сторона клиента переходит к программированию на основе событий. Java EE, PHP, Rails и т.д .. все они должны адаптироваться, иначе они очень быстро проиграют.