Re: [dev] Talk about sane web browsers

From: Anselm R Garbe <garbeam_AT_gmail.com>
Date: Wed, 9 Sep 2009 09:06:20 +0100

2009/9/9 Pinocchio <cchinopio_AT_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
Received on Wed Sep 09 2009 - 08:06:20 UTC

This archive was generated by hypermail 2.2.0 : Wed Sep 09 2009 - 08:12:03 UTC