Skip to main content

Home/ Future of the Web/ Group items tagged apollo

Rss Feed Group items tagged

Gary Edwards

Google Chrome: Bad news for Adobe « counternotions - 0 views

  • Agree with much of what Kontra said and disagree with many who mentioned alternatives to JavaScript/Chrome. The main, simplest reason Adobe will be in a losing fight in terms of web platform? The Big Two - Google and Microsoft - will never make themselves dependent on or promote Adobe platform and strategy.
  • Luis, I think that’s already in play with HTML5. As I pointed out in Runtime wars (2): Apple’s answer to Flash, Silverlight and JavaFX, Apple and WHATWG are firmly progressing along those lines. Canvas is at the center of it. The glue language for all this, JavaScript, is getting a potent shot in the arm. The graphics layer, at the level of SVG, needs more work. And so on.
  •  
    "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
Gary Edwards

Google on Google Chrome - comic book - 0 views

  •  
    Google Chrome is Google's browser project based on the extraordinary WebKit portable layout engine. Yes, Google has written their own open source browser. The reasons for Google taking this unusual step are very compelling - as this excellent presentation explains. I also think Chrome will be a game changer. The WebKit engine shows up in Adobe's Apollo RiA and, Apple's SproutCore-Cocoa RiA model. Microsoft of course offers the OOXML-XAML-Silverlight RiA that is based on .NET-WPF proprietary formats, protocols and interfaces. These are RiA efforts can be used as either browser plug-ins or stand alone runtimes. Now Google has entered the RiA fray with both feet coming down hard on a browser based runtime engine. Google RiA isn't a "Plug-in". It's the browser as both a browser and RiA runtime engine. Very cool. Let the battle begin!
Gary Edwards

SitePen Blog » Inside the Dojo Toolbox - 0 views

  •  
    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.
Gary Edwards

InternetNews Realtime IT News - The Next Wave in Collaborative Software - 0 views

  •  
    There were three must see demonstrations at Office 2.0; Adobe Genesis, Joblogs and GE. Genesis and Joblogs are stunning examples of what RiA will mean int he future. GE offered a rather extraordinary example of how collaborative computing changes everything in the workplace. GE' Suk made an interesting statement, "Collaboration is simply a digital version of how a workgroup "works" a business process." Done right, collaboration becomes the business process.
  •  
    RiA is making the leap from web design to web application by first reinventing the end users "workspace-workgroup" experience. "... The winds of change are blowing through collaborative software, and they're blowing pretty hard. Here at the Office 2.0 conference, Adobe Systems and Joblogs previewed their approaches, which are strikingly similar. They both offer real time collaboration. Both use mash-ups and provide ease of use well beyond today's collaborative systems, which Joblogs founder Steve Ireland described as "workspace 1.0." Both are aimed at the enterprise and seek to provide context around the user's workspace, doing mash-ups (define) of contact databases, e-mail, calendars, photos, and task lists, although Joblogs' application also offers blogs.
Gary Edwards

The real reason Google is making Chrome | Computerworld Blogs - 0 views

  •  
    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.
1 - 5 of 5
Showing 20 items per page