Как стать автором
Обновить

Комментарии 14

В чем преимущества перед Express/Koa/Restify/Fastify + handlebars/mustache/nunjucks?

PS Несколько лет использовал ExtJS на проекте. Пока не отходишь от дефолтного пути, все более менее нормально. Тормознуто, но работает. Но если надо что-то, что выходит за рамки, начинается боль и страдания. Потому у меня немного предвзятое отношение к ExtJS. Поэтому хотелось бы услышать ответы. Спасибо.
Не хотелось бы заводить здесь холивар. Тем не менее, любая технология имеет свои плюсы и минусы. Насчет тормознутости я бы не был так категоричен. Работаю с 6й версией довольно давно. При сборке в cmd, не самый простой проект в продакшне со всеми стилями, картинками весит 968Кб (из них js ~600кб) и работает никак не медленнее аналога на Vue. Для меня основной плюс Ext JS как раз то, за что ее многие ругают — тут не предполагается работа непосредственно с html (хотя, такая возможность существует). При этом, для всякого рода интранет-лайк систем (для чего extjs и предназначен) возможностей кастомизации хватает с головой.
Зато таких гридов, как в ExtJS, я еще нигде не видел.
Ну и дефолтная стилизация довольно симпатичная — можно брать и пилить приложение не написав ни строчки CSS.

В webix очень неплохие на мой вкус.

О-о-о да… Помню, приходилось под эти гриды рожать скрипты, дабы можно было полноценно редактировать таблицы на сервере. И вроде бы ничего сложного, но даже для простых таблиц это выливалось в несколько килобайт джаваскриптового кода. А таблиц было много, а еще они были взаимосвязанные…
В общем, в итоге обошлись вообще без вебморды. :)
В чем преимущества перед Express/Koa/Restify/Fastify + handlebars/mustache/nunjucks?

