4 ms·

Well BB10 devices might not be for sale, but the browser has been shown off and it is part of the dev devices that developers got at BBJam in September. If you

by icefox 14y ago

Well BB10 devices might not be for sale, but the browser has been shown off and it is part of the dev devices that developers got at BBJam in September. If you want to see a little preview of it in action checkout this preview video taken at BBJam http://www.youtube.com/watch?v=onNTDUncA44 http://www.youtube.com/watch?v=onNTDUncA44 If you follow the link in the article to Matt's post on the RIM developer blog there are more articles on the browser and what it has: http://devblog.blackberry.com/2012/11/blackberry-10-browser-html5-standards/ http://devblog.blackberry.com/2012/11/blackberry-10-browser-... As mentioned in the video one of the neatest aspects of the browser is the fact that the chrome itself is written in HTML/JS. So the animations, transitions etc are all done by WebKit. The BlackBerry browser includes support for remote inspecting which meant not only could we host the chrome on our desktop while developing, but we could debug it from a WebKit browser on our desktop, all while it was running on the device. When you make a web application for BlackBerry10 it will be on top of the WebWorks platform which sits on top of the same HTML Runtime that the browser is using which aligned rim's interests to make sure that web applications work well. For the curious a much more in depth look at the browser and how it was made was shown at this BlackBerryJam session: http://hosting.desire2learncapture.com/RIM/1/watch/50.aspx http://hosting.desire2learncapture.com/RIM/1/watch/50.aspx Disclaimer: I am part of the WebKit team at RIM.

colton36 14y ago
Have you guys managed to avoid the sluggishness issues similar to the ones Mozilla team encountered years ago when the decided to also build the chrome via XUL (HTML/JS/CSS)?
- icefox 14y ago
  One thing to remember is that when the Mozilla team originally created XUL browser engines were a different beast. At the top you have JavaScript which is _significantly_ faster on many different levels. Combine that we current html features supported (and or optimized) by some WebKit ports such as hardware accelerated CSS transitions and you get a much a strong base to create applications on top of. Also writing large JavaScript applications were new back then. These days we have several years of lessons about what works and what doesn't. Lastly the tool situation is much better. Simply what you can get if you limit yourself to inspector is pretty crazy. Remember Firebug didn't even come out until 2006 if I recall. And if all that isn't good enough the HTMLRuntime is multi-process so you absolutely wont run into the contention for the JavaScript engine between the chrome and the pages. To see some animations in action checkout the above video links. Disclaimer: I am part of the WebKit team at RIM these opinions are my own
jonhohle 14y ago
> As mentioned in the video one of the neatest aspects of the browser is the fact that the chrome itself is written in HTML/JS. Why, as an end user, would I ever care about this? All this says to me is that the part of the browser which should be fast and get out of the way is written in an abstraction layer with significant overhead (compared to the alternative, native code), which - to me - means using more RAM and CPU, increasing the cost or decreasing the performance of the device. As a tech demo, I think it's a neat idea. But as a "one of the neatest aspects" of a commercial product, I'm not inclined to be interested in the rest of the app.
- icefox 14y ago
  I highlighting this feature for this particular crowd because the same bits that make the html web applications work on BlackBerry10 is what drives the new Chrome. This means that the guys making the chrome _really_ do care that html applications work well. As for overhead the browser team has always concerned itself with keeping its footprint down both in memory and cpu and by using JS+HTML our total overhead was actually reduced compared to running another framework along side WebKit just for the Chrome. Checkout the above second video for more in depth presentation on this. Disclaimer: I am part of the WebKit team at RIM these opinions are my own

by icefox 14y ago

colton36 14y ago

Have you guys managed to avoid the sluggishness issues similar to the ones Mozilla team encountered years ago when the decided to also build the chrome via XUL (HTML/JS/CSS)?

icefox 14y ago
One thing to remember is that when the Mozilla team originally created XUL browser engines were a different beast. At the top you have JavaScript which is _significantly_ faster on many different levels. Combine that we current html features supported (and or optimized) by some WebKit ports such as hardware accelerated CSS transitions and you get a much a strong base to create applications on top of. Also writing large JavaScript applications were new back then. These days we have several years of lessons about what works and what doesn't. Lastly the tool situation is much better. Simply what you can get if you limit yourself to inspector is pretty crazy. Remember Firebug didn't even come out until 2006 if I recall. And if all that isn't good enough the HTMLRuntime is multi-process so you absolutely wont run into the contention for the JavaScript engine between the chrome and the pages. To see some animations in action checkout the above video links. Disclaimer: I am part of the WebKit team at RIM these opinions are my own

jonhohle 14y ago

> As mentioned in the video one of the neatest aspects of the browser is the fact that the chrome itself is written in HTML/JS. Why, as an end user, would I ever care about this? All this says to me is that the part of the browser which should be fast and get out of the way is written in an abstraction layer with significant overhead (compared to the alternative, native code), which - to me - means using more RAM and CPU, increasing the cost or decreasing the performance of the device. As a tech demo, I think it's a neat idea. But as a "one of the neatest aspects" of a commercial product, I'm not inclined to be interested in the rest of the app.

icefox 14y ago
I highlighting this feature for this particular crowd because the same bits that make the html web applications work on BlackBerry10 is what drives the new Chrome. This means that the guys making the chrome _really_ do care that html applications work well. As for overhead the browser team has always concerned itself with keeping its footprint down both in memory and cpu and by using JS+HTML our total overhead was actually reduced compared to running another framework along side WebKit just for the Chrome. Checkout the above second video for more in depth presentation on this. Disclaimer: I am part of the WebKit team at RIM these opinions are my own