Subscribe: Tagneto
http://www.blogger.com/feeds/19002723/posts/default
Added By: Feedage Forager Feedage Grade B rated
Language: English
Tags:
amd  api  app  apps  code  github  loader  module  modules  new  node  release  requirejs  volo  web apps  web  work 
Rate this Feed
Rate this feedRate this feedRate this feedRate this feedRate this feed
Rate this feed 1 starRate this feed 2 starRate this feed 3 starRate this feed 4 starRate this feed 5 star

Comments (0)

Feed Details and Statistics Feed Statistics
Preview: Tagneto

Tagneto



Notes on JavaScript, RequireJS, and Mozilla Labs.



Updated: 2018-03-05T16:53:20.005-08:00

 



Moving to a new blog

2012-09-05T16:23:12.795-07:00

Any new posts I do will be at jrburke.com. There is a post over there about the new blog.

I will keep this blog for historical purposes, but any new posts will be at the new location.




volo 0.2.3: semver and a web site

2012-08-29T20:15:05.297-07:00

volo, a command line tool to create web projects, add front end dependencies and automate tasks, is now at 0.2.3. Get it via npm:

    npm install -g volo

The complete set of changes are here. The notable ones:

1. semver ranges can be used with dependencies now. For example:

    volo add requirejs/~2 

will download the latest 2.x version of jrburke/requirejs from GitHub.

2. volo add mentions possible incompatibilities after doing a nested dependency install, and gives commands for manually choosing one of the other versions.

3. volo now has a simple web site that hopefully gives a better idea intro to volo. Many thanks go to James Long for starting the structure and helping to refine its message. There is more to do for the site, but it is already much better than what was there before.



RequireJS 2.0.6 released

2012-08-18T21:46:41.023-07:00

RequireJS 2.0.6 is available.

The main focus of this release was cleaning up some rough edges in the r optimizer after switching to esprima for all module parsing/tracing. Most notably, the findNestedDependencies build option should work correctly again. The bundled UglifyJS was updated to 1.3.3 too.

Complete list of fixes:



RequireJS 2.0.5 released

2012-08-08T16:14:33.678-07:00

RequireJS 2.0.5 is available, along with almond 0.1.2 that matches the 2.0.5 behavior.

The most notable changes:
Complete listing of:





On client components for web apps

2012-07-25T14:34:42.394-07:00

