Group items tagged

a framework for JavaScript applications called ViewsHandler. ViewsHandler is not another JavaScript templating solution but works on the assumption that in most cases you'll have to create a lot of HTML initially but you'll only have to change the content of some elements dynamically as new information gets loaded or users interact with the app. So instead of creating a lot of HTML over and over again all I wanted to provide is a way to create all the needed HTML upfront and then have easy access to the parts of the HTML that need updating. The first thing you'll need to do to define your application is to create an object with the different views and pointers to the methods that populate the views:

Fyrdility asks the question; when it comes to the future of the Open Web, is Apple worse than Microsoft? He laments the fact that Apple pushes forward with innovations that have yet to be discussed by the great Web community. Yes, they faithfully submit these extensions and innovations back to the W3C as open standards proposals, but there is no waiting around for discussion or judgement. Apple is on a mission.

IMHO, what Apple and the WebKit community do is not that much different from the way GPL based open source communities work, except that Apple works without the GPL guarantee. The WebKit innovations and extensions are similar to GPL forks in the shared source code; done in the open, contributed back to the community, with the community responsible for interoperability going forward.

There are good forks and there are not so good forks. But it's not always a technology-engineering discussion that drives interop. sometimes it's marketshare and user uptake that carry the day. And indeed, this is very much the case with Apple and the WebKit community. The edge of the Web belongs to WebKit and the iPhone. The "forks" to the Open Web source code are going to weigh heavy on concerns for interop with the greater Web.

One thing Fyrdility fails to recognize is the importance of the ACiD3 test to future interop. Discussion is important, but nothing beats the leveling effect of broadly measuring innovation for interop - and doing so without crippling innovation.

"......Apple is heavily involved in the W3C and WHATWG, where they help define specifications. They are also well-known for implementing many unofficial CSS extensions, which are subsequently submitted for standardization. However, Apple is also known for preventing its representatives from participating in panels such as the annual Browser Wars panels at SXSW, which expresses a much less cooperative position...."

InfoWorld's Tom Yager makes the case for the WebKit visual document model over AJAX. The problem with AJAX as he sees it is that it's JavaScript heavy. And that breaks precious Web interoperability. He makes the point that if something can be done in CSS, it should. He also argues that WebKit is the best tool because the document model is that of advanced HTML5 and CSS3.

"... These [WebKit] browsers also share a stellar accelerated JavaScript interpreter that makes the edit/run/debug cycle go faster. They are also the only browsers that deliver on CSS4 and HTML5 standards (with some elements that are proposed to the W3C standards body). Sites that are visually rich may start sprouting "best viewed with Safari" banners until other browsers catch up. The banner would also let users know that your site is optimized for iPhone....."

Humm. Did you catch that? CSS4!!! I guess he's referring to the WebKit penchant for putting advanced graphical transitions and animations into CSS instead of relying on a device specific or OS specific API.

Placing the visual interface instructions in the documents presentation layer (CSS4) is a revolutionary idea. The WebKit model will go a long way towards creating a global interoperability layer that rides above lower device, OS, browser and application specifics. So yes, by all means let's go with CSS4 :)

A Computational Knowledge Engine for the Web In a nutshell, Wolfram and his team have built what he calls a "computational knowledge engine" for the Web. OK, so what does that really mean? Basically it means that you can ask it factual questions and it computes answers for you. It doesn't simply return documents that (might) contain the answers, like Google does, and it isn't just a giant database of knowledge, like the Wikipedia. It doesn't simply parse natural language and then use that to retrieve documents, like Powerset, for example. Instead, Wolfram Alpha actually computes the answers to a wide range of questions -- like questions that have factual answers such as "What country is Timbuktu in?" or "How many protons are in a hydrogen atom?" or "What is the average rainfall in Seattle this month?," "What is the 300th digit of Pi?," "where is the ISS?" or "When was GOOG worth more than $300?" Think about that for a minute. It computes the answers. Wolfram Alpha doesn't simply contain huge amounts of manually entered pairs of questions and answers, nor does it search for answers in a database of facts. Instead, it understands and then computes answers to certain kinds of questions.

