А как же новость о том что Qualcomm продал Vuforia каким-то левым товарищам и теперь не очень то понятно, что будет дальше с одной из лучших библиотек для мобильной AR?
Я считаю что angular абсолютно последователен и совершенно логичен в рамках выбранной дата-драйвин концепции.
Но это не отменяет проблем его реализации — вербозность и «тоталитарность», если вы понимаете о чём я.
Фиг с ней с вербозностью — хотя это вполне себе бессмысленные временные затраты, но вот «тоталитарность» гораздо злее. Высшим злом любого фреймворка я считаю ситуацию, когда его внутренние проблемы с формулировкой «вам это не надо», всплывают наверх через весь продукт, к конечному пользователю. И «вам это не надо» приходится говорить уже пользователю («все равно его не брошу потому что он хороший»). Или отказываться от такого фреймворка :)
Занимательный факт, что я заметил. Ангулар обычно хают люди, которые
Безапелляционненько как-то. Есть люди которые просто нашли более _эффективный_ (результат\время) фреймворк для своих задач. И с высоты своего опыта, прошу прощения за высокий штиль, недоумевают почему ангулар присвоил себе звание «серебряной пули».
Я, например, считаю что в фундаменте ангулара(1.х) лежит серьёзный компромисс. Давайте у нас всё будет работать не так быстро как могло бы ( а иногда и откровенно умирать, признаемся честно), но это ничего — зато мы всё круто зарегулируем и стандартизуем. Это пахнет «программизмом для программистов», а не для конечных пользователей. Процессом ради процесса. Да, для каких-то задач ангулар — отличный инструмент. Но не для всех. И даже не для 90%. Это один инструмент из многих — есть молоток, а есть шуруповёрт.
Теперь можете рассказать мне что я не имею большого опыта программирования на vanillajs и далее по тексту. Только перед этим расскажите с какими фреймворками(кроме ангулара) вы реально работали, щупали руками и применяли на практике.
По моему мнению — shadow DOM это ключевая компонента понятия «тру визуальная компонента», прошу прощения за тавтологию. Основное качество — максимальная независимость компоненты от контекста приложения, с сохранением стройной и гибкой декларативной составляющей описания + возможностью суперпозиции с другими компонентами.
От VCL(Delphi, c++Builder) до WPF\Adobe Flex\Qt QML — все удобные UI фрэймворки проводят эту идею. Если появится такая, нативная среде исполнения, сущность — отсохнет целая гроздь «костылей» (тот же яндекс-БЭМ — если не отсохнет совсем, то уж точно серьёзно «усохнет»).
Переход от <input/> к <myinput/>, где myform и myinput — мои, полностью кастомные компоненты (как по визуалу, так и по бизнес-логике) которые я могу независимо, в сторонке, описать и потом использовать так же свободно как «стандартные» тэги — это сродни перехода от WinForms к WPF, это то что уже вчера надо было.
Т.е. гугл тут даже не изобретает тут велосипед, он просто пытается протолкнуть производство недостающих деталей к уже готовым и объезженным велосипедам. И если у него получится — я буду только рад.
Ключевое слово «в перспективе» :( Классическая боль веб-разработчика. Да, шэдоу-дом и инкапуслированные CSS это круто и правильно, кто бы спорил! Но пока нет нативной поддержки этих фич в 99% пользовательских браузеров — это всё фикция и тормоза. Сейчас использовать полимеры в реальном продакшене (забываем про хром, вспоминаем про ie) — это добровольно вешать на себя довольно серьёзные оверхеды полифилов. Продукт реакта, в общем, будет работать заметно быстрее, чем продукт полимера. Я на полимер облизывался ещё года полтора назад… но по моим наблюдениям, с точки зрения широкой аудитории: воз и ныне там. И более того, мне кажется, что из политических соображений, многие фичи, необходимые для реализации полимера «по полной программе», будут искусственно тормозится не-гуглами.
Вообще-то интерпретатор выполнит сначала function x() {};, затем var x; и только потом x=1;
Вообще-то интерпретатор _сначала_ выполнит var x; потом function x() {} и только потом x = 1.
Both function declaration and variable declarations are hoisted to the top of the containing scope. And function declaration takes precedence over variable declarations (but not over variable assignment)
Я только не понял причём тут WebKit в плане обсуждения производительности чистого JS? :)))
WebKit уже довольно часто используется только как WebCore, а Javascript-движок каждый норовит прикрутить свой, ибо Webkit'овый «стоковый» не блещет производительностью. Т.е. в данном случае Chrome это WebKit + v8. Его то преимущество над, вероятно, стоком мы и наблюдаем.
Профит я понимаю, эдакий кэш мгновенного доступа уже виденных картинок. Но у любого кэша должен быть лимит. По-моему не очень правильно оставлять возможность выжрать все ресурсы и уйти в даун — здесь такая возможность присутствует.
И да, после перезума, хоть все images и удалились из DOM, память не освободилась [ на старте было 30 мегабайт, я догнал 2000 тайлами её до 130Мб, после перезума память упала до 120]. Но это вполне может быть жадность V8, да.
Открыл OSM на leaflete. Странные конечно моменты есть — если «драгать» на одном маштабе, то тайлы(image) только добавляются в контейнерный layer div, и никогда не удаляются в таком режиме. Хорошо, что браузер умный(chrome) — выгружает офф-скрин картинки, поэтому память течёт слабозаметно, но DOM то растёт. Вот додрагал до 2000 тайлов, сделал zoomout и ждал, ну секунды две наверно, пока DOM избавлялся от этих 2000 имаджей. Я не то чтобы «гундю», мне просто интересно — это ради плавности так сделано или просто руки не дошли до «тайл-коллектора»?
Да, я понял Вашу точку зрения, но, тем не менее, придерживаюсь мнения, что меньшим злом в данной ситуации, было бы считать, что backward compatability в таких серьёзных вещах существенно более вероятен, чем наоборот. Поясню почему я так думаю:
Да, есть вероятность, что google выпускает косячный браузер, с испорченной акселерацией — но это будут объективные проблемы гугла, которые он, очевидно, будет решать всеми силами и в кратчайшие сроки.
Да, есть вероятность того, что гугл вдруг решает отказаться от хардварной акселерации совсем. Есть, но ма-аленькая.
Вообще, CSS3 без соответствующей производительности — во многом фикция. Т.е. пути назад как бы и нет.
Ну в конце концов, можно было отладочное сообщение в консоль отладки кинуть — «Здравствуйте, мы очень осторожные индусы, мы живём сегодняшним днём и боимся думать о завтрашнем. Ахтунг!!! Неизвестный браузер детектед!!!».
Поезд уже ушёл, и далеко, но я всё-таки расскажу свою грустную историю использования flex разметки.
Дело было в Chromium (не путать с Chrome ). На радостях разбомбил свой js-layout который реализовывал стандартную north-west-center-east-south раскладку с изменяемыми ширинами. И забомбил всё на flex-ах. Код упростился, разметка стала волшебно-прозрачной — никаких врапперов-переврапперов. Но. Потом всё это пришлось отыгрывать обратно ( спасибо, SVN). А дело вот в чём — в центральной области у меня происходят массовые анимации. А во flex разметке у chromium'а отключается оптимизация рендеринга, если смотреть на DevTools, то каждый кадр он отрисовывает целиком, на всё окно. А та же анимация, но в float или absolute рендерится кусочками — только там где на экране произошло изменение. fps отличается очень сильно. Пришлось попрощаться с волшебной чёткостью разметки и вернуться к миксу из js'а, float'а и absolute'а.
Я недавно наткнулся на одно существенное(для меня) отличие:
— старые флексбоксы формально имели свойство «box-lines: multiple», но по факту все бразуеры игнорировали это свойство
— новые флексбоксы поддерживают flex-wrap, который реально работает как минимум в chrome 21/22.
Вкратце эта(вышеописанная) штука позволяет, например создавать IconView (а-ля проводник) из элементов различной высоты, заранее неизвестной высоты (float, как вы понимаете, перед такими ситуациями пасует)
Кроме того новый стандарт мне кажется более логичным, простым и в тоже время более гибким.
Единственное, что я почерпнул из этой статьи: «Боль в жопе непременно появится, если засунуть туда грабли». И не поспоришь ведь. Берегите здоровье — осторожнее с граблями, куда попало не суйте.
должно же быть или я ничего не понял? :)
Но это не отменяет проблем его реализации — вербозность и «тоталитарность», если вы понимаете о чём я.
Фиг с ней с вербозностью — хотя это вполне себе бессмысленные временные затраты, но вот «тоталитарность» гораздо злее. Высшим злом любого фреймворка я считаю ситуацию, когда его внутренние проблемы с формулировкой «вам это не надо», всплывают наверх через весь продукт, к конечному пользователю. И «вам это не надо» приходится говорить уже пользователю («все равно его не брошу потому что он хороший»). Или отказываться от такого фреймворка :)
Безапелляционненько как-то. Есть люди которые просто нашли более _эффективный_ (результат\время) фреймворк для своих задач. И с высоты своего опыта, прошу прощения за высокий штиль, недоумевают почему ангулар присвоил себе звание «серебряной пули».
Я, например, считаю что в фундаменте ангулара(1.х) лежит серьёзный компромисс. Давайте у нас всё будет работать не так быстро как могло бы ( а иногда и откровенно умирать, признаемся честно), но это ничего — зато мы всё круто зарегулируем и стандартизуем. Это пахнет «программизмом для программистов», а не для конечных пользователей. Процессом ради процесса. Да, для каких-то задач ангулар — отличный инструмент. Но не для всех. И даже не для 90%. Это один инструмент из многих — есть молоток, а есть шуруповёрт.
Теперь можете рассказать мне что я не имею большого опыта программирования на vanillajs и далее по тексту. Только перед этим расскажите с какими фреймворками(кроме ангулара) вы реально работали, щупали руками и применяли на практике.
От VCL(Delphi, c++Builder) до WPF\Adobe Flex\Qt QML — все удобные UI фрэймворки проводят эту идею. Если появится такая, нативная среде исполнения, сущность — отсохнет целая гроздь «костылей» (тот же яндекс-БЭМ — если не отсохнет совсем, то уж точно серьёзно «усохнет»).
Переход от <input/> к <myinput/>, где myform и myinput — мои, полностью кастомные компоненты (как по визуалу, так и по бизнес-логике) которые я могу независимо, в сторонке, описать и потом использовать так же свободно как «стандартные» тэги — это сродни перехода от WinForms к WPF, это то что уже вчера надо было.
Т.е. гугл тут даже не изобретает тут велосипед, он просто пытается протолкнуть производство недостающих деталей к уже готовым и объезженным велосипедам. И если у него получится — я буду только рад.
Вообще-то интерпретатор _сначала_ выполнит var x; потом function x() {} и только потом x = 1.
Both function declaration and variable declarations are hoisted to the top of the containing scope. And function declaration takes precedence over variable declarations (but not over variable assignment)
WebKit уже довольно часто используется только как WebCore, а Javascript-движок каждый норовит прикрутить свой, ибо Webkit'овый «стоковый» не блещет производительностью. Т.е. в данном случае Chrome это WebKit + v8. Его то преимущество над, вероятно, стоком мы и наблюдаем.
И да, после перезума, хоть все images и удалились из DOM, память не освободилась [ на старте было 30 мегабайт, я догнал 2000 тайлами её до 130Мб, после перезума память упала до 120]. Но это вполне может быть жадность V8, да.
Да, есть вероятность, что google выпускает косячный браузер, с испорченной акселерацией — но это будут объективные проблемы гугла, которые он, очевидно, будет решать всеми силами и в кратчайшие сроки.
Да, есть вероятность того, что гугл вдруг решает отказаться от хардварной акселерации совсем. Есть, но ма-аленькая.
Вообще, CSS3 без соответствующей производительности — во многом фикция. Т.е. пути назад как бы и нет.
Ну в конце концов, можно было отладочное сообщение в консоль отладки кинуть — «Здравствуйте, мы очень осторожные индусы, мы живём сегодняшним днём и боимся думать о завтрашнем. Ахтунг!!! Неизвестный браузер детектед!!!».
Дело было в Chromium (не путать с Chrome ). На радостях разбомбил свой js-layout который реализовывал стандартную north-west-center-east-south раскладку с изменяемыми ширинами. И забомбил всё на flex-ах. Код упростился, разметка стала волшебно-прозрачной — никаких врапперов-переврапперов. Но. Потом всё это пришлось отыгрывать обратно ( спасибо, SVN). А дело вот в чём — в центральной области у меня происходят массовые анимации. А во flex разметке у chromium'а отключается оптимизация рендеринга, если смотреть на DevTools, то каждый кадр он отрисовывает целиком, на всё окно. А та же анимация, но в float или absolute рендерится кусочками — только там где на экране произошло изменение. fps отличается очень сильно. Пришлось попрощаться с волшебной чёткостью разметки и вернуться к миксу из js'а, float'а и absolute'а.
— старые флексбоксы формально имели свойство «box-lines: multiple», но по факту все бразуеры игнорировали это свойство
— новые флексбоксы поддерживают flex-wrap, который реально работает как минимум в chrome 21/22.
Вкратце эта(вышеописанная) штука позволяет, например создавать IconView (а-ля проводник) из элементов различной высоты, заранее неизвестной высоты (float, как вы понимаете, перед такими ситуациями пасует)
Кроме того новый стандарт мне кажется более логичным, простым и в тоже время более гибким.