Common misconceptions about Boot-to-Gecko, and the Web

Posted on by

中文版刊登於謀智台客部落格。

Being asked to introduce the Boot to Gecko project to various audiences, I think it’s appropriate for me to write some FAQ here on common misconception of the project, and the Web in general.

Misconception #1: Boot to Gecko is yet another mobile platform for apps.

To run you apps on Boot to Gecko (and any other devices with a browser), you would just have to deliver your apps on the plain old-school Web on Internet.

Boot to Gecko is aim to (re)boot to the web. That is, to bring the Open Web to a level that it could compete with proprietary mobile platforms. To application developers, the Web is yet another platform to develop (you would need to port your apps from Obj-C/Java to HTML5), but the good news is your app would now becomes the cross-platform web app, not B2G Apps, PhoneGap Apps, nor Metro-style Windows 8 Apps, and it’s always available to everyone on every platform, one web address away. It would also make your app free from platform vendor control, since no one owns the Web.

Misconception #2: Phone need to be always on-line to use Boot to Gecko and web apps.

Even though every apps on B2G phone is from a web address, even the home screen itself, offline capability can be easily achieved with HTML5 Offline AppCache technology. It’s something that can be done today, available to many browsers available on both desktop and mobile. The only thing you should take care of is how network dependent your app really is. Even on iOS, Twitter app or Facebook app is useless without network connection. You should define a clear boundary between program assets and online information in your HTML5 app. After all, it’s not just an website anymore.

Misconception #3: Web app is crappier than “native apps” in turns of UX.

This is a notion I strongly disagree. The only reason mobile browsers on devices perform worse than the native app is because the venders of the device did not invest enough effort on it. There is a conflict of interest here. Limiting the capability of APIs accessible, besides permission management issue, is the same thing. At Mozilla, we can show that with proper engineering, mobile browser, or web runtime, can run smoothly as silk on devices and deliver the so-called “native” experiences. Other venders investing the web is also doing the same thing. For devices running B2G or Chrome OS, the native app is web apps, there is no point to make it slow, intentionally or unintentionally.

Misconception #4: Web apps running on B2G is dependent on B2G or Mozilla Web APIs.

Yes and no. If you need specific access like SMS message database or phone dialing, initially B2G would be the only platform that make these features available to you. However, we design these Web APIs with standardization in mind, and work closely with standardizing bodies to made these APIs ready for other venders to implement. Evidently, our Web APIs does not live under PhoneGap.*, Windows.*, nor Ti.*; they are design to be at where it should be, like navigator.* (Sure, as experimental features, they came with moz prefix right now, and usual feature detection is advised).

If you choose other packaged web app solution, then, your web app is depend on it. Forever. Mozilla would like you to develop and distribute apps directly to the Web, and you should.

Misconception #5: Apps on Web are free of charge, developers will never make money out of it.

Yeah, like no one had ever become billionaire because of applications or services they put on the web.

There are tons of way to provide services on the web in exchange for money, surely there are ways to make money with web apps, other than bagging for US$0.99 from users. Sure, closed platform with single distribution “app store” seems effective in terms of delivering revenue to developers (besides having 30% of your money being taken along the away), but Mozilla believes choices matters, and an open platform deliver choices to both users and developers.

Mozilla is also exploring effective distribution and monetize channel for the Open Web, in our Open Web App Project and the Mozilla Marketplace website. The goal of offering choices and freedom is deeply embedded in the feature design, both in browser App API and in storefront, and with user authentication and authorization (which is the scope of the Mozilla Persona project, previously known as BrowserID).

Conclusion

Just like Mozilla did with Firefox years ago, we intend to deliver great product that could influence the market, and let the market influence other venders. No one owns the Web, and no one should. Mozilla is here not to make money or become monopoly, but to bring the goodness to the Web that could drive innovation and opportunities centuries to come.

The CTO of Opera Software, Håkon Wium Lie, once said the Web will last for at least 500 years, and made impact to the society just like Gutenberg’s printing press. I totally agree with him, even though none of us will be around and told me I was wrong, as he puts it. Let’s make it great.

Disclaimer: This post express the opinion of my own and does not necessarily represents the point of view of Mozilla nor Mozilla Corp.

請記得投票

Posted on by

繳稅、守法並不代表你同意這個政府的作為，但是沉默與不行使公民權力是。請記得本週末去投票。

I managed to squeeze this into 140 chars:

Paying taxes and obey the law does not mean consent to the current administration, but silent and not acting [your] citizen right is. PLEASE VOTE.

This Has Been a Public Service Announcement.

2011 報告

Posted on by

一年又過去了，是該報告一下近況。

Mozilla Corporation 新工作

11 月底的時候換了工作。新工作在 Mozilla 的台北新辦公室，加入的研發團隊做 B2G 專案相關的研發。一開始，MozTW 的我們接到 Mozilla 私下告知關於在台北設點的計畫。起初雙方的交流僅止於公司和社群未來在行銷面上的合作方式，並沒有特別聊到什麼工作機會；事後才知道 B2G 除了 System Engineer 之外還有 Front-end Engineer 的職務，才投了履歷，做了面試。這算是一個角色的轉換，畢竟社群和工作是不一樣，而且在某個層次是不相容的；也就是基於這樣的心情，11 月的 MozCamp Asia，我以社群志工的身分最後一次參加 Mozilla 活動，對抓火狐網站的數據和心得做一個報告。

