Комментарии 82
НЛО прилетело и опубликовало эту надпись здесь
Так и знал, что кто-то спросит =)
Ну, во-первых, мне было интересно.
Во-вторых, а почему бы и нет?
В-третьих, разве это не прекрасно, когда на сервер и на клиенте мы используем один язык? Один тестовый фреймворк, одинаковая сериализация (JSON), ну и прочие прелести.
Ну, во-первых, мне было интересно.
Во-вторых, а почему бы и нет?
В-третьих, разве это не прекрасно, когда на сервер и на клиенте мы используем один язык? Один тестовый фреймворк, одинаковая сериализация (JSON), ну и прочие прелести.
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
На самом деле у nodeJS есть вполне конкретные и понятные плюсы перед другими платформами, дело в том что javascript — идеален для создания неблокирующего I/O. Которым nodeJS обладает, это позволяет ему иметь серьёзные преимущества в скорости по сравнению с другими платформами при таких операциях как обращение к БД и чтение из файлов… подробнее есть тут: nodejs
Я, конечно, извиняюсь, но «мне было интересно», «а почему бы и нет?» и «разве это не прекрасно» — звучит не очень убедительно =)
Это для тех кто хорошо пишет на js, теперь могут и на серверной стороне что нить зубубенить :)
ещё поиски могут привести сюда
Простите, что немного не в тему, но существуют ли какие-нибудь статьи или готовые решения для создания десктопного софта на базе V8, WebKit и Javascript? Ведь на основе мозилловского кода пишутся Songbird и KomodoEdit, хотелось бы чего-то подобного. На днях искал, но к своему удивлению ничего не нашел.
air?
Google Gears?
WebKit встроен в библиотеку Qt. Если я не ошибаюсь, то там можно дергать его низкоуровневое API. Правда документации на сайте Apple по этому поводу нет, а на форумах отсылают к документации GTK порта вебкита.
Есть Titanium ( www.jstoolbox.com/2008/12/10/titanium-novaya-ria-platforma/ )
v8 не поддерживает мультитредовость (там у него глобальный лок и боттлнек из-за этого). Использовать его на server-side достаточно проблематично. Если только иметь много процессов.
ИМХО, нельзя объять необъятное и впихнуть невпихуемое.
Javascript хорош как скриптовый язык на клиентской стороне, незачем его на сервер пихать.
Javascript хорош как скриптовый язык на клиентской стороне, незачем его на сервер пихать.
Когда писал топик, обещал себе не влезать в подобные споры, но не удержусь.
Чем javascript хорош на клиентской стороне и почему его незачем пихать на сервер?
Чем javascript хорош на клиентской стороне и почему его незачем пихать на сервер?
Поверьте, я не троллинга ради написал комментарий, это действительно мое скромное мнение. И мне тоже совсем не хочется спорить.
Хорош на клиентской стороне он тем, что позволяет легко работать с DOM и описывать какую-либо логику взаимодействия пользователя и страницы (сервиса).
Незачем его пихать на сервер, потому что он:
1 изначально для этого не был предназначен,
2, хотя это и вытекает из 1 — не имеет встроенных средств для работы с файловой системой, БД и т.д., следовательно, нуждается опять же в дополнительных библиотеках
Хорош на клиентской стороне он тем, что позволяет легко работать с DOM и описывать какую-либо логику взаимодействия пользователя и страницы (сервиса).
Незачем его пихать на сервер, потому что он:
1 изначально для этого не был предназначен,
2, хотя это и вытекает из 1 — не имеет встроенных средств для работы с файловой системой, БД и т.д., следовательно, нуждается опять же в дополнительных библиотеках
описывать какую-либо логику взаимодействия пользователя и страницы (сервиса)
Эта логика как-то принципиально отличается от логики на сервере?
не имеет встроенных средств для работы с файловой системой, БД и т.д., следовательно, нуждается опять же в дополнительных библиотеках
Node — это и есть такая библиотека. Только БД там пока нет (но есть дополнение к ней для работы с постгресом). Почти все языки работают с файловой системой или БД через библиотеки.
И вот еще аргумент. Если в команду придет новый разработчик, то он, скорее всего уже будет знать js, потому что писал на нем клентский код и у него не будет шока от специфичных языковых кренделей, как в случае с другими языками (например, переход с C# на руби, с PHP на Java и наоборот)
По поводу последнего согласен, есть плюс.
Однако, когда, допустим, эта библиотека разрастется настолько, что сможет покрыть все те задачи и ситуации, которые покрывает тот же PHP сейчас, разработчикам придется учить специфические кренделя Node =) Конечно не так сложно, как новый язык, это да.
Однако, когда, допустим, эта библиотека разрастется настолько, что сможет покрыть все те задачи и ситуации, которые покрывает тот же PHP сейчас, разработчикам придется учить специфические кренделя Node =) Конечно не так сложно, как новый язык, это да.
Эта логика как-то принципиально отличается от логики на сервере?
Ну, я думаю, да. Хотя бы потому, что на сервере парадигма «клиент-сервер», т.е. пришел запрос, произошли какие-то действия, выдан ответ. На клиенте же больше задач ориентировано на события, т.е. вовсю используется асинхронное программирование. На сервере, насколько я знаю (поправьте если не прав), вроде бы все синхронно.
На сервере все точно также ориентировано на события — пришел запрос => вызван обработчик события.
Да и вообще, как это зависит от языка?
Все, надоело спорить
Да и вообще, как это зависит от языка?
Все, надоело спорить
На Javascript также можно синхронно писать. Допустим есть какой то JS скрипт на сервере, он принимает параметры от клиента, выполняет логику, пишет в БД (например, через стронние билиотеки) и отдает ответ обратно клиенту.
Перенос JS логики оправдан если нужно обезопасить исполнение части JS кода, также проще производить изменения без перекомпиляций и другой головной боли.
Это не просто размышления, в данный момент делаю модули заказчику включая регистрацию и даже управление биллингом — делается на серверном JS, критичные к скорости модули реализованы на Java.
Перенос JS логики оправдан если нужно обезопасить исполнение части JS кода, также проще производить изменения без перекомпиляций и другой головной боли.
Это не просто размышления, в данный момент делаю модули заказчику включая регистрацию и даже управление биллингом — делается на серверном JS, критичные к скорости модули реализованы на Java.
не имеет встроенных средств для работы с файловой системойВы путаете язык и окружение. Окружение браузера не позволяет работать с фс и прочее, почему это должно как-то влиять на язык?
БДНифига-се. Ну-ка назовите язык со встроенной работой с БД. Только из реально используемых, а не академический.
Я понял вашу точку зрения ) Если так рассуждать, ни в каком языке этого нет, конечно.
Я не совсем уместно использовал слово «встроенных». Лучше будет сказать что-то вроде «готовых», «отлаженных», «устоявшихся», «общепринятых» и т.д. способов реализации. Которые можно найти в мануалах по языку.
Если говорить о C#, допустим, абстрагируясь от .NET — в нем нет работы с БД. Но C# ведь не используется в отрыве от фреймворка, поэтому можно сказать, что работа с БД в нем более или менее нативная. Также с PHP. Я думаю, сервера, на которых стоит PHP, не умеющий работать с MySQL — большая редкость.
Вобщем, не будем спорить на пустом месте, я думаю =)
Я не совсем уместно использовал слово «встроенных». Лучше будет сказать что-то вроде «готовых», «отлаженных», «устоявшихся», «общепринятых» и т.д. способов реализации. Которые можно найти в мануалах по языку.
Если говорить о C#, допустим, абстрагируясь от .NET — в нем нет работы с БД. Но C# ведь не используется в отрыве от фреймворка, поэтому можно сказать, что работа с БД в нем более или менее нативная. Также с PHP. Я думаю, сервера, на которых стоит PHP, не умеющий работать с MySQL — большая редкость.
Вобщем, не будем спорить на пустом месте, я думаю =)
Наверное тут имелась ввиду не встроенная работа с БД, а вообще работа с БД. И то что в других языках это воплощено, а для JS надо делать и опять же возникает вопрос — «зачем тратить столько времени на изобретение того что есть?»
Изначально он не был предназначен — это когда его Netscape много лет назад сочиняла. С тех пор много воды утекло. :-) Сейчас JS — это по сути абстракция. Синтаксис есть, объектная модель есть — чего еще надо-то? Клиентская реализация отличается от серверной по сути только «обвязкой» из объектов, принципиально ничего не меняется. Вот я сейчас пишу на JS для IPTV SetTopBox'а с движком Оперы — чтобы реализовать специфические функции железа (проигрывание видео-потоков, регулирование громкости, выключение/включение самой приставки, прошивка новой прошивки и т.п.) производителю нужно было только написать ма-а-аленькие библиотечки (вес .so'шек — считанные килобайты), которые являются «прокладками» и по сути тупо дают возможность вызывать функции соответствующего модуля ядра Линукса. Работать очень удобно и документация очень простая: каждая библиотечка создает прототип объекта, которым можешь пользоваться, а в документации просто описываются свойства/методы/события каждого объекта. И таким способом функционал можно расширять бесконечно… При этом это будет легко и беспроблемно — с сохранением изначального синтаксиса и свойств языка, а вспомните сколько геморроя у php было пока новые функции вводили и т.п.
Я последние несколько месяцев занимаюсь OLE-автоматизацией достаточно плотно, с использованием JS ) Так что прекрасно понимаю, о чем вы.
И да, мне тоже JS как язык нравится гораздо больше, чем PHP )
Однако, если мне понадобится писать какой-либо server-side, я не выберу JS, во всяком случае сейчас, это точно. Потому что мне в этом видятся помимо удобства написания кода — целые поля граблей. Лучше я буду писать на неудобном PHP, но если у меня возникнет некоторая нетривиальная задача, я с 99% вероятностью найду как эту задачу решать на PHP или еще каком-нибудь хорошо «обкатанном» языке или технологии.
И да, мне тоже JS как язык нравится гораздо больше, чем PHP )
Однако, если мне понадобится писать какой-либо server-side, я не выберу JS, во всяком случае сейчас, это точно. Потому что мне в этом видятся помимо удобства написания кода — целые поля граблей. Лучше я буду писать на неудобном PHP, но если у меня возникнет некоторая нетривиальная задача, я с 99% вероятностью найду как эту задачу решать на PHP или еще каком-нибудь хорошо «обкатанном» языке или технологии.
С этой точки зрения — полностью согласен!
К сожалению, с чисто практической точки зрения и с точки зрения конкретного инструментария у JS все «отработано» действительно только на клиентской стороне.
Ну, поживем — увидим. Программировать на нем на сервере — было бы очень неплохо! К сожалению, все это еще совсем не развито…
К сожалению, с чисто практической точки зрения и с точки зрения конкретного инструментария у JS все «отработано» действительно только на клиентской стороне.
Ну, поживем — увидим. Программировать на нем на сервере — было бы очень неплохо! К сожалению, все это еще совсем не развито…
>Изначально он не был предназначен — это когда его Netscape
>много лет назад сочиняла.
Изначально Netscape использовала Javascript и на сервере, и на клиенте, и сделала какую-то техногогию (в переводе живая нить, кажется) для связи клиентской и сервереной стороны.
А по теме — не все задачи являются вызовом функций операционной системы или OLE — часто надо писать алгоритмическую часть, и тут Javascript ничем не поможет.
Правильный подход — не сваливать язык и интервейс в одну кучу. Например,
>В-третьих, разве это не прекрасно, когда на сервер и на
>клиенте мы используем один язык? Один тестовый
>фреймворк, одинаковая сериализация (JSON), ну и прочие
>прелести.
JSON — это промежуточный формат для реализации интерфейса, зачем его привязывать жёстко к Javascript?
>много лет назад сочиняла.
Изначально Netscape использовала Javascript и на сервере, и на клиенте, и сделала какую-то техногогию (в переводе живая нить, кажется) для связи клиентской и сервереной стороны.
А по теме — не все задачи являются вызовом функций операционной системы или OLE — часто надо писать алгоритмическую часть, и тут Javascript ничем не поможет.
Правильный подход — не сваливать язык и интервейс в одну кучу. Например,
>В-третьих, разве это не прекрасно, когда на сервер и на
>клиенте мы используем один язык? Один тестовый
>фреймворк, одинаковая сериализация (JSON), ну и прочие
>прелести.
JSON — это промежуточный формат для реализации интерфейса, зачем его привязывать жёстко к Javascript?
Может, потому, что JSON == Javascript Object Notation?
Сериализовать можно во что угодно, JSON я привел именно потому, что он самый, что ни на есть «родной» для javascript, чтобы его десериализовать, нужно просто проэвалить строчку.
Я не понял вашу мысль, поясните, пожалуйста.
Сериализовать можно во что угодно, JSON я привел именно потому, что он самый, что ни на есть «родной» для javascript, чтобы его десериализовать, нужно просто проэвалить строчку.
А по теме — не все задачи являются вызовом функций операционной системы или OLE — часто надо писать алгоритмическую часть, и тут Javascript ничем не поможет.
Я не понял вашу мысль, поясните, пожалуйста.
В клиенте мы используем Javascript для работы с большими конструкциями типа DOM. Если писать на Javascript обработку, скажем, битовых полей в бинарных файлах — получим проблемы и с производительностью, насколько я понимаю.
Плюсы для использования JS на сервере можно было бы найти, если бы действительно было проще связать серверную и клиентскую части, написанные на одном языке. Но при аккуратном подходе проще для серверной части объявить интерфейс (например RPC на JSON какой-нибудь) и пользоваться существующими уже сейчас методиками и готовыми программистами.
Плюсы для использования JS на сервере можно было бы найти, если бы действительно было проще связать серверную и клиентскую части, написанные на одном языке. Но при аккуратном подходе проще для серверной части объявить интерфейс (например RPC на JSON какой-нибудь) и пользоваться существующими уже сейчас методиками и готовыми программистами.
1) Ага, точно — было что-то такое! По крайней мере вспоминаю, что в 90-х я об этом даже что-то в книжках читал…
2) Насчет алгоритмической части хотелось бы действительно поподробнее. Вы пишете как пример про «обработку битовых полей в бинарных файлах», но разве это имеет отношение к обсуждаемой теме? Обработка битовых полей вообще прямо скажем не сильная сторона любых скриптовых языков с динамической типизацией, однако тому же php и работающим на нем людям это совершенно не мешает. :-) И, опять же, что мешает реализовать нужный функционал в дополнительных объектах точно также, как в прочих случаях? Я особых проблем не вижу… А с битами работать, кстати, вообще не проблема — в JS благо операторы для побитовых операций есть. Как говорится, дайте мне OR, AND и XOR — и я переверну Землю. ;-) И даже сдвигов побитовых не надо, которые в JS тоже есть. :-)
А вот на принципиальные именно алгоритмические косяки JS посмотреть было бы интересно. Не флейма ради, а самообразования для. :-)
2) Насчет алгоритмической части хотелось бы действительно поподробнее. Вы пишете как пример про «обработку битовых полей в бинарных файлах», но разве это имеет отношение к обсуждаемой теме? Обработка битовых полей вообще прямо скажем не сильная сторона любых скриптовых языков с динамической типизацией, однако тому же php и работающим на нем людям это совершенно не мешает. :-) И, опять же, что мешает реализовать нужный функционал в дополнительных объектах точно также, как в прочих случаях? Я особых проблем не вижу… А с битами работать, кстати, вообще не проблема — в JS благо операторы для побитовых операций есть. Как говорится, дайте мне OR, AND и XOR — и я переверну Землю. ;-) И даже сдвигов побитовых не надо, которые в JS тоже есть. :-)
А вот на принципиальные именно алгоритмические косяки JS посмотреть было бы интересно. Не флейма ради, а самообразования для. :-)
По пункту 2:
А чем это плохо? Если вспомнить архитектуру интерпритатора того-же PHP, то в пакет библиотек входят написанные на C/C++, реализующие различный функционал. Лиха беда начало, с развитием возможности писать server-side на js реализация функционала подтянется. Больше языков, красивых и разных.
А чем это плохо? Если вспомнить архитектуру интерпритатора того-же PHP, то в пакет библиотек входят написанные на C/C++, реализующие различный функционал. Лиха беда начало, с развитием возможности писать server-side на js реализация функционала подтянется. Больше языков, красивых и разных.
пишу на ASP/Jscript 6 лет
сделать можно чёрта лысого
после простоты и стройности javascript разнобой во всех принципиальных концепциях РНР кажется просто чудовищным .)
сделать можно чёрта лысого
после простоты и стройности javascript разнобой во всех принципиальных концепциях РНР кажется просто чудовищным .)
ASP Jscript поглядите .))
а в сторону Aptana Jaxer пробовали копать?
Пока нет. Но это уже в планах =)
Да, Jaxer решает. Особенно интересно подключать серверно jquery и полосовать таблицы одной строчкой кода.
вот бы кто-нибудь написал здесь про него подробно — отдельной статьёй… :)
Интересная штука, но слишком уж он пропагандирует смешение логики и представления.
Серверный DOM, к сожалению, бесполезен. Там и проблемы с огромным кол-вом передаваемых по сети данных, и с сериализацией и тп.
Очень мешает невозможность сделать проксируюмую функцию на клиенте, когда функция — свойство объекта:
Серверный DOM, к сожалению, бесполезен. Там и проблемы с огромным кол-вом передаваемых по сети данных, и с сериализацией и тп.
Очень мешает невозможность сделать проксируюмую функцию на клиенте, когда функция — свойство объекта:
test = function(){}; test.proxy = true; // все норм. test - глобальная переменная
someObf.test= function(){}; someObf..proxy = true; // не работает
Прошу прощения за опечатки. Последняя сточка должна быть такой:
someObj.test = function(){}; someObj.test.proxy = true; // не работаеттам даже так она не станет прокси. Не знаю почему, но проксифицируются только функции которые вообще олдскульно объявляются:
но из этой функции мы можем уже вызывать серверные методами любого уровня вложенности.
+ вызов прокси-функции делает синхронный запрос на сервер, то есть это ни разу не seamless AJAX, как пытаются заявить разработчики JAXER и вот эти прокси функции как раз и есть бесполезная вещь, в отличие от серверного DOM.
с серверным DOM мы можем заменить парадигму XML+XSLT на HTML+jQuery, я уже приводил пример выше — можно легко располосовать таблицу, серверно подключив jQuery
function a(){
//...
}
a.proxy = true;
но из этой функции мы можем уже вызывать серверные методами любого уровня вложенности.
+ вызов прокси-функции делает синхронный запрос на сервер, то есть это ни разу не seamless AJAX, как пытаются заявить разработчики JAXER и вот эти прокси функции как раз и есть бесполезная вещь, в отличие от серверного DOM.
с серверным DOM мы можем заменить парадигму XML+XSLT на HTML+jQuery, я уже приводил пример выше — можно легко располосовать таблицу, серверно подключив jQuery
<script runat="server" src="jquery.js"></script>
<script runat="server">
$('table > tbody > tr:even').addClass('even');
</script>
на клиенте все четные строки в таблицах будут с классом even.
Серверный DOM не нужен потому что с DOM надо на клиенте работать. И вопрос не в удобстве, а в быстроте внесения изменений потом.
Категорично слишком. Я пробовал работать с DOM на сервере — это не только очень удобно но и быстро. Вместо XSLT преобразований использовать jquery мне, как js-разработчику намного проще, соответственно изменения вносить тоже проще и быстрее.
MVS, REST — аббревиатуры, которые не просто так стали популярны сейчас. Серверный DOM — такое же зло, как обращаться в шаблонах к базе. Да, порой проще, но никак не на пользу.
По поводу быстроты у меня очень большие сомнения. Сколько соединений надо сделать, чтобы выполнить что-нибудь типа
По поводу быстроты у меня очень большие сомнения. Сколько соединений надо сделать, чтобы выполнить что-нибудь типа
$('.some-class').css('color', 'red')?Соединений чего с чем? Короче, ни одного соединения не надо делать.
Я так понимаю, вы думаете, что кроме клиентского DOM, на жизненном цикле страницы существует какой-то серверный DOM, и если там, на сервере его поменять. то он поменяется на клиенте?
Так вот, это не так, все гораздо прозаичнее. В Jaxer серверный DOM существует только на этапе генерации страницы, его можно менять JS-средствами, но после того как весть DOM вываливается в HTML виде в response, он, серверный DOM, перестает существовать. Никакими прокси-функциями с клиента до него не достучаться.
И использовать его надо в том же ключе, что и XML+XSLT, например, если на сервере сформировано многоуровневое HTML меню:
то покрасить все родительские элементы меню, присвоив им класс «in» можно очень просто:
Естественно, надо разделять данные и отбражение, и очень красиво на мой взгляд иметь такую структуру:
один и тот же закешированный код обрабатывается разными js-обработчиками и на выходе получаем главное меню и подменю.
В итоге, это не зло, а очень удобный способ сформировать страницу на сервере используя JS. Ну, а в кривых руках любое средство — зло.
Я так понимаю, вы думаете, что кроме клиентского DOM, на жизненном цикле страницы существует какой-то серверный DOM, и если там, на сервере его поменять. то он поменяется на клиенте?
Так вот, это не так, все гораздо прозаичнее. В Jaxer серверный DOM существует только на этапе генерации страницы, его можно менять JS-средствами, но после того как весть DOM вываливается в HTML виде в response, он, серверный DOM, перестает существовать. Никакими прокси-функциями с клиента до него не достучаться.
И использовать его надо в том же ключе, что и XML+XSLT, например, если на сервере сформировано многоуровневое HTML меню:
ul сlass="menu"
____li
____li
____li
________ul
____________li
____________li сlass="active"
____________li
____li
то покрасить все родительские элементы меню, присвоив им класс «in» можно очень просто:
$('ul.menu li.active').closest('ul.menu').find('li:has(li.active)').addClass('in');Естественно, надо разделять данные и отбражение, и очень красиво на мой взгляд иметь такую структуру:
include('navigation.html', 'mainmenu.js');
include('navigation.html', 'submenu.js');
один и тот же закешированный код обрабатывается разными js-обработчиками и на выходе получаем главное меню и подменю.
В итоге, это не зло, а очень удобный способ сформировать страницу на сервере используя JS. Ну, а в кривых руках любое средство — зло.
Спасибо за разъяснение.
Только вот если все равно будет использоваться шаблонизатор, то зачем тут серверный DOM? Пост-обработка?
Только вот если все равно будет использоваться шаблонизатор, то зачем тут серверный DOM? Пост-обработка?
Самое смешное, что Jaxer не имеет шаблонизатора в классическом понимании. Можно, конечно, пользоваться вот этим:
PURE
EJS
chain.js (jquery plugin)
или Javascript Microformatting от John Resig
но Jaxer предполагает другой подход, схема
БД -> XML + XSLT = HTML меняется на
БД -> JSON + JS = HTML или если кешировать куски
БД -> HTML + JS = HTML
+ возможность использовать один и тот же JS-код на сервере и на клиенте (классические пример — валидация форм на клиенте и потом тем же кодом на сервере)
мне нравится такая гибкость, можно использовать любую парадигму программирования, ну и JS — очень стройный язык, хотя первое, что приходит впервые в голову впервые услышавшему словосочетание serverside javascript — «нахрена это надо? есть же PHP хотя бы»
PURE
EJS
chain.js (jquery plugin)
или Javascript Microformatting от John Resig
но Jaxer предполагает другой подход, схема
БД -> XML + XSLT = HTML меняется на
БД -> JSON + JS = HTML или если кешировать куски
БД -> HTML + JS = HTML
+ возможность использовать один и тот же JS-код на сервере и на клиенте (классические пример — валидация форм на клиенте и потом тем же кодом на сервере)
мне нравится такая гибкость, можно использовать любую парадигму программирования, ну и JS — очень стройный язык, хотя первое, что приходит впервые в голову впервые услышавшему словосочетание serverside javascript — «нахрена это надо? есть же PHP хотя бы»
Согласен. Имхо, Jaxer наиболее близок к Adept.
Сейчас пишу CMS на Javascript, Компилятор Rhino. Как можно будет делать какие-то выводы, напишу статью. Времени мало, продвигается слабо:(
Основной плюс, в отличие от v8, — не надо компилировать на сервере. Подойдет любой Java хостинг. И, конечно, гибкость JS и мощь Java очень привлекают.
Основной плюс, в отличие от v8, — не надо компилировать на сервере. Подойдет любой Java хостинг. И, конечно, гибкость JS и мощь Java очень привлекают.
интересное решение, мы движемся в одну сторону forum.hivext.ru/index.php?topic=18.0, я так понимаю вы используете java scripting? если есть какие то вопросы или есть чем поделится, можно отписаться на форуме. Скоро откроем scripting сервис для разработчиков, приходите пописать на серверном Javascript, вам точно понравится.
Кстати, серверные приложения под Opera Unite тоже на JS пишутся.
У меня на работе коллега тоже последние недели серверным яваскриптом занимается =) c использование v8/spidermonkey.
Как по мне, если очень хочется писать на яваскрипте на сервере, то берем Rhino и проблем с платформой нет.
Как по мне, если очень хочется писать на яваскрипте на сервере, то берем Rhino и проблем с платформой нет.
Кроме Node, еще и MooTools ( mootools.net/download ) так же недавно выпустил библиотеку для серверного JS.
Ага, я его тоже поставил, правда в виртуалку. Очень интересный сервер, надо сказать :)
Теоретически v8 намного быстрее тогоже PHP, ведь если верить немногочисленным источникам, то перед выполнением он компилируется в машинный код, хотя ничего подробного на эту тему не нашёл =(
Привет из 2016. NodeJS уже 6 версии и очень популярен.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Server-side JS (v8+Node)