Утром было маловато времени для развернутого ответа. Думаю, вы не совсем поняли о чем пост. Возможно, я сумбурно написал. Там не идет речь о генерации html-страниц с использованием какого-то шаблонизатора. Просто отмечается, что такая возможность есть. Основная затея была сделать нечто, что позволяет упростить создание и поддержку RIA приложений. Проще показать на примере.
Предположим, по нажатию на красной кнопке вам нужно у всех он-лайн пользователей вашего приложения показать сообщение «Пользователь Вася нажал красную кнопку». В этом случае при стандартном подходе по событию нажатия на кнопку вы отправите сообщение на сервер, на сервере нужно добавить роут с обработчиком, далее, необходимо остальных пользователей известить что кнопка нажата. Все это куча кода в клиентской и серверной частях. Я предлагаю более простой способ (код рабочий если его подставить в пример из статьи):
Контроллер на клиенте:
Ext.define('Module.messages.view.FormController', {
   .....
    ,init(view) {
     ....
         this.model = Ext.create('Module.messages.model.Model',{
             listeners: {
                 onredbutton: (user) => {
                       // событие redbutton будет вызвано сервером у всех клиентов
                       alert(`Пользователь ${user} нажал кнопку`)
                 }
             }  
         });
        this.control({
            ...
            '[action=redbutton]'    : {click: () => {
                  // вызовем метод на сервере, передадим ему имя юзера
                  this.model.$onredbutton(Ext.WS.user) 
            }}            
        })         

Модель:
Ext.define('Module.messages.model.Model', {
    extend: 'Core.data.DataModel'
    /* scope:server */
    ,async $onredbutton(user) {
        this.fireEvent('onredbutton', 'all', user);              
    }
})

Интересный эксперимент, но я бы вежливо посомневался на предмет практической пользы от Ext JS на сервере как вообще, так и в данной конкретной реализации:


  • Классовая система имеет смысл в браузерах, которые ничего кроме ванильного ES5 не знают; Node умеет в ES8, которое хоть и не так наворочено, но вполне работоспособно.
  • Загрузчик и отслеживание зависимостей заточено на Cmd и вне своих рамок выпьет крови по полной программе. То, что вы грузите ext-all-debug.js уже как бы намекает; при этом загружается весь фреймворк, а используется может быть 1% от его возможностей. Понятно, что 30-40 мб памяти для сервера ни о чём, но сам факт.
  • Система конфигов гибка и приятна, но платить за неё придётся производительностью, и платить дорого. А отказываться от неё больно.
  • Система событий абсолютно полностью заточена под браузеры. Я не до конца понимаю, как вам вообще удалось завести всю эту дребедень под Нодой, но есть все шансы, что выстрел в ногу из ядерной пушки на каком-то этапе случится. А если нет, то и толку от неё мало: событийная система в Ext синхронна по определению, что для браузера ещё как-то в общем ничего, но для Ноды смерти подобно.
  • Абсолютно не очевидный при разработке нюанс, который впоследствии практически гарантированно поставит колом систему в боевой среде: Ext JS полностью завязан на глобальные объекты. Ваша память ещё не течёт, как дырявое решето? Будет. Опять же для браузеров терпимо, а вот для сервера каюк.

И т.д., и т.п. Реализация серверной логики на Ext.app.Controller улыбнула, сделали приятно старому шарлатану. :) А что касается приёма и отправки сообщений, то всё уже украдено до нас. Ext Direct вам в помощь.


В общем, не нужно оно на сервере, совсем. Это я вам как доктор говорю.

Все написанное Вами правильно, но не совсем. Если понимать, что ExtJS все-таки больше приедназначен для интранета и всяких там админок, то:
Классовая система имеет смысл в браузерах, которые ничего кроме ванильного ES5 не знают; Node умеет в ES8, которое хоть и не так наворочено, но вполне работоспособно.

Современные версии броузеров прекрасно умеют ES8 (всякое старье поддерживать в подобных системах нет нужды)

Загрузчик и отслеживание зависимостей заточено на Cmd и вне своих рамок выпьет крови по полной программе. То, что вы грузите ext-all-debug.js уже как бы намекает; при этом загружается весь фреймворк, а используется может быть 1% от его возможностей. Понятно, что 30-40 мб памяти для сервера ни о чём, но сам факт.

Сборка сервера через Cmd занятие бессмысленное, классы подгружаются и остаются в памяти по мере необходимости стандартным нодовским require (там разный набор файлов библиотеки для клиента и сервера). А клиент, да, собирается через cmd и превращается в 1мб. То, что в примере ext-all-debug.js для упрощения этого самого примера. Вообще, вопрос сборки такого проекта интересен сам по себе, рамок одной статьи маловато для этого. Могу описать, если хотите)

Система конфигов гибка и приятна, но платить за неё придётся производительностью, и платить дорого. А отказываться от неё больно.

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

Система событий абсолютно полностью заточена под браузеры. Я не до конца понимаю, как вам вообще удалось завести всю эту дребедень под Нодой, но есть все шансы, что выстрел в ногу из ядерной пушки на каком-то этапе случится. А если нет, то и толку от неё мало: событийная система в Ext синхронна по определению, что для браузера ещё как-то в общем ничего, но для Ноды смерти подобно.

Хм, никакой синхронности от сервера не требуется: сервер просто кидает в сокет нужного клиента сообщение «парень, тебе тут событие» и забывает про него. Остальное дело клиента… Механизм совершенно другой на серверной стороне, синтаксис только похожий, что бы было единообразие в коде.

Абсолютно не очевидный при разработке нюанс, который впоследствии практически гарантированно поставит колом систему в боевой среде: Ext JS полностью завязан на глобальные объекты. Ваша память ещё не течёт, как дырявое решето? Будет. Опять же для браузеров терпимо, а вот для сервера каюк.

Глобальные объекты вы имеете ввиду DOM? На сервере их нет в принципе, соответственно, они не используются. Вы видите ExtJS как сборник UI-компонент, но по факту там 2 части — Core (движок классов) и UI (компоненты и все с ними связанное). Мы делали на этой штуке систему лояльности, при нагрузке в районе 150 запросов/сек в течении суток я не заметил каких-то утечек на сервере…

А что касается приёма и отправки сообщений, то всё уже украдено до нас. Ext Direct вам в помощь.

Вопрос не стоит в отправке сообщений. Очень хочется иметь под рукой всю картину движения данных от формы в UI до базы данных на сервере, а не прыгать между бакэндом и фронтом, которые, к тому же, при одинаковом языке программирования (в случае с нодой на сервере) построены на совершенно разных паттернах. Целью этого эксперимента было привести все к одному знаменателю. Что бы у меня в каталоге users в папке view лежали формы и таблицы для списка пользователей, а в model все что касается данных…

Вот как-то так)

Если понимать, что ExtJS все-таки больше приедназначен для интранета и всяких там админок

