Прикладной JavaScript
Sep. 19th, 2014 11:09 pmСижу, изучаю очередной 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++ допиливать...