Ну и так по мелочи: визуальные вкладки, вкладки слева (справа, снизу), Ctrl+middle mouse для zoom=100%, вкладко-зависимые попапы (неблокирующие всё окно приложения!), меню F12(отключение JavaScript!), приватный режим в том же окне, настройки для сайтов, управление с клавиатуры (без мыши) и некоторые другие мелочи.
А ещё в старой Опере можно было добавить textarea как поисковый движек, а не только input. Благодаря этому, я сделал себе однобуквенный шорт-кат для translate.google.com — ни Chrome, ни новая Опера этого не умеет.
Спасибо. Не знал. Но, к сожалению, это не всегда поможет. Сейчас очень много жаваскрипта на страницах, а даблклин это всё таки даблклик, и на него сработают события, скорее всего не те, что вы ожидаете. А ещё на этот способ сильно влияет css (в отличии от того, что был реализован в старой Опере) — просто откройте любой репозиторий на github и попробуйте выделить слово «Watch», не нажав на него — сколько я не пробовал — не получилось. И это просто наиболее простой пример.
А так спасибо, не знал про эти возможности — они действительно облегчат мне переезд со старой Оперы на новую.
Со всем согласен, кроме 4, 5, 7 — лично я не буду по этому функционалу скучать.
Сам сижу одновременно на новой Опере (Dev-channel) и старой и могу добавить ещё несколько отличий в юзабилити:
1. Выделение текста по двойному клику: Если есть большой параграф с текстом, то, при даблклике по слову выделяется это слово, при следующем клике по этому же слову выделяется предложение, а уже при следующем клике выделяется параграф. Чертовски удобно, когда нужно скопировать только предложение. Ни один другой браузер так не умеет — они выделяют сначала слово, а потом сразу параграф.
2. Создание вкладки. В старой Опере есть настройка «Открывать новую вкладку вслед за текущей», благодаря ей появляются два способа создать новую вкладку: Плюсик в панели вкладок (он же Ctrl+T) и клик средней кнопки мышки по свободному месту в панели вкладок. Отличаются эти способы кардинально: первый создаёт новую вкладку вслед за текущей, а второй способ создаёт новую вкладку в конце списка открытых вкладок. Когда открыто более 20+ вкладок (а у меня обычно так), то это просто супер удобно. Но даже если в новой Опере появится настройка «Открывать новую вкладку вслед за текущей», она бесполезна без возможности создать вкладку в конце — то есть только наличие обоих этих способов создаёт комфорт.
3. Mouse Rocket Gestures. В новой Опере «вроде бы как» есть эти самые Mouse Rocket Gestures, но они реализованы так, что кажется, что сами разработчики новой Оперы больше ими не пользуются. При навигации по web-приложениям (History API) или по anchore'рам (т.е. без перезагрузки страницы) нажатие «Правая кнопка мыши» + «Левая кнопка мыши» действительно заставит браузер перейти назад по истории, но при этом выделит часть страницы от того места где мы были и до того, куда мы попали. Особенно заметно, когда ходишь по github'у или большим документам типа спецификации ECMA-262 — тут воспроизвести очень просто: тыкаем по ссылке в Contents а потом делаем Mouse Rocket Gestures back.
4. Чисто субъективное ощущение — браузер на движке webkit/blink жрёт больше оперативной памяти чем старая опера. Одной из причин может быть то, что все картинки, которые когда либо попадали в DOM-дерево и были загружены в память в raw-виде, так там и останутся, даже если Image-элемент больше не видим (даже с display:block) и даже если он был извлечён из DOM-дерева. Старая Опера держала в памяти только то, что нужно в данный момент показывать. И да, в старой Опере можно было часто наблюдать «подгрузку» больших картинок каждый раз, когда мы уходим с вкладки и возвращаемся на неё, но я считаю, это небольшая цена за экономию памяти (да у меня 8Gb оперативы и я не хочу, чтобы браузер ел больше 1.5).
Дело как раз в том, что популяризации Microdata API как раз и мешает её отсутствие в Chromium. А выпилина экспериментальная поддержка была как раз из-за низкой популярности :) Замкнутый круг какой-то.
Ну и из-за того, что Microdata API не правильно позиционируется, это можно понять просто почитав ветку в Google Group, в которой обсуждали выпиливание.
По мне, так это не правильно. Microdata API такая же часть WEB API, как и Clipboard API (наполовину бесполезный), Drag and Drop API (кроме дропа файлов бесполезный), Keyboard API (который пилят и переписывают уже более двух лет, а в Chrome как раз реализована самая старая спецификация — самая бесполезная, и её никто не выпиливает, хотя её использовать не возможно), File API (который проигрывает по скорости и потреблению памяти флешу).
В той ситуации, когда мы, по факту, имеем в современных браузерах полу-бесполезные недоработанные (редакторами спецификации) API, которые никто напрямую не использует (потому что неудобно), выпиливание Microdata API (которая привносила действительно что-то новое) это просто верх маразма. Но, я в Chromium не контрибучу, поэтому меня они не послушают.
Для $scope есть нативное Micrpdata API, через которое и двойной байндинг делается достаточно легко. P.S. Может быть я покажу себя дилетантом, т.к. не использовал в работе Angular (смотрел демки, читал доки) и могу неправильно понимать $scope.
Да, на es6 можно уже смело писать. Правда сам traceur не использую — по разным причинам, и на первом месте потому, что он генерит плохой код на выходе.
А ещё можно сразу начать писать на es6 modules. И не придумывать велосипед.
Хотя тяга к структурированному коду это хорошо, плюсик вам за это (ну и за картинку — порадовали :) )
Разработка стандартов это долгий, нудный и сложный процесс. Есть Early Draft спецификации Message Formatting. Который поддерживает плюарализацию, обращения, пол, сравнение с эталоном, отступы и многое другое. Будущий стандарт должен будет реализовывать ICU(International Components for Unicode). Но сам ICU ещё не доделан и тот формат, который сейчас описан в спецификации не совместим (на уровне «не плодите больше сущностей») со строковыми шаблонами es6, так что пока не ясно, когда выпустят хотя бы рабочий черновик.
К слову, в Angular и GWT используется именно ICU формат.
В TS замечательно то, что никто тебя не принуждает использовать типы. В принципе, мне они нужны только для перегрузки функций и более внятного описания классов.
Но сам я сейчас пишу на ES6 (вот пример) и не могу нарадоваться, хотя типов данных и enum(особенно) и не хватает.
Признаться я спешил, поэтому в моём комментарии есть неточности:
1. К сожалению, ни [].has, ни [].contains в спецификации на данный момент нету — нужно уточнить почему.
2. Имел ввиду не класс URI, а класс URL (спецификация)
По существу:
Судя по всему, вы знаете про ECMAScript 6, поэтому не можете не знать, что большинство описанных вами проблем решено в следующей версии языка:
1. У массивов есть [].contains(item) — возвращающий булевое значение. У строк есть .contains, .startsWith, .endsWith
2. let/const появились
3. Number.isNaN работает иначе чем isNaN
4. Стандартный класс URI (уже работает в V8)
5. Классы class A extends B {}
6. __proto__ deprecated. Используйте Reflect.getPrototypeOf, Reflect.setPrototypeOf
Слепили за 10 дней.
Неправда и провокация. За 10 дней слепили версию, которую два года допиливали, до того состояния, чтобы отправить на стандартизацию в ISO. Текущая поддерживаемая браузерами — версия ECMA-262 редакция 5.1 2011 года — то есть почти 16 лет развития. 6 версия редакции (пресловутый Harmony) разрабатывалась последние 3 года — небольшой срок для такой сложной работы (все ведь помнят, сколько понадобилось времени для завершения работы над C++11 и принятии его в качестве стандарта?).
Вы можете возразить, что существуют браузеры, которые даже не в полной мере поддерживают ES 5.1, что уж говорить про ES6. Я на это обычно отвечаю, что самая популярная версия Python — 2.7 2010 года. Чтобы подтянуть старые браузеры до уровня ES 5.1 или даже ES 6, вы можете использовать полифилы. Вы даже можете уже писать на ES6 (т.к. стандарт уже не будет серьёзно меняться), просто используя прансляцию на этапе сборки проекта.
В javascript можно не только писать unit-тесты (для которых существует куча библиотек), но и покрыть буквально каждую операцию так называемым code coverage (одна из самых популярных библиотек для этого istanbul).
Для отлавливания ошибок на этапе компиляции (для js это этап сборки проекта) используются статические анализаторы кода (типа JSLint, eslint и других) или препроцессоры типа TypeScript (в котором есть типизация).
Но конечно, нужно рассматривать конкретный проект, может быть в вашем случае вы и поступили правильнее перенеся логику на C#.
К сожалению, стрелочные функции это не панацея и не помогут в приведённом вами случае. Чтобы было лучше понятно, можно относится к стрелочным функциям не как к функциям, а как к блокам — то есть стрелочные функции полезны только в рамках того же контекста, в котором были созданы.
В случае же кода this.$dom_obj.click( this.someFuncton.bind( this ) ); придётся всё также использовать .bind либо, вы можете воспользоваться волшебным handleEvent, о нём вы можете почитать в моей недописанной статье, либо в англоязычных источниках
А ещё в старой Опере можно было добавить textarea как поисковый движек, а не только input. Благодаря этому, я сделал себе однобуквенный шорт-кат для translate.google.com — ни Chrome, ни новая Опера этого не умеет.
А так спасибо, не знал про эти возможности — они действительно облегчат мне переезд со старой Оперы на новую.
Сам сижу одновременно на новой Опере (Dev-channel) и старой и могу добавить ещё несколько отличий в юзабилити:
1. Выделение текста по двойному клику: Если есть большой параграф с текстом, то, при даблклике по слову выделяется это слово, при следующем клике по этому же слову выделяется предложение, а уже при следующем клике выделяется параграф. Чертовски удобно, когда нужно скопировать только предложение. Ни один другой браузер так не умеет — они выделяют сначала слово, а потом сразу параграф.
2. Создание вкладки. В старой Опере есть настройка «Открывать новую вкладку вслед за текущей», благодаря ей появляются два способа создать новую вкладку: Плюсик в панели вкладок (он же Ctrl+T) и клик средней кнопки мышки по свободному месту в панели вкладок. Отличаются эти способы кардинально: первый создаёт новую вкладку вслед за текущей, а второй способ создаёт новую вкладку в конце списка открытых вкладок. Когда открыто более 20+ вкладок (а у меня обычно так), то это просто супер удобно. Но даже если в новой Опере появится настройка «Открывать новую вкладку вслед за текущей», она бесполезна без возможности создать вкладку в конце — то есть только наличие обоих этих способов создаёт комфорт.
3. Mouse Rocket Gestures. В новой Опере «вроде бы как» есть эти самые Mouse Rocket Gestures, но они реализованы так, что кажется, что сами разработчики новой Оперы больше ими не пользуются. При навигации по web-приложениям (History API) или по anchore'рам (т.е. без перезагрузки страницы) нажатие «Правая кнопка мыши» + «Левая кнопка мыши» действительно заставит браузер перейти назад по истории, но при этом выделит часть страницы от того места где мы были и до того, куда мы попали. Особенно заметно, когда ходишь по github'у или большим документам типа спецификации ECMA-262 — тут воспроизвести очень просто: тыкаем по ссылке в Contents а потом делаем Mouse Rocket Gestures back.
4. Чисто субъективное ощущение — браузер на движке webkit/blink жрёт больше оперативной памяти чем старая опера. Одной из причин может быть то, что все картинки, которые когда либо попадали в DOM-дерево и были загружены в память в raw-виде, так там и останутся, даже если Image-элемент больше не видим (даже с display:block) и даже если он был извлечён из DOM-дерева. Старая Опера держала в памяти только то, что нужно в данный момент показывать. И да, в старой Опере можно было часто наблюдать «подгрузку» больших картинок каждый раз, когда мы уходим с вкладки и возвращаемся на неё, но я считаю, это небольшая цена за экономию памяти (да у меня 8Gb оперативы и я не хочу, чтобы браузер ел больше 1.5).
Ну и из-за того, что Microdata API не правильно позиционируется, это можно понять просто почитав ветку в Google Group, в которой обсуждали выпиливание.
По мне, так это не правильно. Microdata API такая же часть WEB API, как и Clipboard API (наполовину бесполезный), Drag and Drop API (кроме дропа файлов бесполезный), Keyboard API (который пилят и переписывают уже более двух лет, а в Chrome как раз реализована самая старая спецификация — самая бесполезная, и её никто не выпиливает, хотя её использовать не возможно), File API (который проигрывает по скорости и потреблению памяти флешу).
В той ситуации, когда мы, по факту, имеем в современных браузерах полу-бесполезные недоработанные (редакторами спецификации) API, которые никто напрямую не использует (потому что неудобно), выпиливание Microdata API (которая привносила действительно что-то новое) это просто верх маразма. Но, я в Chromium не контрибучу, поэтому меня они не послушают.
P.S. Может быть я покажу себя дилетантом, т.к. не использовал в работе Angular (смотрел демки, читал доки) и могу неправильно понимать $scope.
Хотя тяга к структурированному коду это хорошо, плюсик вам за это (ну и за картинку — порадовали :) )
К слову, в Angular и GWT используется именно ICU формат.
1. Поддержка Node.js
2. Куча опций
3. Возможность полифилизации
Насколько они совместимы? Т.е. написав документацию на JSDuck, смогу ли я воспользоваться утилитами понимающими JSDoc?
Но сам я сейчас пишу на ES6 (вот пример) и не могу нарадоваться, хотя типов данных и enum(особенно) и не хватает.
1. К сожалению, ни [].has, ни [].contains в спецификации на данный момент нету — нужно уточнить почему.
2. Имел ввиду не класс URI, а класс URL (спецификация)
По существу:
Судя по всему, вы знаете про ECMAScript 6, поэтому не можете не знать, что большинство описанных вами проблем решено в следующей версии языка:
1. У массивов есть [].contains(item) — возвращающий булевое значение. У строк есть .contains, .startsWith, .endsWith
2. let/const появились
3. Number.isNaN работает иначе чем isNaN
4. Стандартный класс URI (уже работает в V8)
5. Классы class A extends B {}
6. __proto__ deprecated. Используйте Reflect.getPrototypeOf, Reflect.setPrototypeOf
Неправда и провокация. За 10 дней слепили версию, которую два года допиливали, до того состояния, чтобы отправить на стандартизацию в ISO. Текущая поддерживаемая браузерами — версия ECMA-262 редакция 5.1 2011 года — то есть почти 16 лет развития. 6 версия редакции (пресловутый Harmony) разрабатывалась последние 3 года — небольшой срок для такой сложной работы (все ведь помнят, сколько понадобилось времени для завершения работы над C++11 и принятии его в качестве стандарта?).
Вы можете возразить, что существуют браузеры, которые даже не в полной мере поддерживают ES 5.1, что уж говорить про ES6. Я на это обычно отвечаю, что самая популярная версия Python — 2.7 2010 года. Чтобы подтянуть старые браузеры до уровня ES 5.1 или даже ES 6, вы можете использовать полифилы. Вы даже можете уже писать на ES6 (т.к. стандарт уже не будет серьёзно меняться), просто используя прансляцию на этапе сборки проекта.
Для отлавливания ошибок на этапе компиляции (для js это этап сборки проекта) используются статические анализаторы кода (типа JSLint, eslint и других) или препроцессоры типа TypeScript (в котором есть типизация).
Но конечно, нужно рассматривать конкретный проект, может быть в вашем случае вы и поступили правильнее перенеся логику на C#.
В случае же кода
this.$dom_obj.click( this.someFuncton.bind( this ) );придётся всё также использовать.bindлибо, вы можете воспользоваться волшебнымhandleEvent, о нём вы можете почитать в моей недописанной статье, либо в англоязычных источниках