MHTML (MIME HTML) which allows all of webpages referenced resources to be downloaded and saved in a single file. This way you can avoid having the manageability problem of many loose files which many browsers produce when you save a web page. This is very useful for archiving webpages to file servers and local disk as well as emailing webpages to people....... An alternative to MHTML would be ZIP containers similar to ODF, OOXML, and XPS. Moving to standardized, containerized files will provide the same benefit of MIME HTML, allowing entire webpages and associated resources to be treated as a single file for better usability.

the Palm Pre WebOS is based on Linux, and is in some way an extension of what they've been crafting for a while now, but on top of that Linux core is a display layer that is basically WebKit: all of the apps, including Palms own, are built in HTML, CSS and Javascript, and can make calls deeper into the OS for certain functionalities. That means almost any web developer can build an app for the phone, but there are limitations; like no 3D in this first release. .... excellent review! The Palm Pre is a huge win for the WebKit layout and sugarplum document model (highly advanced, graphical and interactive HTML-CSS-SVG-JS)

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.

Hey, maybe web apps will after all be able to hold two-way conversations some day? :-)

Nvidia chief executive Jen-Hsun Huang is on a mission to get graphics chips into everything from handheld computers to smart phones. He expects, for instance, that low-cost Netbooks will become the norm and that gadgets will need to have battery life lasting for days. Holding up an Ion platform, which couples an Intel low-cost Atom processor with an Nvidia integrated graphics chip set, he said his company is looking to determine "what is the soul of the new PC." With Ion, Huang said he is prepared for the future of the computer industry. But first, he has to deal with Intel. Good interview. See interview with Charlie Rose! The Dance of the Sugarplum Documents is about the evolution of the Web document model from a text-typographical/calculation model to one that is visually rich with graphical media streams meshing into traditional text/calc. The thing is, this visual document model is being defined on the edge. The challenge to the traditional desktop document model is coming from the edge, primarily from the WebKit - Chrome - iPhone Community. Jen-Hsun argues on Charlie Rose that desktop computers featured processing power and applications designed to automate typewritter (wordprocessing) and calculator (spreadsheet) functions. The x86 CPU design reflects this orientation. He argues that we are now entering the age of visual computing. A GPU is capable of dramatic increases in processing power because the architecture is geared to the volumes of graphical information being processed. Let the CPU do the traditional stuff, and let the GPU race into the future with the visual processing. That a GPU architecture can scale in parallel is an enormous advantage. But Jen-Hsun does not see the need to try to replicate CPU tasks in a GPU. The best way forward in his opinion is to combine the two!!!

This is a must see discussion!!!! Especially if you've seen the Ted Nelson series of talks at Google. (Ted Nelson invented Hypertext, and continues to promote the XANDU view of highly graphical and interactive computing based on an advanced "digital" document model). Jen-Hsu fully embraces the sugarplum document model, dissing i a gentle way the legacy of x86 text-number processing designed to replace typewritters and calculators to produce the same printed document.

Nvidia has also announced an ION based board optimized for the Google Android Mobile-Telecommunications OS!

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.

Maybe the EU can right the marketplace and restore competition by identifying all proprietary formats, protocols and interfaces used by Microsoft in an anti-competitive way; then issue a directive to either replace these locks with open standard alternatives, or pay a monthly anti-competitive reimbursement penalty until such time as the end user effectively replaces these systems. This approach is similar to the "WiNE solution" put forward to Judge Jackson as part of the USA anti-trust remedy. Judge Jackson favored a break up of Microsoft into two divisions; Operating systems and other businesses. Few believed this was enforceable, with many citing the infamous "Chinese Wall" claims made by Chairman Bill

While the last decade was focused on the Web, the next phase in the evolution of our industry will be on the convergence of Web, mobile and desktop applications and the ability to extend existing applications with these new technologies for a consistent user experience regardless of how and where the information is viewed,' says Nexaweb CTO Jeremy Chone

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.

