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

[Mark Rowe]

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 
compiler.

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.

Kind regards,

Mark Rowe
<http://bdash.net.nz/>