Имеет ли смысл создавать веб-приложения на чистом JavaScript (как на стороне клиента, так и на стороне сервера)?

Question

Я всегда рассматривал JavaScript как отличное дополнение (или, скорее, в последние пару лет, как обязательное условие) к клиентской части любого веб-приложения. Даже когда я начал использовать Mootools, который делает большой шаг от манипуляций с DOM и нацелен на общую цель, OO Framework, я все еще не думал, что буду рассматривать использование JavaScript для разработки на стороне сервера. JavaScript принадлежит фронту, точка - вот что я думал.

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

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

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

РЕДАКТИРОВАТЬ: Ссылка в ответе Ванварила ( Почему node.js совершенно потрясающий ) открывает интересное обсуждение в разделе комментариев, которое стоит прочитать. Я, например, решил, что хотя использование Javascript на стороне сервера является жизнеспособной концепцией и может иметь свои преимущества, я бы определенно не стал создавать корпоративное приложение с этой архитектурой. По крайней мере на данный момент. Этот вопрос, возможно, придется повторить через год, я могу себе представить, что ответ кардинально изменится в ближайшем будущем.

Answer 1

Прежде всего, вы взглянули на node.js ? JavaScript - один из языков, который за последние несколько лет претерпел огромные изменения и, вероятно, будет продолжать расти.

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

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

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

Answer 2

Unhosted - это «проект», полностью посвященный приложениям только для javascript, которые работают только в веб-браузере и используют сервер как хранилище для (зашифрованных) данных.Там вы найдете несколько примеров.

Answer 3

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

Один язык.Напишите клиентскую и серверную части вашего интерфейса на JavaScript.

- http://docs.meteor.com

Answer 4

Мы создаем наши CMS и внешние интерфейсы, используя http://Helma.at,, которые в настоящее время обслуживают ~ 250 млн. Страниц в месяц. Это JavaScript насквозь.

Обратите внимание, что это не передовая технология, как вы, вероятно, предполагаете: Helma разрабатывается с 1998 года, а мы используем ее в производстве с 1999 года.

Answer 5

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

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

Answer 6

Это не новая идея. На самом деле, он был настолько стар, что был в моде, затем вышел и теперь возвращается снова.

Классический ASP на Windows Server IIS может использовать javascript в качестве языка сценариев на стороне сервера. он может общаться с локальной файловой системой, SQL-сервером и т. д. очень, очень простые вещи.

Вы можете легко написать некоторый ASP-код, который возвращает JSON для использования вашим клиентским скриптом ajax.

Проблема в том, что MS проигнорировала классическую asp и перешла на asp.net (c # или VB.net), поэтому нам нужно подождать, пока сообщество заново изобретет серверный JavaScript, чтобы вернуться туда, где мы были в 2001 году.

Answer 7

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

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

Если это так, каковы будут преимущества использования JavaScript как для передней, так и для задней части?

• Нет переключения между языками для разработчиков
• Повторное использование кода (например, хотите проверить правильность данных? Один и тот же код можно использовать на клиенте и на сервере).