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.