Drive your career as React Developer with Symphony Solutions!
×Закрыть

Альтернативы CoffeeScript-у: современное положение дел. Что-то из них «взлетело»?

Значит так: многие (может все) говорят о CoffeeScript как об основном языке, который компилирует в JS. По крайней мере, я так понимаю, что большинство фронтэндеров его (кофескрипт) именно как лидера и рассматривают. С этим конечно не поспоришь — он видимо действительно наиболее часто используемый компилируемый в js язык — я даже где-то читал/слышал, что он стал чуть ли не стандартом де-факто в мире фронтэнда.

Но вот мне стало интересно. А есть ли ему реальные конкуренты? ну типа TypeScript или ClojureScript? Или они из серии «широкоизвестное в узких кругах» (типа TypeScript юзат сугубо дотнетчики, а ClojureScript — кложуристы)? «Взлетели» ли они или нет (может еще нет и у них все впереди)?

И как обстоят дела с Dart, Elm и разных менееизвестных PureScript ( www.purescript.org ), PogoScript ( pogoscript.org ) и проч., и проч, и проч. (в репозитории npm, например, вроде воз и маленькая тележка разных компиляторов в js, большая часть из которых видимо не более чем сырое поделие)?

Что же из этого, кроме CoffeeScript’а, взлетело или имеет шансы взлететь? Или же в ближайшем будущем реальных конкурентов кофескрипта не предвидется?

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

LinkedIn
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Пишу на CoffeScript с помощью сайта jstocoffee, хоть и рубист. Как-то вообще не воспринимаю код на CS.

ES6 + Babel — лучшая альтернатива.
^^^^ this

Кофескрипт плохой язык.
Например, авторы почему-то решили, что с таким поведение все нормально
x = 0
text = (y) -> x = 10; x + y
console.log x # 0
test(0)
console.log x # 10

Нормально, если я явно этого хочу. В javascript нужно опустить кл. слово `var`, в python это nonlocal. А в coffescript тупо нет выбора, нет shadowing, все функции это замыкания, которые могут повлиять на внешний скоуп.

К сожалению судя по гугл трендам TS уверенно делает CS, но в итоге, я думаю, авторитетом и стандартом в мире фронт-енда будет ES 2015+.
У CS есть серьезные недостатки, типа неявного скоупинга, для решения которых скорее всего придется менять и усложнять синтаксис, за простоту которого его все любят.
А TS, на мой взгляд, заставляет web программиста заниматься каким-то низкоуровневым хардкором из леденящего кровь мира с++; вот взять, например, definition files, я, конечно, понимаю зачем они нужны, но заниматься их написанием для какой нибудь мелкой либы, которая нужна всего в паре мест, совсем не хочется.

Рішення вивчити CoffeeScript прийшло після перегляду кількох прикладів коду. Розробник кофі на своєму сайті пишуть, що код стає в 2 рази менше і набагато читаєміший і це правда. Переконався на власному досвіді. Не віриш?Порівняй сам
file.coffee
file.js
+ Демка

Особисто про себе скажу, що писати код стає дійсно приємніше і відчуваєш кайф від дійсно вирішення актуальних проблем, не займаючись рутиною нативного js

Але фронт енд розивається і рухається вперед, з виходом es6,
якщо Jeremy(розробник CoffeeScript) не переробить компілятор CS, він стане застарілим
Причин для цього більш ніж багато. Головна з них це те що ES6 реалізовує більшість фішок із CS і реалізовує він їх за допомогую іншого синтаксису. Наприклад
ES6 class Foo{ constructor(){ .. } classMethod(){} } CS class Foo constructor:()-> .. classMethod ()->
І якщо відсутність фігруних дужок — особливість синтаксису у кофі, і це норм, то присутність «двокрапки» у класі CS не відповідає синтаксису ES6.

Тому зараз рекомендую рухатися у сторону es6+babel.

Всё круто, классно, вау-эффект есть. Но вот скажите на кой там классы? Ладно уже налепили класс Vec2 (хоть без него там тоже можно спокойно обойтись), но класс World там зачем???
И зачем кофискрипт все ваши классы дополнительно в IIF заворачивает, неужели без них никак нельзя?

якщо зірки запалюють — це комусь потрібно ©

