I'm sorry to report that it is going to take more work to get jQuery running on jsdom. Sizzle however does work! I really want to keep jsdom as light as possible, so adding in full browser emulation like env.js is not really a priority at this time. stackoverflow.com/questions/1801160/can-i-use-jquery-with-node-js
Это от автора jsdom.
По поводу моего незнания, вывод абсолютно нелогичен. И неверен, кстати (полтора года хардкорного JS). ПРавее остальных себя не считаю. Привык оперировать аргументами.
> используйте любой каркас типа base2
Они кривы в мелочах.
> разрушение объектов в языках со сборкой мусора — не дело.
Вы не поняли. multi.rubyforge.org/text8.html
> для событийно-управляемых приложений и вообще для Unix потоки скорее вредны.
Согласен, что в этом классе приложений они не нужны. Тем не менее, я говорил о мощности языка и платформы вообще.
> Yehuda Katz является контрибутором в такой проект, как jQuery Core
и?
в языке
— Классическое наследование, mix-ins
— method_missing
— destructuring
— &:method
— потоки
— всё — объекты
в комьюнити
— Rails, Rack, Passenger
— DHH, Yehuda Katz
Могу по каждому пункту развернуть, почему это действительно нужно, и написать еще много чего))
В целом, преимуществ node.js два:
— скорость (да, V8 рулит)
— молодость (орентир на асинхронность дан изначально, нет legacy кода)
При этом сам язык менее мощный и выразительный, чем руби (см. выше). Зачем писать на менее мощном языке, при том, что производительность имеет тенденцию повышаться просто из-за следствий закона Мура, я не понимаю.
...«нужны классы для прямоугольника и квадрата» — это не задача, а начало решения не поставленной задачи.
Чтобы как-то определиться, нужно понять желаемую функциональность, в первую очередь.
Clojure — это немного другое… Не ощущения плотной стены скобок и списков, как в классических лиспах. Плюс много вкусностей типа Software Transactional Memory, Persistent Data Structures, и т. д.
Реально интересно, даже после руби.
Вы, простите, заочно это все высказываете? Не имеючи, то есть?
Свобода есть в Сидии — свобода перенюхать тысячи и тысячи какашек, чтобы обнаружить, что все они — натурально какашки. Плюс бесценная свобода выложить свою какашку «на радость детворе»…
Так что как раз iPhone — классический пример того, как нужно строить проприетарную платформу.
* и будет тогда все тормозить пипецкак ;)
И по многим другим пунктам контраргументов пока не вижу.
stackoverflow.com/questions/1801160/can-i-use-jquery-with-node-js
Это от автора jsdom.
По поводу моего незнания, вывод абсолютно нелогичен. И неверен, кстати (полтора года хардкорного JS). ПРавее остальных себя не считаю. Привык оперировать аргументами.
Yehuda пишет server-side JS?
jQuery на node.js неприменима.
Они кривы в мелочах.
> разрушение объектов в языках со сборкой мусора — не дело.
Вы не поняли. multi.rubyforge.org/text8.html
> для событийно-управляемых приложений и вообще для Unix потоки скорее вредны.
Согласен, что в этом классе приложений они не нужны. Тем не менее, я говорил о мощности языка и платформы вообще.
> Yehuda Katz является контрибутором в такой проект, как jQuery Core
и?
в языке
— Классическое наследование, mix-ins
— method_missing
— destructuring
— &:method
— потоки
— всё — объекты
в комьюнити
— Rails, Rack, Passenger
— DHH, Yehuda Katz
Могу по каждому пункту развернуть, почему это действительно нужно, и написать еще много чего))
В целом, преимуществ node.js два:
— скорость (да, V8 рулит)
— молодость (орентир на асинхронность дан изначально, нет legacy кода)
При этом сам язык менее мощный и выразительный, чем руби (см. выше). Зачем писать на менее мощном языке, при том, что производительность имеет тенденцию повышаться просто из-за следствий закона Мура, я не понимаю.
А что за мелочи?
Чтобы как-то определиться, нужно понять желаемую функциональность, в первую очередь.
Реально интересно, даже после руби.
Свобода есть в Сидии — свобода перенюхать тысячи и тысячи какашек, чтобы обнаружить, что все они — натурально какашки. Плюс бесценная свобода выложить свою какашку «на радость детворе»…
Так что как раз iPhone — классический пример того, как нужно строить проприетарную платформу.