Комментарии 48
Многабукаф но асилил.
Пока читал, всё время думал «а ведь в Rails 3.1 всё уже решили», а потом дочитал и успокоился.
> Поскольку и Петя и Вася ни на чем, кроме джаваскрипта, программировать не умели
Нафиг такие друзья? Node.js бегает вроде бы быстрей всех из-за движка V8.
Нафиг такие друзья? Node.js бегает вроде бы быстрей всех из-за движка V8.
therubyracer работает еще быстрее, чем внешний NodeJS засчет контектов и прямых вызовов. Есть еще mustang, который те же яйца, но вид сбоку.
Сразу подумал — «щас тут будут окунать CoffeeScript». Угадал наполовину.
Кстати, большинство моих коллег к CoffeeScript относятся скептически. Хотя, раньше и к HAML/Sass скептически относились, но ничего — втянулись.
Кстати, большинство моих коллег к CoffeeScript относятся скептически. Хотя, раньше и к HAML/Sass скептически относились, но ничего — втянулись.
Мне кажется, что порог вхождения все повышается и повышается… Ruby + rails + html + haml/slim + css + scss/sass + js + coffeescript… Cвязка ruby + rails + html + js + css немного проще :-)
> Ruby + rails + html + haml/slim + css + scss/sass + js + coffeescript
ну тогда уж Ruby + rails + haml + scss + coffeescript. либо одно, либо другое обычно. да и эта связка в общем-то не для новичков в rails.
ну тогда уж Ruby + rails + haml + scss + coffeescript. либо одно, либо другое обычно. да и эта связка в общем-то не для новичков в rails.
Ну мне казалось, что знание haml не освобождает от необходимости знать html (иначе это будет странно), равно как и знание coffeescript подразумевает знание client side js. А про связку не для новичков… Эти примочки усиленно продвигаются сообществом, частенько в jobs упоминается haml, в рельсах 3.1 ставят coffeescript по умолчанию… значит нужно курить.
ну если по части haml вы в общем-то правы, нужно знать как минимум концепцию и назначение тегов, то по части кофискрипта тут такая ситуация, что по сути это самостоятельный язык, довольно похожий на руби, и используя его, хоть js знать и желательно, но не обязательно.
а scss — и вовсе скорее расширение css, чем его упрощение/стиллизация.
а scss — и вовсе скорее расширение css, чем его упрощение/стиллизация.
Я не спорю, просто пришел в эту песочницу и приходится разбираться с десятком dsl, это здорово конечно что они есть — красота, DRY и все такое, но вначале времени уходит на это просто вагон. А best practicies хочется соблюдать ;-)
Я что-то вообще не заметил похожести на руби. Табы, list comprehensions, «x < y < z», оператор in — это же сплошной питон.
Ну действительно дело привычки. Но после того, как втянешься, тяжело потом возвращаться к «родному» джаваскрипту.
Примерно как после haml практически нереально заставить себя начать снова руками писать и закрывать теги, а после sass писать обычный css.
Примерно как после haml практически нереально заставить себя начать снова руками писать и закрывать теги, а после sass писать обычный css.
Исправьте ссылку на rubyracer, пожалуйста (.git в конце), я уж подумал, и он вымышленный)
> В статье, среди прочего, написанно что мол, JRuby очень быстрый и вообще крутой
очень спорный вопрос. может он и быстрее MRI, но памяти кушает в 2-4 раза больше. из-за этого в реальных условиях 6 фронтендов в кластере на VPS на MRI 1.9.2 работают быстрее, чем 3 фронтенда на JRuby при одинаковом расходе памяти и диска. процессора может jruby кушает меньше, но чтобы нагрузить его полностью, надо делать несоизмеримую конфигурацию.
> CoffeeScript, UglifyJS, sprockets, ExecJS
что-то у вас смешались в кучу кони, люди. понимаю, зачем нужно первое, второе и третье. но ответьте на главный вопрос по топику, зачем испольнять в ruby-среде server-side javascript?
и последнее замечание. как и было отмечено, многабукаф, при том что весь смысл поста в десяти строках кода.
очень спорный вопрос. может он и быстрее MRI, но памяти кушает в 2-4 раза больше. из-за этого в реальных условиях 6 фронтендов в кластере на VPS на MRI 1.9.2 работают быстрее, чем 3 фронтенда на JRuby при одинаковом расходе памяти и диска. процессора может jruby кушает меньше, но чтобы нагрузить его полностью, надо делать несоизмеримую конфигурацию.
> CoffeeScript, UglifyJS, sprockets, ExecJS
что-то у вас смешались в кучу кони, люди. понимаю, зачем нужно первое, второе и третье. но ответьте на главный вопрос по топику, зачем испольнять в ruby-среде server-side javascript?
и последнее замечание. как и было отмечено, многабукаф, при том что весь смысл поста в десяти строках кода.
Хотелось как-то обратить внимание на тот долгий и героический путь, который в итоге привел к этим десяти срочкам кода. :)
ну это-то в общем-то ладно, у вас довольно интересный стиль написания, за который многабукаф вам можно простить :)
но вот по части зачем нужен в ruby-среде server-side javascript, я так до сих пор и не понял.
но вот по части зачем нужен в ruby-среде server-side javascript, я так до сих пор и не понял.
Так ведь эти самые CoffeeScript/UglifyJS и есть server-side джаваскрипт.
А, допустим, завтра какой-нибудь очередной Вася напишет на джаваскрипте тулзу, которая будет оптимизировать и ужимать html. Помню, недавно гугл вроде что-то подобное релизил.
И с помощью ExecJS эту самую server-side тулзу можно будет прикрутить в виде middleware к тем же рельсам, например. И не придется очередные огороды городить. Красота ведь.
А, допустим, завтра какой-нибудь очередной Вася напишет на джаваскрипте тулзу, которая будет оптимизировать и ужимать html. Помню, недавно гугл вроде что-то подобное релизил.
И с помощью ExecJS эту самую server-side тулзу можно будет прикрутить в виде middleware к тем же рельсам, например. И не придется очередные огороды городить. Красота ведь.
ну дело всё в том, что чтобы пользоваться CoffeeScript/UglifyJS, вам лично не нужен ExecJS. рельсы сами всё делают за вас.
по части прикручивания JS-тулов в качестве middleware — здесь тоже: а) ExecJS нужен только тому, кто будет писать гем б) всё тоже самое можно написать без ExecJS, вызывая тулзу из руби выполнением команды командной строки.
по части прикручивания JS-тулов в качестве middleware — здесь тоже: а) ExecJS нужен только тому, кто будет писать гем б) всё тоже самое можно написать без ExecJS, вызывая тулзу из руби выполнением команды командной строки.
Так блин, чтобы тулза работала из командной сроки, нужно чтобы командная строка отвечала некоторым свойствам. Скажем, чтобы из командной строки запускать coffee, в PATH должен быть nodejs и установленный nmp c пакетом coffeescript.
Намного проще в гем приложить js-исходник и запускать его через execjs.
А статья, наверное, как раз для потенциальных писателей гемов. Зачем в повседневной жизни execjs — фиг знает. Ну разве что можно на нем какой-нибудь крутой облачный фреймворк для тестирования js написать. или еще какой-нибудь изврат в этом духе.
Намного проще в гем приложить js-исходник и запускать его через execjs.
А статья, наверное, как раз для потенциальных писателей гемов. Зачем в повседневной жизни execjs — фиг знает. Ну разве что можно на нем какой-нибудь крутой облачный фреймворк для тестирования js написать. или еще какой-нибудь изврат в этом духе.
ужимать нужно не итоговый html, а шаблоны. с css та же история, если вы собираете статику чаще, чем при деплое, то тут уж впору задуматься, всё ли у вас хорошо с логикой
Node.js — нирвана асинхронности ;-) Хотя зачем тогда связка с Ruby… я чего-то не понимаю.
event machine — нирвана асинхронности в ruby, но опять-таки не в этом дело. если использование JS становится принципиальным именно из-за асинхронности, то проще запустить чистый node.js.
и вообще, не люблю я эту вашу асинхронность. на данный момент её считаю не более, чем buzzword'ом, который используют в основном люди, имеющие мало отношения к high-load'у.
и вообще, не люблю я эту вашу асинхронность. на данный момент её считаю не более, чем buzzword'ом, который используют в основном люди, имеющие мало отношения к high-load'у.
Ну я пока high load не заморачивался, Вам виднее конечно… Комментарий был к тому, что с позиции разработчика не самого большого левела для меня не очевиден профит execjs, разве что действительно писать гемы, как заметил уважаемый ТС.
highload в умах большинства — тот же buzzword. на деле же асинхронность в нём не такая уж и лишняя.
а «не люблю асинхронность» зачастую не более, чем «я не знаю, как этим пользоваться»
а «не люблю асинхронность» зачастую не более, чем «я не знаю, как этим пользоваться»
> а «не люблю асинхронность» зачастую не более, чем «я не знаю, как этим пользоваться»
«люблю асинхронность» в общем-то зачастую то же самое ;)
по части highload — большинство хотя бы назначение этого термина понимают. большинство пищащих об асинхронности (и довольно большая доля тех, кто с ней работает) не могут даже внятно сказать, какой от неё профит, и за счёт чего он получается.
«люблю асинхронность» в общем-то зачастую то же самое ;)
по части highload — большинство хотя бы назначение этого термина понимают. большинство пищащих об асинхронности (и довольно большая доля тех, кто с ней работает) не могут даже внятно сказать, какой от неё профит, и за счёт чего он получается.
Спрашивается и нахрена тогда Rails? Возьмите какой-нибудь RingoJS или ExpressJS, эйфория от Rails вроде бы прошла уже в долине, most guys moved on.
Ну, в рельсах и в руби помимо CoffeeScript/UglifyJS сильно много разных других приятностей. По сути, идеальный сферический разработчик в ваакуме с джаваскриптом вообще не сталкивается — пишет себе на руби. А фронтенд-скрипты на кофескрипте, который придумывался с закосом под опять же под руби.
вы так говорите, как-будто RingoJS или ExpressJS чем-то лучше Rails.
Популярность, эйфория, тренды… Cant take this bullshit anymore :-/
Немного не понимаю недовольства комментаторов. Мало ли что нужно написать или адаптировать к готовому проекту.
А вообще, даже если бы тут была бессмысленная чепуха, я бы всё равно дочитал бы пост до конца — стиль повествования выше всяких похвал.
А вообще, даже если бы тут была бессмысленная чепуха, я бы всё равно дочитал бы пост до конца — стиль повествования выше всяких похвал.
Ещё, ещё!!! :)
Всё таки, я не понял. Зачем надо запускать js код в руби? Какой от этого профит?
А, допустим, Петя и Вася — православные, они не засоряют глобальную область видимости функциями и varами, не лепят замыканий с закопанными внутри зависимостями между библиотеками друг друга,
а используют систему модулей CommonJS (спецификацию Modules/1.1.1)
Что тогда?
а используют систему модулей CommonJS (спецификацию Modules/1.1.1)
Что тогда?
Если вам так нравится яваскрипт, пишите сразу на ноде, в чем проблема? А делать компилятор одного высокоуровневого языка в другой — заведомый фейл, так как тупая железка будет выдававть менее качественный и производительный код, чем программист.
Хотя зачем это объяснять рубистам, у которых там стоит 20 плагинов к рельсам и все это добро только минуту запускается, а потом работает со скокростью от силы в пару rps.
И еще, в реальности, проект, который вы описали, загнется с вероятностью 99% если каждый программист будет писать на своем языке и с помощью кучи костылей все это связывать. Завтра к вам придет студент, прочитавший основы Питона и школьник-эрлангер, и тогда вообще никто в получившейся каше из кода и костылей не разберется.
Хотя зачем это объяснять рубистам, у которых там стоит 20 плагинов к рельсам и все это добро только минуту запускается, а потом работает со скокростью от силы в пару rps.
И еще, в реальности, проект, который вы описали, загнется с вероятностью 99% если каждый программист будет писать на своем языке и с помощью кучи костылей все это связывать. Завтра к вам придет студент, прочитавший основы Питона и школьник-эрлангер, и тогда вообще никто в получившейся каше из кода и костылей не разберется.
Давайте по пунктам.
Причем тут вообще нравится/не нравится джаваскрипт? Думаю, мало кому охота садиться писать на ноде после рельс. Это неудобно, медленно и не стоит свеч в большинстве случаев. Про компилятор я вообще ничего не понял кроме того, что вы явно сморозили какую-то ахинею.
Если вы имеете ввиду транслятор Coffeescript, то лол, он как раз в 90% случаев генерирует более качественный код, чем программист. Ага, такая вот тупая железяка. Примерно так же, как тупая железяка делает миллионы вещей, которые не под силу человеку. Например, расчитывает траектории ракет, управляет ядерными электростациями, передает и получает в секунду времени столько информации, сколько человеку за год не прочитать или складывает циферки с бешенной скосростью, отрисовывая трехмерную графику, чтобы программист мог после работы погонять с друзьями в квейк.
Собственно, неплохим подтверждением моих слов является тот факт, что современные компиляторы компилируют более высокий язык C в машинные коды намного круче, чем любой, даже самый гуру-программер смог бы написать на ассемблере.
Про рубистов и пару rps — качественный вброс, я его комментировать даже не буду. Слишком толсто.
Ну и про реальность. У вас с ней нелады. Знаю, ничего банальнее в качестве примера привести нельзя, но опять же Basecamp. Живет себе, много лет существует. Бабло приносит. Создатель недавно вон поменял Lamborghini Gallardo на Zondа и разбил уже три порше участвуя в полупрофессиональных гонках.
И они там, о боже ж мой, совсем дурачки, пишут себе на CoffeeScript, который «компилируется» в менее качественный и производительный код, и в ус не дуют. Чтоб я так жил.
Причем тут вообще нравится/не нравится джаваскрипт? Думаю, мало кому охота садиться писать на ноде после рельс. Это неудобно, медленно и не стоит свеч в большинстве случаев. Про компилятор я вообще ничего не понял кроме того, что вы явно сморозили какую-то ахинею.
Если вы имеете ввиду транслятор Coffeescript, то лол, он как раз в 90% случаев генерирует более качественный код, чем программист. Ага, такая вот тупая железяка. Примерно так же, как тупая железяка делает миллионы вещей, которые не под силу человеку. Например, расчитывает траектории ракет, управляет ядерными электростациями, передает и получает в секунду времени столько информации, сколько человеку за год не прочитать или складывает циферки с бешенной скосростью, отрисовывая трехмерную графику, чтобы программист мог после работы погонять с друзьями в квейк.
Собственно, неплохим подтверждением моих слов является тот факт, что современные компиляторы компилируют более высокий язык C в машинные коды намного круче, чем любой, даже самый гуру-программер смог бы написать на ассемблере.
Про рубистов и пару rps — качественный вброс, я его комментировать даже не буду. Слишком толсто.
Ну и про реальность. У вас с ней нелады. Знаю, ничего банальнее в качестве примера привести нельзя, но опять же Basecamp. Живет себе, много лет существует. Бабло приносит. Создатель недавно вон поменял Lamborghini Gallardo на Zondа и разбил уже три порше участвуя в полупрофессиональных гонках.
И они там, о боже ж мой, совсем дурачки, пишут себе на CoffeeScript, который «компилируется» в менее качественный и производительный код, и в ус не дуют. Чтоб я так жил.
Все в принципе правильно, только в некоторых случаях вы преувеличиваете. Например, насчет компилятора С и самого талантливого программиста. Утверждение ошибочное. Вы фанатично кодили на asm, изучали досконально все инструкции современных процессоров, разобрали каждую задачку с crackmes.de? Не стоит так утверждать… А в остальном согласен ;-)
Начнём с того, что Coffeescript — банальный транслятор. Никаких оптимизаций он не делает. Just syntax sugar. Поэтому он будет либо на уровне JS кода, либо медленнее, если вы не в курсе во что ваш кофе транслируется.
Что касается тулзов, то они успех не гарантируют — рельсы это отлично показывают. Много сейчас проектов, где именно Rails сыграли решающую роль? Не припомню.
Что касается тулзов, то они успех не гарантируют — рельсы это отлично показывают. Много сейчас проектов, где именно Rails сыграли решающую роль? Не припомню.
Я не про оптимизации речь вел. Я про то, что код качественнее.
Это банально означает, что благодя некоторым особенностям дизайна языка, налепить багов в кофескрипте сложнее, чем на джаваскрипте. От программиста-дебила это, конечно, не спасет, но некоторые банальные баги, типа проваливающихся в глобал из-за забытого
Это банально означает, что благодя некоторым особенностям дизайна языка, налепить багов в кофескрипте сложнее, чем на джаваскрипте. От программиста-дебила это, конечно, не спасет, но некоторые банальные баги, типа проваливающихся в глобал из-за забытого
var переменных или ошибки логики нестрого сравнения, просто не существуют в кофескрипте.Для подобных багов есть JSLint, всё вышеперечисленное он отлавливает.
Я на самом деле люблю творчество Кенаса, пользуюсь его _ & Backbone. CS уважаю, за инновационность, но в отличие от того же Objective-J или GWT его «практичность» мне неочевидна, так что я лично был очень удивлён, например, аргументации DHH по невключению HAML, но включению CS. А так… я бы скорее Traceur посмотрел, но это я)
Я на самом деле люблю творчество Кенаса, пользуюсь его _ & Backbone. CS уважаю, за инновационность, но в отличие от того же Objective-J или GWT его «практичность» мне неочевидна, так что я лично был очень удивлён, например, аргументации DHH по невключению HAML, но включению CS. А так… я бы скорее Traceur посмотрел, но это я)
Не существует проектов, где что-то играет решающую роль. Никто не мешает на рельсах написать кусок говна, а на пхп конфетку.
Не надо приплетать сюда вопросы религии. Тут никто на самом деле не считает, что использование рельс гарантирует что-то, кроме весьма быстрой и комфортной разработки.
Не надо приплетать сюда вопросы религии. Тут никто на самом деле не считает, что использование рельс гарантирует что-то, кроме весьма быстрой и комфортной разработки.
> тупая железка будет выдававть менее качественный и производительный код, чем программист.
В 1960х — несомненно.
В 1960х — несомненно.
Несмотря на оптимистичное завершение статьи в фоне теперь крутится ожидание неминуемого апокалипсиса :'(
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
История про ExecJS или как выполнять джаваскрипт в руби