И зачем кофискрипт все ваши классы дополнительно в IIF заворачивает, неужели без них никак нельзя?
та не можна) це нормальна реалізація класів на ES5, babel так само компілить

це не продакшин, а просто тест
P.S. без багато чого можна обійтися, але це забезпечує необхідну абстракцію і повторне використання коду.+ООП style)

це нормальна реалізація класів на ES5, babel так само компілить
Я с этим и не спорю, я говорю, что классы здесь не нужны, как минимум в случае с World, как максимум везде в данном примере.
це не продакшин, а просто тест
Конкретно этот пример да, но он четко демонтсрирует то, что будет на продакшене. И не дай бог, чтоб такое кто-то еще умудрился в цикл какой-нибудь засунуть, иначе никакой garbage collector с этим “потоком ....” не справится.

Для

забезпечує необхідну абстракцію і повторне використання коду.+ООП style)
достаточно создать объект и при острой необходимости ООП сделать Object.create. Никаких классов, лишних замыканий и IIFE не надо. В конце концов “ОО” расшифровывается как “Объектно ориентированное ...” и в джаваскрипте есть уникальная возможность работать сразу с объектами. ООП можно влепить везде. Даже в этом примере можно было создать по всем канонам джавы пару абстрактных классов и фабрику “Миров”, но зачем?

класи потрібні
ООП — об’єктний стиль, а об’єкти мають властивості і можливість наслідування. Так у реальному світі. За допомогою тільки Object.create ти не ралізуєш цього. Тому потрібен клас.

ООП — об’єктний стиль, а об’єкти мають властивості і можливість наслідування.

Є різні визначення ООП. Не всі з них включають наслідування.
c2.com/...ObjectOrientedProgramming
c2.com/...efinitionOfObjectOriented

4. Every object is an instance of a class (which must be an object).
И не дай бог, чтоб такое кто-то еще умудрился в цикл какой-нибудь засунуть, иначе никакой garbage collector с этим «потоком ....» не справится.
що саме засунути в цикл?
не бачу ніяких прооблем у продуктивності з такою реалізацією

ES6 + Babel — лучшая альтернатива.

Танцевать надо от того, какую конкретно проблему решает тот или иной скрипт. И проблемы в основном 3:
1) скорость и удобство написания кода (не все учились сразу писать на JS),
2) читабельность получаемого кода (тут с ES6 трудно соперничать),
3) дополнительный функционал (и вот тут уже каждый ищет то, чего ему не хватает. Например, TypeScript может назначать переменным типы, как в более строгих языках. Не всегда это надо, но если надо, то ES6 этого делать не может, да и похоже не будет.)
Потому какая разница что куда взлетело или нет. Если у вас есть задача, для которой оптимально использовать не чистый JS, то выбирайте, что подходит, и используйте.

CoffeeScript писали люди, які не любили синтаксис жаваскрипта і мислили лише як рубі девелопери. Писав плагін для atom.io на кофескрипті — взагалі не зрозумів, навіщо він там треба. Краще ES2015 підключити через Babel і вперед, не оглядайся на всякі висери бекенд-програмістів.

Лучше JavaScript’а может быть что угодно только другой JavaScript :)
Лучший язык, который компилируется в JavaScript 5 — это JavaScript 6.

Т.к. большинство браузеров еще не поддерживают ECMAScript 6, то можно использовать компилятор, который будет преобразовывать JS6 в JS5. Например Babel

P.S.
Список языков, которые компилируются в JavaScript

P.S.
Список языков, которые компилируются в JavaScript
хренасе) я конечно подозревал, что их много, но не думал, что настолько много))))

ну вообще-то есть только одна достойная/популярная/имеющая смысл альтернатива из компилируемых и это TypeScript, и ни как не coffescript. Последний популяный вроде среди хипстеров.

пгастите, а кофе-скрипт таки взлетел? Оо

я думал, что взлетел. а нет так нет)

типа TypeScript юзат сугубо дотнетчики
А CoffeeScript хіба не рубісти юзають? Якшо шо, то я не в курсі.

та я сам не в курсе, если чесно) просто мне казалось, что кофескрипт юзает основная часть тех, кто для написания JS-кода юзает компилируемые языки

Я вів до того, що CoffeeScript був написаний людими, яких надихав синтаксис Ruby. Відповідно, він ніфіга не розповсюджений — просто людям, які пишуть backend, стало зручніше писати код на frontend в проектах на RoR.

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

