I was hoping we’d hear from Don Melton on the idea that Safari is the new IE and he didn’t disappoint. For those that don’t know Don is the man that started the WebKit and Safari projects at Apple. He’s also a former Netscape developer so he’s been around the web and web browsers for a very long time. If you have some time go listen to Debug 69, it’s a bit explicit, Don like to drop the F-bomb, but it’s also very informative.
Two things stood out about how the Safari team approaches development of new things. They really care about security and battery life, since mobile is now king. It’s apparent they introduce features quite a bit more slowly than Google. That fact goes a long way to explaining why Google forked WebKit to create the Blink project. They wanted to move faster and felt held back by Apple’s WebKit team.
UPDATE: 7/25/2015 – I sent a link to Mr. Melton via Twitter and he graciously took the time to come read this post, which I really appreciate. Afterward he provided some excellent feedback. Here’s a correction to the statement above:
@Fahrni WebKit isn’t moving slower than Blink, just differently. And Google didn’t fork it to move faster. They did it simply for control.
— Don Melton (@donmelton) July 25, 2015
Something I’ve been an advocate for is the implementation of the ECMA CLI in all web browsers. It was interesting to hear Don talk about the idea of Web Assembly, which is the new push to make languages that convert down to JavaScript so you can write in multiple languages on the web (which is why I’m a fan of a CLI implementation, we could have C# on in the browser, nifty.) Don’s take made me reevaluate my position. Why not let websites be websites and let applications be applications? Both need HTTP and the web. I’m a fan of web services and that is definitely the new backbone of any application development today. A lot of applications, be it in the browser, or native, depend on web services to do their job. The application I work on daily is no exception. At Agrian we have a web application and a native iOS App backed by a web service. The native application was created because Agrian wanted to create the best user experience they possibly could, not to mention provide a great offline experience. Our application is used by farmers that are often out in the country side, and often without connectivity. Changes are cached and synchronized when the farmer has a connection. It provides a good experience all thanks to the ability to save while offline and push changes to our web service when the time is right. Wow, sorry, went off the rails there.
The point is, I’m not sure making the web browser do everything you can do on the desktop is the right thing to do. Let the web be the web. If you want to do a native application embrace the platform and do the best possible job you can for your users. This holds true for Android or iOS. Both provide great SDK’s built to take full advantage of the platform.
Go forth and create.
