WebKit2, now with multiprocess architecture.
This is quite a nice idea that has the potential to increase the overall stability of major WebKit based browsers. While I sense some friction between the two competing products Safari and Chrome for obvious reasons, I expect both teams taking the best solutions. I would like to see:
- Safari adopting the faster V8 JavaScript engine from Google.
- Chromium improving the already excellent UI application layer with the WebKit2 adoption.
- Microsoft open sourcing IE9. LOL
http://trac.webkit.org/wiki/WebKit2
https://lists.webkit.org/pipermail/webkit-dev/2010-April/012255.html
This is quite a nice idea that has the potential to increase the overall stability of major WebKit based browsers. While I sense some friction between the two competing products Safari and Chrome for obvious reasons, I expect both teams taking the best solutions. I would like to see:
- Safari adopting the faster V8 JavaScript engine from Google.
- Chromium improving the already excellent UI application layer with the WebKit2 adoption.
- Microsoft open sourcing IE9. LOL
http://trac.webkit.org/wiki/WebKit2
https://lists.webkit.org/pipermail/webkit-dev/2010-April/012255.html
Post from Google Buzz, 13 people liked this, 10 comments
iPhone SDK and Developers
I'm having some fun with the recent discussions about the change in the iPhone SDK License Agreement regarding programming languages. For most developers, this is the perfect nonsense situation, a complete stupidity,..., bla, bla.
The missing point is that programming languages are not the problem. The big problem is what I call the executing runtime environment for a specific technology. For example, for Java technology you need the Java Virtual Machine, for .NET technology you need the .NET Framework, for Flash you need the Flash player, for native applications you need to rely in the OS and native libraries.
All the languages I know (including Objective-C) are computationally equivalents so theorically, it doesn't matter what is your choice, but in practice there is a totally different story. Every language is tightly coupled to a technology and in some cases to a specific OS.
Restricting the allowed languages is a mere (and agresive) shorcut to keep away poorly crafted runtime environments layered on top of the native iPhone OS. This is a great benefit for people who actually use the iPhone like a phone and in some way, the business itself.
I have more to say but I prefer reading your comments first.