Имеет ли смысл создавать чистые веб-приложения на основе JavaScript (как на стороне клиента, так и на стороне сервера)?
Я всегда рассматривал JavaScript как отличное дополнение (вернее, в течение последних двух лет, как должно быть) к клиентской стороне любого веб-приложения. Даже когда я начал использовать Mootools, который делает большой шаг от манипулирования DOM и нацелен на общую цель, OO-структуру, я все же не думал, что буду рассматривать JavaScript для разработки на стороне сервера. JavaScript принадлежит фронту, периоду - тому, что я думал.
Ну, похоже, по мнению некоторых проклятых умных людей, я ошибся. Впервые конкурс платформы веб-разработки под названием Plat_Form принял команду, в которой на сервере и на стороне клиента использовался чистый JavaScript и. Что еще, вот что организаторы конкурса должны были сказать об этом:
"У нас было одно приложение из команды Upstream Agile, которое будет работать с JavaScript как на сервере, так и на стороне клиента. Поскольку это может стать основной тенденцией в ближайшие годы, мы считаем их участие проблеском будущего и принять эту команду, даже если никто с этой платформой не применялся".
Итак, мой вопрос: действительно ли это жизнеспособная концепция, чтобы создавать многоуровневые веб-приложения исключительно на JavaScript? Если да, то каковы были бы преимущества использования JavaScript как для фронта, так и для бэкэнд?
РЕДАКТИРОВАТЬ: Ссылка в ответе Vanwaril (Почему node.js абсолютно потрясающий) показывает интересный обсуждение в разделе комментариев, которое стоит прочитать. Я, например, решил, что, хотя использование Javascript на стороне сервера является жизнеспособной концепцией и может иметь свои преимущества, я определенно не стал бы создавать корпоративное приложение с этой архитектурой. По крайней мере на данный момент. Этот вопрос, возможно, потребуется снова спросить через год, я могу представить, что ответ в ближайшее время резко изменится.
Ответы
Ответ 1
Во-первых, вы посмотрели node.js? JavaScript является одним из языков, который за последние несколько лет видел скачки и границы развития и, вероятно, продолжает расти.
С точки зрения функциональности он менее зрелый по сравнению с другими серверными технологиями, но активное сообщество делает его не так уж далеко.
Наконец, поскольку его язык, который работает как на передней, так и на задней панели, его последствия для повторного использования кода и форматов обмена данными значительно ускоряют разработку приложений.
Я не уверен, что он готов к выпуску еще (если вы сами не готовы внести свой вклад в кодовую базу), но серверный JavaScript - хороший вариант для экспериментов.
Ответ 2
Unhosted - это "проект", который полностью посвящен приложениям только для javascript, которые работают только в веб-браузере и используют сервер как хранение (зашифрованных) данных. Здесь вы найдете несколько примеров.
Ответ 3
Мы создаем нашу CMS и интерфейсы, используя http://Helma.at, в настоящее время обслуживающий ~ 250 миллионов страниц в месяц. Это JavaScript через.
Обратите внимание, что это не технология кровотечения, как вы, кажется, предполагаете: Хельма находится в разработке с 1998 года, и мы используем ее в производстве с 1999 года.
Ответ 4
Чтобы на самом деле ответить на вопрос - да, вполне реально создавать клиент-серверные веб-приложения полностью на JavaScript и фреймворках, которые получили сцепление в течение двух лет с момента запроса - особенно Meteor - сделать это намного проще, чем раньше:
Один язык. Напишите как клиент, так и серверные части вашего интерфейса в JavaScript.
- http://docs.meteor.com
Ответ 5
Серверный код сервера должен быть особенно надежным и хорошо спроектированным, поскольку он управляет несколькими клиентами в многопоточной среде. Сложность процессов бизнес-уровня и необходимость точного повторного использования кода всегда приводили меня к написанию кода на стороне сервера на Java. Я бы не стал использовать Java script, потому что он нацелен на другое использование.
При этом я использую Java script на сервере для репликации сценариев проверки на стороне клиента, например. Таким образом, вы можете использовать один кусок кода проверки на обоих концах. Пользователь получает отзывчивую проверку браузера, но задняя часть повторно проверяет, если кто-то обходит проверку переднего конца.
Ответ 6
Итак, мой вопрос: действительно ли это жизнеспособная концепция, чтобы создавать многоуровневые веб-приложения исключительно на JavaScript?
Да, хотя инструменты относительно незрелые по сравнению со многими другими языками.
Если да, то каковы были бы преимущества использования JavaScript как для фронта, так и для бэкэнд?
- Отсутствие переключения между языками для разработчиков
- Повторное использование кода (например, хотите проверить правильность данных) Тот же код может использоваться на клиенте и на сервере).
Ответ 7
Это не новая идея. На самом деле он так стар, чтобы быть в моде, затем вышел и теперь возвращается снова.
Clasic ASP на сервере Windows IIS может использовать javascript в качестве языка сценариев на стороне сервера. он может разговаривать с локальной файловой системой и SQL-сервером и т.д. очень простой материал.
Вы можете легко написать код ASP, который возвращает JSON, который будет использоваться вашей клиентской стороной script ajax.
Проблема заключается в том, что MS проигнорировали классический asp и перешли на asp.net(С# или VB.net), поэтому нам нужно дождаться, когда сообщество заново изобретет javascript на стороне сервера, чтобы вернуться туда, где мы, где в 2001 году.
