Прикладной JavaScript

[recoder]

Сижу, изучаю очередной JavaScript-фреймворк. На этот раз YUI3. Раньше приходилось покопаться в Dojo, была задача за пару месяцев изучить ExtJS (aka Sencha) и пописать на нём. И всё это время одолевает меня один вопрос-непонимание...

И нет, этот вопрос отнюдь не "Ну почему же универсальным языком интернетов оказался этот ужасный монстр?" У нас, программистов, ответ "так исторически сложилось" подходит почти к любому вопросу. Ладно... Я другого не понимаю.

Каждый серьёзный фреймворк начинается с того, что вводится своя система классов, свойств, модулей и пр. Почему? Потому что на голом JS писать большие системы так же удобно как на ассемблере и вообще "см. рис.1." Потом поверх этой системы наворачиваются всякие паттерны, на которых строятся MVC, виджеты и всё остальное. Причём шаг влево, шаг вправо от этих паттернов - и всё начинает становиться раком в самый неподходящий момент (поскольку язык динамический и никаких compile time checks нет и вообще "см. рис.1.").

И вот я не понимаю - почему ни один фреймворк не вводит свой скриптовый язык, компилирующийся в JavaScript. Чтобы в этом языке были зафиксированы все специфические концепции конкретного фреймворка. И тогда программист не будет заморачиваться на поиск незамеченных искажений паттернов, а будет заниматься собственно решением своей насущной задачи.

Делов-то: взять, скажем CoffeeScript, форкнуть его и допилить немножко. Радикально было бы адаптировать какой-нибудь Haxe или Elm. Но практически хватило бы даже минимальной кодогенерации в JavaScript. А никто не делает!

Впрочем - выяснилось, что я немножко вру. Таки-есть один скриптовый язык, заточеный под Ember.js (Иуда рулит!) - EmberScript. Тем более непонятно, почему другие серьёзные игроки в эту сторону не смотрят. Занимался бы я UI так, как занимался десять лет назад - точно бы учудил такую надстройку к ExtJS. А сейчас - нет, лучше пойду свою REST-систему на C++ допиливать...

Comments

[katren.livejournal.com]

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

[avnik.livejournal.com]

Я пока аккуратно поглядываю на clojurescript и elm (и еше было что-то elm-подобное)

[sergey babinsky (from livejournal.com)]

А в сторону GWT не смотрел? В этом плане он решает задачу на 5+. А если ещё и руки прямые - так ещё и хороший результат получается.

Мы его выбрали.

[sprocket1.livejournal.com]

Андрей, я думаю, у этой ситуации есть очень простое объяснение. Фреймворки же начинаются не как фреймворки, а как пара удобных загогулин в рамках базового языка. Эти загогулины могут как стать потом фреймворком, так и не стать. Причём подозреваю, большинство из них именно не становится. Если же ты затеешь писать транслятор, то помимо новшеств тебе придётся ещё написать кучу стандартной бухгалтерии, которая как минимум будет отражаться на библиотеки в базовом языке, а как максимум – написаны с нуля.

Что касается момента продуктизации (или любого другого момента, когда фреймворк становится зрелым), то очевидно на каждом таком этапе альтернативой созданию транслятора является внесение полезного функционала во фреймворк. Думаю, выбор любой коммерческой компании в данной ситуации понятен.