Проблема в том, что под капотом — prototype. С классами работать не всегда удобно. Класса у меня вообще может не быть, а super, тем не менее, нужен. Приходится в одном месте использовать нативный, а в другом — самоделку.
Конечно, можно. Каждый, кому не лень, писал свой велосипед.
Дело в том, что предложенный стандарт выглядит недоделанным. Скажем, переменная this существует всегда, можно заглянуть в спецификацию и узнать, чему она равна в каждом конкретном случае.
А вот super…
Тут вопрос вот в чём: «несколько десятков метров» — это сколько? Скажем, 100 метров — верю, скорее всего сработает. 30 метров — как повезёт. 10 метров — точно не успеет.
Ещё быстроразъёмные соединения не внушают доверия. Я бы предложил пироножи.
Код посмотрел. Некоторые идеи есть, но кодить пока некогда. А на естественном языке мне мысли о коде выражать труднее, чем на JS.
Будет окно в своих скриптах — предложу свой коммит для Rat.
А пока мне интересно, как Вы думаете реализовать события. Я сам очень мало работал с canvas и рассчитываю с помощью какого-то из Ваших фреймворков ликвидировать безграмотность.
Можно всю отрисовку сделать асинхронной. Рендерер ждёт, когда прогрузятся все картинки, а потом рисует элементы в порядке следования.
Или, ещё лучше, грузить картинку при создании элемента, а не при отрисовке. Рисовать же несколько раз можно, а грузить достаточно один раз.
Пройдёмся по опечаткам (дюже они страшные):
*я не друг тем людям, для которых смысл этой записи не очевиден.
*а к толстому клиенту не лучше не подходить
Вот что бывает, когда в конце рабочего дня комменты пишешь…
Дело в том, что предложенный стандарт выглядит недоделанным. Скажем, переменная this существует всегда, можно заглянуть в спецификацию и узнать, чему она равна в каждом конкретном случае.
А вот super…
2. С чего бы им разваливаться?
Ещё быстроразъёмные соединения не внушают доверия. Я бы предложил пироножи.
Будет окно в своих скриптах — предложу свой коммит для Rat.
А пока мне интересно, как Вы думаете реализовать события. Я сам очень мало работал с canvas и рассчитываю с помощью какого-то из Ваших фреймворков ликвидировать безграмотность.
Боюсь именно поэтому мусора станет больше, т.к. люди из других ЯП будут ещё реже заглядывать в спецификацию JS.
Конечно, конструкция силовых частей механизма должна быть другая. Но алгоритм работы…
Или, ещё лучше, грузить картинку при создании элемента, а не при отрисовке. Рисовать же несколько раз можно, а грузить достаточно один раз.
data-ориентированность тут не до конца. Ну, не беда, можно допилить. Жаль, времени пока нет в коде копаться…
*я не друг тем людям, для которых смысл этой записи не очевиден.
*а к толстому клиенту
нелучше не подходитьВот что бывает, когда в конце рабочего дня комменты пишешь…