[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: SimpleWebKit (was GNUstep Web browser (was Re: WebKit Bounty))

From: Yen-Ju Chen
Subject: Re: SimpleWebKit (was GNUstep Web browser (was Re: WebKit Bounty))
Date: Tue, 20 Mar 2007 11:41:08 -0700

On 3/20/07, Mark Rowe <bdash@webkit.org> wrote:
Hi there,

I'm not interested in getting into a debate about which direction
GNUstep should take for developing a web rendering engine.  As a
complete outsider to the community anything I say has little influence,
and I have no place in trying to exert any.  I am merely trying to
share some of the knowledge and experience that I have acquired over
the few years that I have been involved with WebKit.  If the GNUstep
community decides to move towards a different solution, whether it be
SimpleWebKit or some other appropach, I wish you the best of luck.

I'll only address the points relevant to WebKit below:

On 03/20/07, Riccardo <multix@ngi.it> said:

> Although people will say Obj-C++ was needed because of the usage of
> KHTML, I think that Apple underestimated the task of getting KHTML to
> work cleanly and if those resources were put in better use a cleaner
> and better WebKit woul dhave existed. And no need of ugly languages,
> less crashes, better memory managment. And about speed - I don't know.

Speed and memory footprint are *huge* factors in the choice of language
in a situation such as this. WebKit in Safari 2.0.4, the version
currently shipping with Mac OS X 10.4, is one of the fastest browsers
available on any platform.  The current development version has had
substantial performance improvements in many areas.  This is achieved
through a combination of smart algorithms and a programming language
that can take advantage of the computing resources available.  While
Objective-C is a lovely language to develop in, it's dynamic nature
severly limits the possibility for performance optimisations by the

If you believe Objective-C is the One True Programming Language then by
all means use it to develop a web platform.  WebKit is in many ways
about using the right tool for the job.  The performance-criticial
portions in WebCore and JavaScriptCore are written in C++.  The
easy-to-use API that most developers see on a day-to-day basis is
Objective-C in the WebKit layer.   Objective-C++ allows high
performance without sacrificing a developer-friendly API.

> [...]  porting WebKit will be a great task too, will probably need
> latest compilers
> and will bind us at Apple.
> What if in the future WebKit will need Obj-C 2.0 features - let us be
> saved. Or it will ocnstantly need some ugly Core* stuff? Or some other
> decisions whcih might hurt us or which we don't want to share?

The core functionality in WebKit is in cross-platform C++ code.  Both
JavaScriptCore and WebCore are buildable without any dependencies on
Apple-specific technologies, even on Mac OS X.  The implementation of
the WebKit API layer, and it's hooks into JavaScript via
WebScriptObject etc, currently has some dependencies on either
CoreFoundation, Mac OS X private APIs, or Cocoa implementation details.
 A port to GNUstep would involve factoring these platform-specifics out
of the main code.

WebKit currently makes use of Objective-C 2.0 features if you're
building it on a prerelease version of Mac OS X 10.5.  This is purely
an API nicety, it is no way used in the implementation of WebKit
itself.  As far as I know there a no plans to use any Objective-C 2.0
language features in WebKit in the near future.  If GNUstep developers
are involved with WebKit there would be a good incentive to keep the
current state of play.

I think this quotation from Mark's comment on blog
summarizes what work needed to be done:

"JavaScriptCore and WebCore are quite portable,
and have already been ported to Qt, Gdk and Windows.
Work would need to go in at the WebCore layer to support
GNUsteps rendering primitives (the Mac OS X version use
CoreGraphics so isn't directly portable). Work would also need
to go in at the WebKit level to have it function on GNUstep
without its Mac OS X dependencies."


Kind regards,

Mark Rowe

Discuss-gnustep mailing list

reply via email to

[Prev in Thread] Current Thread [Next in Thread]