JavaScript *

Chromium Embedded Framework (CEF) — это проект с открытыми исходными кодами, созданный в 2008 году как элемент управления Web browser, работающий на базе Chromium от Google.
На данный момент это довольно мощный инструмент для разработки настольных приложений, со списком решений, использующих этот контрол можно ознакомиться здесь. Но достаточно сказать, что его используют такие широко известные продукты, как Evernote и Steam.

Итак, что же дает этот фреймворк?

Приветствую, жители Хабра'полиса!

При разработке веб-интерфейсов, зачастую есть необходимость в использовании всплывающих (модальных) popup-окон или вывода сообщений. Поисковики в топе выводят давно уже приевшиеся плагины а-ля «Colorbox». Ничего плохого о нем не скажу — но довольно часто встречается и глазам как-то поднадоело что-ли.



Душа желает чего-то нового и универсального, подходящего под любой дизайн интерфейса.
По-этому хочу представить jQuery плагин вывода сообщений в виде всплывающего окна, название которого немало известно в футбольном мире — «Messi» (MESsage SImple). И так, начнем…

Сколько же существует всяких языков программирования, еще один? Ну можно и так сказать, а можно сказать и по другому: я программист и пишу программы на разных языках программирования для разных задач. В одних языках есть одни плюсы, в других — другие. Вот я и решил предложить свой универсальный язык программирования для множества задач.

ObjectScript — новый объектно-ориентированный язык программирования с открытым исходным кодом. Сами исходники занимают 459 Кб (парсер, компилятор и виртуальная машина) и находятся в двух файлах source\objectscript.h и source\objectscript.cpp. Скачать их можно по прямой ссылке тут. ObjectScript — очень легкий, предназначен для вставки в приложение на C++.

ObjectScript сочетает в себе возможности таких языков, как JavaScript, Lua и PHP. Например, синтаксис в основном взят из JavaScript, множественное присваивание — из Lua, работа со свойствами через перегружаемые методы — из PHP.

Кроме унификации нескольких существующих языков программирования, ObjectScript добавляет также и свои уникальные и полезные фишки.

В данной статье я расскажу о новинках в DOM API, которые мы можем использовать уже сейчас или в ближайшем будущем.
Публикация статьи приурочена к радостному событию начала реализации некоторых новых DOM4 API методов в Google Chrome. Многие методы и свойства можно использовать уже сейчас, некоторые из них работают через префиксы, но к каждому методу или свойству я постараюсь дать Polyfill, реализующий их или отбрасывающий браузерные префиксы.
Методы я постарался описать в соответствии с JSDoc для Google Closure Compiler.

* это перевод статьи с DailyJS

Введение

LispyScript — древовидный язык программирования, который компилируется в JavaScript. Собственно говоря, это что-то между JavaScript и Lisp.
Скрипт на Lispy состоит из подобных выражений:

(<function> arg1 arg2 arg3 ...)

Хочу поделиться набором ссылок на нексолько полезных, интересных и, возможно, не самых известных материалов по JavaScript. Из них вы узнаете немного больше об истории появления языка, о его настоящем, тонкостях реализации в различных браузерах, и о будущем развития стандарта ECMAScript. О различных способах наследования в том числе об эмуляции «классического» ООП, множественном наследовании и миксинах. О функциональном стиле программирования в JavaScript: чистые функции, map, reduce, частичное применение и композиции функций. И, наконец, что если бы Хемингуэй писал на JavaScript?

Привет всем!



Сразу ссылка для нетерпеливых: http://bit.ly/habrauser

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

Под катом же немного подробностей для интересующихся.

От переводчика: Представляю вашему вниманию перевод многообещающего стандарта Веб-компонентов от Google, который может стать трендом в ближайшие несколько лет. В данный момент, знание этого стандарта не несёт практического применения, поэтому, если вы не фанат всего нового и интересного, вам возможно будет скучно читать данный перевод.
Перевод выложен на github, поэтому, если вы хотите помочь с переводом или исправить ошибку сделайте pull request, ну или пишите в личку.

Статус: Эксперементальный драфт

Авторы:

• Dominic Cooney, Google, dominicc@google.com
  
• Dimitri Glazkov, Google, dglazkov@chromium.org
  

Введение

Компонентная модель для Web'а (или Web Components) состоит из четырёх модулей, которые, будучи использованными вместе, позволят разработчикам web-приложений создавать виджеты с богатыми визуальными возможностями, легкие в разработке и повторном использовании, что в данный момент невозможно с использованием только CSS и JS-библиотек.

Статья посвящена Java девелоперам, которых жизнь заставила или пока только заставляет двигаться вперед, к светлому agile будущему. Препологается, что читатель знаком с Java, Javascript и слышал про JSR 223.

Постепенно концепция стандарта HTML5 становиться реальностью. Браузеры начинают поддерживать новые возможности, которых так не хватало. Но с новыми возможностями появляются и новые проблемы.
В данной статье рассматривается Application Cache API — совокупность функций, обеспечивающих продвинутое кэширование ресурсов web-приложения, и с помощью которых можно просматривать загруженные ранее сайты без подключения к сети Интернет. Особое внимание я уделил практическому использованию и проблемам Application Cache.

SlickGrid – небольшой javascript-компонент для отображения таблиц. Отличительной чертой этого компонента является концентрация на порядке отображения информации, а не на работе с ее (информации) источником. Другой отличительной чертой SlickGrid является весьма скудная документация, в том числе описание того, что касается работы через AJAX.

Основная идея

В процессе изучения способов многопоточной обработки изображений в браузере многие сталкиваются с проблемой отображения результата Web Workers в canvas. В основном это происходит из-за того, что в web worker нельзя передать элементы DOM. Решением может быть использование getImageData(). Данная статья описывает конкретный пример использования данной технологии на примере обработки фильтра blur в отдельном потоке.

