I’ve written an article (in Finnish, sorry) comparing the data model approaches of two HTML5 application frameworks, Backbone and Spine:
http://kfalck.net/2011/12/29/tietomallit-html5-sovelluksissa-backbone-vs-spine
My main conclusion is that Spine (which uses CoffeeScript) allows for simpler apps, with less mandatory boilerplate and less unnecessary complexity. On the other hand, Backbone (which uses JavaScript) has more features, such as field-level data modification events.
This isn’t a technical article (sorry for misleading title :)). The title should be “We Need Your Help”.
We will be arranging monthly events and meetups during next spring: Upcoming Events – Spring 2012 | Frontend.fi Events. The goal is to arrange an event with topical discussion every month. But… we’re missing premises.
We’ve already arranged three successful events. But lately it has been a bit harder to find decent premises for larger events with lectures and discussion.
Our humble request is: if you happen to know premises we could use for the events, then 1) check the upcoming dates from our event calendar and 2) please contact us at info at frontend dot fi. We’re quite sure there are many companies with good premises available to borrow or to rent.
So, this our “call to action”: help us to arrange more events in future. Thank you!
Google has released a new programming language, Dart, for building up web applications in GOTO Aarhus 2011. It’s a class-based programming language for creating structured web applications.
You can get familiar with Dart at: http://www.dartlang.org/. And if you want to quickly try it yourself, visit http://try.dartlang.org/. In addition, if you want to build Dart yourself, visit GettingTheSource.
But is there a need for (yet) another programming language? Will Dart replace some parts of JavaScript or other languages that compiles into JavaScript (eg. CoffeeScript) as some authors tend to claim? Who will benefit from using Dart?
Please, share your opinions.
Meanwhile, we’ll try to keep this post updated as more information is revealed.
In the browser stats discussion Tuomas Salo suggested the screen resolutions of Ilta-Sanomat users would be interesting.
Thanks yet again to Timo Rinne, here we have them.
iltasanomat.fi screen size stats from the last 30 days
Not maybe a surprise that resolutions below 1024 width basically don’t exist anymore. 1024 width is down to 11,2%.
The success of 1024×768 can be most probably explained by it being the iPad’s resolution. On the other hand I would guess it’s often the same legacy people who use IE6 and IE7 (~8%) that haven’t upgraded from their CRT monitor, probably dating back to 1996.
For screen height seems 768 is the safe bet as 768 & 800 combined hold a share of 37.17%.
I guess the average of pixels on screen while reading iltasanomat.fi is around 1 million.
This time thanks to Asmo Halinen and Iltalehti we have fresh stats on the Finnish mobile browsers and devices!
As Iltalehti has ~2 million unique weekly visitors online I would judge their mobile site to be a good representation of the Finnish mobile web userbase. However note that these numbers are only from the the low-end compatible m.iltalehti.fi. In addition their portfolio includes for example an iPhone app which is excluded from these numbers. Thus I would guess these stats are biased toward the low-end devices (mostly Nokia).
m.iltalehti.fi browser stats from 8.-14.8.2011
We can see a more even competition here than in the computer browsers. Again there are three big ones and Opera as a steady marginal browser. The Mozilla Compatible Agent means basically Nokia Symbian phones. I would expect that to go down in favour of Internet Explorer during the next 12 month.
Safari, Android browser and Opera all support HTML5 to some extent. Symbian browser less so, for example even the fresh new Symbian Anna browser still won’t support local storage, one of the most useful features of HTML5.
Here are the device shares (operating systems) from 8.-14.8.2011 (as delivered by Asmo Halinen):
SymbianOS 38,4% Android 25,5% iPhone 16,2% Nokia 2,8% Samsung 1,0% Windows 0,8% iPod 0,7%
The numbers are pretty much the same as in browsers. This just shows how hand in hand the browsers and devices still go today apart for the good work Opera has done. One notable thing is that Safari has a share of 26,98% while iPhone and iPod combined make only 16,90%. I wonder if this is a bias in the stats or if Safari is really used that much outside of Apple devices.
Big thanks to Timo Rinne and Ilta-Sanomat for the openness to drive forward the Finnish web developer community!
The stats are from www.iltasanomat.fi and are from the last 30 days. Note that the mobile site is not part of these stats. I would regard this as a very good benchmark on the current state of the Finnish browser base taking into account Ilta-Sanomat’s ~2 million unique weekly visitors. According to my calculations 92% of the used browsers support HTML5 at least on some level.
iltasanomat.fi browser stats from the last 30 days
Yayi! Firefox has overtaken IE. Also Chrome & Safari are well in competition. Something that would have sounded hard to believe 5 years ago when IE was dominating. The only browser that hasn’t really managed to anywhere is Opera, a steady marginal browser.
iltasanomat.fi Internet Explorer stats from the last 30 days
Glad to see IE6 at 0.6% out of all browsers. Also IE7, last Microsoft browser without any HTML5 support, is now at 7.4%. There is still someone with IE5, good luck to her…
iltasanomat.fi Firefox stats from the last 30 days
Firefox keeps its browser base pretty well updated. I wonder what’s with the crowd stuck at version 3.6.18?
If you have created JSON based REST APIs that return top-level arrays, you should read this article. The illustrated situation is having an API in a known URL, let’s say http://example.com/api/mydata.
It returns an array:
["my", "secret", "data"]
Now it’s possible to construct a third party site, in another domain, which uses a <script> tag to load that URL. JavaScript can be loaded across domains to accommodate advertising systems:
<script src=”http://example.com/api/mydata”></script>
Normally, loading the URL via a <script> tag does nothing, because the JSON is evaluated and as it doesn’t set any global variables, the data cannot be accessed. But by maliciously overriding JavaScript’s internal Array prototype, you can create a custom constructor to “steal” and copy the data when the anonymous top-level array is created. Check the original article for an example.
The fix is to use top-level objects instead of arrays in your JSON. So the API would return something like this instead:
{ “mydata”: ["my", "secret", "data"] }
In this case, the JSON cannot be loaded as a standalone JavaScript file, because top level object literals are a syntax error.
Moral of the story: It’s best to always return top-level objects from your JSON APIs, even if the data structure design becomes slightly less elegant.
Here’s a notification e-mail many of you might have received today:
“We are contacting you to let you know you important changes in Google Apps browser support and recommended steps to take.
Beginning on August 1, 2011, Google Apps support for the following browsers versions will be DISCONTINUED:
- Microsoft Internet Explorer 7
- Mozilla Firefox 3.5
- Apple Safari 3″
And furthermore:
“For this reason, beginning August 1, 2011, Google Apps will support the current and previous major releases of Chrome, Firefox, Internet Explorer and Safari on a rolling basis. Each time a new version is released, we’ll begin supporting that version and stop supporting the third-oldest version.”
I really hope others will follow Google’s lead.
jQuery 1.6 is out already. It’s been just three months after release of version 1.5. Biggest changes is in Attribute module. jQuery handles now DOM attributes and DOM properties separately. This is important to remember for example when checking if checkbox is checked. With older jQuery you could check it with $(“#mycheckbox”).attr(“checked”), but as of 1.6 attr(“checked”) will return actual value of the attribute, which is usually an empty string. I can imagine this change will cause quite a few curse words among developers who aren’t aware of this change.
Performance improvements is also significant. Check image below to see how huge improvements I am talking about.
Source: http://blog.jquery.com/
As somebody who reguarly uses return false at the end of JavaScript click events, this article (HN comments) came as a bit of a surprise for me.
The return false statement is typically used in click handlers to prevent the browser from navigating to a hash URL when clicking a link like <a href=”#”>. If you forget to put it in, you will see an extra “#” appearing in the browser’s URL bar when you click the link.
But what you really should be doing is calling event.preventDefault(). Why? Because return false will also stop the event from propagating to parent elements, which might need to know about the click.
In other words, if you have a structure like <div><a href=”#”></div>, the parent div will never see the click event. By using event.preventDefault() you will allow it to see the click, enabling you to add click events to both the a and div elements as needed.
As mentioned in the Hacker News comments, the widespread use of return false is largely due to IE6 not supporting event.preventDefault(). However, if you use jQuery, it will automatically normalize the event objects so that event.preventDefault() works also on IE6.