Значит так: многие (может все) говорят о CoffeeScript как об основном языке
Wat?
что большинство фронтэндеров его (кофескрипт) именно как лидера и рассматривают.
Rly?

Честно говоря, я не имею ни малейшего понятия, откуда вы это взяли. Можно обратится ко всяким сайтам и убедится в обратном: тыц или заглянуть в статистику модуля кофискрипта, скажем для www.drupal.org/...roject/usage/coffeescript.

Имхо, кофискрипт, абсолютно ненужный рудимент. Который немного экономит время на печатание кода, но в последствии на порядок уменьшает читаемость кода. Еще у кофискрипта есть отвратительная фича «компилить говнокод», которая вылазит в самый неподходящий момент и потом приходится отлаживать обычный JS, чтобы он работал нормально. Так же он может плодить кучу ненужных замыканий (точнее плодят их разработчики, в целях экономии печатания пары лишних символов). Но ничего, пусть продукт жрет больше памяти, работает медленнее, главное, что разработчик написал на 20 символов меньше и может спокойно идти пить кофе.

Да, CoffeeScript подойдет для своих маленьких проектиков, для каких-то небольших плагинов к jQuery. Но использовать его на крупных проектах крайне неразумно, т.к. для начала вы сразу отсекаете часть потенциальных разработчиков, которые знают JS, причем знают его хорошо. Плюс к этому новички будут втягиваться в проект в разы дольше. Больше времени будет нужно для того, чтобы разобраться в функционале, написанном год назад, к примеру. Да и с каждой строчкой кода у вас будет расти время компиляции и вероятность ошибок.

реальных конкурентов кофескрипта не предвидется?
С этим полностью согласен. Конкурентов у него нет, т.к. с приходом ES6 надеюсь он загнется и больше нигде не будет всплывать.
Честно говоря, я не имею ни малейшего понятия, откуда вы это взяли.
ну я имел ввиду его популярность не относительно джаваскрипта, а относительно других (копилируемых в JS) языков.
Еще у кофискрипта есть отвратительная фича «компилить говнкод», которая вылазит в самый неподходящий момент и потом приходится отлаживать обычный JS, чтобы он работал нормально.....
ну меня в данный момент такие подробности мало интересуют, а интересует соотношение сил CoffeeScript vs. другие_компиляторы_в_JS
Конкурентов у него нет, т.к. с приходом ES6 надеюсь он загнется и больше нигде не будет всплывать.
что ж, посмотрим как там будет) Может кофескрипт и прочие ...script-ы действительно временное явление...
что ж, посмотрим как там будет) Может кофескрипт и прочие ...script-ы действительно временное явление...
Надеюсь, что так и будет. Всякие там *script создавались именно для того, чтобы добавить синтаксический сахар, которого не было в нативном яваскрипте. ES6 решает эти проблемы (ну почти)

Сам я до недавнего времени использовал CoffeeScript, потом вернулся на обычный яваскрипт (по той причине, что в команде только я один владею кофескриптом). Теперь посматриваю в сторону ES6

синтаксический сахар, которого не было в нативном яваскрипте
Кто не в курсе, гугл даст ответ по запросу «es6 vs coffeescript»

А, а то я грешным делом подумал, что там пофиксили типизацию или сделали нормальную поддержку асинхронных операций

нормальную поддержку асинхронных операций
она нормально работает, но в ЕС7 будет сахар еще сверху
пофиксили типизацию
там нет проблем с типизацией, есть разработчики которые не умеют работать с динамической типизацией
там нет проблем с типизацией, есть разработчики которые не умеют работать с динамической типизацией
важное отличие — со слабой типизацией
в питоне, например, типизация динамическая, но строгая, что исключает необходимость заучивать идиотскую «таблицу приведения типов» — она просто не нужна

Ну коль не хотите учить, приводите везде типы явно.
Или, если угодно, пользуйтесm TypeScript-oм, он будет вам ошибки на стадии компиляции выводить.

Вы знаете, я пишу очень много на джс, из таблицы привидения типов знаю как число в строку за счет этого преобразовать, и еще преобразование к булевому типу (последнее работает почти как и в других языках) больше знать не надо, проблем связаных с привидением типов не испытывал года 4 гдето

гуд
хорошо знать о практической стороне из первых уст

