Group items matching

in title, tags, annotations or url

Another article taking up the issue of "Blame the W3C" for what increasingly looks like a proprietary Web future. The author is an Ajax-DOJO supporter, and he tries to defend the W3C by saying it's not their job, they don't have the "power" or the "authority" to push the Web forward. About the best they can do is, at the end of the day, try to corral big vendors into agreement. Meanwhile, the Web has become the wild wild west with browser vendors innovating into their corporate web stacks where vast profits and future monopolies rest. For me, WebKit represents the best effort insisting that the Web remain Open. It's OSS with excellent big vendor support. And they are pushing the envelope. Finally!

I reformatted my response to marbux concerning HTML5 and web application lack of interoperability. The original article these comments were posted to is titled, "Siding with HTML over XHTML, My Decision to Switch.... ".

Rather than shoehorning more and more functionality into the browser itself (and going through all the rigorous standardization procedures that this requires), maybe it's time we separated the UI from the underlying client-side logic. Let the browser handle the View. Let the Controller exist somewhere else, independent of the presentation layer. We already have a means to achieve this separation for client-side code today: browser plug-ins.

New working draft from W3C. See also details of the call for comment: http://lists.w3.org/Archives/Public/w3c-wai-ig/2008JulSep/0034

Awesome commentary in the must read category. JC nails it; starting with "layout"! ....... "We were both part of the same team and he was creating some UI elements that I was to wire up. As I sat there (in awe) watching him work I realized that much of his considerable skill was rooted in fundamentals not unlike the art of programming. Of course, there are design skills that are intuitive that can't be "learned." But, that can also be said of the logical clarity found in a really elegant data model or a brilliant inheritance tree. I am certainly no designer, but I have observed the more creative among us for several years and have gained some insight into their world. In this article I'll share some basic principles that can help raise your design acumen and improve the experience of your users...... " Layout I'd like to attack my goal of imparting design wisdom by breaking the topic into four buckets. The first is layout.

Just because the web has been open so far doesn't mean that it will stay that way. Flash and Silverlight, arguably the two market-leading technology toolkits for rich media applications are not open. Make no mistake - Microsoft and Adobe aim to have their proprietary plug-ins, aka pseudo-browsers, become the rendering engines for the next generation of the Web.

I doubt that MSOffice ODF will make a difference. ODF was not designed to be compatible with MSOffice, and conversion from native binary to ODF will result in a serious loss of fidelity and business process markup. If the many ODF pilots are an indication, the real killer is that application specific processing logic will be lost on conversion even if it is Microsoft doing the conversion to ODF. This logic is expressed as scripts, macros, OLE, data binding, media binding, add-on specifics, and security settings. These components are vital to existing business processes. Besides, Microsoft will support ISO 26300, which is not compatible with the many aspects of ODF 1.2 currently implemented by most ODF applications. The most difficult barrier to entry is that of MSOffice bound business processes so vital to workgroups and day-to-day business systems. Maybe the report is right in saying that day-to-day business routines become habit, but not understanding the true nature of these barriers is certain to cloud our way forward. We need to dig deeper, as demonstrated by the many ODF pilot studies.

I've pretty much stayed out of the EU action against Microsoft primarily because it misses the mark by so much. The browser is not the means by which Microsoft seeks to create a Web based monopoly. MSIE is a useful tool used to frustrate Web developers and systems providers, but we are way beyond the point where removing/replacing MSIE becomes an effective remedy to Microsoft monopolist abuses. Way beyond! There is however no doubt in my mind that the browser is going to be the portable WebOS of the future. The problem is that browser runtimes are also host for proprietary runtime plug-ins. Like MS Silverlight! Read on freind. My comments are three part, and posted down the line, somewhere around 183. Heavy on the WebKit stuff as usual! Look for "gary.edwards".

What the InformationWeek 500 data tells us about the use of emerging technologies.

One of the best ways to create that perception (and reality) is to get more mobile developers building for the Web instead of any specific platform. It's a win for developers looking to reach the broader market. It's a win for end-users who shouldn't be forced into picking a specific platform or network (eg: iPhone/AT&T) just to get access to certain applications. It's a win for Google. Who is it not good for? You don't have to look far.