對於 Mozilla，感覺一直都是千絲萬縷的。就如之前的文章提到的，一切一切都是個往回看的過程：那個跑去 MozTW 的大學生一定沒有想到，Mozilla 後來對他職涯的意義……從因為參加志工活動開始，認識了厲害的同輩，還有認同理念的朋友，到現在實質進入了 Mozilla 本身變成員工，開發下一代的 Mozilla 其中一項自己也曾想過的產品。在 MoCo-TW 的同伴都很優秀，但開始工作之後也深切體認到自己因為盜版非資工出身導致的基本知識不足；寫程式時每每總是想著，如果我知道更多資料結構和演算法的知識就好了。當然我不是那種跑去面試會跟面試官說「願意在公司努力學習」的人（這樣是找不到工作的），只是實際工作時能這樣覺得，然後開始讀書，應該算是成長吧。

喔，我好像忘記提到為了找工作，我把 Portfolio、個人網站、Blog、CV 全部都改版了？在新工作的第一個星期就被 iThome 邀請了訪問，順勢就拿了 Adopt Mozilla 娃娃拍了照，哈。

Relationship

2011 年的另一個美麗的意外就是新的感情。女友是高中同學，在畢業前夕一起籌備畢業典禮的朋友之一。不是同班同學，所以當時也不是真的很熟，這幾年就保持著線上媒體（Facebook、Plurk、BBS）的聯繫，偶而她的樂團有演出的時候才會見到面這樣。一直都是欣賞著對方，後來因為某個奇怪的原因見面（此處保留），就這樣開始了一切。

在知道對方心意那刻除了很訝異，也覺得自己很幸運。能得到這種純粹的喜歡，要讓自己更好，值得得到才行。

一直在 Facebook 上面閃大家就不好意思了 :P

Convergence

當一切都匯集，要更努力拉住才行。大家新年快樂。

American Censorship Day

Posted on by

Note: If you are reading this on the site, you will see the banner censored.

The US Congress is currently discussing a bill that will give the power of government to shut down websites, prosecute social network users (i.e. you and me) for making minor non-commercial copyright violation (e.g. singing a pop song on Facebook), etc. This is the end of free speech on Internet as we know it, and is an attempt to build national firewall and censorship system much like the one in China.

Please join us for the fight to preserve freedom on Internet. More information can be found at americancensorship.org.

Animate.css

Posted on by

Animate.css 是一組好玩的 CSS animation keyframe，提供很多誇張的 DOM 動畫效果。使用方法根據網頁是用 Script 在想要做動畫的元素上面加上 class，然後就會觸發 CSS transition。以 jQuery 為例：

$('.bouncy').addClass('bounceInDown');

但這個作法有個問題，在他的範例頁面上也是，就是在動畫結束之後沒有辦法再跑一次（因為要先拿掉 Class 再加才會有 transition）。所以最基本的，應該要在動畫跑完（預設是 1 秒鐘）之後把 class 偷偷拿掉。我還有其他的需求像是 *Out 的 transition 跑完之後就把元素藏起來、callback、如果不支援的瀏覽器就跑 jQuery 動畫這樣，最後就變成這樣一個小小的 helper plug-in 了。

jQuery.fn.animateCSS = function (className, callback) {
	var that = this;
	if (!Modernizr.csstransforms || !Modernizr.csstransitions) {
		// for old browsers we use jQuery animation
		// only fadeIn and fadeOut for now
		if (/In/.test(className)) this.fadeIn(1000);
		if (/Out/.test(className)) this.fadeOut(1000);
	}
	if (/In/.test(className)) this.show();
	setTimeout(
		function () {
			that.removeClass(className);
			if (/Out/.test(className)) that.hide();
			if (typeof callback === 'function') callback.apply(that, that);
		},
		950
	);
	return this.addClass('animated ' + className);
}

有需要請隨意複製貼上到自己的專案去囉。

jQuery 的 live() 被 Deprecate 了

Posted on by

在 jQuery 1.7，live() 方法被標示為 deprecate （不建議使用），意思就是不建議新的專案使用這個方法，另外下個版本的 jQuery 可能會拿掉這個方法，到時候如果要升級 jQuery 的話有用到就要改寫。jQuery 建議的寫法是用 1.4.2 之後就存在的 delegate() 或是 1.7 提供的 on()。

on() 統合了 bind()、live()、delegate() 等方法，用這個方法可以取代前述方法的功能。不過這就好玩了：如果 on() 可以取代 bind() 和 live()，原本的程式碼應該要分別怎麼改寫？

看了半天文件才得到下面的結論：

// 舊
$('#myid').bind(event, fn);
// 新 (改名字就好)
$('#myid').on(event, fn);

// 舊
$('#not_in_dom_yet').live(event, fn)
// 新
$(document).on(event, '#not_in_dom_yet', fn);

另外也是寫下來之後才發現之前 live() 語法的問題：

  1. live() 的原理是把事件綁在上層的元素，事件 bubble 上去之後再去檢查從下面上來的事件是不是符合之前設定的 selector。這個原理在 on()（或是 delegate()）才會被暴露出來（有發現那個 document 嗎？）。如果只寫 live() 的話等於是不求甚解的用法，最明顯的問題是無法掌握事件觸發的順序，常常在 bind() 裡面有用的 ev.stopPropagation() 改成 live() 就沒用了。
  2. live() 把事件掛在 document，雖然比每個元素都 bind() 有效率，但是還是要過濾很多傳上來的無關事件。用 delegate() 或是 on() 才能指定要把事件 bind 在哪裡。
  3. live() 的語法不合邏輯。一個用 $('#not_in_dom_yet') 選元素的 jQuery 物件，裡面明明就沒有 DOM 元素，那照理說後面接上的方法都不應該做任何事情。結果 live() 反而是這樣運作的。

所以，就如 jQuery blog 所說的，這的確是一個瘦身計畫：只提供一個簡單的 API 來處理所有事情可以簡化程式碼的設計，也可以幫大家腦袋裡存的文件瘦身。那篇文章，還有 1.7 新功能的介紹，建議大家有空可以看看。