Libraries

Datatable to barchart without images, libraries or plugins

Following the results of a survey on library use by developers I was asked to make it easier to do a head to head comparison of the data of one of the questions. I thought it’d be interesting to start a dynamic bar chart from scratch and it is incredible just how easy these things are nowadays.

Animated barchart from datatable example

Here is the final result:

The code is available on GitHub and you can see it in action there, too.

Check the code comments to see what I did – there is no magic in there, just using what browsers give us these days.

There is a bit more to it as I explain in this Screencast on YouTube:

If you don’t want the barcharts to show up but check if meter or progress is supported instead, add a parameter to the URL:

This is an interesting little demo as you’d probably be tempted to use meter from the get-go, but thinking about the data here makes a data table the best starting point.


View full post on Christian Heilmann

VN:F [1.9.22_1171]
Rating: 0.0/10 (0 votes cast)
VN:F [1.9.22_1171]
Rating: 0 (from 0 votes)

Developer survey results: libraries and cross-browser on mobile?

At Mozilla, we are dedicated to keep the web open and independent of a single company or technology. This means that users should have a choice of browsers and technology to use to go online and should not be blocked out because they can’t afford a certain device or are forbidden to change their browser.

In the world of mobile web development there is currently a massive debate going on about the need for support of various browsers seeing that the most successful phone systems both use the same browser engine. This is good, and we need this debate. It is not good though when developers block out users because they concentrate on targetting a browser. Sometimes this is not by choice of the developer – they are simply using tools that do that blocking for them and the usefulness of the tool outweighs the qualms developers have about that.

We are currently talking to library and tool developers and help them support more than one browser engine to prevent this. As a start of that process we wanted to get a glimpse of what people are using right now so we make sure we have the most impact when we help. This is why we conducted an online survey asking developers about their tools for mobile development.

590 developers took the survey and we are thankful for them spending their time giving us a lot to ponder and think about.

We are very aware that this is *not* a scientifically clean research and should be taken with a grain of salt (we haven’t asked how many times people used the tools or how much of their work is building mobile apps) but it gives us a good idea of what is going on.

So without further ado, here are the numbers as charts with a quick commentary:

Platforms

A lot of developers showed their love for the web in this survey, but then again it was a survey initiated by Mozilla. Most likely an Apple-lead survey would have different results. iOS and Android are the follow-up and Windows Phone and Blackberry are less of a concern for the developers who filled the survey. This, of course, could differ greatly were we do to this survey targetted to different markets. Interesting that in the case of Android the amount of “must have” is higher than “focus” – the only platform showing this.

What platforms are you targeting with your apps – Web
focus 370 63%
must have 153 26%
supported 33 6%
sometimes 23 4%
not at all 11 2%
What platforms are you targeting with your apps – iOS
focus 261 44%
must have 207 35%
supported 53 9%
sometimes 28 5%
not at all 41 7%
What platforms are you targeting with your apps – Android
focus 182 31%
must have 221 37%
supported 102 17%
sometimes 47 8%
not at all 38 6%
What platforms are you targeting with your apps – Windows phone
focus 10 2%
must have 46 8%
supported 131 22%
sometimes 173 29%
not at all 230 39%
What platforms are you targeting with your apps – Blackberry
focus 8 1%
must have 15 3%
supported 100 17%
sometimes 164 28%
not at all 303 51%

People may select more than one checkbox, so percentages may add up to more than 100%.

Libraries

In the world of libraries jQuery and jQuery mobile very much took the lead with more than 200 more uses than the next follower Zepto.js. A lot of feedback was that developers don’t like libraries and use their own hand-rolled solutions on mobile instead. While it is good to see that libraries that work cross-browser are the most used ones (jQuery just announced that they happily support Firefox mobile), the high number of Sencha users is worrying and we’ll see how we can help make their cross-browser support better. Sencha was also mentioned a lot in the “why webkit only” question which shows that it is an important tool for developers.

