Posts

Showing posts with the label clientjs

Communicating between Web Workers via MessageChannel

Occasionally, you want Web Workers to communicate with each other. Doing so is not obvious as most Web Worker examples are about communicating between the main thread and a Web Worker. There, one uses postMessage() to send messages directly to the Worker. Alas, that doesn’t work for communicating between two Workers, because you can’t pass references to Workers around. MessageChannel The solution is to establish a channel between the Workers: const channel = new MessageChannel(); receivingWorker.postMessage({port: channel.port1}, [channel.port1]); sendingWorker.postMessage({port: channel.port2}, [channel.port2]); We are creating a new MessageChannel and sending references to its two ports to two Workers. Every port can both send and receive messages. Note the second parameter of postMessage() : It specifies that channel.port1 and channel.port2 should be transfered (not copied) to the Workers. We can do that because MessagePort implements the interface Transferable . Po...

What happened to Web Components?

Three years ago, there was a lot of excitement surrounding Web Components: everybody talked about them, the frameworks Ember and Angular planned to integrate them or even be based on them, etc. By now, that excitement seems to have died down. This blog post examines what happened to Web Components. Spoiler: they are alive and well and slowly being adopted across browsers. Refresher: Web Components Web Components are a suite of specifications that help with implementing custom HTML elements: Custom elements: an API for registering your own implementations for HTML elements. Shadow DOM: Encapsulates and hides the innards of a custom element inside a nested document. The most important part of Web Components and hardest to polyfill. Templates: enable you to store HTML data inside an HTML document. The content of a <template> element is parsed without interpreting it (no loading of images etc.). HTML Imports: let you import other HTML documents into the current one. That way, HTML d...

New frontend framework “Aurelia”: Web Components, 6to5, jspm, MVVM

Aurelia is a new framework by Durandal creator Rob Eisenberg (which helps credibility-wise). It uses an interesting combination of technologies/techniques: Web Components: as an infrastructure for widgets (polyfilled where necessary) 6to5 : to compile ECMAScript 6 to ECMAScript 5 jspm : for package management MVVM (as used by Knockout and the Knockout-inspired Durandal): as a UI pattern jspm is currently based on Traceur, support for 6to5 is work in progress . Quoting Eisenberg on how Aurelia combines 6to5 and jspm: There is work on system.js currently to decouple it from traceur and allow the use of 6to5 instead. Note that it only loads traceur if you are feeding it actual es6 code that hasn’t been transpiled. Since aurelia is transpiled and the skeleton is set up to use 6to5…system.js actually never loads traceur and it never comes into play. I haven’t used Aurelia, yet. Opinions welcome.

The roles of AngularJS and Polymer

A key feature of AngularJS 2.0 is its support for Web Components [1] . Google’s Polymer is a Web Component polyfill (enabling them on all current browsers) and a framework on top of Web Components. This blog post describes how the Angular team sees the roles of AngularJS and Polymer. The roles, according to the AngularJS team AngularJS 2.0 team member Rob Eisenberg recently explained the relationship between AngularJS and Polymer: “Angular is really designed around optimizing application development (including DI, routing, templating and decorator directives, more advanced databinding)” “while Polymer is really optimized around custom element development. So, it has basic templating and binding and a strong component model.” Therefore, Eisenberg expects people to implement cross-framework UI components either as pure Web Components or via Polymer. He thinks apps and app-specific components are more likely to be built in Angular. Are Polymer and AngularJS competing? Yes and no At Goo...

Three Google I/O videos about Web Components and Polymer

Image
The videos of the Google I/O 2014 talks have been online for a while now. Three of them are about Web Components and Polymer. This blog post briefly describes what they are about and mentions a few highlights, which may help you to decide which videos you want to watch. The three talks are: “ Polymer and the Web Components revolution ” by Matt McNulty (38:47) “ Polymer and Web Components change everything you know about Web development ” by Eric Bidelman (36:13) “ Unlock the next era of UI development with Polymer ” by Rob Dodson (41:30) If you need a quick primer to Web Components, you can look at slide 35ff of the slides for my talk “ Six technologies that will change the web platform ”. Polymer and the Web Components revolution Matt McNulty gives a broad overview of Web Components and Polymer, setting the stage for the remaining two talks. McNulty explains why Web Components are important, then describes Polymer , which is a Web Components polyfill plus a convenience layer on top. ...