This is a response to a blog post by TJ Holowaychuk about browser-based components for web applications, and Isaac's notes on TJ's post.I am going to try to make this brief because I get tired of people in the Node community wanting to apply the same patterns from Node in the browser. I feel like I say these things on a periodic basis, but human communication is hard, and I certainly could do better. But I also want to get back to just making things. So this will be terser than I normally would like.Web componentsI suggest TJ look at volo, my attempt in this space. It does lots of what he describes already, and it can even be used as a module in another command line tool. We use volo for some things in Mozilla already.volo uses GitHub as the component registry. It does so without the downsides that TJ mentions.Specifically, volo uses the GitHub HTTP API to get version tags, do registry searches. I grabs .zip snapshots for a given version/github commit/branch, so the command line tool (the consumer) does not need use git. Git is not necessary on the client side.This means the downloaded code is smaller -- no need to get a full repo and all of its commits.volo also understands dependencies via the shorter "owner/repo/tag" IDs instead of the full github URLs.It has a "shim" repo that means it can support installing components without needing the author of the component to conform to some new publishing system. Since it allows {version} replacement in URLs, the registry setup just needs to be done once. From then on, normal best-practice versioning via git tags is enough.Some other notes in this post.Base module formatNode bros, the AMD trolling is getting tiresome. Node's module system is woefully under-specified for web-based loading. While you can limp along with browserify, there are still these issues:* For builds you need a wrapped format. For CDN deployment you need a wrapped format. browserify uses a wrapped format. AMD anyone? For that reason alone, AMD will never go away. Get used to it already.* Web code needs a callback-style require for on-demand loading.* Browserify's uses of file paths for IDs is awful for mixed local and CDN-based loading. Module IDs need to stay in ID format, not translated to a specific file path.* Loader plugins reduce the need for callback-style APIs, and callback pyramid of doom, or inside-out callback hell, or the need for promise based programs. This more than makes up for the extra level of indent in AMD.Loader plugins solve the translation issues TJ talks about, and they can participate in optimization builds, meaning templating engines can inline the JS function form of the template. Ditto for language transpilers like CoffeeScript.By doing this:define(function (require) {    //node module code in here.    //Return module value instead     //of needing `module.exports`});you have an AMD module.Quit dismissing AMD for surface issues. AMD avoids mandating translation layers that lead to more things for the developer to understand and fix, and more process for the user to go through to deploy code. It is a net win when the source file works when deployed anywhere, without requiring specialized builds/converters.Even if you want to personally use Node style and always do builds before loading in the browser, AMD is a great target for the built, wrapped format. You can even use the requirejs optimizer to do this, with the cjsTranslate option.The universal module boilerplate gets simpler when Node supports AMD's define along with Node's existing module format. If you want to help improve the ugliness, start there.AMD comes from real world exprience in Dojo with trying to deploy an unwrapped module format that depended on XHR+eval in dev and a wrapped format for builds. Yes, you can something to to work but the second order translation and support costs are not worth it. Some environments disallow eval. CORS configuration is awkward, and[...]



RequireJS 2.0.4 released

2012-07-09T18:44:26.168-07:00

 RequireJS 2.0.4 is available.
 
And hot on the heels of 2.0.3, there is a 2.0.4 release! Unfortunately a bug with a fix that was in 2.0.3 caused a different bug, and it was not found until after the 2.0.3 release. It made the optimizer unusable in certain situations, so the change was rolled back and 2.0.4 is out, with the only change over 2.0.3 being the rollback of that previous change.


I apologize for the extra noise.




RequireJS 2.0.3 released

2012-07-09T17:41:37.850-07:00

 RequireJS 2.0.3 is available.

Just a maintenance bug fix release. Most notable changes are probably:
  • optimizer now does not fully resolve "paths" until all config sources (mainConfigFile, build profile and comand line args) have been merged.
  • a fix for data-main resolution for require.
Full list of fixed bugs:





volo 0.2.2 released

2012-07-07T00:13:37.457-07:00

volo 0.2.2, a JS package manager and project automator, has been released. To install/update:

npm install -g volo

Here is a list of changes. Probably the most notable one:

volo create will run npm if there is a package.json in the downloaded project template with a dependencies property, and if there is not an existing node_modules directory.

This makes it easier to share volo commands between projects and their volofiles.

Example: the create-responsive-template now uses these separate volo commands in its volofile:
  • appcache: generates an appcache manifest for a project.
  • ghdeploy: deploys a directory of code to github pages.









Comments on Isaac's ES modules post

2012-06-26T12:11:01.300-07:00

Isaac Schlueter posted some thoughts on the ES modules proposal. He works on Node and NPM, so it is great to see things from his perspective vs. my browser-based perspective.I believe his post an my previous ES modules post fit together well. Here is some feedback on Isaac's post to point out where we align and what may still need more discussion. Section titles and numbered points below match the ones in Isaac's post.Problems with the Current Spec1. It seems to be based on the assumption that nesting module systems is a thing that people want.As Isaac says, "no one wants to write a module system". Agreed. The default behavior of a built in loader should be enough for most, nearly all people. Others can build their own systems with existing tech, and if they catch on, consider them later.I prefer to have support for loader plugins that have a constrained API. I'm not sure how that fits with Isaac's view. My previous post outlines uses cases where AMD folks have found them useful, and they help reduce the "pyramid of doom" of callbacks for resources that are important for a module to do its work, and therefore reduces the complexity of the module's external API. If Isaac has a different way to solve those issues, it would be good to know.2. It puts too many things in JavaScript (as either API or syntax) which belong in the host (browser/node).I think Isaac means that the browser implements a default Loader.resolve(), and Node does its own thing, but the language does not have a built default.I think there is value in using the browser model as the default language one, with Node having the ability to override as it sees fit. The browser model of single file IO lookup based on a declarative config can work in "everything is available locally" model.But for me this is a small distinction. I do not relish trying to convince a separate standards body that is even more unwieldy than es-discuss to code the default browser resolver, but if that is how it must go, so be it.My main desire: the front end developer should not have to ship a library file to do imperative configuration of a loader.3. It borrows syntax from Python that many Python users do not even recommend using.Agreed. I would not include import * if it were just up to me. The "evaluate dependencies first before evaluating the current module" means that just normal let/var destructuring could be used, no more need for import at all. All that is needed is a way to call out a dependency either via a keyword like "from" or via an API like "from()" or "require()". Or reusing "import" to be simpler, as Isaac does later in the post.4. It favors the “object bag of exported members” approach, rather than the “single user-defined export” approach.I too prefer a way to set the exported value (return in AMD parlance, module.exports = in Node).  There needs to be a way to allow just the "exports" property assignment for circular dependencies, but for everything else (the vast majority of modules) assignment is nice.I believe that exports approach in the ES design was chosen so that they can do the type checking of export values, supports circular dependencies, and with destructuring, it was argued that it was more palatable for getting the export value with this model:import {jQuery} from 'jquery';Not my favorite, but I could live with it.The "middle way" evaluation approach would support module value assignment.A Simpler Proposal1. A Loader built-in object, with a few methods that must be specified before modules can be used.See feedback above. If a front end developer needs to ship a JS library to bootstrap the Loader, that is a failure condition for me.I can understand exposing a Loader API so that for example someone could make an AMD API shim, but the ideal, future case should be no need for imperative setup. Simple decl[...]



ES Modules: suggestions for improvement

2012-06-25T21:17:21.599-07:00

There has been a recent bout of comments about ECMAScript (ES) harmony modules on twitter and elsewhere. Here is my attempt to explain parts of it, some of the design tradeoffs, and perhaps a middle ground that would open up some options that may bridge some gaps.Modules are one of those things that seem very simple, but involve quite a lot of decisions and tradeoffs. This post is mostly just about module linking and module ID resolution, and even with that, it is quite long.If ES Modules do not come up with different ways to work (or maybe explain where I have it wrong), they are not competing well with what can be done with a combination of CommonJS/Node and AMD.My background: I work on RequireJS and AMD.What is itFirst, some links to the specs. The "harmony" moniker means it is in process for the next version of the ECMAScript (JavaScript) language:Harmony Modules: The basic module spec.Harmony Module Loaders: Specifies how you can create isolated loaders for modules. Very useful.The module examples page is suggested if you want to get a feel for it, but it is good to read the other docs too. It can be a bit daunting though, unless you speak the spec language.Points of referenceOne way to evaluate how ES Modules works is to compare it to something you may already know:CommonJS / Node. Node implements a version of the CommonJS module API.AMD / RequireJS. RequireJS implements the AMD module API.Run time vs compile timeES is a "compile time" approach where the formats mentioned above are "run time" approaches. Maybe not precise terms, but here is a definition of what is meant by those terms for the purposes of this post:"Compile time" means:JS text is parsed, and the "module" "import", and "export" syntax is found.Any dependencies are fetched and parsed.Once the dependency tree has been all fetched, the ES module loader will wire up the exports from a dependency to a module's "module" or "import" use, and do type checking on that export type and how it is referenced in the moduleThe module code is then evaluated/executed."Run time" means: there is usually no pre-parse stage. The JS text is evaluated, and any module API that is encountered is run as it is encountered.AMD will actually do a small parse step if the module looks like:define(function (require) {    var a = require('a');});In that case, it will parse the function to look for require() dependencies, and then load and execute the dependencies first before running the function above."Compile time" was chosen for ES because:it is familiar from other scripting languagessets the way for other possible static features, like macrosensures that "import *" are static, *not* dynamic bindingsallows some type checking on the values that are explicitly "export"ed.generally seen as safer and easier to reason about that run time.The CommonJS/Node style of pure runtime, no parse, was hard to get to work with some edge cases as I understand it, but I heard that second-hand, I did not see that discussion.Impact of compile timeFor compile time to work well, it should use new keywords in the language, to have clear markers on what is participating in the module system.Although, it could work with a module API instead of new syntax, by only recognizing literal use of that API, and do not support variable assignment of the API or dependencies to other names. This is what AMD does for the "sugared CommonJS form" mentioned above.For "import *", static binding is critical because anything that is a runtime scope lookup gets into "with" territory, and "with" has been seen as a mistake by the committee. ES5's 'use strict' bars its use.Since new syntax is involved, ES Modules cannot be "shimmed" into existing JS libraries. There is a Module Loader "runtime" registration call that can used for a mod[...]



volo 0.2.1 released, using volo as a library

2012-06-20T23:26:18.181-07:00

volo 0.2.1 has been released. This is a bug fix release, if you are using 0.2.0, you are encouraged to upgrade. Here is the list of fixes. To install:

    npm install -g volo

Also new: the ghvolo project. It shows how to use volo as a library to just resolve dependency IDs to github-hosted resources. This is useful if you are building a command line interface for fetching front end dependencies and you want to use the same github resolution logic as volo, but without using volo to do the actual installation of dependencies.

ghvolo is a command line tool that supports "search" and "resolve". Nothing is installed by using ghvolo. It just uses volo as library to resolve IDs to some JSON data. See the README for more information and some sample commands.



Cajon: a browser module loader for CommonJS/node/AMD modules

2012-06-13T11:39:36.276-07:00

I just released the first version of Cajon. From the README:

Cajon is a JavaScript module loader for the browser that can load CommonJS/node and AMD modules. It is built on top of RequireJS.

You can use it to code modules for your project in CommonJS/node style, then use the RequireJS Optimizer to build all the modules into an AMD-compliant bundle. This allows you to then use a small AMD API shim, like almond, to get nicely optimized code without needing a full runtime loader.

See the README for more information and restrictions.

Why do this?

It is an experiment, to see what people like to build with. The attributes of AMD are needed for any comprehensive JavaScript module solution, but some people really like sugar, and the sugared form of AMD may not be enough for them. They also may want to use existing CommonJS/node modules as-is but still want to get a good, optimized/built story, and something that works well cross-domain in the browser.

This experiment goes along with the latest requirejs 2.0.2 optimizer setting, cjsTranslate, which will automatically convert CommonJS/node modules to have a define() wrapper, so they can be consumed by the optimizer. This would allow you, for example, to build a node command that watched your js lib folder as you did changes to modules in the CommonJS/node format, and build them into an optimized AMD bundle.

End result, if you cannot bring yourself to use AMD:

If you do not want to do builds during your CommonJS/node-based module development, use Cajon. If you like doing builds, you can now use the RequireJS optimizer (with the almond AMD shim) to do that.

To be clear: CommonJS/node modules as-is are not enough for a comprehensive JS module solution. These tools allow you to use them though and fill in the gaps by "compiling down" the code to AMD.



RequireJS 2.0.2 released

2012-06-12T20:00:46.408-07:00


 RequireJS 2.0.2 is available.

More bug fixes, thanks to the community for really putting it through its paces.

Notable change for the optimizer: The "dir" output directory is now deleted before each build run, if it exists. This is done to avoid problems with transforms via onBuildRead/onBuildWrite that made it difficult to do incremental builds. If you want to keep the "dir" directory between optimizer runs, then set "keepBuildDir" to true.

Complete list of changes:





volo 0.2.0 released

2012-06-07T00:10:20.661-07:00

volo 0.2.0 has been released. volo is a front end JavaScript package manager, which uses github as the source repository. It can install whole project templates, and it understands volofiles for doing project-specific task automation.

The 0.2.0 release is significant in a few ways:

1) It is now only delivered via npm. So to install it:

    npm install -g volo

2) the format of volofiles have changed. The old format will still work in this release, but to get the new, shorter "shell string" support or for reusing volo commands that can be installed via npm, you will need to convert your volofile to the new format. Some details in the conversion ticket, but see the "Creating a volofile" and "Creating a volo command" pages for more information.