What libraries do you use to build mobile web apps/sites?
jQuery 437 74%
jQuery mobile 301 51%
Zepto.js 116 20%
JO 5 1%
XUI.js 23 4%
Sproutcore 9 2%
Sencha touch 88 15%
JQTouch 61 10%
Mootools mobile 16 3%
M project 1 0%
Nimblekit 2 0%
Lime.js 10 2%
Wink 2 0%
Uxebu Bikeshed 1 0%
Other 152 26%

People may select more than one checkbox, so percentages may add up to more than 100%.

All in all we collected 66 libraries (in order of popularity): jQuery, jQuery mobile, Zepto.js, Sencha Touch, JQTouch, XUI.js, Backbone, Mootools mobile, Lime.js, Sproutcore, Angular JS, Underscore, Bootstrap , Enyo, Modernizr, Dojo, handlebars, JO, Closure, Dojo Toolkit, GWT, Hammer.js, iScroll, require.js, YUI, Chibi, Ember.js, Kendo, Kinetic, Lungo.js, Nimblekit, Prototype, Wink, Adobe Air, Atto, Box2D, ChesterGL, Cobra, Crafty, Cujo, d3.js, Dart , Dojo Mobile, Dojo Mini, enhance.js, Eyebrow.js, fitml, gl-matrix, H5BP, JQMobi, Javelin, Jukebox, Knockout, MProject, Mootools, Openlayers, Path , Playcanvas, pointer.js, Raphael, Sugar.js, TerrificJS, Thorax, Titanium Mobile, Uxebu bikeshed, Wakanda

Conversion frameworks

There is no doubt that Phonegap / Cordova rules this segment of the market followed by Appcelerator. Quite a lot of feedback was also people claiming that native apps should be coded natively. Being a web evangelist, I disagree as you can not convert from native to web but the other way around, but it is interesting to see that developers felt the need to have their say here.

Which frameworks do you use to convert apps to native apps?
PhoneGap 325 90%
Appcellerator 50 14%
MoSync 2 1%
Other 38 10%

People may select more than one checkbox, so percentages may add up to more than 100%.

All in all we collected 13 conversion tools (in order of popularity): Phonegap, Adobe Air, Apache Cordova, Cocoon.js, Brightcove App Cloud, Mosync, Sencha Native SDK, appMobi, Flex Mobile, Mobileweb, Monotouch and backbone.

Visual editors

Not many developers seem to use visual editors, which is probably because most of them are still in a “beta” or “alpha” stage. It would be interesting to do the same survey with Flash developers who are moving towards HTML5 and see if the numbers are higher. As it stands, Adobe Edge and Sencha Animator are the clear winners, and some of the entries were interesting including one “you got to be kidding me” :).

Do you use any visual tools/converters to build apps? If so, which?
Adobe Edge 19 36%
Sencha Animator 10 19%
Other 25 47%

People may select more than one checkbox, so percentages may add up to more than 100%.

All in all we collected 17 editors (in order of popularity): Adobe Edge, Sencha Animator, Adobe Dreamweaver, Adobe Flash, Adobe Photoshop, Codiqua, Construct 2, Hype, Playcanvas , Radi, Rhodes, Telrik, Tiggzi, Tiler, Wakanda, Web Developer Add-on, WebMatrix

Webkit only?

71% of developers filling out the survey said they test for more than Webkit browsers and in the general feedback section of the survey we had a lot of information as to how people are testing and what would make things much easier for them. This makes us happy of course.

Do you test on non-Webkit browsers?
Yes 421 71%
No 169 29%

Reasons to test for webkit only

The main reason here is a lack of time to test on other platforms which is understandable – we can assume that a lot of projects from a planning perspective have 99% iOS/Android written all over them. The “lack of incentive” number is high, too, which is understandable – if you can’t show the numbers, you don’t get the time to support. The high number of “not supported on hardware” is of course another very understandable reason and we wished there would be a way to change this.

Fixed environment defined by client needs 46 24%
Lack of time to support more browser platforms 103 55%
Lack of incentive – I don’t know what the benefit of supporting more is 79 42%
Lack of documentation how to install and debug on non-webkit browsers 43 23%
Bugginess of other browsers on test platforms 31 16%
Lack of support for other browsers on target hardware 68 36%
Other 20 11%