Ну вот если вы это понимаете, то также должны понимать, что для интранета и всяких там админок очень часто используется всякое старьё (конкретно, IE11). В котором не то, что ES8, а даже и ES6 едва присутствует.


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

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


А клиент, да, собирается через cmd и превращается в 1мб.

Вот тут будут возникать отдельные вопросы, и даже целая пачка. Емнип, Cmd совершенно не в курсе ваших тегов scope:server и если исходники используются там и сям, то перед сборкой клиентской части нужно выкусывать серверную. А это дополнительный инструментарий, шаг сборки, да и просто геморрой.


Вообще, вопрос сборки такого проекта интересен сам по себе, рамок одной статьи маловато для этого. Могу описать, если хотите)

Спасибо, с процессом сборки Cmd я, можно сказать, интимно знаком. :) Не настолько этот процесс интересен, как вам кажется, а вот сложен намного более, чем вам представляется.


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

Я в своё время потратил много, много дней на профилирование Ext JS и выводы были очень интересные. В большей части приложений порядка 20-30% времени до первой отрисовки съедало именно создание объектов и в частности, создание конфигов для них. Вы в курсе, как эта штука внутри устроена? Посмотрите, механизм весьма интересный и гибкий, но и тормозной при этом — очень много накладных расходов на создание объекта с заданным прототипом.


Хм, никакой синхронности от сервера не требуется: сервер просто кидает в сокет нужного клиента сообщение «парень, тебе тут событие» и забывает про него.

От сервера требуется асинхронность, иначе масштабирование системы будет под очень большим вопросом. Поскольку всё происходит в одном event loop, каждый кусок кода должен быть очень быстрым и возвращать управление планировщику как можно быстрее. А в Ext на каждое событие можно повесить обработчик, который может тоже стрелять события, на которые могут быть повешены обработчики, и так далее ad nauseam. Всё это происходит синхронно, и пока весь код не отработает, управление к планировщику не вернётся и никакие другие куски кода работать не будут.


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


В вашем случае всё это не очевидно, потому что серверная сторона маленькая и простенькая, и на грабли вы ещё не наступали. Может и не наступите. Но подход не масштабируется в принципе.


Глобальные объекты вы имеете ввиду DOM?

Нет, при чём тут DOM. В браузере верхний объект это window, в Node это global, но суть не меняется: Ext JS создаёт иерархию классов в виде вложенных объектов со ссылкой на верхний объект. Когда вы пишете что-нибудь в стиле:


var foo = new Ext.bar.Foo();

То вот этот Ext, технически, это переменная в глобальном контексте, а по факту свойство window.Ext (или global.Ext). Всё, что находится в самом объекте Ext, живёт в памяти всегда.


Большая часть этих вложенных объектов — это классы Ext. Некоторые объекты это singletons, а ещё некоторые просто объекты JavaScript, безо всякой специальной магии. Проблема в том, что и singletons, и некоторые классы, и даже просто объекты, делают очень много всяких разных штук, очень не полезных для расхода памяти. Держат ссылки на экземпляры своего типа (StoreManager держит ссылки на все Store, ComponentManager на все компоненты, etc), размещают всякие кеши на прототипе, и протчая, и протчая. И всё это растёт и пенится, от чего Garbage Collector рано или поздно становится плохо. Для браузера это опять же не очень критично — стал тормозить, F5 и понеслось. А вот на сервере будет больно.


Вы видите ExtJS как сборник UI-компонент, но по факту там 2 части — Core (движок классов) и UI (компоненты и все с ними связанное).

Я вижу Ext JS как кусок говна софта, на который я потратил 6 лет жизни. ;) Частей там существенно больше двух.


Мы делали на этой штуке систему лояльности, при нагрузке в районе 150 запросов/сек в течении суток я не заметил каких-то утечек на сервере…

6.2 у вас? Это приятно слышать, потому что я потратил несколько месяцев на отлов всех утечек, до которых мог дотянуться. Похоже, что выпилил все крупные, раз вы проблем до сих пор не заметили. :)


Но вот до конца проблему решить не удалось и не удастся. Я могу много рассказать о том, как оно течёт, куда, и почему, но если вкратце: текло, течёт, и течь будет. Основная больная проблема это глобальные ссылки, и от них никуда не денешься. Архитектура такая.


Что бы у меня в каталоге users в папке view лежали формы и таблицы для списка пользователей, а в model все что касается данных…