3) "volo add" now recursively adds dependencies. It does not do fancy conflict resolution -- if a dependency with the same name is already installed in that location, then that existing dependency is used.

Recursive dependency installation only works if your package.json has a volo.dependencies section (or there is a shim for the project you want to use in the shims repo). The backbone library has a shim entry, so you can try it out by doing:

    volo add backbone

It is a big release, but there is more to do, particularly on console feedback and formatting. At least now the code structure is set better for the future.




RequireJS 2.0.1 released

2012-06-01T13:42:28.766-07:00

 RequireJS 2.0.1 is available.

A few fixes to clean up some edges from the 2.0 release. If you are using 2.0.0, you should upgrade to 2.0.1 right away. Changes:



Package Management for Front End JavaScript

2012-05-31T15:20:37.465-07:00

I have been working on volo, which is a real, working attempt at providing a solution for front end Javascript package management.It seems like more people are starting to look at this, and here are my suggestions on what the solution should look like. I do not expect everyone to use volo, but if we all agreed to some basics, then it will allow some easier interop (see the end of this post).Resist the temptation to make your own registryOne of the harder parts is to agree on a registry for code. With volo I have gone with using GitHub because:It already exists and works/scales.It has social/feedback tools and search.Used by many JS libraries already, it is already part of developer workflow.I suggest starting with GitHub as the registry. They have a nice API that volo uses to get tags and files out of a repo.It would be easy to replicate a stand-alone server that has the same API later if it seemed like GitHub as the registry did not make sense, but by using GitHub and its API, some of the mundane bikeshedding over API and registry construction goes away.The "owner/repo" IDs with github, vs just the "repo" single namespace that is in something like npm, is a distinct benefit to have for a registry. Forks should be possible, with the default search on just "repo" giving the most popular version, which is usually the original repo. Given GitHub's social tools, they have a way to measure popularity, and it seems to work out pretty well.  Easy conventionTry to find a convention so that configuration is not required. The basic convention that volo uses: it checks for any explicit configuration (see below) but if none is found, it pulls down the zipball of a version tag, and if there is one JS file at the top level of the zipball, that is the script that is installed.There is a bit more to the convention, but this basic convention works for many JS libraries. It helps encourage providing small libraries that can be composed together well with other libraries in other repos.Easy configurationThe above convention does not work for every project. Some folks do not want to host their code on github, and some projects need to do a "build" step to deliver the final code, and like hosting that built code outside the git repository. So there needs to be a way to configure what to download for a dependency.volo uses a package.json property, volo.url, to find it. Example for jQuery:{    "volo": {        "url": "http://code.jquery.com/jquery-{version}"    }}It supports {version} substitution with a version value from a version tag.More is documented in the package.json page. volo also understands a volo.archive, but I want to reduce that config to just volo.url, and have it do content type detection to know if it is a single JS file or an archive zip/tarball.Do not require server devs to changevolo has a "shims" repo it checks if a library does not have the package.json "volo" property it is looking for, so it makes it easy to bootstrap new libraries into the system without requiring the library author to do anything.Of course it is best and more distributed if the library author supports the package.json property/properties directly, but for now it has been easy to consume scripts without getting complete buy-in from library authors.Let's coordinateI would love it if there were other tools besides volo for this functionality, as long as we agreed to the above GitHub bootstrapping and some package.json properties we can all read and understand.In particular, I do not want these properties under a "volo" name in the package.json. I am doing that for now just so I do n[...]



RequireJS 2.0 released, onward AMD

2012-05-28T14:06:13.340-07:00

RequireJS 2.0 is available.There is an in-depth upgrade guide to what is new, but the big ideas behind the release:Treat legacy, traditional "browser globals" scripts more like modules (but seriously, upgrade your libraries to optional AMD registration).Handle errors better.Even better large scale module usage support.While the 2.0 code has gotten some use, it is still new, and it is naturally more subject to issues than the 1.0.x releases. If you do see an issue, please report it.I am really grateful for the quality and quantity of community feedback that prompted the 2.0 release, with community members paving the way for core changes by doing implementations via the loader plugin API.Plugin APIs are awesome, and the loader plugin API is one of the great strengths of the AMD module ecosystem. In addition to reducing the "pyramid of doom" that can occur in async resource fetching, it helps try out ideas for the loader, and supports transpiled languages like CoffeeScript.I sometimes see some confusion about AMD modules and RequireJS, and I want to take a moment to reiterate the problem they are trying to solve.The AMD API is about getting workable module syntax in JavaScript that meets all the async, networked nature of browsers without having the hidden costs down the road (no eval, CORS/cross-origin concerns, needing a transform to ship code).Node's module API and using something like browserify is not enough for browser modules. It works for a certain case of problems, but to be a complete solution, a standardized callback-based require for on-demand async loading after initial module load and a wrapped module format that supports named modules for bundling are needed at a minimum. Loader plugins are also incredibly useful for reducing the async "pyramid of doom" for resources that are needed as part of module initialization. If node was able to integrate something like amdefine into their core it would really make it a complete JS module solution.ECMAScript harmony modules account for the async network IO in browsers, and it has the ability to change the internals of browser script loading so that it will not hit the eval and CORS issues that node/commonjs modules have. But it is not done, and still has quite a few kinks to work out. It will still have the same "how do I use browser globals scripts that do not declare their dependencies" issues that people see when starting to use AMD modules with older scripts. The shim config in RequireJS 2.0 is an attempt to ease that problem, and I hope that AMD and RequireJS can continue to help inform the ECMAScript effort.So until node closes the gap on some things needed for browser loading, or ECMAScript harmony modules work out the kinks and ship, there is AMD, and RequireJS aims to be the reference implementation for the AMD APIs.If you want to support AMD loaders in your library code, there are some code templates that can help you do that in a way that still allows your code to work in traditional "browser globals" situations.AMD: the worse JS module API, except for all the others. Because it works better in more cases. [...]



Web app template update, now with GitHub auth

2012-05-03T23:58:16.705-07:00

This is a quick update about the latest version of the web app template I have been working on.

You can check out some background on this app template from the previous post.

The big change since that last post: Dan Mosedale had some good feedback about treating GitHub Pages as a deploy target, so I changed around the template to do do that.

As part of these changes, volo has a new release 0.1.2 that has support for doing GitHub authorization to do OAuth-based API calls with GitHub. The app template uses this to create a GitHub repo on the fly for GitHub pages deployment.

The nice thing about this setup is that the app creation is simpler (no more questions), and you can decide later to deploy to GitHub pages without needing to make the decision up front:

allowfullscreen="" frameborder="0" height="281" mozallowfullscreen="" src="http://player.vimeo.com/video/41541859" webkitallowfullscreen="" width="500">
See the video for a more complete walkthrough, but basically to get started now it just looks like this:

volo create myproject volojs/create-responsive-template
cd myproject
volo appcache (generates the appcache-enabled build)
volo ghdeploy (copies the built contents and pushes them to GitHub Pages)

Useful links from the video:




Draft plan for RequireJS 2.0

2012-04-27T23:34:05.175-07:00

I outlined what I think RequireJS 2.0 will look like. It includes links to some working code, but the code is provided more to prove out the ideas in the wiki page. The code is still considered experimental.

See the link on that wiki page to provide feedback.



RequireJS 1.0.8 released

2012-04-20T16:30:50.156-07:00

RequireJS 1.0.8 is available.

It has been about two months since the last release, and there were some issues in the queue that would be nice to have fixed while I work on the requirejs.next release.

1.0.8 Release Notes

On requirejs.next, I have started "dev2.0" branches to play with the next bigger release for RequireJS and the r optimizer. The support for the AMD APIs will be stable. The main focus is on reevaluating some of the configuration options for the loader and how and when it resolves modules internally.

I was thinking of doing the changes as part of a 1.1 release, but since I'm thinking of possibly removing some config options, I am doing the work in "2.0" dev branches while I experiment, since semver conventions ask that the major version changes if there are backwards incompatible changes.

But again, those incompatible changes would only be around the configuration options used for the loader. The AMD API support will remain stable. I am also not sure how much will actually change, still experimenting with implementation. I will post a longer update once I feel confident of a plan going forward, and when it will be easier to give feedback on the direction.



Web apps on GitHub Pages that install into Gaia

2012-04-13T16:17:46.656-07:00

This is part of my exploration into making apps with the web. This particular example explores:Trying out the Boot to Gecko's (B2G) Gaia UI in Firefox NightlyUsing the Mozilla Web Apps API to install a web appHosting the appcache-enabled web app using GitHub PagesHere is a video that shows how it came together: allowfullscreen="" frameborder="0" height="281" mozallowfullscreen="" src="http://player.vimeo.com/video/40323462" webkitallowfullscreen="" width="500">A text summary of the video:B2G and GaiaB2G is Mozilla's mobile device operating system. It has a set of web apps called Gaia that show the home screen and some default apps, like a phone dialer.I did not want to flash a phone to try out Gaia and the B2G ideas. Fortunately, Firefox Nightly is very similar to the Gecko version used in B2G. So by running Firefox Nightly, you can run Gaia on your desktop.  Plus, you can do so without messing up your default Firefox installation.This way you can try out the UI and to experiment with web apps and APIs that would allow you to make apps that install into Gaia. Firefox Nightly does not have all the device APIs, like the telephony APIs, but for most apps it has enough to get you started.Gaia, and the web apps it supports, are all served from domains. There can only be one app per domain. Fortunately you can use subdomains. This works out well when hosting your web apps on GitHub Pages. You do need to obtain a domain, but then you can map your subdomains (a.domain.com, b.domain.com) to different GitHub Pages repos.I used Node to run a dev web server that serves the Gaia UI from localhost. See the jrburke/gaia-devserver README on information on how to set that up.Setting up your web app projectI used volo to create a new appcache-enabled, responsive web project using the volojs/create-responsive-template project template. When creating the template, you have the option to create one that works as a GitHub Pages project. volo also runs the build to generate the appcache-enabled build of the project. Since it uses appcache, the app could be usable even when a B2G device is offline.Once I created the project, I ran git init and set up gh-pages branch. Then I added the CNAME file so that I could configure a subdomain that I own to point at GitHub Pages. Then I committed all the changes.The web project also comes with tools/devserver to run a local web server that serves the dev version of the app. By modifying my local /etc/hosts file to point a dev test domain at my localhost, I could do development and try out the app install code.UninstallingI did not show this in the video, but to uninstall the app go to https://myapps.mozillalabs.com/, find the app, click the mouse and hold down the button. An X will appear. Release the mouse button to uninstall it.For that to work, you need to give myapps.mozillalabs.com access to uninstall apps:1) Close Firefox Nightly2) edit gaia/profile/user3) Add https://myapps.mozillalabs.com to the 'dom.mozApps.whitelist:user_pref("dom.mozApps.whitelist","http://dialer.gaiamobile.org:8424,http://homescreen.gaiamobile.org:8424,https://myapps.mozillalabs.com");4) Launch Firefox Nightly. Now you should be able to uninstall your app when going to https://myapps.mozillalabs.com/ End ResultPretty neat. There are still some rough edges, but it is exciting to try out.At some point, I want to trick out the project template to allow adding in Persona/BrowserID for identity hookup, but I will need to run a smart server to handle the user info. I also want to look more i[...]



