Re: [dev] Talk about sane web browsers

From: Anselm R Garbe <garbeam_AT_gmail.com>
Date: Tue, 8 Sep 2009 14:02:50 +0100

2009/9/8 Uriel <lost.goblin_AT_gmail.com>:
> On Tue, Sep 8, 2009 at 11:50 AM, Anselm R Garbe<garbeam_AT_gmail.com> wrote:
>> 2009/9/8 Uriel <lost.goblin_AT_gmail.com>:
>>> On Tue, Sep 8, 2009 at 10:07 AM, Anselm R Garbe<garbeam_AT_gmail.com> wrote:
>>>> I think it is clear that the existing web stack can't be implemented
>>>> in a less sucking way.
>>>
>>> This is ridiculous, are you saying that a web rendering engine can't
>>> suck less than webkit or geko? Are you fucking kidding me?
>>
>> Theoretically it can suck less than webkit, geko or what not, but it
>> still would suck much more than a web replacement engine that has not
>> to support the current web stack.
>>
>> BUT it is nearly impossible to do considering the man years needed to
>> make the existing web stack "work" and the continuous effort to keep
>> it working (considered all the upcoming features such as html5,
>> geolocation, device apis, etc that are expected to be supported by a
>> browser engine).
>>
>> Undertaking the development of a less sucking browser engine could
>> easily end up in a more sucking browser from the end user point of
>> view... because it won't support every web page. Or in other words it
>> will be the w3m or lynx  experience when trying to access Google Maps
>> ;)
>>
>>> Any implementation will suck hugely, but there is tons of shit that
>>> suck in webkit and geko that are in no way required to suck to be 'web
>>> compatible'.
>>
>> Have you considered that this is because of the web stack and not
>> because of stupid WebKit C++ developers?
>>
>> I mean come on, that netsurf thing is barely comparable to WebKit atm,
>> otherwise you must be joking.
>>
>>>> That's why it's quite clever and pragmatic to
>>>> let the WebKit folks do the ugly work.
>>>
>>> It might be pragmatic, but there is nothing 'clever' about it.
>>
>> The "clever" aspect is that others do the work, mostly people that
>> have far more clue about the current web stack than ourselves...
>>
>>> Chrome is not a black box, what I meant was that Chrome has put WebKit
>>> into something much closer to a real black box than what uzbl and surf
>>> are doing.
>>
>> Ok
>>
>>>> Second, I see nothing wrong with experimenting with browser chromes
>>>> like what uzbl or surf do.
>>>
>>> Experimenting with anything is cool, pretending it is something it
>>> clearly isn't is not cool. Uzbl and surf are not 'sane browsers' that
>>> 'follow the Unix Philosophy', and to claim so is to be either
>>> delusional or disingenuous.
>>
>> I more and more dislike using the term "unix philosophy". At least the
>> official surf website doesn't claim surf to follow the unix philosophy
>> or to be "sane" in some way. I didn't follow the whole thread here
>> however.
>>
>>>> BUT using Chrome as a base looks like much more effort to me, not to
>>>> mention its baroque build system.
>>>
>>> Perhaps, but Chrome has actually built something much closer to a real
>>> black box around WebKit, which is what some people here were claiming
>>> they had done, when it clearly isn't the case, and unless that is
>>> addressed not only will uzbl and surf be little more than very thin
>>> coats of paint on top of the sewage leaking WebKit turd, they will
>>> also be insecure and performance hogs.
>>
>> I'd be careful with this "Google gets it right" trust.
>
> Don't give me this shit, Google could not get 2+2 right even if their
> stock options depended on it.
>
> Still the design of the Chrome architecture is *way* saner than that
> of any other browser out there. It is still hideous and awful, but if
> you can see it is light years ahead of the mozilla crack monkeys or
> the Apple cult of fucktards, you have no clue what you are talking
> about.
>
> Of all things Google has done since they built a search engine, Chrome
> might be the first that is not pure liquid shit (if there were others,
> I have forgotten them).
>
>>Theoretically a
>> very thin layer around WebKit should perform better, have less bugs
>> and be more secure than the rather thick layer of "Google Chrome" --
>
> Theoretically and practically you have fuck shit clue what you are
> talking about. You are wrong on *every account*.
>
> Perhaps you want to go back to operating systems where all code runs
> in ring 0 and all processes are cooperatively scheduled, that is much
> simpler so according to your 'theory' it should perform better, have
> less bugs and be more secure.
>
>> but this only holds unless the developers of both layers are similar
>> experienced.
>
> This has very little to do with the experience of any developers and
> with the architecture involved. Precisely because the Chrome design
> means that mistakes are much less harmful, so even if developers are
> total morons (which they are), they can cause much less damage.
>
>> And one has to admit that Google has hired damn good
>> developers compared to the average IT world.
>
> Hah! Google developers are a bunch of delusional XML-addled crackheads
> that for the most part could not build any system worth shit without
> ruining it with tons of Java, XML, C++, OO and any other garbage
> imaginable.
>
> Still, somehow, god only knows how, they have come up with a design,
> that while it sucks, it is *way* superior to that of any other major
> web browser out there.
>
> uriel
>
> P.S.: Funny thing, I was comparing mentally the architecture of chrome
> to that of all other browsers, and realized the one it is most closely
> similar to is abaco! (Of course not quite, and actually in a few ways
> the division of labour among he various processes is more sensible in
> Chrome!).

So you judge about things you believe you have superior clue about,
then go ahead and do us a favor and build a decent web browser that we
can all be happy with.

As I said very often to you: talking and discrediting things is
*simple*, but getting things done isn't. Perhaps you are brave enough
to proof your judgements with a real piece of software development one
day?

Kind regards,
Anselm
Received on Tue Sep 08 2009 - 13:02:50 UTC

This archive was generated by hypermail 2.2.0 : Tue Sep 08 2009 - 13:12:02 UTC