LINUX.ORG.RU

Первая стабильная версия Scala.js

 ,


2

5

Представлена новая версия Scala.js, плагина компилятора языка программирования Scala, создающего в результате компиляции Javascript вместо обычного байт-кода JVM. Выпущенная версия 0.6 лишилась флага «экспериментальной версии» и стала первой стабильной сборкой проекта.

Scala.js позволяет программировать для браузера с использованием всех возможностей языка, включая макросы и большую часть стандартной библиотеки. Разработчики могут пользоваться готовой инфраструктурой сборки и тестирования, а также писать код который может исполняться как в браузере, так и на серверной стороне в JVM.

За два года существования проект обзавелся экосистемой, включающей модули для интеграции с различными браузерными фреймворками, средствами тестирования и отладки.

>>> Подробности

★★★★★

А что происходит если вызвать что-то нереализованое? Нормальная ошибка?

vertexua ★★★☆☆ ()

А есть что-то подобное на python. И насколько подобные решения разумны для каких-то мелких вещей (для которых JS и создавался изначально), или это только для новомодных веб-приложений которые состоят целиком из js кода?

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

MrClon ★★★★★ ()

Т.е. теперь на скале можно писать под Ноду?

А если запустить в v8, будет быстрее обычной?

yoghurt ★★★★★ ()
Ответ на: комментарий от MrClon

ну для мелкого норм, если никто кроме тебя это трогать никогда не будет, для крупного наоборот слишком много граблей и проблем миллион всплывет, там только js или в крайнем случае cs/ts, остальное не нужно.

umren ★★★★★ ()
Ответ на: комментарий от MrClon

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

Для мелких не очень подходит, котому как runtime довольно толстый. Пока основная цель проекта — большие single page приложения.

maxcom ★★★★★ ()
Ответ на: комментарий от maxcom

Что-то такое я и предполагал. И я так понимаю никаких подвижек в этом плане не предвидится? Окай, продолжу корячиться с JS.

MrClon ★★★★★ ()
Ответ на: комментарий от MrClon

есть, но страшно

вот brython я иногда использую - скорость меня устраивает :)

buratino ★★★★ ()
Ответ на: комментарий от MrClon

ну и кофескрипт - это такой рубитон, некоторые его руби-фишки я бы и в python не отказался использовать :)

buratino ★★★★ ()

- как оно по памяти?

- атомы, матчинг, term to binary to term есть ?

Обобщая можно предположить существование для остальных популярных язычков. Даже asm.js есть ;)

anonymous ()
Ответ на: комментарий от MrClon

Решения на петон не разумны по определению.

anonymous ()
Ответ на: комментарий от lazy_aleks

Чем именно js не по нраву? Мб подойдут coffee/typescript?

На больших проектах SPA будешь танцевать вокруг 100кб+ js/cs-кода в отлове мелких багов с типизацией, внезапными null'ами, разруливая попутно весь сallback hell и т.д. Сабж как раз решает эти проблемы.

shahid ★★★★★ ()

Я так понимаю, JS недостаточно тормозит? :}

Deleted ()

ох, какая новость-то интересная. а ведь недавно еще JS был недоязычком для реализации браузерных свистелок на стороне клиента.

Komintern ★★★★★ ()

Я упустил что такое *.js. Объясните, что объединяет проекты с таким окончанием?

Ну вот например asm.js использовался в Humble Bundle для того, чтобы запускать бинарники в браузере. По всей видимости, это такой файлик для браузера.

node.js - это уже не файлик. В информации о пакете - огромный список файлов, сишных бинарников. Тогда почему *.js, а не просто node?

ZenitharChampion ★★★★★ ()
Последнее исправление: ZenitharChampion (всего исправлений: 1)
Ответ на: комментарий от ZenitharChampion

Я упустил что такое *.js. Объясните, что объединяет проекты с таким окончанием?

Обычно то, что они связаны тем или иным образом с JavaScript.

Legioner ★★★★★ ()

Да уж. Пугает меня эта тенденция, все и вся переписывать на жабаскрипт. Такими темпами придется реализовывать отдельный процессор, выполняющий жабаскриптовые инструкции.

Meyer ★★★ ()

640 гигабайт оперативной памяти хватит всем!

Solace ★★ ()
Ответ на: комментарий от Meyer

Да уж. Пугает меня эта тенденция, все и вся переписывать на жабаскрипт.

Есть альтернатива?

Такими темпами придется реализовывать отдельный процессор, выполняющий жабаскриптовые инструкции.