Если вы немного копнёте в Direct, то увидите: это как раз средство свести серверную сторону к абсолютному минимуму. По факту к надстройке над базой данных, которая делает проверку прав доступа и может быть чуть-чуть ещё.


А всё, что вам нужно, можно сделать на клиентской стороне. Благо, Ext JS как раз для таких вещей и создан.

Ух, мы с вами, чувствую, погрузимся в такие дебри, от куда будет сложно выбраться. Я с Ext'ом со 2й версии, т.е. года, этак с 2008, если мой склероз мне не изменяет:) Но многие вещи о которых вы пишете довольно спорные, на мой взгляд.

Ну вот если вы это понимаете, то также должны понимать, что для интранета и всяких там админок очень часто используется всякое старьё

Эта практика, когда СБ запрещали все кроме ИЕ6 прошла много лет назад. Я еще не разу за последние лет 5 не встречал клиента (а их, поверьте, было довольно много), который сказал бы, что его црмка должна работать на ИЕ8. Все прекрасно понимают, что стоимость поддержки легаси-броузеров в проекте стоит очень дорого.

Вот тут будут возникать отдельные вопросы, и даже целая пачка. Емнип, Cmd совершенно не в курсе

Про сборку. Не cmd единым жив интернет) cmd такой же инструмент как оные другие. Никто не мешает включить его в цепочку других инструментов. У меня для сборки простенький баш-скрипт, можно пользоваться гулпом или кучей других сборщиков. Порядок, примерно такой: разделяет общие файлы, очищает от «чужих методов» -> запускает cmd для клиента -> пакует в контейнер. В зависимости от проекта, можно собрать отдельно сервер, отдельно клиент или 2-в-одном.

В большей части приложений порядка 20-30% времени до первой отрисовки съедало именно создание объектов и в частности, создание конфигов для них.

Да объясните, наконец, зачем на сервере что-то отрисовывать? На сервере это работает так: Ext.create -> <Трансляция имени класса в путь к файлу> -> requere(<файл>). Еще немного времени возьмет всякого рода фокусы с наследованием, но это копейки. После этого класс у вас в памяти и все последующие Ext.create этого класса мгновенные. Кроме того, большинство классов на сервере живут пока жив текущий процесс.

От сервера требуется асинхронность, иначе масштабирование системы будет под очень большим вопросом. Поскольку всё происходит в одном event loop, каждый кусок кода должен быть очень быстрым и возвращать управление планировщику как можно быстрее. А в Ext на каждое событие можно повесить обработчик, который может тоже стрелять события, на которые могут быть повешены обработчики, и так далее ad nauseam.

Спасибо, что просветили насчет event loop, я то, грешным делом, думал как же эта хренотень работает) Если серьезно, то, внимание, вопрос что такое this.fireEvent и чем оно отличается от this.myCoolMethod? Ответ: ровным счетом ничем, это самый обычный метод класса на сервере, который по названию совпадает с методом fireEvent на клиенте, который делает все то, что вы там понаписали. Серверный this.fireEvent сделает асинхронно ровно то, что написал я, а именно, отправит в клиентские сокеты сообщения «чувак, тебе событие». Клиент получит это сообщение, прочитает, что там написано и вызовет уже клиентский fireEvent для нужного объекта. Но кодируя проект если мне нужно в реальном времени о чем-то сообщить клиенту я просто напишу fireEvent на сервере вместо тонны кода, который остается под капотом.

Я вижу Ext JS как кусок говна софта, на который я потратил 6 лет жизни. ;) Частей там существенно больше двух.

Сочувствую) Я после 6лет с ПХП долго восстанавливал нервную систему. С Ext JS у меня более счастливый брак))

6.2 у вас? Это приятно слышать, потому что я потратил несколько месяцев на отлов всех утечек, до которых мог дотянуться. Похоже, что выпилил все крупные, раз вы проблем до сих пор не заметили. :)

В броузере утечки неизбежны, слишком много всего там живет разношерстого. Сервер в этом плане на порядок проще, и отловить утечки там реально.

Если вы немного копнёте в Direct, то увидите: это как раз средство свести серверную сторону к абсолютному минимуму. По факту к надстройке над базой данных, которая делает проверку прав доступа и может быть чуть-чуть ещё.

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

В начале времен, когда трава была зеленее и столы выше, программы на клиенте и сервере были написаны одинаково, и могли поддерживаться программистами с одинаковыми компетенциями. Потом настали трудные времена и клиент ушел от сервера. И превратились программисты во фронтендеров и бакэндеров. Я просто пытаюсь снова воссоединить клиент и сервер:) (это юмор, в субботу можно. Только, ради Бога, не пишите про всякие там соапы, терминалы и прочее, что было в те далекие времена)

