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

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

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

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

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

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

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

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

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

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

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

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

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

Why would you want to process something in Javascript when you can process it in PHP or ASP.NET which are designed specifically for this task?

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

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

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

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

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

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

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

Does anyone see Server-side Javascript taking off?

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

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

Что сегодня является основным для молодого хакера?

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

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

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

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

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

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

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

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

The goal for this project is to create a standard library that will ultimately allow web developers to choose among any number of web frameworks and tools and run that code on the platform that makes the most sense for their application.

людям, которые говорят: «Почему бы вам выбрать JS, а не java или любой другой язык?» - вы должны прочитать эти Повторное введение Крокфорда и забудьте о DOM - DOM супервыгоден, но это не ошибка JS, а JS не является DOM.

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

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

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

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

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

• HTML
• CSS
• Javascript
• Серверный язык J2EE / ASP / Ruby / Python / PHP
• SQL

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

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

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

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

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

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

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

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

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

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

Node.js стал популярным и доказал, что серверный JavaScript никуда не денется =)