Нууу... Динамическая типизация — это конечно хорошо, но иногда хочется и строгой типизации. Вроде как правильнее...
Шучу, конечно :) Обажаю динамическую типизацию :)

Всё вышеперечисленное и в ES5 работает отлично.

Ви використали це слово на j?! jQuery це минуле століття і нормалні люди його не використвоують. Забудьте про нього!

Любопытно, и чем же, по-вашему, заменили jQuery в плане манипуляции DOM?

Ну, в этом смысле — да. А чем заменить jQuery UI, jQuery validate?
Да и, в целом, не очень себе представляю, как шаблонизатор поможет в случаях desktop-like интерфейса с схлопывающимися панельками, всплывающими формочками и т.п.

добавляется CSS класс с анимацией — и вуаля! все красиво разворачивается

И кто же и каким образом этот класс добавляет в DOM? ;)
Если что, далеко не везде используется (и целесообразно использовать) React или подобные ему библиотеки, умеющие вычислять умный «DOM diff»

И кто же и каким образом этот класс добавляет в DOM? ;)
при помощи шаблонизатора:
{#isShowModal}
<dialog class="to-this-class-applied-cool-animation"></dialog>
{/isShowModal}
далеко не везде используется (и целесообразно использовать) React или подобные ему библиотеки
1. React — появился недавно, до него было уйму шаблонизаторов
2. Мы сейчас говорим о том что можно не использовать jQuery для манипуляций с DOM, а не о целесообразности. т.к. никакие реальные задачи тут не решаем
React — появился недавно, до него было уйму шаблонизаторов

Которые умели высчитывать точечную разницу, а не заменять целые куски DOM-дерева, вызывая ненужные reflow / repaint ?

Мы сейчас говорим о том что можно не использовать jQuery для манипуляций с DOM, а не о целесообразности

Позвольте не согласиться. Исходный тезис был такой:

jQuery це минуле століття і нормалні люди його не використвоують

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

Шаблонизаторы “старой школы” здесь явно не в кассу, так как исходную разметку вообще эффективнее строить на сервере, а для точечных изменений в DOM шаблонизаторы “старой школы”, в отличие от jQuery, неэффективны.

React, наверное, когда-нибудь заменит jQuery. Но, не раньше, чем на него портируют всё богатство jQuery UI, плагинов и библиотек валидации.

Которые умели высчитывать точечную разницу, а не заменять целые куски DOM-дерева, вызывая ненужные reflow / repaint ?
то как некоторые используют jQuery, зачастую приводит к более ресурсоёмким вычислением, чем шаблонизаторы «старой школы», как вы выражаетесь.
Позвольте не согласиться. Исходный тезис был такой:
лично я отвечал на ваше:
чем же, по-вашему, заменили jQuery в плане манипуляции DOM
я не говорил что jQuery умер, или не нужен. я говорил о том что для ДОМ манипуляций он вовсе не обязателен, можно и без него обойтись.

насчет старых шаблонизаторов — вы их сильно недооцениваете, раз angular прижился, где шаблонизация более увесиста и менее контролируема зачастую нежели в них.
и

jQuery UI
уже заменили — bootstrap &... Material!!! последний уже доступен для angular, react, polymer, ember. там столько няшный приблуд которые по дефолту мобайл-френдли.
а все остальные jQuery плагины не очень, и обычно есть не завязанные на него адекватные реализации
уже заменили — bootstrap &... Material!!! последний уже доступен для angular, react, polymer, ember. там столько няшный приблуд которые по дефолту мобайл-френдли.
а все остальные jQuery плагины не очень, и обычно есть не завязанные на него адекватные реализации
Слова типового JavaScript фанбоя.

виновен — я люблю свою работу, и пришел в АйТи не ради денег — каюсь, грешен

Свого часу заюзав sortable з jQuery UI; в Бутрстрепі такого не знайшов.. О_о.
Якщо мова про бутрстреп зайшла, то ще про семантік нагадаю)

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

5 минут гугла rubaxa.github.io/Sortable но скорее всего вы захотите что-то заточенное под ваш фреймворк

ну так в гуглі багато чого є, пост був до порівняння jQuery і Бутстреп.

Dojo toolkit. А якщо серйозно, то... просто JavaScript. Ми ж тут всі JavaScript програмісти а не jQuery?

Подписаться на комментарии