asm.js это более прагматичный подход. Не знаю, насколько он «взлетел».

Legioner ★★★★★ ()

Требует ли оно java/scala для генерации итгогового js?

makoven ★★★★★ ()
Ответ на: комментарий от Meyer

Да уж. Пугает меня эта тенденция, все и вся переписывать на жабаскрипт.

Тут же дело в другом. Такие вещи нужны, чтобы имеющийся код запускать «в браузере». Ну или как раз если НЕ хочется писать на js, а «надо».

DarkEld3r ★★★★★ ()
Ответ на: комментарий от Solace

Терабайт, если уж на то пошло. А также 640 процессоров и какое-нибудь охлаждение, ревущее как реактивный истребитель на взлете.

Meyer ★★★ ()
Ответ на: комментарий от Komintern

а ведь недавно еще JS был недоязычком для реализации браузерных свистелок на стороне клиента.

в этом и суть, ведь писать на нём что то объёмное - занятие весьма трудозатратное. Поэтмоу и появляются всякие тайпсктипт, кофе, скалаjs - потому что писать на js удовольствие как я вижу себе не дешёвое ввиду некоторых особенностей языка. А уж поддерживать кем то написаный объёмный код...

AndreyKl ★★★★★ ()
Ответ на: комментарий от Meyer

это наоборот как раз - написали такую штуку чтобы можно было нормальный язык скомпилять в js (просто потому что браузеры больше ничего не умеют).

AndreyKl ★★★★★ ()
Ответ на: комментарий от AndreyKl

писать на нём что то объёмное - занятие весьма трудозатратное

ИМХО, единственное, чего не хватает современному js - это простенького статического анализатора:

  • кинуть ворнинг если переменная была типа number, а стала, например, Object.
  • кинуть ворнинг если объект был сконструирован (через функцию или через {}), и была попытка писать/читать поле, которое в конструкторе не было определено

По-моему, это сократило бы количество ошибок и головных болей процентов на 80. Ни в одном линтере, почему-то не видел такой функциональности

makoven ★★★★★ ()
Последнее исправление: makoven (всего исправлений: 1)
Ответ на: комментарий от makoven

ИМХО, единственное, чего не хватает современному js - это простенького статического анализатора:

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

Как например насчёт нормальной стандартной, а не костыльной самопальной у каждого своей и почти всегда кривоватой системы импорта и сборки? хороший импорт например у явы/скалы, на мой вкус. (о том что в es6 есть, я в курсе)

AndreyKl ★★★★★ ()
Ответ на: комментарий от AndreyKl

костыльной самопальной у каждого своей и почти всегда кривоватой системы импорта и сборки

То, что каждый пентюх пишет свой революционный «requirejs», не означает что ими надо пользоваться.

Есть простой module pattern, которого хватает в большинстве случаев. Пишешь по одному такому модулю на каждый файл, подключаешь их в конец HTML-я тегами script.

Либо совершаешь «сборку» проекта:

cat file1.js > app.js
cat file2.js >> app.js
...

Проблема с модулями и импортами есть, я не отрицаю. Но это не острая проблема, в отличие от слабой типизации

makoven ★★★★★ ()
Последнее исправление: makoven (всего исправлений: 2)
Ответ на: комментарий от AndreyKl

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

Как показывает (мой) опыт с typescript, добавление типов поверх существующих проектов - такая морока, что лучше не трогать его и пятиметровой палкой.

А вот усилить динамическую типизацию было бы очень неплохо

makoven ★★★★★ ()
Последнее исправление: makoven (всего исправлений: 1)
Ответ на: комментарий от makoven

(немного в сторону)

я честно говоря приглядываюсь к тайпскрипту, всё собираюсь щупать, поэтому мне интересно мнение щупавших. но твою мысль не вполне понял:

- ты имеешь ввиду что новый проект можно начинать писать на тайпскрипт, а старый лучше не трогать?

- или же вообще тайпскрипт лучше не трограть? (согласно твоему опыту, ясное дело)

AndreyKl ★★★★★ ()
Ответ на: комментарий от AndreyKl

Как правило, есть js-модуль от одного автора. И есть d.ts дефиниции для этого модуля от других авторов. И не всегда код и d.ts совпадают. Мне часто приходилось подправлять что-то руками в d.ts файле чтобы скомпилялось без ошибок.