The race is on. Google will win the consumer Web. Microsoft will win the business Web. Sadly i don't think there is any way for Google to challenge Microsoft with regard for the privilege of transitioning existing MSOffice bound workgroup- workflow business processes to the Web. Even if Google Docs could match MSOffice feature to feature, cracking into existing MSOffice workgroups is impossibly hard. Anyone who doubts this ought to take a second look at the Massachusetts ODF Pilot Study, or the recently released Belgium Pilot results. Replacing MSOffice in a workgroup setting is simply too disruptive and costly because of the shared business process problem.

Good analysis by Stephen Vaughan-Nichols. He gets it right. Sort of. Stephen believes that Chrome is desinged to kill MSOffice. Maybe, but i think it's way too late for that. IMHO, Chrome is designed to keep Google and the Open Web in the game. A game that Microsoft is likely to run away with. Microsoft has built an easy to use transiton bridge form MSOffice desktop centric "client/server" computing model to a Web centirc but proprietary RiA-WebStack-Cloud model. In short, there is an on going great transtion of traditional client/server apps to an emerging model we might call client/ WebStack-Cloud-RiA /server computing model. As the world shifts from a Web document model to one driven by Web Applications, there is i believe a complimentary shift towards the advantage Micorsoft holds via the desktop "client/server" monopoly. For Microsoft, this is just a transtion. Painful from a monopolist profitability view point - but unavoidably necessary. The transition is no doubt helped by the OOXML <> XAML "Fixed/flow" Silverlight ready conversion component. MS also has a WebStack-Cloud (Mesh) story that has become an unstoppable juggernaut (Exchange/SharePoint/SQL Server as the WebSTack). WebKit based RiA challengers like Adobe Apollo, Google Chrome, and Apple SproutCore-Cocoa have to figure out how to crack into the great transition. MS has succeeded in protecting their MSOffice monopoly until such time as they had all the transtion pieces in place. They have a decided advantage here. It's also painfully obvious that the while the WebKit guys have incredible innovation on their side, they are still years behind the complete desktop to WebStack-RiA-Cloud to device to legacy servers application story Microsoft is now selling into the marketplace. They also are seriously lacking in developer tools. Still, the future of the Open Web hangs in the balance. Rather than trying to kill MSOffice, i would think a better approach would be that of trying to

There are five reasons why Google is doing this, and, if you read the comic book closely - yes, I'm serious - and you know technology you can see the reasons for yourself. These, in turn, lead to what I think is Google's real goal for Chrome.

I'm still keeping the door open on a suspicion that Microsoft may have planned to end the life of MS Office after the new fortress on the server side is ready. The code base is simply too brittle to have a competitive future in the feature wars. I can't get past my belief that if Microsoft saw any future in the traditional client-side office suite, it would have been building a new one a decade ago. Too many serious bugs too deeply buried in spaghetti code to fix; it's far easier to rebuild from the ground up. Word dates to 1984, Excel to 1985, Powerpoint to 1987, All were developed for the Mac, ported years later to Windows. At least Word is still running a deeply flawed 16-bit page layout engine. E.g., page breaks across subdocuments have been broken since Word 1.0. Technology designed to replace yet still largely defined by its predecessor, the IBM Correcting Selectric electro-mechanical typewriter. Mid-80s stand-alone, non-networked computer technology in the World Wide Web era? Where's the future in software architecture developed two decades ago, before the Connected World? I suspect Office's end is near. Microsoft's problem is migrating their locked-in customers to the new fortress on the server side. The bridge is OOXML. In other words, Google doesn't have to kill Office; Microsoft will do that itself. Giving the old cash cow a face lift and fresh coat of lipstick? That's the surest sign that the old cow's owner is keeping a close eye on prices in the commodity hamburger market while squeezing out the last few buckets of milk.