People may select more than one checkbox, so percentages may add up to more than 100%.

Webkit only technology

The question “What technologies/features do you use on Webkit browsers that are crucial for you and not available on others?” was answered by 135 developers and only partly answered what we needed to know. A lot of it wasn’t features of Webkit but general speed and availability reasons that are reliant on the operating system and the hardware. A lot of the answers also simply stated that these browsers come with the hardware which means end users have them and developers don’t have an overhead of installing other browsers or tools. However, quite a few developers praised the predictability of a “one browser platform web” and not having to worry about vendor prefixes and differences in html5 support.

What can mobile Firefox do better?

The question “If yes, what could Firefox mobile provide to make your life easier?” got around 230 answers and is a great resource for us to improve the browser. The message that came across loud and clear was the need for remote debugging for Firefox Android which was just announced here on the hacks blog. It is obvious that developers do not want to have a long gap between writing code and seeing the results on their phones – very understandable indeed. Quite in demand was also a native simulator for the Desktop to avoid the need of having a phone at all. Another thing that stood out was support for older and more hardware.

Anything else?

The “Anything else you want to get heard?” question got 73 answers with a lot of great feedback, especially praise for what is happening right now in the world of Mozilla and some very detailed concerns of developers. We now have a great time going through these answers and will see how we can accelerate a few of the demands in our next browser builds.

Check the results

We’ve uploaded the anonymised answers as a spreadsheet to Google Docs, so feel free to read and dig at your own leisure: Mozilla libraries survey.

A huge Thank You

Last but not least, we want to say Thank you! to everyone who participated. We now have a lot of insightful information and can focus our outreach to frameworks, tools and libraries that will have the most impact when it comes to supporting a cross-browser web. We were also very positively surprised that the trolling and fanboi-ing was kept to a bare minimum – this showed us that the topic really is important for all developers out there.

View full post on Mozilla Hacks – the Web developer blog

VN:F [1.9.22_1171]
Rating: 0.0/10 (0 votes cast)
VN:F [1.9.22_1171]
Rating: 0 (from 0 votes)

HTML5 Web applications and libraries survey – first results

At Mozilla, we are dedicated to keep the web open and independent of a single company or technology. This means that users should have a choice of browsers and technology to use to go online and should not be blocked out because they can’t afford a certain device or are forbidden to change their browser.

In the world of mobile web development there is currently a massive debate going on about the need for support of various browsers seeing that the most successful phone systems both use the same browser engine. This is good, and we need this debate. It is not good though when developers block out users because they concentrate on targetting a browser. Sometimes this is not by choice of the developer – they are simply using tools that do that blocking for them and the usefulness of the tool outweighs the qualms developers have about that.

We are now planning to talk to library and tool developers and help them support more than one browser engine to prevent this. As a start of that process we wanted to get a glimpse of what people are using right now so we make sure we have the most impact when we help. This is why we started a quick online survey asking developers about their tools for mobile development.

We are happy to report that to date we have 480 answers and it is time to take a first stab at looking at the data.

We are very aware that this is *not* a scientifically clean research and should be taken with a grain of salt (we haven’t asked how many times people used the tools or how much of their work is building mobile apps) but it gives us a good first glimpse at what makes most sense for us to do.

So without further ado, here are the raw numbers as charts:

Platforms

Not many surprises there, iOS and Android are in the lead, quite a lot of people see the web as a must-have (but this is a survey called out by Mozilla…) and Blackberry and Windows Mobile are not that hight on people’s radar.

What platforms are you targeting with your apps – iOS
focus 208 43%
must have 168 35%
supported 43 9%
sometimes 24 5%
not at all 36 8%
What platforms are you targeting with your apps – Android
focus 147 31%
must have 183 38%
supported 85 18%
sometimes 33 7%
not at all 31 6%
What platforms are you targeting with your apps – Blackberry
focus 5 1%
must have 11 2%
supported 83 17%
sometimes 136 28%
not at all 244 51%
What platforms are you targeting with your apps – Web
focus 306 64%
must have 121 25%
supported 26 5%
sometimes 18 4%
not at all 8 2%
What platforms are you targeting with your apps – Windows phone
focus 8 2%
must have 36 8%
supported 112 23%
sometimes 137 29%
not at all 186 39%

