akzhan 20 апр 2010 в 03:48

seedJS — Менеджер пакетов CommonJS

1 мин

2.2K

Node.JS *

+23

Комментарии 38

tyumener 20 апр 2010 в 06:53

Картинка на червяков похожа :)

НЛО прилетело и опубликовало эту надпись здесь

medved13 20 апр 2010 в 11:56

Не просто похожа, а прямо вылитые червяки. Копошаться такие в баночке, копошаться. А ты их достаёшь по одному, на крючок насаживаешь и каааак… фьюх… и поплавочек уже мерно качается на волнах. А рядом в ведре рыба пойманная плещется. И костерок потрескивает.

Чорт, что-то на рыбалку захотелось :)

tigso 20 апр 2010 в 18:29

Сегодня хлеб с тмином купил, брат тоже разглядывал разглядывал и говорит на червяков похожи.

s0b3r 20 апр 2010 в 06:57

Было бы интересно почитать про это поподробнее. Из этого «обзора» я вынес только, что есть какие-то семки.js

kirilloid 20 апр 2010 в 07:15

Есть такая концепция: Server-side Javascript
CommonJS — это язык, построенный на основе javascript для воплощения концепции.
(начнем проводить аналогию например с php)

Вот для этой реализации был написан менеджер пакетов (pear).

Между делом нам сообщают, что работает сервер для пакетов на node.js.
Последний представляет из реализацию(?) CommonJS на основе js-движка V8 (от Хрома)
с доп. библиотеками для написания произвольного TCP-сервера.

Поправьте, если что не так.

akzhan 20 апр 2010 в 07:43

Всё верно. В будущем вероятно, добавят поддержку других серверов.

akzhan 20 апр 2010 в 07:33

Сейчас становится очень популярной разработка серверных приложений на Javascript с использованием машины, управляемой событиями.
Скорость и стабильность таких приложений обычно превосходят аналогичные на Ruby/EM и Python/Twisted.
Немаловажно также единообразие серверного и клиентского окружения.

Самы распространённый сервер для таких приложений — Node.JS.

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

В частности, крайне не хватало менеджера пакетов для простоты их создания и распространения.

Теперь есть.

s0b3r 20 апр 2010 в 07:47

Теперь понятно. Мне кажется, стоит сделать отдельный блог под серверный JS, потому что под Javascript'ом как-то принято понимать клиентский JS. Хотя, с другой стороны, продвигать в массы будет проще через этот блог. Но тогда стоит получше разжёвывать в постах о том что это и с чем его едят, а может быть помещать ссылки на посты по этой теме. Тогда и желающих помочь больше найдётся ;)

ksdaemon 20 апр 2010 в 07:49

Да, тема очень интересная и нужная. Тем более в свете все большей популярности ServerSide JS.

brainfucker 20 апр 2010 в 09:01

Похоже seed является неким враппером над nodejs, как это влияет на производительность?

akzhan 20 апр 2010 в 09:06

Фактически никак.

Замедляются вызовы require, которые обычно в приложении выполняются ещё до входа в цикл сообщений.

brainfucker 20 апр 2010 в 09:11

Просто подозрения вызвал этот файл http://github.com/seedjs/seed/blob/master/src/loop.cc

akzhan 20 апр 2010 в 09:18

Насколько я помню, это выход из цикла и вход в цикл сообщений библиотеки libev.
Используется для requireSync.

Xpeh 20 апр 2010 в 14:09

>Самы распространённый сервер для таких приложений — Node.JS

Мне кажется, Opera Unite популярней.

akzhan 20 апр 2010 в 16:35

Opera Unite построена с использованием технологии одноранговой сети.

Я жке говорю про традиционный стек client-server.

Xpeh 20 апр 2010 в 16:54

Удивительно, но «традиционный стек client-server» никак не противоречит «использованию технологии одноранговой сети», просто каждый компьютер может быть и сервером, и клиентом.
В случае Opera Unite ваше определение «серверных приложений на Javascript с использованием машины, управляемой событиями» вполне подходит.

brainfucker 20 апр 2010 в 08:59

Семки.js =D похоже тока для реальный пацанов, пойду поставлю.

brainfucker 20 апр 2010 в 09:53

Кстати установка не самая тривиальная никогда не понимал, что мешает сделать через makefile

akzhan 20 апр 2010 в 10:00

Форкнитесь и добавьте Makefile ;)

Вообще говоря, использование make не является стандартным для разработчиков на том же Ruby, где есть великолепные альтернативы (rake, thor).

Уверен, что появится и альтернатива make на чистом Javascript.

kurokikaze 27 апр 2010 в 18:16

Есть jake — клон rake. Используется например в фреймворке Geddy для генерации шаблона приложения.

almirus 20 апр 2010 в 07:01

семена укропа? )

porzione 20 апр 2010 в 08:23

похожи на семена фенхеля :)

skiedr 20 апр 2010 в 19:48

Зира?

mekegi 24 апр 2010 в 17:59

нет. это Тмин обыкновенный — используется в кулинарии

pento 20 апр 2010 в 07:55

Не самая удачная иллюстрация.

akzhan 20 апр 2010 в 07:57

Это их лого )

TedBeer 20 апр 2010 в 08:50

V8 не поддерживает E4X и это очень грустно

akzhan 20 апр 2010 в 09:04

Можно посмотреть в сторону

TedBeer 20 апр 2010 в 09:27

Спасибо, гляну обязательно поближе. Но это все костыли, а E4X — стандарт.

brainfucker 20 апр 2010 в 09:57

Это просто библиотеки, а E4X действительно стандарт… Костылями имхо неуместно простые библиотеки называть.

TedBeer 20 апр 2010 в 10:06

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

brainfucker 20 апр 2010 в 09:06

Для Node.js есть libxmljs и несколько других неплохих библиотек для работы с XML.

kirilloid 20 апр 2010 в 11:52

А еще ни один браузерный js-движок не поддерживает работу с файлами и сокетами. Но node.js-то их поддерживает. Может, и добавят.

TedBeer 20 апр 2010 в 12:15

Chromium уже поддерживает вебсокеты. Мозиловский движок — File API ( частично).

kurokikaze 20 апр 2010 в 12:19

Слишком глубоко придётся в V8 копаться. Поддержку файлов и сокетов можно добавить просто добавив функций глобальному объекту, а E4X — уже изменение синтаксиса JS.

egorinsk 21 апр 2010 в 08:03

Слушайте, а чем вам нравится Server side JS? Тем, что там можно писать как курица лапой и при этом интерпретатор не ругается? По моему, так яваскрипт — гадость с неудобным синтаксисом, кроме того язык динамический и плохо оптимизируемый (читай тормозной). Там даже наследования нет нормального, или функции типа object_merge.

akzhan 21 апр 2010 в 16:45

Начнём с того, что на сегодня для этого языка существуют фактически самые быстрые движки, которые вообще доступны для динамических языков.

Кроме того, писать для web обычно гораздо удобнее на языках с динамической типизацией.

«Нормальное» наследование добавляется включением любой библиотеки наподобие base2.

Зарегистрируйтесь на Хабре, чтобы оставить комментарий