SGML, HTML, and XML

Professor Brailsford on the background of HTML and the story of an important workshop with Sir Tim Berners-Lee, which he attended. You can watch the three short videos on Computerphile.

The insight here is valuable with regards of early research of markup languages, and where is has intercepted with the history of the Web, and what the academic community was trying to achieve.

Obviously, the later quarrels between supporters of XHTML v.s. HTML5, and W3C v.s. WHATWG was epic, yet it’s important that new technologies are always built on top of the old, no matter how “uncool” the old technologies we think they are.

I hope there are more interviews like this documenting the later history of the Web markup technologies.

前端開發領域的終結(與重生)

數年前 awoo 給了一篇重要的演講,試圖定義網路前端開發這個領域的獨立的職能,還有其作為基石,不可或缺的角色。從那邊出發,想要寫一下這幾年的觀察與心得。

先大膽的下標:網路前端開發(Web front-end development)即將終結。

就如當年的演講所定義的一樣,網路前端開發一都是跨領域的拉扯與協調。專業的能力必須同時展現在使用者體驗(UX)、專案管理(Project Management)、產品管理(Product Management),以及為了產品選擇最適合的技術的軟體工程(Software Engineering)能力,還有為了產品開發特殊技術的電腦科學(Computer Science)能力。有些團隊的前端開發還會兼視覺設計(Visual Design)。講到這裡,大家有沒有發現其實這邊已經把一個 client application 團隊的所有職能列完了(笑)?前端最大的危機,或是最大的潛能,就是可以成為以下所列的任一職務之一,或是被這些職能吸收:

  • 視覺設計師(Visual Designer)
  • 使用者體驗設計師(User Experience Designer)
  • 產品經理(Product Manager)
  • 專案經理(Project Manager)
  • 軟體工程師(Software Engineer)
  • 電腦科學家(Computer Scientist)

為何要說網路前端開發即將終結呢?首先的問題是專案的大型化與專業化;大部分的網站已經不是單純的資訊載體了,而是堅實的線上服務。一個優秀的線上服務需要專業的分工去設計與實作最好的呈現以及產品規劃,一人或許能兼任多個職能,但是必須要在這多個職能上都足夠優秀。另外一個觀察是市場現實:Web 或是 Mobile Web 還是很重要,但是它一個產品/服務中只會是其中一種呈現,而不會是唯一的呈現。這樣的產品會仰賴堅實的軟體工程規劃去細緻的拆分前後端的功能與實作,而瀏覽器所顯示的「網頁」會越來越像另一個跟 iOS/Android app 並立的 client-side software。這就呼應到最後一點了:在 Web is the Platform 的遠景之下,瀏覽器再也不只是呈現你最獨特又漂亮的版面的佈局引擎,而是和 Windows/OS X/iOS/Android 一樣的應用程式平台與虛擬機。瀏覽器的廠商們也在朝向這個未來努力,累積這個平台提供給應用程式的功能。

我預期前端開發在工程面向的職能會越來越像一般應用程式開發的軟體工程,只是用不同的技術組合,例如寫 iOS 要懂 Swift 跟 AutoLayout,但寫 Web 要知道 JavaScript 跟 CSS。像是這樣的對應會越來越明顯,對軟體工程專業的要求也會越來越高。Web 作為一個獨特的平台,並不代表他的技術組合必須永遠是獨特的。即便是不同的語言(JavaScript),軟體工程模式還是可以交換且通用的經驗。重新發明其他平台累積過的輪子,或是一年換一個 ecosystem 最熱門的工具,並不是真正的經驗累積。更何況技術組合也確實在聚合中:WebAssembly 會開始讓 Web 成為支援多個語言的開發平台,也會有更多的技術被移植到 Web 上,藉由 <canvas> 繞過 DOM,而且實用化(還記得 Flipboard 怎麼在 Web 實作 60fps 效能的版面嗎?)。

我希望這樣的終結是這個領域的轉機。「前端開發(Web front-end development)」的工程面專業化成為「軟體工程(Software Engineering)」的過程是漸進的,只要有正確的心態,一定能和整個領域一起轉換。若有足夠的基礎知識,還可以進一步精進電腦科學的技術。即便不把自己的角色定位為軟體工程師,若有正確的機會,前述的其他職能也不會難以觸及。這是一個在職涯過程中一定會面對的選擇。

畢竟如果不羽化的話,就無法飛行了。


註:之前 UX Mag 也有文章立論「網頁設計(Web Design)」即將終結,而他們的職能會被視覺設計以及使用者體驗設計給吸收。這個狀況對前端開發來說也是相似的。

Service Worker and the grand re-architecture proposal of Firefox OS Gaia

TL;DR: Service Worker, a new Web API, can be used as a mean to re-engineering client-side web applications, and a departure from the single-page web application paradigm. Detail of realizing that is being experimented on Gaia and proposed. In Gaia, particularly, “hosted packaged app” is served as a new iteration of security model work to make sure Service Workers work with Gaia.

Last week, I spent an entire week, in face-to-face meetings, going through the technical plans of re-architecture Gaia apps, the web applications that powers the front-end of Firefox OS, and the management plan on resourcing and deployment. Given the there were only a few of developers in the meeting and the public promise of “the new architecture”, I think it’s make sense to do a recap on what’s being proposed and what are the challenges already foreseen.

Using Service Worker

Before dive into the re-architecture plan, we need to explain what Service Worker is. From a boarder perspective, Service Worker can be understood as simply a browser feature/Web API that allow web developers to insert a JavaScript-implemented proxy between the server content and the actual page shown. It is the latest piece of sexy Web technologies that is heavily marketed by Google. The platform engineering team of Mozilla is devoting to ship it as well.