Для этого нам понадобится 2 файла: index.html и filter_worker.js

Callback-функции чрезвычайно важны в языке Javascript. Они есть практически повсюду. Но, несмотря на имеющийся опыт программирования на C/Java, с ними у меня возникли трудности (как и с самой идеей асинхронного программирования), и я решил в этом разобраться. Странно, но я не смог найти в интернете хороших вводных статей о callback-функциях — в основном попадались отрывки документации по функциям call() и apply() или короткие кусочки кода, демонстрирующие их использование, и вот, набив шишек в поисках истины, я решил написать введение в callback-функции самостоятельно.

Начну издалека. С браузеров. Новинками браузеростроения интересуюсь не так уж и часто, но вот однажды, со скуки, решил посмотреть, что javascript грядущий нам готовит и что с этого нам могут предложить современные браузеры. Речь идет, само собой, не о ECMAScript 5, а уже о ECMAScript 6 ECMAScript Harmony. Через пару минут серфинга я наткнулся на такую вот сводную табличку. Не самая актуальная — Chrome, например, довольно давно поддерживает Proxy. Само собой, разброд оказался еще тот. В браузере это использовать пока не реально.
В браузере. А на сервере? На сервере нет необходимости поддерживать зоопарк различных браузеров. Node.js использует V8 — тот же javascript движок, что и Chrome, соответственно, он должен поддерживать те же новые возможности языка.

Начну с того, что метод jQuery.each я всегда использую только для работы с jQuery object. В остальном — циклы for / while или свой аналог «each». Вроде это и логично, но в документации говорится о том, что вышеупомянутый метод можно использовать для любых коллекций.
Разрушим этот миф.

ECT — это логическое развитие существующих подходов к шаблонизации под соусом высокой производительности. В начале года я публиковал свою разработку — шаблонизатор JUST. ECT начинался как его развитие, но через некоторое время различие в них стало слишком большим, поэтому появился новый продукт.

Синтаксис

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

Логичным решением в данной ситуации стало использование CoffeeScript в качестве встраиваемого языка.

Вступление

Люди всегда стремились систематизировать музыку, разбивая её на жанры и поджанры. Основным методом такой систематизации был и остаётся «исторический» метод, который можно описать так:
Есть исполнитель K, который играет музыку похожую на жанр L, но явно в этот жанр не вписывающуюся. Сам исполнитель или муз. критик, лейбл придумывают для такой музыки новый под жанр, жанра L – LL. И через R лет жанр LL становится каноническим. Или не становится, в зависимости от результатов «проверки временем». Таким образом, все музыкальные жанры можно соединить в граф, в котором жанр L ближе к корню, а LL – к листьям.

Этот метод является историческим, так как поджанры всегда появлялись позже основных жанров. Т.е. этот способ иллюстрирует развитие музыки, её эволюцию. Но такой граф не совсем корректно иллюстрирует связи жанров друг с другом, с плоской музыкальной точки зрения. Т.е. из двух совершенно разных музыкальных направлений, разных эпох могут появиться поджанры которые будут настолько близки, что значительное число музыкантов будут в качестве своей “лейбы” указывать оба жанра. Но в “историческом” графе они вряд ли будут рядом.
К тому же из-за высокой степени субъективности и сложности исторического метода, не существует “единого дерева жанров”. Насколько я осведомлён, существуют лишь отдельные успешные попытки построить такой граф на уровне отдельных групп близких жанров.

Сегодня в корпоративном блоге Mozilla появилась запись одного из ключевых разработчиков Firefox Девида Андерсона (David Anderson) о том, что фонд заканчивает разработку нового движка для JavaScript под кодовым наименованием IonMonkey. Широкий круг пользователей сможет отметить повышение быстродействия браузера на страницах сложных веб-приложений уже с выходом Firefox 18, бета-версия которого будет выпущена 20 ноября.

Работа IonMonkey будет состоять из трёх фаз и выглядеть следующим образом: сначала будет выполняться трансляция в промежуточное представление (intermediate representation (IR)), к полученному результату будут применяться различные алгоритмы по оптимизации и уже после этого этот IR будет транслироваться непосредственно в машинный код.

Здравствуйте, я разработчик игр на Flash. Последнее время все больше стало появляться постов про флешокапец, и MustHave JavaScript (дальше JS). Вроде как за JS будущие, и за открытым вебом.
Я долго не рассматривал JS всерьез как платформу для разработки игр. Ведь это интерпретированный язык, и скорость JS оставляет желать лучшего. Но совсем недавно был портирован на JS мой любимый фреймворк для анимации TweenLite. Вместе с этим автор создал тестовый пример показывающий производительность актуальных JS фреймворков: здесь.

Мне стало очень интересно, так как TweenLite JS выдавал неплохие FPS. И тут я решил написать такой же пример для сравнения Flash и JS фреймворков.
Дальше мне стало интересно сравнить FPS этих примеров в разных браузерах, и на разных ОС.
Сам тест — это анимация передвижения, и изменения размеров картинок, при чем можно изменять их количество. Тестовый пример для Flash лежит здесь, исходники примера здесь.

Однажды, при разработке сложного приложения на JavaScript-е возникла непреодолимая проблема — большой массив в Internet Explorer (далее IE). Так как я изначально проверял работу в Chrome, то не замечал каких-либо проблем при использовании массивов. Скажу больше — вложенные массивы не вызывали чувства страха. Chrome легко справлялся с трудными задачами. Однако IE, в очень жёсткой форме, указал на все мои огрехи и недостатки кода, особенно на обработку Больших массивов.