Making apps with the web

2012-04-12T19:01:06.572-07:00

The pieces are coming together: you can can use the web (HTTP, HTML, JS, CSS) to package focused pieces of functionality as apps, with the possibility to make money. This post outlines how it is coming together, and how you can get involved. While I work in the Mozilla Labs group and I am sure this post will have a Mozilla slant, this is my personal outlook.What is a web appI am old school, so when I hear "web app" I associate that with the "more of an app style than document style" web page. Something more like GMail instead of the New York Times.However, it seems to be getting a more focused definition, something that implies characteristics around the actual usage of the app. Here is a fuzzy definition of it:A web app is a focused piece of functionality implemented using web technologies. These pieces of functionality are grouped in an "app dashboard".In the ancient web times, the app dashboard was just your browser bookmarks. However, the newer dashboards have a richer relationship to the apps. There are app icons/sections that can change state, and with Windows Metro, even provide some data display services. There are other associated concepts like an app being purchased and working offline.So, in a way, everything old is new again, but better and richer. The "native app" success on mobile devices has set the stage and help define what should be possible.While web apps may not be completely equivalent with the capabilities of native apps yet, the stars are moving into position.Alignment of the starsUsing web apps to deliver functionality is coming together because to the following forces:Platforms and moneyDesign practicesDevelopment toolsPlatforms and moneyHere are the platforms where you can use the web to make apps, and how you can make money doing so.Today's mobile: PhoneGap/CordovaThe PhoneGap approach works now, today. Apps are made with just plain HTML/JS/CSS and wrapped up in an platform-specific binary that gives the code access to the device capabilities.Cordova is the Apache-housed, open source parts that PhoneGap is built on. Work in Cordova feeds into web standards discussions. The hope is to not need Cordova at all, but just have all the capabilities built into the web platform.Make money the usual ways via the platform-specific app stores: charge up front, do freemium, in-app purchases, use ads.Future mobile: Boot to Gecko (B2G)Mozilla is working on a web-only mobile OS called Boot to Gecko (B2G). The great thing about this platform: it is just plain web technologies. All apps are fetched from URLs, and they can work offline through web technologies like AppCache.The tagline for B2G is "the web is the platform". The "native" in B2G is the web. If the web is not sufficient in some way, Mozilla is putting real effort into improving it. Just like Cordova, the development is all out in the open. You can be the change you want to see by participating.The B2G effort includes a set of default web apps, including a web app "home screen". This set of web apps is called Gaia. You can "install" your app into the home screen using the web app APIs, and Mozilla is working on a marketplace and APIs to allow other marketplaces for apps. There is an identity API via Persona, and efforts to work out other details like digital receipts. The apps roadmap page will help you get acquainted with some of the moving pieces if you want to get involved.Right now the B2G code is still really early in development. It is a bit rough to get going. Think of it as getti[...]