Installing web apps natively

Web apps have been around for a while, but the ability to install them as if they were native apps is relatively new. This blog post takes a look at what’s currently possible. Delivering and publishing installable web apps Web apps are called installable if they can be installed natively. Such apps are currently delivered in either one of two formats: Hosted: the app is delivered as a collection of assets (HTML, CSS, JavaScript, etc.), hosted individually on a web server. Two associated files provide important meta-data: App manifest: specifies information such as: the app’s name; links to icons; the path of the HTML file that is the entry into the app; etc. Cache manifest: enumerates the assets of an app, enabling engines to download all of them and run the app offline. Packaged: the app is delivered as an archive that contains all of its assets. The archive still contains an app manifest, but doesn’t need a cache manifest. In order to publish a web app, to put it online, two opti...

Meet the site of the Web Components community

Image
The Web Components community has a new site: WebComponents.org . Quoting Addy Osmani : WebComponents.org is the home for the community to learn and discuss Web Components. The site had previously been soft-launched at webcomponents.github.io and is now online at the final URL. It’s good to have a single site with a simple URL where one can look up information related to this important technology. The site’s twitter account is @Web_Components . WebComponents.org features icons for the Web Components sub-standards (Shadow DOM etc.), which can be downloaded in various formats at a repository on GitHub. Previously, the best location with Web Components resources was a page by Eric Bidelman. I’m hoping that this page will be merged into WebComponents.org.

Identifying the current <script> element

