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.
Friday, April 27, 2012
Friday, April 20, 2012
RequireJS 1.0.8 released
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.js 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.
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.js 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.
Friday, April 13, 2012
Web apps on GitHub Pages that install into Gaia
This is part of my exploration into making apps with the web. This particular example explores:
A text summary of the video:
B2G and Gaia
B2G 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 project
I 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.js 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.
Uninstalling
I 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 Nightly
2) edit gaia/profile/user.js
3) Add https://myapps.mozillalabs.com to the 'dom.mozApps.whitelist:
4) Launch Firefox Nightly. Now you should be able to uninstall your app when going to https://myapps.mozillalabs.com/
End Result
Pretty 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 into IndexedDB as a client side data storage.
In addition, it would be interesting to see how I could get this to work so it shows up in the Chrome Web Store and how it might fit in to the Windows 8 web app support.
- Trying out the Boot to Gecko's (B2G) Gaia UI in Firefox Nightly
- Using the Mozilla Web Apps API to install a web app
- Hosting the appcache-enabled web app using GitHub Pages
A text summary of the video:
B2G and Gaia
B2G 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 project
I 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.js 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.
Uninstalling
I 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 Nightly
2) edit gaia/profile/user.js
3) 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 Result
Pretty 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 into IndexedDB as a client side data storage.
In addition, it would be interesting to see how I could get this to work so it shows up in the Chrome Web Store and how it might fit in to the Windows 8 web app support.
Thursday, April 12, 2012
Making apps with the web
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 app
I 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 stars
Using web apps to deliver functionality is coming together because to the following forces:
Here are the platforms where you can use the web to make apps, and how you can make money doing so.
Today's mobile: PhoneGap/Cordova
The 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 getting access to iOS a year before the first iPhone shipped.
Desktop
Both Firefox and Chrome will know how to install web apps. The hope is that all the browser vendors can converge on some common APIs and get those uplifted into all browsers.
Mozilla is also working out a way to "install" a web app from your browser into your desktop operating system. A small OS app shell will be wrapped around a web renderer that is tied to that specific web app. For the end user, it just looks like any other app installed on their desktop.
You will be able to use web technologies for Windows 8 Metro apps and in Windows Phone. Microsoft is making the web stack a first class development option for their platform.
On the money side:
There is the Chrome Web Store for Chrome browsers, and Mozilla is working on a Marketplace. The hope is to work out open, standardized APIs that would allow other marketplaces and integration with any web browser. There is a Windows Phone Marketplace, and I fully expect a marketplace for Metro apps for Windows 8.
While marketplaces by themselves do not translate directly into money, they establish ways for users to buy functionality and discover new apps. They set up a fertile environment. Using ads and providing apps for free with money coming in from other channels will still be possible.
Design practices
There are a few design practices that fit well with web app development:
Mobile first
The number of mobile, non-desktop PC devices are growing like crazy. The "app" phase was brought on by these mobile devices. By focusing on these mobile experiences first, it sets you up to reach a very big market.
Focused execution
This falls out of the Mobile First design approach. When you start with mobile, the interfaces are usually more focused. This is a great way to do any app design -- make sure to distill the design problem to the smallest user goal possible, and then build up from there as necessary.
Responsive design
Different kinds of devices that have different resolutions and input methods are best served with some custom work done for each device. However, there is a lot of code that can be shared by moving away from a "pixel perfect" and device-specific look to more of a "web aesthetic" using responsive design.
URL-based design
"Mobile Apps Must Die" brings up some interesting points when apps are addressable via URLs. It opens up new discovery possibilities and different ways to "organize" your apps.
Developer tools
Here are some APIs that can help with web app plumbing:
I hope to share more tools and approaches as I discover them.
Under construction
As you jump into making web apps you will discover some rough edges. You may get frustrated. This is OK. The future is under construction.
If you want to see change, get involved. Move the Web Forward is a great resource that can help you figure out how you want to engage.
I am a web hacker and my current interest is the B2G platform, so I will be checking out Gaia. I will share what I find as I go along. If you want to engage on a lower level, check out the Gonk and Gecko layers in B2G.
I am really excited to see web apps come into their own for many different platforms that include ways to make money. It is great to see some smart designers figure out how to design for the web app world.
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 app
I 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 stars
Using web apps to deliver functionality is coming together because to the following forces:
- Platforms and money
- Design practices
- Development tools
Here are the platforms where you can use the web to make apps, and how you can make money doing so.
Today's mobile: PhoneGap/Cordova
The 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 getting access to iOS a year before the first iPhone shipped.
Desktop
Both Firefox and Chrome will know how to install web apps. The hope is that all the browser vendors can converge on some common APIs and get those uplifted into all browsers.
Mozilla is also working out a way to "install" a web app from your browser into your desktop operating system. A small OS app shell will be wrapped around a web renderer that is tied to that specific web app. For the end user, it just looks like any other app installed on their desktop.
You will be able to use web technologies for Windows 8 Metro apps and in Windows Phone. Microsoft is making the web stack a first class development option for their platform.
On the money side:
There is the Chrome Web Store for Chrome browsers, and Mozilla is working on a Marketplace. The hope is to work out open, standardized APIs that would allow other marketplaces and integration with any web browser. There is a Windows Phone Marketplace, and I fully expect a marketplace for Metro apps for Windows 8.
While marketplaces by themselves do not translate directly into money, they establish ways for users to buy functionality and discover new apps. They set up a fertile environment. Using ads and providing apps for free with money coming in from other channels will still be possible.
Design practices
There are a few design practices that fit well with web app development:
Mobile first
The number of mobile, non-desktop PC devices are growing like crazy. The "app" phase was brought on by these mobile devices. By focusing on these mobile experiences first, it sets you up to reach a very big market.
Focused execution
This falls out of the Mobile First design approach. When you start with mobile, the interfaces are usually more focused. This is a great way to do any app design -- make sure to distill the design problem to the smallest user goal possible, and then build up from there as necessary.
Responsive design
Different kinds of devices that have different resolutions and input methods are best served with some custom work done for each device. However, there is a lot of code that can be shared by moving away from a "pixel perfect" and device-specific look to more of a "web aesthetic" using responsive design.
URL-based design
"Mobile Apps Must Die" brings up some interesting points when apps are addressable via URLs. It opens up new discovery possibilities and different ways to "organize" your apps.
Developer tools
Here are some APIs that can help with web app plumbing:
- Application Cache: learn it. Yes, it has its quirks, but for serving offline UI, it is the state of the art.
- localStorage: for storing smaller name/value paires of data offline.
- IndexedDB: for storing larger amounts of data offline. Right now iOS/Android devices do not support IndexedDB, just the older, deprecated Web SQL. However, that should change over time. Lawnchair can provide an adapter layer if you need to target platforms with uneven storage support today.
I hope to share more tools and approaches as I discover them.
Under construction
As you jump into making web apps you will discover some rough edges. You may get frustrated. This is OK. The future is under construction.
If you want to see change, get involved. Move the Web Forward is a great resource that can help you figure out how you want to engage.
I am a web hacker and my current interest is the B2G platform, so I will be checking out Gaia. I will share what I find as I go along. If you want to engage on a lower level, check out the Gonk and Gecko layers in B2G.
I am really excited to see web apps come into their own for many different platforms that include ways to make money. It is great to see some smart designers figure out how to design for the web app world.
Subscribe to:
Posts (Atom)