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

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

Написать код с использованием ООП, которое превосходит возможности даже стандарта ES7? Звучит впечатляюще?

Да уж, во времена ES13 звучит впечатляюще.

Выражение сказано было по поводу реализации ООП, с ES6 стандарта по выше упомянутый ES2022 мало что изменилось в этом направлении (добавлена приватность членов класса и свойств). И если подменить ES7 и ES13 суть не изменится.

Ну ооочень мало что изменилось - async / await (ES8) так, например, вообще на стиль написания кода не повлиял -)

async и await это конечно прекрасно, но как это коррелирует с объектно-ориентированным программированием?

async/await также поддерживались в версии данного фреймворка, о чем говорится в статье (если ее прочитать целиком, а не шапку).

В фреймворке есть защищенные члены класса, смеси, интерфейсы, абстрактные классы, более совершенная система свойств и так далее, чем не может похвастаться JS в "те самые времена" ES13.

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

Хмм, ну давайте про ООП, хоть я и говорил про стандарт в целом. Принципиально ООП не поменялся с ES3 - так что было бы странно, если бы фреймворк этого не поддерживал. А вот что касается синтаксического сахара, только в ES13 по сравнению с ES12 появилось:

С учетом того, что ES6 в плане этого сахара давал нового только конструкторы и публичные методы инстансов и классов, а ES7 ничего - не мало.

Даже тот же async / await расширил синтаксис классов асинхронными методами.

А что к самой статье, что к фреймворку нет никаких претензий - просто не вчитывался.

Статья - перевод публикации датируемой на начало 2021 года, что можно узнать по ссылке под заголовком, а в оригинальной статье описывается версия фреймворка, которая появилась еще одним годом ранее. На тот момент сравнивать с нереализованным стандартом, наверное, не имело смысла. Может мне стоило бы добавить от себя это в начале, но, не уверен, стоит это тогда называть переводом.
Вот по сравнению с ES7, а не, скажем, ES6 не ведаю, тут нужно мнение автора оригинала. Если это была бы моя публикация я бы сравнивал конечно же с последним стандартом.
Возвращаясь к "ООП, которое превосходит возможности даже стандарта ES7", скорее стоило бы подчеркнуть аналогичные особенности (именно, аспект ООП), а не ВСЕ нововведения последних стандартов - допущение моего перевода, тут если есть возможность, я исправлю. Спасибо за понимание.

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

Интересно, примерно, в каком году. Я с ним познакомился в 2017. Тогда была 5 версия. Да баги были и щас есть, но потихоньку исправляются. Не смог воспроизвести ошибку, которая на скрине. Буду признателен, если опишите как ее получить.

https://qooxdoo.org/qxl.widgetbrowser/ Тут выбираете таблицу, кликаете по строке. Воспроизводится в Firefox, в других браузерах не пробовал. Да, важное замечание - воспроизводится когда в Windows настроен скейлинг на 125% (это практически неизбежно, если у вас лэптоп). На 100% скейлинге пробовал - всё хорошо. Но это не решение проблемы, конечно же.

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

Бага наблюдается в огнелисе, рамка выделения ячейки таблицы сползает при зуме - от темы не зависит.
По поводу пикселей чекбоксов, на некоторых смотрится ничего при +/ - масштабировании, в каких-то ужасно как на скрине. Что самое интересное - некоторые элементы формы (элементы управления) имеют свою реализацию, а не из коробки, делалось, я полагаю, в те далекие времена когда одинаковый эффект хотелось наблюдать на всех движках браузеров и под капотом этого чебокса вообще компонент див со стилями, содержащий растровую картинку. Оставлено либо потому что руки не доходят или ради поддержки старых версий браузеров. Может замена на шрифт-иконки или векторное представление изменит расклад.

 "Kuckst du!" и грубо переводится как "Аккуратней или ваши глаза могут вылезти из орбит от изумления!"

А дословно переводится: "Смотри" или "Посмотри".

Упреждая возражения: хрени, типа разного значения в разных контекстах в немецком нет - немецкие слова всегда точно или почти точно переводятся на русский язык.

UPD: Перевод по схеме немецкий->английский->русский - почти всегда приводит к потере первоначального смысла.

Спасибо за поправку, есть кстати статья на немецком ресурсе, которая немного отличается по структуре и наполнением. Соглашусь, мне тоже не понравилось как ее перевел автор в английской статье по фреймворку.

Просто глагол kucken - в мультитране записан как "смотреть [на что-то с любопытством]". Форма второго лица, вместе с "du" (ты) в качестве подлежащего, и порядок слов - вместе дают повелительное наклонение.
Короче, это я бы перевёл как "Посмотри [, это любопытно]".

На то время когда писалась статья оригинальная, да, свежий.

А зачем было переводить новость о выходе фрейморка по прошествии почти двух лет?

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

Ух ты, ребята перепридумали ExtJS?

Почему перепридумали? эти два фреймворка ровесники.

Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации