2009/9/9 Pinocchio <cchino...@gmail.com>: >>> I am saying this because even after a lot of marketing muscle and >>> commercial force, it has been hard for Adobe, Sun and Microsoft to push >>> their rendering stacks over HTML + Javascript. Flash is the only thing >>> which gained major adoption... and the picture might change once HTML 5 >>> comes out. >>> >> >> The Flash strategy is definitely what I have in mind. >> > > I guess the problem would be convincing the 100s of millions of people to > install our plugin. Much worse than converting web app developers to our > stack. [I have a feeling I didn't quite get your point here...]
Well, before taking the penetration aspect too far -- it is more important to discuss the actual new web stack first. Key to it is that it provides benefits wrt the existing web stack in many aspects (like flash *yuck* or silverlight -- not too sure about silverlight adoption though), that in itself will drive adoption. (Packaging the new browser as a plugin for legacy browsers would make a lot of sense though to drive adoption.) But what I'm more interested in is this: - knowing the limitations of HTTP and complexity of HTTP/1.1 compliant web servers, shouldn't the new web stack rely on a new protocol instead? - knowing the limitations of nowadays web applications, how should the content be organized? Should there be a strict separation of data/content and views? How would extension points look like? How would a scripting interface look like? What about security to begin with? - what content should be representable? When seeking for real benefits in a new web stack, the benefits can't be of plain "less sucking implementation/standard" nature, because end user won't care if the underlying technology sucks less or sucks a lot, they can't decide and they have no strong opinions about it (like usual car customers don't really care if it's an Otto motor or a Wankel motor or a Boxer). I think the benefits could be in the following areas: - presentation: less limitations/more freedom in how content can be displayed, better display format (this has to be done right, one reason for flash's success was that it provides a way to present content that can't be achieved in static HTML+CSS), using HTML+CSS isn't great and very limited in possibilities for presentation - ease-of-use: I think the web [2.0] is quite successful, because absolute beginners can create a web page + some scripting logic without the need to know a lot about programming or computers in general, a driver for a new web stack must take this into account, it has to be simpler than HTML+CSS for noobs - collaboration: less limitations wrt embedding/interfacing with [foreign] content - consistency: consistent display among all platforms (requires a clear and explicit standard spec) - performance: better performance (this depends on the content standard and potentially the protocol) - security: better security (this might be not a big adoption driver though) Feel free to add your thoughts... >>> Benefits of going the suckless format: >>> - Concise, hacker friendly, open source implementation. >>> - Rapid evolution of the format to new usage scenarios. >>> - Platform support, acceleration >>> - Warm fuzzy feeling of using less RAM + CPU cycles for rendering >> Maybe it is not that hard to do. I think it is possible to build a >> prototype using Lua with some GUI toolkit bindings for instance: the >> server would send the Lua source to the client, and the client interprets >> it. Please no lua. I've seen that before... Kind regards, Anselm