Тут же не снижали, а завышали совместимость. Если бы людей отвращали друг от друга — это одно. А их скорее пытаются столкнуть друг с другом, ну в крайнем случае через какое-то время разочаруются.
правильная мысль, главное не сидеть дома. У «неудачников» вероятность социального контакта — 1 к 100, допустим, если для «клевых» — 1 к 10. Если постоянно куда-то выбираться в НОВЫЕ места и получать больший объем потенциальных контактов — если встретишь 1000 человек, то с 10 как минимум завяжется общение.
Ну и плюс самому не закрываться, но это уже сложнее.
про CORS, кстати, очень часто вопросы задают. Рекомендую всем поизучать новую спецификацию XHR, заголовки для CORS, узнать, что был такой XDR, и какие есть способы кроссдоменных запросов
Еще раз, внимательно.
Это будет свойство, не более. Метод класса не будет далее наследоваться, то есть
class Fruit {}
Fruit.add = function(){}
class Apple extends Fruit {}
Apple.add //=> undefined
И внимательно перечитайте, что я написал. Переназначить, не просто назначить. Приведу пример, который у меня был. Решил через событийную модель.
class Player {
...
get volume(){return this._volume}
set volume(val){...}
...
}
class MetaPlayer extends Player {
set volume(val){
return; //нужно было заблокировать функционал
}
}
var p = new Player;
p.volume; // => 100
var p = new MetaPlayer;
p.volume; //=> undefined. Геттер для метода отнаследованного класса "потерялся".
Вы, видимо, не работали либо с ООП, либо с классами в es6, раз так радостно это утверждаете.
Ну вы же сами понимаете, что инстанс Object в JS это не объект в понимании классического ООП. Это ближе к Hash в руби или Map какой-нибудь там в джаве. Просто назвали так.
Да и не все в жс объекты. 4 instanceof Object === false. Да даже 4 instanceof Number === false.
Давайте я скажу вам факт, после которого ООПсрач можно закрыть будет? Если нет желания срача ради срача.
ООП в жс есть. Но оно канонично использовалось для механизмов работы DOM, глубоко интегрированных в реализации языка, сам подход в ЖС всегда был преимущественно функциональным, то, что создаются методы — это необходимый сахар из-за невозможности делать оверлоад функций.
Без ООП пришлось бы для каждого типа ноды назначать свои методы, потому что не было бы цепочки HTMLAudioElement -> HTMLMediaElement -> HTMLElement -> Node -> EventEmitter -> Object (могу путать точный порядок).
Нет, нету. Это на самом деле просто сахар, реально на класс это не похоже:
-нельзя создать методы или свойства класса (ну, статические)
-нельзя переназначить только геттер или сеттер метода (нужно повторно назначать оба)
и так далее
ну я же говорю — я ими не пользуюсь, только вижу обзоры :) По крайней мере выглядит оно на порядок лучше чем продающиеся поделки Михалыча с третьего Мототракторного или дядюшки Ляо.
Прямо радуюсь каждый раз как векслер выпускает новый девайс. Не, я фанат моторолы и делла на самом деле, если говорить о гаджетах, но то что русская команда создает действительно качественные вещи — это просто здорово
Крутая штука, я только одно не понимаю: покупать стационарный бокс с андроидом и ставить эмулятор винды и подключать мышку, чтобы поиграть в олдскульные игры? Может, лучше прямо на компе это и делать? :)
Вобщем, я закончу эту мысль, подытожив: очень мало кто из нас пишет на машинном коде, так что смиритесь, все мы управляемые, и нами давно манипулируют (если задето самолюбие, то читай: за нас борются, нас завлекают). Это я к тому, чтобы у Вас не было иллюзий типа “я пишу на самом правильном языке или использую самую оптимальную технологию”.
А что, разве библиотеки есть только в JS?
Интерфейс: Не стандартизирован. Есть аналогичные объекты (кнопка, поле ввода и т.п.), но это не объекты ОС, а схожие объекты браузера и их значительно меньше. Большая часть объектов реализуется разработчиком самостоятельно.
Ну окей, и что дальше? Для интерфейсов есть куча библиотек. Есть даже Objective-J, который позволяет макось-разработчикам писать по ощущениям натурально нативные приложения.
Производительность (интерфейс): Средняя или низкая. Приложение интерпретируемое и работает в бразуере — надстройке в ОС, поэтому имеет доступ только к ресурсам браузера. Ключевым показателем при выборе браузера до сих пор является его скорость работы, что подтверждает актуальность вопроса.
asm.js по перформансу приближается к приложениям на c++ (полгода назад был всего в 2 раза медленнее). В него можно скомпилировать любой llvm-код (это уже про то, что библиотеки скудны и их мало).
я могу докопаться до половины фраз, просто по-моему вы не до конца понимаете, в чем разница между веб-приложением и обычным приложением.
Веб-приложение — это в 99% случаев морда до определенного бэкэнда, которая должна БЫСТРО загружаться, и предоставлять определенную информацию или интерфейс. Она может в любой момент закрыться, должна быстро перезапускаться и хорошо кэшироваться.
С нативными приложениями никому и в голову не придет тягаться, тут слишком разный класс задач.
Даже если говорить про игры: казуалки лучше пойдут в браузере (быстрая загрузка, интеграция с соцсетями), а тяжеловесов в веб нельзя: если кэш случайно потрется, вы будете опять выкачивать 25гб unreal tournament 2015 по мобильному интернету?
Ну и плюс самому не закрываться, но это уже сложнее.
«Профессионализм» видимо выражается в возможности снятия сырого, не предусиленного звука.
как-то по душе еще
Это будет свойство, не более. Метод класса не будет далее наследоваться, то есть
И внимательно перечитайте, что я написал. Переназначить, не просто назначить. Приведу пример, который у меня был. Решил через событийную модель.
Вы, видимо, не работали либо с ООП, либо с классами в es6, раз так радостно это утверждаете.
Да и не все в жс объекты. 4 instanceof Object === false. Да даже 4 instanceof Number === false.
Давайте я скажу вам факт, после которого ООПсрач можно закрыть будет? Если нет желания срача ради срача.
ООП в жс есть. Но оно канонично использовалось для механизмов работы DOM, глубоко интегрированных в реализации языка, сам подход в ЖС всегда был преимущественно функциональным, то, что создаются методы — это необходимый сахар из-за невозможности делать оверлоад функций.
Без ООП пришлось бы для каждого типа ноды назначать свои методы, потому что не было бы цепочки HTMLAudioElement -> HTMLMediaElement -> HTMLElement -> Node -> EventEmitter -> Object (могу путать точный порядок).
-нельзя создать методы или свойства класса (ну, статические)
-нельзя переназначить только геттер или сеттер метода (нужно повторно назначать оба)
и так далее
А вам честно удобно с таким шрифтом жить?
Начали про ангуляр, продолжили про жквери, закончили gulp-concat.
И да, есть модуль gulp-browserify, который еще и сурсмапы делает.
А что, разве библиотеки есть только в JS?
Ну окей, и что дальше? Для интерфейсов есть куча библиотек. Есть даже Objective-J, который позволяет макось-разработчикам писать по ощущениям натурально нативные приложения.
asm.js по перформансу приближается к приложениям на c++ (полгода назад был всего в 2 раза медленнее). В него можно скомпилировать любой llvm-код (это уже про то, что библиотеки скудны и их мало).
я могу докопаться до половины фраз, просто по-моему вы не до конца понимаете, в чем разница между веб-приложением и обычным приложением.
Веб-приложение — это в 99% случаев морда до определенного бэкэнда, которая должна БЫСТРО загружаться, и предоставлять определенную информацию или интерфейс. Она может в любой момент закрыться, должна быстро перезапускаться и хорошо кэшироваться.
С нативными приложениями никому и в голову не придет тягаться, тут слишком разный класс задач.
Даже если говорить про игры: казуалки лучше пойдут в браузере (быстрая загрузка, интеграция с соцсетями), а тяжеловесов в веб нельзя: если кэш случайно потрется, вы будете опять выкачивать 25гб unreal tournament 2015 по мобильному интернету?
github.com/visionmedia/co