ZOHO Speaks about Chrome: "The biggest losers in Google's announcement are not really competing browsers, but competing rich client engines like Flash and Silverlight. As Javascript advances rapidly, it inevitably encroaches on the territory currently held by Flash. Native browser video is likely the last nail in the coffin - and Google needs native browser based video for its own YouTube, so we can be confident Google Chrome and Firefox will both have native video support, with Javascript-accessible VOM (video object model) APIs for web applications to manipuate video. As for Silverlight, let me just say that if Silverlight is the future of web computing, companies like us might as well find another line of work - and I suspect Google and Yahoo probably see it the same way too. More speculatively, I believe we will witness the emergence of Javascript as the dominant language of computing, as it sweeps the client side and starts encroaching on the server. The server landscape today is split between "enterprise" platforms like Java and .NET on the one side (we ourselves are in the Java camp on the server side), and "scripting" languages like PHP, Python, Ruby on the other, with Javascript firmly entrenched on the client. Languages like Ruby promise tremendous dynamism and flexibility to the developer, but their relatively weak execution environments have held them back. It is telling that both Java and .NET come with state of the art just-in-time compilers, while none of the major scripting languages do......" Interestingly, ZOHO already has a prototype running on Chrome! Solves tons of performance problems for them, as well as givign them an on-line / off-line story (Gears). The success of Chrome depends on Chrome "killer apps"; Not browser surfing features! And we already have a number of killer apps that will immediately take advantage of Chrome: gMail, gReader, gMaps and Google Docs! ZOHO will no doubt use Chrome to put themselves squarely i

"What's good for the Internet is good for Google, and the company says its strategic proposition for the newly introduced Chrome browser is: a better platform is needed to deliver a new generation of online applications......." This is one of the best explanations of why Google had to do Chrome i've seen thus far. Kontra also provided some excellent coverage concerning the Future of the Web in a two part article previously published. Here he nails the RiA space, comparing Google Chrome, Apollo (Adobe AiR/Flex/Flash) and Microsoft Silverlight. Chrome is clearly an Open Web play. Apollo and Sivlerlight are proprietary bound in some way. Although it must be said that Apollo implements the SAME WebKit layout engine / WebKit docuemtn model as Google Chrome, Apple Safari-iPhone, Nokia, RiM and the Iris "Smart Phone" browser. The WebKit model is based on advanced HTML, CSS, SVG and JavaScript. Where Adobe goes proprietary is in replacing SVG with the proprietary SWF. The differences between JavaScript and ActionScript are inconsequential to me, especially given the problems at Ecma. One other point not covered by Kontra is the fact that Apollo and Silverlight can run as either browser plugins or standalone runtimes. Wha tthey can't do though is run as sufing browsers. They are clearly for Web Applications. Chome on the other hand re-invents the browser to handle both surfing mode AND RiA. Plus, a Chrome RiA can also run as a plugin in other browsers (Opera and FireFox). Very cool. The last point is that i wouldn't totally discount Apple RiA. They too use WebKit. The differnece is tha tApple uses the SquirrelFish JavaScript JiT with the SproutCore-Cocoa developers framework. This approach is designed to bridge the gap between the OSX desktop/server Cocoa API, and the WebKit-SproutCore API. Chrome uses the V8 JiT. And Adobe uses Tamarin to compile JavaScript-ActionScript. Tamarin was donated to the Mozilla community. If there is anythin that will s

Yet another wrapper around OpenOffice.org, this time the 3.0 version still in beta. $99.90 per seat for 10 users, Lots of Javascript to give a web collaboration capability. Perhaps most notable so far: [i] a sniff that there's a fair amount of money behind this one; and [ii] an article by Eric Lai says they approached the OOo Project but were rebuffed because they compete with desktop OOo. Support for different browsers planned. an XULRunner plug-in the works. Several mashups mentioned. Claims 80 percent of OOo features available, which is another way of saying that 20 per cent of the features are not supported. Claim that oSays code will be released under GPL. Apparently that's just their custom stuff because OOo 3.0 beta is LGPL. Building a business atop a code base controlled by a malevolent branch of Sun Microsystems seems less than wise. More at zooos.com. Preliminary impression: Like OOo itself, dead end technology that sucks mind and market share from software that supports truly open standards. The world needs to figure out that the OpenDocument format is roughly as open as OOXML. Open standards are fully specified so anyone can implement them.

Web Content Editing Made Simple Only EditLive! offers true ease of use with enterprise capabilities. It is the ideal solution for editing rich HTML documents in CMS, wikis, blogs, email and more. Give your content authors an editing solution that they will actually use. The Word-like interface makes content creation easy for business users who know nothing about HTML and want to keep it that way.