Почему базы кода в n-уровневой разработке имеют равное количество, если не больше, кода JavaScript сейчас?

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

Я начал с базовой веб-разработки на ASP, и очень рано, на странице были смешаны отображение и бизнес-логика. Разработка на стороне клиента сильно различалась (VBScript, различные варианты JavaScript), и у нас было много предупреждений о проверках на стороне сервера (и поэтому я держался в стороне от логики на стороне клиента).

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

Затем я запрыгнул на ленточный универсал ASP.NET и начал использовать их подход MVC. Я также понял, что Java, похоже, является языком слоновой кости корпоративных систем, а также попробовал их подход MVC. Позже ASP.NET разработал этот шаблон проектирования MVVM, и Java (точнее, J2EE или JEE) также боролась и выдвинула свои подходы MVC2.

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

Почему произошло это движение от разработки сервера к разработке на стороне клиента? Я сделал простой подсчет строк в одном из моих проектов JEE, и в JavaScript больше строк кода, чем в Java (исключая сторонние библиотеки). Я обнаружил, что большинство внутренних разработок с использованием языков программирования, таких как Java или C #, просто для создания REST-подобного интерфейса, и что все тяжелые усилия по отображению, визуализации, вводу / выводу данных, взаимодействию с пользователем и т. Д ... решаются через клиентскую среду, такую ​​как Angular, Backbone, Ember, Knockout и т. д.

В эпоху до jQuery я видел множество диаграмм, в которых была четкая, концептуальная грань между M, V и C в MVC в n-уровневой разработке. Post-jQuery, где нарисованы эти линии? Кажется, что MVC и MVVM все в порядке в коде JavaScript, на стороне клиента.

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

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

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

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

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

Поскольку компьютеры становились все более мощными, разделение труда стало возможным. Теперь у вас могут быть файловые серверы, серверы баз данных, веб-серверы, серверы печати и так далее. Каждая машина может быть несколько оптимизирована для поставленной задачи и обслуживаться кем-то, обладающим необходимым опытом. Могут быть написаны программы, которые запускаются в веб-браузере, поэтому установка клиента больше не требуется. Это называлось многоуровневым или n-уровневым. Браузеры в основном использовались как тупые терминалы, как и в дни мэйнфреймов, хотя метод связи с сервером был более сложным, менее закрытым и основывался на механизмах прерываний, а не на распределении времени и опросах. Обработка переместилась обратно на сервер (ы).

Тем не менее, веб-разработка пришла с совершенно новым набором головных болей. Большинство бизнес-приложений, написанных для браузера, представляли собой статические формы и отчеты. В пользовательском интерфейсе было очень мало интерактивности. Javascript еще не обрел второе дыхание, и были серьезные проблемы с несовместимостью браузеров, которые препятствовали его широкому распространению. Однако все стало намного лучше. HTML5 и CSS3 предоставляют существенные новые возможности для модели программирования браузера, появился jQuery и помог целому поколению программистов выяснить, насколько полезным может быть Javascript. Появились новые пользовательские интерфейсы. Стало возможным писать высокоинтерактивные пользовательские интерфейсы в браузере, даже полноценные игры. Обработка снова вернулась к клиенту.

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

Вы, кажется, смешиваете два совершенно разных понятия:

1. Разделение представления и бизнес-логики (MVC) => повышение удобства обслуживания
2. Назначение выполнения узлу => повысить эффективность

В те времена, когда клиент-серверные вычисления часто путали, они подразумевали первое, поскольку клиенты обычно не обладали большой вычислительной мощностью по сравнению с серверами. Поэтому казалось естественным перенести «тяжелые» вычисления бизнес-логики (M) на серверы, сохраняя при этом «легкую» обработку представления (V) для клиентов. В свою очередь вы должны были реализовать своего рода арбитр (С) для перевода между ними.

Теперь, когда клиенты легко демонстрируют мастерство процессов, которое когда-то подразумевало дорогостоящее серверное оборудование, линии размыты относительно того, где выполнять бизнес-логику - на стороне клиента или на стороне сервера. Действительно, ответ зависит от вашего конкретного варианта использования и вашего выбора компромиссов, например:

• задержка клиента по сравнению со сложностью: обработка на стороне сервера делает системы проще, потому что не требуется развертывать / загружать код на клиент, однако это происходит за счет задержки на стороне клиента во время вычислений.

• Сложность по сравнению с нагрузкой на сервер: вычисления на стороне клиента могут увеличить сложность системы, но также могут помочь уменьшить нагрузку на сервер.

• устойчивость децентрализованного приложения по сравнению с центральным исполнением: в мире мобильных приложений может быть важно поддерживать работу клиентов, несмотря на отключение сети. Однако это происходит за счет управления несколькими развернутыми версиями бизнес-логики.

Это не исчерпывающий список многих компромиссов.

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

В большинстве бэкэнд-разработок с использованием языков программирования, таких как Java или C #, просто создается интерфейс, похожий на REST, и что все тяжелые усилия по отображению, визуализации, вводу / выводу данных, взаимодействию с пользователем и т. д ... решаются с помощью клиента. боковые рамки, такие как Angular, Backbone, Ember, Knockout и т.д ...

Может быть, бэкэнд-программирование / сервисы кажутся такими же старыми, но это суть приложения. Практика кодирования может быть более эффективной в этих областях. Инструменты, языки, браузеры и фреймворки все еще развиваются, поэтому UI / UX сложно разрабатывать. Это новые вещи, которых не было у старого ASP. Если бы мы могли покончить с пользовательскими интерфейсами с простыми формами и HTML-таблицами, в этих областях также не было бы особого интереса / ажиотажа, но пользователям нужны перетаскивание, анимация, переходы, всплывающие окна и т. Д.

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

Почему произошло это движение от разработки сервера к разработке на стороне клиента?

Здесь на самом деле два вопроса:

1. Почему программирование на стороне клиента, где происходит прогресс?
2. Почему приложения написаны для запуска на клиенте, а не на сервере?

Два на самом деле разные.

Почему программирование на стороне клиента, где происходит прогресс?

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

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

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

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

Почему приложения написаны для запуска на клиенте, а не на сервере?

Есть много непосредственных причин, но наиболее заметным из последних лет является рост смартфонов.

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

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

Клиентские приложения позволяют быстро и синхронно обрабатывать состояние, относящееся к отдельному пользователю. Они позволяют вам переложить ваши вычислительные расходы на ваших пользователей. Они позволяют вам избежать простоев и плохого подключения к сети. Они делают серверный код настолько тупым, что его можно кэшировать в самой сетевой инфраструктуре - статических файлах HTML и JS или в готовых ответах для мобильных приложений.

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

Вы задали несколько вопросов, на некоторые из которых уже есть хорошие ответы. У некоторых еще не было своих ответов:

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

Роберт Харви дал отличный ответ.

... от поддержки компилируемых языков до языков сценариев,

Языки сценариев предлагают много преимуществ ( также ) перед скомпилированными языками, например:

• легче учиться и использовать
• устранить время компиляции (ускоренная разработка)
• предоставить больше возможностей (более высокий контроль приложений)
• разрешить быстрые изменения в запущенном коде
• и т.п.

... от обязательного к функциональному программированию,

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