Ух, мы с вами, чувствую, погрузимся в такие дебри, от куда будет сложно выбраться. Я с Ext'ом со 2й версии, т.е. года, этак с 2008, если мой склероз мне не изменяет:)

Можем и забраться, если вам интересно будет. :) Я с Ext работаю не так давно, в Sencha меня пригласили как раз аккурат к релизу 4.2. С тех пор уже 6 лет прошло, время летит...


Но многие вещи о которых вы пишете довольно спорные, на мой взгляд.

Запросто, понимание у всех разное. Я вижу вещи изнутри, вы на них смотрите снаружи, может и не совпасть.


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

IE11 ещё очень много где используется, и будет использоваться долго. У нас были клиенты, которые в конце 2018 всё ещё использовали IE7 и приложения на базе Ext 4. Масштабы есть очень разные, и стоимость поддержки тоже отличается очень сильно.


Про сборку. Не cmd единым жив интернет) cmd такой же инструмент как оные другие.

Нет, не такой же. Гораздо сложнее, и с более глубоким пониманием именно Ext JS. В Cmd очень много всякой магии для отслеживания зависимостей, настолько много, что заменить Cmd просто нечем. И бОльшая часть этой магии работает на уровнях, вам совершенно не очевидных.


Это уже не говоря о преобразованиях кода. У вас, скорее всего, никогда не было повода заглянуть в код production build и сравнить его с исходниками. Разница будет весьма заметная, в основном в классовой системе. Ext.define преобразуются в более дешёвые вызовы Ext.derive и т.д. Много тонких нюансов.


Порядок, примерно такой: разделяет общие файлы, очищает от «чужих методов» -> запускает cmd для клиента -> пакует в контейнер. В зависимости от проекта, можно собрать отдельно сервер, отдельно клиент или 2-в-одном.

Именно об этом я и говорил: за кажущееся упрощение серверной части вы платите усложнением toolchain, усложнением кода, разного рода проблемами, несвойственными серверной стороне, и т.д. Конкретно в вашем случае и сейчас цена может быть незаметно низкой, но она есть, и если потребуется ваше решение масштабировать, то цена будет расти быстрее, чем выгода.


Да объясните, наконец, зачем на сервере что-то отрисовывать? На сервере это работает так: Ext.create -> <Трансляция имени класса в путь к файлу> -> requere(<файл>).

На сервере отрисовывать незачем, хотя и можно. Я говорил о своих исследованиях, которые проводил на браузерной стороне. Там критерием истины служит время от начала загрузки до первой отрисовки, в случае сервера скорее от начала загрузки до создания дерева объектов. Себестоимость создания этого дерева никуда не девается.


Еще немного времени возьмет всякого рода фокусы с наследованием, но это копейки.

Ошибочное мнение. Настолько не копейки, что специально для этого в Cmd есть целый кусок преобразования кода.


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

Речь не о классах, а об экземплярах класса. Посмотрите внимательно в Ext.Config и Ext.Configurator, там много интересного. Если вкратце, то при создании каждого экземпляра класса создаётся прототипная цепочка конфигов, и на это тратится существенное время. За гибкость надо платить.


Серверный this.fireEvent сделает асинхронно ровно то, что написал я, а именно, отправит в клиентские сокеты сообщения «чувак, тебе событие».

Возможно, я не совсем внимательно смотрел в код. У вас же серверная логика базируется на Ext.app.Controller? Контроллеры умеют стрелять события по своему событийному домену и слушать их, всё это происходит синхронно. То, что события в WebSocket отправляются асихронно, не означает, что больше ничего не происходит.


Кроме того, речь даже не о ваших событиях в WebSocket. Речь о том, что вы используете штатный механизм, который никогда не был предназначен для такого варианта использования. И этот механизм очень легко может выстрелить вам в ногу, если вы не будете очень аккуратны. Вы-то может и будете, а вот другие люди, не так хорошо понимающие этот механизм?


Сочувствую) Я после 6лет с ПХП долго восстанавливал нервную систему. С Ext JS у меня более счастливый брак))

Я рад, что вам нравится наш фреймворк. Это всегда приятно слышать. :)


В броузере утечки неизбежны, слишком много всего там живет разношерстого. Сервер в этом плане на порядок проще, и отловить утечки там реально.