Matt Assay has posted an interesting article arguing the point of view that Google Chrome will have a difficult time catching up Microsoft SharePoint. While everyone is moving to the Web, many will be surprised ot find that Microsoft is already there. Very surprised.

Good article from Matt Assay

Great insight into Adobe AiR and the transition from browser based surfing to web application building.

Building the Dojo Toolbox allowed us to dive into Adobe® AIR™, and to create a blended toolchain of JavaScript, PHP, Python and Rhino (JavaScript on the Java Virtual Machine) for developing an amazing desktop application using open web technologies. One of the most noticeable things you'll see when moving from typical browser-based development to AIR is that you only have one browser to worry about. Dojo does a great job of masking browser JavaScript API differences, but there are still enough differences in CSS and other aspects of application development that it is somewhat refreshing to only have one platform to develop again. Also, since AIR includes WebKit, it has one of the fastest JavaScript implementations around and offers numerous useful experimental CSS properties that you can use in the AIR context. Apple has invested a lot in WebKit development, and AIR will naturally inherit those benefits when they next upgrade the included WebKit.

The consensus of the developers who are using WebKit is clear: it's an outstanding rendering engine that lends itself to an extremely diverse assortment of practical uses. It is everywhere, and it is gaining traction at a very impressive rate. That traction is causing some developers to question whether Mozilla's Gecko rendering engine is still relevant.

Historical walkthrough comparing two great rendering engines (layout); Mozilla Gecko and WebKit.

I've installed and played with Chrome but I'll spare you my review of it. What's more interesting to me and of concern to you is where the Internet is heading as specific client- and server-side technologies (as well as the entities in between) become deeply aligned with one another at the expense of openness. Or should I say Internets?

One new feature I'm particularly excited about is process affinity. The online comic describes each tab as a separate running process. Why is this important? The short answer is robustness. A web application running in your browser, is a lot like an application running on your operating system, with one important distinction: Modern operating systems[1] run applications in their own separate process space, while modern browsers[2] run web applications in the same process space. By running applications in separate processes, the OS can terminate a malicious (or poorly written) application without affecting the rest of the OS. The browser, on the other hand, can't do this. Consequently a single rogue application can suck up mountains of memory and eventually crash your entire browser session, along with every other web application you were using at the time.

Good discussion on why Chrome is a great web application foundation

Google released its second web browser yesterday afternoon, adding additional headroom for web applications stretching the limits of what it's possible to accomplish within a web browser. The Google Chrome team assembled domain experts in various fields over the past six years, both through direct hires and acquisitions, to create a new browser and its critical components from scratch. GMail and Google Maps pushed the Web to its limits, taking advantage of browser technologies invented in Redmond but left dormant for far too long. Contributing to Firefox's core, writing browser extensions, and championing HTML could only take the $150 billion company so far: they needed to own the full browser to push their Web efforts forward at full speed.

"We realized that the Web had evolved from mainly simple text pages to rich, interactive applications, and that we needed to completely rethink the browser. What we really needed was not just a browser but also a modern platform for Web pages and applications, and that's what we set out to build," writes Sudar Pichai, Google's vice president for product management on the official Google blog. Beautifully done Google!

Yup. They're making noises about moving Flash and AIR into ARM-based appliances. This seems a sound strategic move for Adobe in response to Silverlight, drilling hard for the big computing market that already dwarfs the desktop computer market. It ain't just about the desktop and the Web anymore, folks.

Adobe positioning AIR for a move into embedded systems? E.g., from Wikipedia: "Because of their power saving features, ARM CPUs are dominant in the mobile electronics market, where low power consumption is a critical design goal. Today, the ARM family accounts for approximately 75% of all embedded 32-bit RISC CPUs, making it one of the most widely used 32-bit architectures. ARM CPUs are found in most corners of consumer electronics, from portable devices (PDAs, mobile phones, media players, handheld gaming units, and calculators)." Don't miss page two of the linked article.