Если писать что-то свое, то, ИМХО, лучше писать сразу на js и отдельно писать d.ts-файл. Но тогда мы лишаемся ts-сахарка (class, arrow). С генерацией d.ts из ts-файла тоже есть подводные камни (сейчас не вспомню какие).

Ну и последнее (из-за чего я забросил ts) - это как организована компиляция дерева исходников и как реализован инклюд d.ts-файлов. Они организованы не очень удобно и не совсем очевидно. Это словами сложно описать - надо потрахаться самому, чтобы понять )

А, да - еще вечные template- классы и функции. Для того, чтобы подогнать динамическую природу js к статике

makoven ★★★★★ ()
Последнее исправление: makoven (всего исправлений: 3)
Ответ на: комментарий от makoven

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

AndreyKl ★★★★★ ()
Последнее исправление: AndreyKl (всего исправлений: 1)
Ответ на: комментарий от AndreyKl

А я склоняюсь к ковырянию 6to5. Трансляторы рождаются и умирают, а ECMA - вне времени и пространства )

makoven ★★★★★ ()
Ответ на: комментарий от makoven

большого опыта с 6to5 у меня нет, но ковырять - ковырял. Сахар конечно делает своё дело. импорты, человеческие форы, стрингтемплейты... эти раздражающие «тут будет цифра » + v + ", а тут буква.." наконец то уходят в прошлое. впечатления приятные. Но вместе с тем это всё тот же ecma, а на мой вкус в нём минусов больше чем плюсов, хоть наверное насчёт времени и пространства ты и прав ).

AndreyKl ★★★★★ ()

а есть бенчмарки? мне так, чисто поржать)

MyTrooName ★★★★★ ()
Ответ на: комментарий от MyTrooName

Пишут, что в отдельных случаях на 30% быстрее JavaScript. В самых худших случаях не более чем в 2 раза медленней.

Legioner ★★★★★ ()
Ответ на: комментарий от Legioner

на 30% быстрее JavaScript

(javapetrosyan mode) И на 10% быстрее Си, если хорошенько прогреть виртуальную машину

makoven ★★★★★ ()
Последнее исправление: makoven (всего исправлений: 1)
Ответ на: комментарий от makoven

Так в том и проблема, решения со статической типизацией плодятся, потому что они не требуют оверхеда для своей реализации. А усиление статической типизации требует либо переделки интерпретатора, либо жутких костылей (вот посмотрим, что будет генерить таки на выходе AtScript).

Хотя может, я не вижу способа, как просто усилить типизацию без оверхеда в текущем положении.

anonymous ()
Ответ на: комментарий от anonymous

Пардон опечатка, усиление не статической, а динамической типизации.

anonymous ()
Ответ на: комментарий от anonymous

А усиление динамической типизации требует либо переделки интерпретатора, либо жутких костылей (вот посмотрим, что будет генерить таки на выходе AtScript)

Интерпретатор переделывать никто, ясное дело, не будет. AtScript это, как я понял, тот же ts только с аннотациями (вроде как даже d.ts файлы из ts будет поддерживать).

Я несколько о другом. Не добавлять в js новый синтаксис вообще, а просто интерпретировать исходник какой-нибуть тулзой, которая проверит, чтобы типы переменных не менялись и чтобы новых свойств в объекты не добавлялось. Конечно, для этого придется проверять весь код, все подключенные библиотеки. Но игра стоит свеч )

makoven ★★★★★ ()
Последнее исправление: makoven (всего исправлений: 1)
Ответ на: комментарий от menangen

Не знаю, не пробовал. Походу у всех типизированных трансляторов должны быть аналогичные проблемы когда дело касается стороннего кода. Ведь нужно как-то узнавать какие типы принимает/возвращает библиотека. Ну либо рассматривать весь сторонний код как тип «any»

makoven ★★★★★ ()
Ответ на: комментарий от maxcom

Не спортивно. Размер рантайма не понятен.

Vit ★★★★★ ()
Ответ на: комментарий от Vit

100 кб несжатого js кода на hello-world. Один человек писал, что в сложном большом корпоративном приложении у него получился мегабайт (несжатого кода). По-моему вполне нормально.

Legioner ★★★★★ ()
Ответ на: комментарий от Legioner

Нежатое никого не интересует. Надо минифицированное и гзипованное.

Vit ★★★★★ ()
Ответ на: комментарий от Vit

Ну вряд ли оно генерит неминифицированный код, так что можешь считать, что он минифицированный. Сжатый – можешь разделить на 3.

Legioner ★★★★★ ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.