Guest blog post by Rodney Rehm You may find yourself in a situation requiring you to know the DOM context of the JavaScript that is currently executing. The DOM context of a running JavaScript is the <script> element that caused the JavaScript to be executed in the first place. With HTML5 the WhatWG introduced document.currentScript , which this article will use to explain simple techniques to make use of DOM context. What do I need the currentScript context for? The script you’re running may be in need of parameterization. It requires some sort of configuration, some data so it can do its job properly. Developers who’ve used RequireJS haven seen this before: <script src="scripts/require.js" data-main="js/main"></script> That’s a shorthand way of doing the following in JavaScript: <script src="scripts/require.js"></script> <script> require.config({ baseUrl: 'js/', deps: ['...

Web platform: five technologies to look forward to in 2014

This blog post describes five technologies that will make 2014 an exciting year for the web platform: asm.js: near-native performance on the web ParallelJS: parallelized JavaScript code ECMAScript 6 (ES6): evolving the language, uniting the community Web Components: a standard infrastructure for widgets CSS Grid Layout: native-like GUI layout asm.js: near-native performance on the web What it is: a subset of JavaScript that runs fast on current engines (about 70% of compiled C++ code, at the moment). Why it is exciting: Near-native speed in web browsers. Tightly integrated with JavaScript. Already compatible with all existing JavaScript engines. An engine optimizing asm.js code takes more work, but can be implemented incrementally. More information: “ asm.js: closing the gap between JavaScript and native ” ParallelJS: parallelized JavaScript code What it is: This project was born under the name “River Trail” and parallelizes JavaScript code that uses ...

Printing Markdown files on GitHub

GitHub displays Markdown files so nicely, it’s a shame there is no print view where all the toolbars etc. are hidden. Note that printing doesn’t necessarily mean that paper is involved. For example, on Mac OS X, you can print to PDF files. This blog post explains three ways of printing Markdown files that are hosted on GitHub: Markdown tools: such as kramdown can be used to turn Markdown files into HTML files that can be printed. Safari’s Reader mode [1] : With many pages, Safari displays a “Reader” button in the address bar. Clicking it usually removes all clutter around content. You can print a page in Reader mode. Disadvantage of this solution (especially compared to the next one): You lose most of the syntax highlighting of source code. Bookmarklet [2] : Create a bookmark with the following URL, click it and everything around the content is removed. javascript:var content = document. querySelector('article'); var body = document.quer...

Why are there so many array-like objects in the DOM?

Tweet by Leon Arnott: #TIL the reason the DOM has so many "array-like objects" that aren't functional arrays… is because in Javascript 1.0, there were no arrays. Explanation: ECMAScript 1 does have arrays, but it corresponds to JavaScript 1.3. JavaScript version numbers apply to the JavaScript engines implemented by Netscape/Mozilla. The cross-engine way of referring to the capabilities of the language are thus ECMAScript versions. Arrays were indeed added after JavaScript 1, as this page shows, which lists the additions for version 1.1. More information on array-like objects and arrays: JavaScript quirk 8: array-like objects Arrays in JavaScript

ECMAScript 6 modules in future browsers

Update 2013-11-22: David Herman has published the slide deck “ Status Report: ES6 Modules ”. [1] is an introduction to ECMAScript 6 modules and how they can be used in current browsers. In contrast, this blog post explains how future browsers will support them natively. As part of that support, we will get the <module> tag, a better version of the <script> tag. Browsers: asynchronous modules, synchronous scripts Modules. To be in line with JavaScript’s usual run-to-completion semantics, the body of a module must be executed without interruption. That leaves two options for importing modules: Load modules synchronously, while the body is executed. That is what Node.js does. Load all modules asynchronously, before the body is executed. That is how AMD modules are handled. It is the only option for browsers, because modules are loaded over the internet. Otherwise, execution would pause for too long. As an added benefit, this approach allows one to load multipl...

The JavaScript console API

In most JavaScript engines, there is a global object console with methods for logging and debugging. That object is not part of the language proper, but has become a de facto standard, since being pioneered by the Firebug debugger. Since their main purpose is debugging, the console methods will most frequently be used during development and rarely in deployed code. This blog post gives an overview of the methods of console . How standardized is the console API across browsers? Firebug first provided the console API and the documentation in its wiki is the closest thing to a standard there is. Additionally, Brian Kardell and Paul Irish are working on a specification for the API, which should lead to more consistent behavior across browsers in the long term. Until then, behavior varies widely. Therefore, this blog post can only provide an overview. For details, you should consult the following documentation for various platforms: Chrome: developers.google.com/chrome-developer-too...

Triggering events in vanilla JavaScript

So you want to trigger an event for a DOM element, without using jQuery? This blog post gives you a quick recipe for doing so. The running example is about sending a submit event to a form. I needed to do that for a demo of user interface testing via CasperJS . And, unfortunately, the Form#submit method does not send that event on most web engines. The recipe Steps: Look up the constructor of the event, via a table on MDN that maps event names to event constructors. Example: submit events are created via the Event constructor. Look up the arguments of the event constructor, via the drafts of the specifications for DOM4 and UI Events . Example: The constructor for interface Event has the following Interface Definition Language (IDL) signature: Constructor(DOMString type, optional EventInit eventInitDict) Optionally, EventInit can be passed in as an object and configures whether an event bubbles or is cancel...

Jed – a JavaScript internationalization toolkit

Internationalization is still a tricky problem: we are still figuring out how to encode text properly, let alone store content in a manner that lets us translate it easily. In contrast, in other areas of web development, tools and technologies are in place so that even non-technical users can be productive. One example is content authoring – you don’t have to know how to write HTML or how to set up a server in order to publish a blog. The Jed internationalization toolkit Alex Sexton describes the goals for his Jed Toolkit as follows: The process of getting an app translated is cumbersome, and is a blocker to getting good applications out there. FTP zips and crazy XML specs mixed with Word Documents rule the landscape. There are no decent apis, or automatic integrations that anybody is using at scale. I want to set out to change this. The Jed Toolkit has been accepted into the Dojo Foundation (which, apart from the obvious Dojo Toolkit, hosts many projects, e.g. RequireJS and Siz...

A proposal for using Canvas in web workers

Ian Hickson, editor of the HTML spec, has proposed a way to let web workers use Canvas. In the browser, all “normal” work happens in a single thread. That means that the user interface and computing tasks are competing for processor time. Thus, if you don’t want to block the user interface, you perform computationally intensive tasks in a background thread, via web workers (see section below ). Creating bitmap graphics is a common activity on the web and a candidate for being done in the background. The easiest solution would be to make Canvas (HTML element and bitmap API), available to workers. But that is not possible, because they don’t have access to the DOM and Canvas cannot exist independently of it. Quoting Ian Hickson : I was faced with two options: Option A: Provide an API for off-screen graphics in workers, requiring that every frame you package the whole thing up, send it over to the main thread, and blt it there. Option B: Provide a mechanism by which a worker ...