Будет ли серверная часть JavaScript взлетать? Какая реализация наиболее стабильна?

Мне нравится читать блог гуглера Стива Йегге, и недавно я наткнулся на его статью, где он утверждает, что Mozilla Rhino является хорошим решением для серверной части JS. Это несколько небрежная расшифровка, возможно, вы предпочтете посмотреть видео выступления . Это также дает некоторое представление о том, почему он считает серверную часть JS хорошей идеей в первую очередь (или, скорее, почему он считает, что это хорошая идея использовать динамический язык для написания сценария Java). Я думал, что его доводы были убедительны, так что вы, возможно, захотите проверить это.

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

Почему вы хотите обрабатывать что-то в Javascript, когда вы можете обработайте его в PHP или ASP.NET, которые являются разработанный специально для этой задачи?

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

Стив Йегге написал в своем блоге о переносе Ruby на Rails серверную часть JavaScript в качестве внутреннего проекта в Google ("Rhino on Rails"). Он сделал это, потому что ему нравится Rails, но использование Ruby не разрешено в Google.

Поддержка JS на сервере становится все сильнее, а количество фреймворков растет еще быстрее.

Совсем недавно была основана группа serversideJS . У них есть много умных людей, которые работают на serverside JS в течение многих лет (некоторые из них более 10).

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

для людей, которые говорят, что "why would you choose JS over java or any other language?"-вы должны прочитать это повторное введение Крокфорда и забыть о DOM - DOM очень хорошо, но это не JS вина и JS не DOM.

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

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

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

• XChat может запускать Javascript плагина.
• У меня есть некоторые бухгалтерские программы, полностью написанные в Javascript.
• Есть такая интересная библиотека IO для V8: http://tinyclouds.org/node/
• CouchDB-это база данных документов с 'queries', записанной в Javascript (TraceMonkey).

Учитывая это, я полагаю, что серверная часть Javascript действительно взлетела.

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

Почему вы хотите обработать что-то в Javascript, когда вы можете обработать это в PHP или ASP.NET, которые предназначены специально для этой задачи?

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

Так что нет, я не вижу, как он взлетает.

Ну, обычная старая ASP поддерживала JavaScript серверную часть много лет назад, и каждый на своей собаке использовал VBShiate вместо этого. Но я должен согласиться с другими: JS не кажется мне правильным инструментом здесь - и я люблю делать это на стороне клиента JS :)

Я лично сделал целый сайт на стороне сервера JavaScript, используя ASP. Я нашел это довольно приятным, потому что я мог иметь некоторое хорошее повторное использование кода. Это включало в себя:

• проверка параметров
• моделирование объектов
• транспортировка объекта

В сочетании с высокоуровневым инструментом моделирования и генератором кода я получил удовольствие от этого проекта.

К сожалению, у меня нет номеров на perf, так как он используется только в интранете. Однако я должен предположить, что производительность находится на одном уровне с VBScript поддержанными ASP сайтами.

Похоже, что большинство из вас отталкивается от этой идеи из-за того, насколько неприятными были различные клиентские реализации Javascript. Однако я бы проверил существующие решения, прежде чем выносить суждение, потому что помните, что ни одно конкретное решение SS/JS не привязано к JS реализациям, которые в настоящее время используются в браузерах. Javascript основан на ECMAScript, помните, спецификации, которая в настоящее время находится в довольно зрелом состоянии. Я подозреваю, что решение SS/JS, которое поддерживает более поздние спецификации ECMA, будет не более громоздким, чем использование других языков сценариев для этой задачи. Помните, что Ruby изначально не был написан как "web language".

Кто-нибудь видит серверную часть Javascript взлетаем?

Попробуйте посмотреть на http://www.appjet.com стартап, делающий размещенные JavaScript приложения, чтобы понять, что вы можете сделать. Мне особенно нравится процесс обучения, который мягко подталкивает пользователя к созданию вещей с минимальными накладными расходами ~ http://appjet.com/learn-to-program/lessons/intro

Сейчас это может показаться странной идеей использовать JavaScript, но вспомните, когда PC начал выходить. Каждый ботаник, которого я знал, печатал на своем новом мусоре-80-е, Commodore64-е, Apple] [печатает в играх или простых приложениях в BASIC.

Где же сегодня основное для молодого хакера?

Вполне возможно, что JavaScript может сделать для веб-приложений на стороне сервера, как BASIC сделал для PC.

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

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

Не только для проверки данных, но и, скажем, HTML или CSS динамических конструкций можно сделать клиентскую или серверную сторону, по крайней мере с моим фреймворком.

До сих пор он работает быстро, мне не на что жаловаться или сожалеть, кроме его большой практичности и масштабируемость, которой я наслаждался в течение этих последних 4 лет, пока не наступил момент что я меняю свой классический код ASP на код javascript.

Вы можете увидеть его на практике в http://www.laferia.com.do

Я думаю, что серверная часть Javascript гарантированно взлетит. Это только вопрос времени.

Mozilla, Google и Adobe настолько заинтересованы в Javascript, что потребуется чудо, чтобы вытеснить его из мира браузеров. Следующий логический шаг-перенести это на серверную сторону.

Это шаг к тому, чтобы отойти от Ходж-поджа интернет-технологий, которые обычно включают в себя все это

• HTML
• CSS
• Javascript
• Язык На Стороне Сервера J2EE/ASP/Ruby/Python/PHP
• SQL

Я мало что слышал о текущем состоянии серверных фреймворков Javascript, за исключением того, что они в основном являются неполными.

Я вижу, что серверная js будет предлагать значительные преимущества в будущих приложениях. Почему? Веб-приложения, которые могут перейти в автономный режим, клиентский db store, Google gears и т. д...

Следуя этой тенденции, все больше и больше логики переходят на сторону клиента. Используйте ORM, который работает на стороне клиента, и используйте другой на стороне сервера (будь то PHP / Ruby / что угодно), напишите свою логику синхронизации дважды на двух разных языках, напишите свою бизнес-логику дважды на двух разных языках?

Как насчет использования js на стороне клиента AND сервера и написания кода один раз?

Убедительно?

Программирование на стороне сервера существует гораздо дольше, чем на стороне клиента, и уже имеет много хороших решений.

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

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

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

Node.js взлетел и доказал, что серверная сторона JavaScript здесь, чтобы остаться =)

Flash Media сервер написан с помощью сценария действий на стороне сервера, который на самом деле является просто javascript (ECMAScript). Так что я делаю это очень часто. На самом деле, большую часть дня я имел дело с SSAS.

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

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