Skip to main content

Home/ Future of the Web/ Group items matching "close" in title, tags, annotations or url

Group items matching
in title, tags, annotations or url

Sort By: Relevance | Date Filter: All | Bookmarks | Topics Simple Middle
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.
Gary Edwards

Siding with HTML over XHTML, My Decision to Switch - Monday By Noon - 0 views

  • Publishing content on the Web is in no way limited to professional developers or designers, much of the reason the net is so active is because anyone can make a website. Sure, we (as knowledgeable professionals or hobbyists) all hope to make the Web a better place by doing our part in publishing documents with semantically rich, valid markup, but the reality is that those documents are rare. It’s important to keep in mind the true nature of the Internet; an open platform for information sharing.
  • XHTML2 has some very good ideas that I hope can become part of the web. However, it’s unrealistic to think that all web authors will switch to an XML-based syntax which demands that browsers stop processing the document on the first error. XML’s draconian policy was an attempt to clean up the web. This was done around 1996 when lots of invalid content entered the web. CSS took a different approach: instead of demanding that content isn’t processed, we defined rules for how to handle the undefined. It’s called “forward-compatible parsing” and means we can add new constructs without breaking the old. So, I don’t think XHTML is a realistic option for the masses. HTML 5 is it.
    • Gary Edwards
       
      Great quote from CSS expert Hakon Wium Lie.
  • @marbux: Of course i disagree with your interop assessment, but I wondered how it is that you’re missing the point. I think you confuse web applications with legacy desktop – client/server application model. And that confusion leads to the mistake of trying to transfer the desktop document model to one that could adequately service advancing web applications.
  •  
    A CMS expert argues for HTML over XHTML, explaining his reasons for switching. Excellent read! He nails the basics. for similar reasons, we moved from ODF to ePUB and then to CDf and finally to the advanced WebKit document model, where wikiWORD will make it's stand.
  •  
    See also my comment on the same web page that explains why HTML 5 is NOT it for document exchange between web editing applications. .
  •  
    Response to marbux supporting the WebKit layout/document model. Marbux argues that HTML5 is not interoperable, and CSS2 near useless. HTML5 fails regarding the the interop web appplications need. I respond by arguing that the only way to look at web applications is to consider that the browser layout engine is the web application layout engine! Web applications are actually written to the browser layout/document model, OR, to take advantage of browser plug-in capabilities. The interoperability marbux seeks is tied directly to the browser layout engine. In this context, the web format is simply a reflection of that layout engine. If there's an interop problem, it comes from browser madness differentials. The good news is that there are all kinds of efforts to close the browser gap: including WHATWG - HTML5, CSS3, W3C DOM, JavaScript Libraries, Google GWT (Java to JavaScript), Yahoo GUI, and the my favorite; WebKit. The bad news is that the clock is ticking. Microsoft has pulled the trigger and the great migration of MSOffice client/server systems to the MS WebSTack-Mesh architecture has begun. Key to this transition are the WPF-.NET proprietary formats, protocols and interfaces such as XAML, Silverlight, LINQ, and Smart Tags. New business processes are being written, and old legacy desktop bound processes are being transitioned to this emerging platform. The fight for the Open Web is on, with Microsoft threatening to transtion their entire business desktop monopoly to a Web platfomr they own. ~ge~
« First ‹ Previous 121 - 122 of 122
Showing 20 items per page