Дело не в разношёрстности. В Node отсутствует DOM, но течь через expandos на DOM нодах браузеры уже давно разучились, этих проблем не было уже с IE8. Дело в управлении памятью в JavaScript, а эта часть одинакова и там, и там.


Технически, бОльшая часть утечек в JavaScript попадает в категорию "псевдо-утечек". В этом случае память остаётся адресуемой и может быть освобождена, но по каким-то причинам сборщик мусора не может её освободить. Обычно это случается из-за того, что где-то есть ссылка на объект, и по цепочке ссылок можно дойти до глобального объекта.


Вот проблема как раз в том, что Ext JS по своей архитектуре способствует таким утечкам, и избавиться от них было очень сложно. В других решениях проблема может быть либо не настолько выраженной, либо отсутствовать вовсе, но в JavaScript всегда очень легко эти утечки создать вручную. Очень, очень легко. В браузере они не критичны, т.к. даже самое долгоживущее приложение рано или поздно закрывают. А вот на сервере это проблема.


Да, я директором пользуюсь если сервер не нодовский. Но нафига мне лишняя прослойка, когда у меня один язык на клиенте и сервере?

Это не прослойка, это транспорт. С разными вкусными плюшками, которые вы можете использовать практически бесплатно.


Еще раз: основная задача в этом проекте максимально стереть границу между клиентом и сервером при сохранении возможностей масштабирования.

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


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

Вы преувеличивается и зелень травы, и трудность времён. :) Web приложения это не более, чем очередной заход в распределённые вычисления. Со своими специфическими заморочками, но в сущности по мелочам.


Я просто пытаюсь снова воссоединить клиент и сервер:)

Зачем? Мне было бы очень интересно услышать развёрнутый и убедительный ответ на этот вопрос. :)


Только, ради Бога, не пишите про всякие там соапы, терминалы и прочее, что было в те далекие времена

Ну вы смешали тоже. SOAP это просто транспортный протокол на базе XML, Ext JS его вполне умеет. И есть клиенты, которые его используют. Я даже пару багов в нём как-то фиксил...

Думаю, вся эта наша дискуссия возникла от того, что мы смотрим на серверную часть с разных колоколен. У нас каждый коммент по объему соизмерим с самой статьей. Немного разгребу свои завалы по работе, напишу вторую статью «как это устроено», что бы сделать разговор более предметным.

По вашему комментарию пара соображений:

1. Серверные классы не наследуют никакие встроенные классы extjs. Вся эта идея начиналась с того, что базовые js классы довольно убогие. Если мне нужно сделать Class2 наследником от Class1, то в js это будет монструозная конструкция c путями к файлу:
const Class1 = require('path/to/FileOfClass1');
module.exports = class Class2 extends Class1 {
...
}

Про реализацию михинов, статических свойств и т.п. стандартным js не мне вам рассказывать…

2. Насчет скорости всего этого хозяйства. Я не пробовал измерять время при создании экземпляров классов-наследников от каких-то стандартных классов (скажем, от того-же Ext.app.Controller). На сервере мне это не нужно. Но если померить время на генерацию экземпляров классов в примере из статьи, то получится в районе 0 (можете сами посмотреть):
// server.js
.....
Ext.Loader.setPath('Api', 'protected/rest');

var t = Date.now();
var c = Ext.create('Api.auth.Main');
console.log('tm 1:', Date.now() - t)

var t = Date.now();
var c1 = Ext.create('Api.auth.Main');
console.log('tm 2:', Date.now() - t);
....

Результат:
$node server
tm 1: 8
tm 2: 0

8мс при первом Ext.create, где основное время занимает дисковая операция по чтению файла, и нулевое время при создании последующих инстансов.
Если в 2х словах, то все что требуется от Extjs на сервере — это возможность вместо:
const Class1 = require('path/to/FileOfClass1');
module.exports = class Class2 extends Class1 {
     constructor() {
          this.prop1 = 1;
          this.prop2 = 2;
     }
}

написать:
Ext.define('Namespace.Class2', {
      extend: 'Namespace.Class1'
      prop1: 1,
      prop2: 2
})

Все остальное на сервере, к extjs не имеет никакого отношения. Просто, одинаковые паттерны в коде клиента и сервера позволяют реализовать все то, что описано в статье.
Зарегистрируйтесь на Хабре , чтобы оставить комментарий

Публикации

Истории