A dependency manager for web projects

2012-03-09T18:03:25.872-08:00

The problemEffective, modular development usually comes with a dependency management tool. Think easy_install for python, ruby gems for ruby, npm for Node.Front-end web development does not have this kind of tool. Traditionally it has been ad-hoc script management done by the developer. However, now that modular development is available now, and will become more prevalent as ECMAScript committee solidifies native module support, front end developers should have a dependency management tool.volo, a solutionvolo is a concrete attempt at this solution. While I do not believe it is fully formed yet, it is already useful, and by having something real to start from, it will better inform any coordinated effort.volo does not have to be the only dependency management tool. Hopefully we can use it as way to discuss common approaches that we can all share.There have been some efforts in this space, in particular npm, cpm and bpm. I go into why those were not used for volo in a Prior art page.The main point of departure is the choice of registry. volo uses GitHub.GitHub as the registryOne of the difficulties with running a dependency management tool is having an effective way to find dependencies. The JavaScript community has really embraced GitHub, and I think it has all of the right pieces to serve as a registry:Allows forks. Namespacing is possible via the use of the owner's name, not just a project name.Has a search function that can give owner/repo values for a given dependency name.Encourages open source and social communities around the source. Supports tags for versions.GitHub has a great simple API for getting versions/repo info.Provides zipballs/tarballs of tags/branches.Dependencies can be pulled not only by version tag but by branch name.Provides a Downloads area for built code.Most importantly, it means volo is already useful without having to stand up a registry or require developers to push code to new places. Many projects can be fetched as-is, and some just need a package.json property to be usable.Conventionsvolo uses some conventions that are used by some JS projects already, to make it easier to bootstrap. For other projects, usually one package.json property is enough for it to be used by volo.Check out the Library best practices document for the conventions and configuration used by volo. volo has some project-specific overrides it uses during this bootstrap phase, to simulate how those projects would behave if they used the package.json property that mapped to their development style.Try it OutSo try it out. It is just one JS file that runs in Node, so it is easy to get rid of it if you do not like it.volo's 0.1.0 release has search built in, so it is fun just to try the following kinds of commands to see what it finds on GitHub:    > volo search jquery    > volo search backbone    > volo add jquery    > volo add dojo    > volo add dijit    > volo add emberNext StepsWhile volo is useful already, it is certainly not done. In particular,Do the library best practices make sense? Also, there is info the rules "volo add" uses. I am hopeful volo allows for a reasonable default convention but still give enough flexibility via a couple package.json properties, including a way to embed a /*package.json*/ comment for single file JS libraries.volo does not install nested dependencies yet. It is doable, just needs a bit [...]



RequireJS 1.0.7 released

2012-02-22T20:49:13.158-08:00

RequireJS 1.0.7 is available.

The fixes are almost all optimizer fixes. There was a fix for a bad source overwriting bug when "appDir" and "mainConfigFile" were used together when mainConfigFile had a paths config.

Release Notes



Template for responsive mobile, offline web apps

2012-02-20T10:26:15.431-08:00

It can be difficult to create a web app that is responsive to different screen resolutions and works well in mobile environments or environments with spotty network availability.

In order to make it easier, Jason Strimpel and I created a project template, create-responsive-template, that takes care of a few things for you:
  • Uses Twitter Bootstrap for a baseline style and responsive UI
  • A couple of small JS helpers for AppCache and network events
  • A build step that optimizes JS and CSS and generates the AppCache manifest for you
A bonus: the tooling is in JavaScript, run in Node. Some background on that choice.

Here is a video that shows how you can use the template:

allowfullscreen="" frameborder="0" height="281" mozallowfullscreen="" src="http://player.vimeo.com/video/36997211" webkitallowfullscreen="" width="500">

The next steps I would like to see for this project template:
  • An IndexedDB data layer: A JS helper library that looks like the IndexedDB API, but will use an API shim over Web SQL if IndexedDB is not available. The shim does not have to implement 100% of the IndexedDB API, but something that allows a good start to local data storage. I am looking at Lawnchair at the moment, but open to other ideas.
  • An easy way to generate app store manifests for Mozilla Web Apps and Google Chrome Store.
If you have any thoughts on how best to accomplish those steps, open an issue with details, or leave a comment here on the blog post.