Many things previously not possible can be done with the worker proxy. For starter, it could replace AppCache while keeping the flexibility of managing cache in the hand of the app. The “flexibility” bits is the part where it gets interesting — theologically everything not touching the DOM can be moved into the worker — effectively re-creating the server-client architecture without a real remote HTTP server.

The Gaia Re-architecture Plan

Indeed, that’s what the proponent of the re-architecture is aiming for — my colleagues, mostly whom based in Paris, proposed such architecture as the 2015 iteration/departure of “traditional” single-page web application. What’s more, the intention is to create a framework where the backend, or “server” part of the code, to be individually contained in their own worker threads, with strong interface definitions to achieve maximum reusability of these components — much like Web APIs themselves, if I understand it correctly.

It does not, however, tie to a specific front-end framework. User of the proposed framework should be free to use any of the strategy she/he feel comfortable with — the UI can be as hardcore as entirely rendered in WebGL, or simply plain HTML/CSS/jQuery.

The plan is made public on a Wiki page, where I expect there will be changes as progress being made. This post intentionally does not cover many of the features the architecture promise to unlock, in favor of fresh contents (as opposed of copy-edit) so I recommend readers to check out the page.

Technical Challenges around using Service Workers

There are two major technical challenges: one is the possible performance (memory and cold-launch time) impact to fit this multi-thread framework and it’s binding middleware in to a phone, the other is the security model changes needed to make the framework usable in Gaia.

To speak about the backend, “server” side, the one key difference between real remote servers and workers is one lives in data centers with endless power supply, and the other depend on your phone battery. Remote servers can push constructed HTML as soon as possible, but for an local web app backed by workers, it might need to wait for the worker to spin up. For that the architecture might be depend on yet another out-of-spec feature of Service Worker, a cache that the worker thread have control of. The browser should render these pre-constructed HTML without waiting for the worker to launch.

Without considering the cache feature, and considering the memory usage, we kind of get to a point where we can only say for sure on performance, once there is a implementation to measure. The other solution the architecture proposed to workaround that on low-end phones would be to “merge back” the back-end code into one single thread, although I personally suspect the risk of timing issues, as essentially doing so would require the implementation to simulate multi-threading in one single thread. We would just have to wait for the real implementation.

The security model part is really tricky. Gaia currently exists as packaged zips shipped in the phone and updates with OTA images, pinning the Gecko version it ships along with. Packaging is one piece of sad workaround since Firefox OS v1.0 — the primary reasons of doing so are (1) we want to make sure proprietary APIs does not pollute the general Web and (2) we want a trusted 3rd-party (Mozilla) to involve in security decisions for users by check and sign contents.

The current Gecko implementation of Service Worker does not work with the classic packaged apps which serve from an app: URL. Incidentally, the app: URL something we feel not webby enough so we try to get rid off. The proposal of the week is called “hosted packaged apps”, which serve packages from the real, remote Web and allow references of content in the package directly with a special path syntax. We can’t get rid of packages yet because of the reasons stated above, but serving content from HTTP should allow us to use Service Worker from the trusted contents, i.e. Gaia.

One thing to note about this mix is that a signed package means it is offline by default by it’s own right, and it’s updates must be signed as well. The Service Worker spec will be violated a bit in order to make them work well — it’s a detail currently being work out.

Technical Challenges on the proposed implementation

As already mentioned on the paragraph on Service Worker challenges, one worker might introduce performance issue, let along many workers. With each worker threads, it would imply memory usage as well. For that the proposal is for the framework to control the start up and shut down threads (i.e. part of the app) as necessary. But again, we will have to wait for the implementation and evaluate it.

The proposed framework asks for restriction of Web API access to “back-end” only, to decouple UI with the front-end as far as possible. However, having little Web APIs available in the worker threads will be a problem. The framework proposes to workaround it with a message routing bus and send the calls back to the UI thread, and asking Gecko to implement APIs to workers from time to time.

As an abstraction to platform worker threads and attempt to abstract platform/component changes, the architecture deserves special attention on classic abstraction problems: abstraction eventually leaks, and abstraction always comes with overhead, whether is runtime performance overhead, or human costs on learning the abstraction or debugging. I am not the expert; Joel is.

Technical Challenges on enabling Gaia

Arguably, Gaia is one of the topmost complex web projects in the industry. We inherit a strong Mozilla tradition on continuous integration. The architecture proposal call for a strong separation between front-end application codebase and the back-end application codebase — includes separate integration between two when build for different form factors. The integration plan, itself, is something worthy to rethink along to meet such requirement.

With hosted packaged apps, the architecture proposal unlocks the possibility to deploy Gaia from the Web, instead of always ships with the OTA image. How to match Gaia/Gecko version all the way to every Nightly builds is something to figure out too.

Conclusion

Given everything is in flux and the immense amount of work (as outlined above), it’s hard to achieve any of the end goals without prioritizing the internals and land/deploy them separately. From last week, it’s already concluded parts of security model changes will be blocking Service Worker usage in signed package — we’ll would need to identify the part and resolve it first. It’s also important to make sure the implementation does not suffer any performance issue before deploy the code and start the major work of revamping every app. We should be able to figure out a scaled-back version of the work and realizing that first.

If we could plan and manage the work properly, I remain optimistic on the technical outcome of the architecture proposal. I trust my colleagues, particularly whom make the architecture proposal, to make reasonable technical judgements. It’s been years since the introduction of single-page web application — it’s indeed worthy to rethink what’s possible if we depart from it.

The key here is trying not to do all the things at once, strength what working and amend what’s not, along the process of making the proposal into a usable implementation.

Edit: This post have since been modified to fix some of the grammar errors.