Libraries

jQuery rules supreme but Sencha touch and Zepto also have their place. Interestingly enough a lot of answers discarded libraries completely and considered them an overhead that will cause damage in the future.

What libraries do you use to build mobile web apps/sites?
jQuery 349 73%
jQuery mobile 248 52%
Zepto.js 90 19%
JO 5 1%
XUI.js 18 4%
Sproutcore 7 1%
Sencha touch 72 15%
JQTouch 50 10%
Mootools mobile 11 2%
M project 1 0%
Nimblekit 2 0%
Lime.js 9 2%
Wink 1 0%
Uxebu Bikeshed 1 0%
Other 126 26%
People may select more than one checkbox, so percentages may add up to more than 100%.

Conversion frameworks

You do love your PhoneGap / Cordova, it seems. There is not too much competition in this market and a lot of feedback was questioning the sense of converting apps as “building them natively makes more sense”.

Which frameworks do you use to convert apps to native apps?
PhoneGap 257 90%
Appcellerator 45 16%
MoSync 2 1%
Other 31 11%
People may select more than one checkbox, so percentages may add up to more than 100%.

Visual editors

The space of visual editors seems to be not to frequented with this audience – would be interesting to see if there is already a mass market for WYSIWYG-like tools in the web app space.

Do you use any visual tools/converters to build apps? If so, which?
Adobe Edge 14 35%
Sencha Animator 9 23%
Other 18 45%
People may select more than one checkbox, so percentages may add up to more than 100%.

Webkit only?

71% of the audience saying they test on other browsers than webkit is making us happy of course, but seeing that a lot of the tools in use are webkit only makes that number questionable. Then again, we didn’t qualify what testing entices in this case.

Do you test on non-Webkit browsers?
Yes 340 71%
No 139 29%

Reasons to test for webkit only

The main reason here is a lack of time to test on other platforms which is understandable – we can assume that a lot of projects from a planning perspective have 99% iOS/Android written all over them. The “lack of incentive” number is high, too, which is understandable – if you can’t show the numbers, you don’t get the time to support.

If no, can you tell us why?
Fixed environment defined by client needs 36 23%
Lack of time to support more browser platforms 85 54%
Lack of incentive – I don’t know what the benefit of supporting more is 65 42%
Lack of documentation how to install and debug on non-webkit browsers 39 25%
Bugginess of other browsers on test platforms 24 15%
Lack of support for other browsers on target hardware 55 35%
Other 16 10%
People may select more than one checkbox, so percentages may add up to more than 100%.

More to come

These are just the numbers right now. Soon we’ll be publishing also the free-form comments we got but for now this should get some discussion going and gives us a great start.

And finally – a massive thank you for everybody who participated in this survey!

View full post on Mozilla Hacks – the Web developer blog

VN:F [1.9.22_1171]
Rating: 0.0/10 (0 votes cast)
VN:F [1.9.22_1171]
Rating: 0 (from 0 votes)

Can you tell us what libraries and tools you use to build mobile web apps?

Want to fix the mobile web? Are you developing mobile apps using web standards and libraries?

At Mozilla we are right now planning our outreach to libraries and tool makers to support more than one platform when it comes to mobile web development. To make sure that we change where it is most needed we need some more information.

Could you do me a favour and fill out a quick survey about libraries and developer use?


View full post on Christian Heilmann

VN:F [1.9.22_1171]
Rating: 0.0/10 (0 votes cast)
VN:F [1.9.22_1171]
Rating: 0 (from 0 votes)

Top 10 JavaScript Libraries, Frameworks and Tools for Web Developers

Despite their names, the Java and JavaScript programming languages share little if anything in common. They have however both experienced rather similar renaissances thanks to the strong open source ecosystems which have grown to surround the languages in recent years.

View full post on web development – Yahoo! News Search Results

VN:F [1.9.22_1171]
Rating: 0.0/10 (0 votes cast)
VN:F [1.9.22_1171]
Rating: 0 (from 0 votes)