Pull to refresh

Comments 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" (ты) в качестве подлежащего, и порядок слов - вместе дают повелительное наклонение.
Короче, это я бы перевёл как "Посмотри [, это любопытно]".

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

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

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

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

Sign up to leave a comment.

Articles