Results of the JavaScript Survey 2012 - JavaScript

Düsseldorf, 15.+ 16. October 2012
www.javascript-conference.com
Results of the JavaScript Survey 2012
We asked the visitors of our JavaScript conference website about their
experiences and evaluations on JavaScript . 299 joined our survey. Here is our
resumé.
1. In order to sum up the state of knowledge of the participants of our survey we asked:
"How experienced are you with JavaScript?"
23.94 % are very experienced with more than 5 years of programming of extensive usage.
48.59 % have moderate experience with JavaScript..... mainly by programming of web interfaces.
23.94 % indicated that they are less experienced in JavaScript..... they merely wrote few scripts.
3.52 % of the people questioned have no experience at all.
very experienced
moderate
experienced
less experienced
2. We wanted to know more about the people questioned and asked "What is the main
focus of your development work"
Multiple answers were possible
85 % are writing web applications in JavaScript
38 % write mobile applications.....
24 % use JavaScript for desktop applications..... and
31 % use it for enterprise applications.
10 % of the persons questioned use JavaScript for other applications than the above mentioned.
90
80
70
60
50
40
30
20
10
0
web
applications
mobile
applications
desktop
applications
enterprise
applications
other
Little happens in the web without JavaScript; hardly any website goes without. But for all that
almost 40 % of the persons questioned work in the field of mobile applications.
3. We wanted to know: " Which language are you using as your 'first' language?"
26 % JavaScript
27 % Java
1 % another JVM language
17 % PHP
11 % C#
18 % other
JavaScript
Java
another JVM language
PHP
C#
other
JavaScript levels with Java ... followed with some distance by PHP as the "first language".
However, for many developer JavaScript is the most important language to work with.
4. Our question "Are you already using the new HTML5 / Css3 features extensively?"
divided the participants into:
a group of 71% who do use the new features
whereas 29 % - one third - prefer working with the older versions.
yes
no
Obviously the new features of HTML and Css are an improvement therefore they are already
extensively used.
5. We thought it is interesting to know whether JavaScript is used for server-side
programming and asked: "Are you using JavaScript for server-side programming - yes or
no?"
27 % said: I use JavaScript for server-side programming
whereas 73 % don't use it for this specific tasks.
server-side programming: YES
server-side programming: NO
Many developers still use JavaScript solely as a frontend language. But maybe one should rather
state: Already 27 % of the persons questioned use JavaScript for server-side programming.
Wouldn't that have been unthinkable some years ago?
6. Now we came to the large subject: Tools & Methods. We asked: "Which JavaScript IDE
are you using?"
WebStorm 7 %
Eclipse with plugin 21 %
Cloud9 3 %
Aptana 6 %
other IDE 29 %
no special IDE 34 %
40
35
30
25
20
15
10
5
0
Webstorm
Eclipse with
plugin
Cloud9
Aptana
other IDE
not special IDE
IDEs are not yet common amongst the JavaScript developer; if at all the Eclipse plug-in is used. But
careful: with question # 9 we found out what's beyond the biggest column of 34 % saying "no
special IDE".
7. "What JavaScript frameworks/technologies/tools are you using?"
Multiple answers were possible
JQuery 77 %
Prototype 11 %
JSON 65 %
Jasmine 10 %
GWT 15 %
CoffeeScript 10 %
WebSockets 22 %
Sencha 9 %
node.js 26 %
Titanium 4 %
Enyo 4 %
qooxdoo 3 %
other 31 %
none 8 %
90
80
70
60
50
40
30
20
10
0
jQuery rules! More than 75 % use this API ...the comparable prototype would lag far behind. The
JSON protocoll is essential for 65 % and thus gained quasi-standard. Curious the naming of the
"newcomer" WebSockets and node.js, who actually cover different fields in the IT development
altogether. Each with a quarter of the people questioned work with WebSockets and node.js.
8. "Are you using a JavaScript MVC Framework? If yes..... which one?"
Multiple answers were possible
The biggest group are the developers who don't use a JavaScript MVC Framework with 66 %
Backbone 13 %
Spine 1 %
Knockout 6 %
Ember 2 %
Angular 3 %
other 9 %
70
60
50
40
30
20
10
0
none
Backbone
Spine
Knockout
Ember
Angular
other
Two-third of the persons questioned use no special MVC framework with JavaScript. If at all
Backbone seems to be used. MVC frameworks do not have the prominence with JS (yet) like with
Java.
9. We expected a bit that our list of tools/frameworks... in the question above was
probably incomplete..... that's why we asked the participants of the survey: "What other
JavaScript tools/frameworks/gizmos are you using that we did not mention?"
The answers were freetext and we just itemize the input we got:
QUnit..... PhantomJS..... "js-signals crossroads.js Hasher.js"..... underscore.js..... Phonegap.....
"Brunch with coffee"..... ECO-Templates..... three.js..... Modernizr..... Respond.js..... Enfocus
Switch..... "- http://valums.com/ajax-upload/ - EJSChart (for historical reasaons)- Google Closure
Compiler - YUI Compressor"..... ext js Charts!..... jqueryui..... jquerypp..... qunit..... uidoc "momentjs
underscorejs bootstrap mustache select2 highcharts requirejs"..... OpenLayers..... ExtJs.....
MooTools..... require.js Mustache..... APF..... cloud9..... nodejs..... clojure script..... treehugger.js.....
http://raphaeljs.com/..... Lawnchair..... V8 directly and an own runtime with gl bindings..... lycheeJS
game engine..... JQueryMobile..... express.js..... "popcorn.js mootools"..... eval..... "express.js mocha
dnode"..... "express.js Railway.js Mongoose"..... "ejCharts Dhtmlx"..... CouchDB..... "meteor.js
express.js jade mustache handlebars mongoose testicular qunit"..... AJAX.....
Mootools.....Netbeans..... Yahoo UI / Alloy UI RequireJS..... Underscore..... rhino We use it to script
our application -> integrated proprietary framework Just plain JS with the least possible overhead.
Atmosphere Framework SignalR rightjs..... mustache Dojo Toolkit Javascript closures are awesome
but they can not be serialized in a proper way. Dojo..... AMD couchapp..... couchdb "requires
impactJS" JsUnit unit test framework "JQuery Mobile JQuery UI dojo soopfw translation Modernizr
Mocha YUI "Framework JavascriptMVC Sencha Ext JS 3 / 4 JSHint/JSLint Grunt QUnit" raphael.js \o/
undercore.js D3 "MooTools LabJS Firebug
Chrome-Debugger" backbone..... node..... Qunit..... jasmine..... jstestdriver..... ExtJS 2.0.2 "require.js
some backbone plugins Bootstrap underscore.js ..." Vaadin..... expressjs..... mootools ExtJS.....
DeftJS..... Crafty..... Hook.io ext.js require.js..... "jQuery UI jQuery Mobile" d3 Dojotoolkit.....
JsTree..... webrtc..... mustache Socket.io..... Mustache..... qwery..... bonzo..... Sinon.js..... JsTestDriver
and some other micro libraries requirejs and modernizr..... "Microsoft ASP 3.0 with JavaScript Dojo
Naradana Platform" PyCharm as IDE DHTMLX..... webgl ecma scripting vows.js; pdf.js; require.js;
handlebar.js..... vertx.io FireBug for debugging serialport for node.js VS 2010..... Jquery.....
phonegap/cordova..... dojo toolkit..... YUI3..... QUnit..... CrmRestKit.js Ja testrunner..... "JSTree
JQM"..... Testacular test runner..... yeoman.io..... cucumber.js "jQuery Mobile Jasmine UI
JsTestDriver Testacular" Mootools..... Raphael.js / Processing.js..... require.js..... jQuery plugins:
datatables..... dygraph..... jstree
The huge diversity is obvious and possibly a strengths of working with JavaScript since the
developer feels the utmost freedom with the tools of his or her fancy.
Question 10: “What are the main strengths of JavaScript?”
Coding:
Simplicity and that Functions are first-class objects and high order functions at the same time it
enables expressive functional programming.
JavaScript is LISP in the browser with a C-like syntax. Hence it's (nearly) as powerful as LISP, and
still gives you lots of freedom.
"I like:
- Everything is an object / hashtable
- Closures
- no strict data types
- pass various arguments to functions
- calling functions in different contexts
- Building GUIs with DOM
It is simple to write event based programs and it is easy to build in a modular structure.
It’s good to have fast operations on huge, sparse arrays.
It's asynchronous, functional, light-weighted and there are a lot of libraries and tools to speed up
development while maintaining quality.
compact (if you can JS :)), powerful because have some functional elements (closures), prototyping
concept is great and allow multiple inheritance. Some event-driven frameworks.
I use JavaScript for many types of frontend development. Like (pre-) form validation, UI things...
None compiling, very flexible debugging inside the browser , function are first class parameters
mighty language with first class functions. In conjunction with coffeescript an awesome
syntax/readability
Functional programming with extremely loose typing.
Rich Client Development, AJAX Requests
JavaScript and PHP -> AJAX
I like its support to program in multiple paradigms (functional in particular) and that, as many
scripting languages, you usually write less code than in traditional languages if you are using
appropriate tools like jQuery.
Fast java-like scripting
When it comes to event-driven procedural flow, JS is simply as good as it gets."
Event driven architecture: sometimes good, sometimes bad.
The asynchronous approach with its callbacks is great
I like the functional programming part of JavaScript. It helps writing asynchronous, event driven
programs.
Visible results
Easy to use, simple and fast in development!
It’s so simple and it works fine
I am currently using JavaScript for an enterprise application for a (relatively conservative) insurance
company. The company's domain experts and case workers are very happy with it. One more reason
to like JavaScript.
Fast develop and deploy cycle. Dynamic typing. Latter can also become a problem...
Work by client
JavaScript is EVERYWHERE and provides a unique solution to a number of problems that are
becoming more prevalent today. When used as a server side language it's event driven nature lends
itself very well to creating APIs and termination points for client connections as well as sending and
receiving large amounts of JSON data
Browser & HTML & CSS
I use it mainly because it's the only way to program stuff in a Browser. Also I like node.js for some
specific problems.
Possible use for server-, app- and webapp programming.
Client side code running in the browser.
User actions can be processed at runtime.
JavaScript is highly flexible and my first choice when programming for a browser. It is present on
every browser without the need to install another plug-in and you can achieve everything you like
(unlike any other language). I haven't seen anything I cannot implement with JS (server and client
side). And despite the lack of a good type checking and the lack of classes it is now one of my
favorite languages. And I started working in C.
Client-side programming and dynamic WebPages and having lots of resources and a wide user-base.
Best client-side script language around
"Good: executed on client side (less performance loss on server side)
Cross-platform, client side scripting w/o third party plug-in
I use it to enhance Client side Logic of PLM system
Dynamic client server interaction
Spread, it's in every browser.
Code reuse since it runs on any platform (either web or embedded via "invisible" web browser)
including mobile
I don't "like" JS, but it is the assembler for the browser.
Any browser related issue has to be solved in JS. Not other language has the same coverage on the
world. Also due to the nature of portability you can use it in a huge number of platforms
I use the browser rendering as device.
Interactivity on Websites, changing HTML without reloading, modern layouts in non-
HTML5/CSS3 browsers
Webpage actions on client side.
Direct webpage manipulation, Ajax, websockets, i love jquery
You can turn it off and so many web sites are simply reduced to their content.
It is flexible and for websites and -applications it is the standard way. With modern browsers it
makes fun.
Nice for effects
Nice for fallbacks (HTML5/CSS3) for old browsers"
It's great for mobile/web apps with HTML(5) and CSS."
Editing the DOM without calling the server again
Easy and fast way of client side interactions and DOM manipulations
End to end applications, building interactive web applications that behave like desktop apps
Mobile apps for multiple platforms
JavaScript is ubiquitous, if you do web development you have to learn the language properly.
Writing web applications with a Client-Server-architecture (JS-based client with the Browser being
the runtime and Java-based server as data backend) feels a lot more natural than the old Web MVC
approach.
I work faster and more efficient with web applications, when Javascript supports me with Ajax. It
would be a bit annoying, if the whole document reloads for each little option I've changed.
Learning & handling & support:
Easy to Learn"
a great and big community
widespread through browser and easy to learn.
Easy, cross-platform, fast, closures, embedded functions, extending, object orientated, everything:)
Good html integration
Very flexible, can hack together quite a lot of coding paradigms.
Probably not better but different. I like the event oriented approach.
Small language with powerful features.
It' easy. It's everywhere. It's fine for quick hacks and for larger applications.
Inheritance, not strongly typed is a plus and minus (sometimes), but can be avoided by using "use
strict" or by compiling. JS is easy to learn, but hard to understand the insides. Everything is an
Object. That is a miracle!
it’s easy to use, and its fast
Easy to lean
fast learning success;
easy to test
Flexibility, speed
Fast,
Simple Syntax,
Easy,
Easy to use. Wide spread
It's on the web, it's free, and it has an awesome community.
"Prototype-based Programming, clean Code"
No threading / synchronizing issues. Higher productivity, although it requires more discipline
regarding testing and coding styles (e.g. using JsLint)
Easy to learn, hard to master; DOM-manipulation, Animations
The syntax is easy and great
It's very easy to code because you don't have to take care of types or type casting.
Cross Platform support
Only a few key concepts -> easy to learn; event driven; clientside a must.
Close in the view
"- fast to implement, test, alterate.
Wide user base.
Diversity, Flexibility
JavaScript is ubiquitous.
Runs everywhere. Code reuse in both client and server. Promotes model driven development
Main strengths are ubiquity and a high level of dynamism.
"Multi-Platform”
flexibility, interpreted language (late binding), widely supported on many platforms
runs natively and fast in nearly every modern browser , works good works html, fast and
simple productive results, very big community, lots of frameworks and widgets for reuse
"Simplistic in nature, flexible in structure”
"When used correctly, JavaScript is extremely versatile and concise. So many libraries and
frameworks are already showing (today) that JavaScript is powerful and enterprise-ready.
Many Engines (Rhino, V8)"
Easily extensible.
In comparison with other programming languages
It has an extremely powerful concept of using objects, that’s something no other language I use
has.
Problems getting solved where there is no other language able to.
- more universal than flash/silverlight
* Closures, Callbacks, Functions are first class. In comparison with Java, this is often an advantage.
* Developing is more dynamic."
It's more flexible and faster than PHP and can do the same stuff.
functional programming - passing a function as a parameter where java would require to a)
create a new class / interface and b) provide a separate function to use, by name and c) instantiate
the class.
“Better for Holistic Programming than class based OO languages."
We commented this data insofar that we accentuated it with bold characters. By keeping the
repetitions we want to give you an impression of the importance of the single statement. We trust
that the reader of this survey can make their own judgments.
Question 11: “What are the main weaknesses of JavaScript?”
General
- prototype based object orientation (there should be a way to do it like in other mainstream
languages: Java, C++, ...)
application structure
scope, lack of multiline strings, wtfjs
Language history, like === vs == etc.
Too loosely typed.
not type safe, cannot distribute compiled code
missing typing, crude object syntax
Weak typing
No strict type checking, variables without types may cause runtime errors. Missing static variables
and objects. Poor inheritance. Poor debugging possibilites.
Too many brackets ;)
people loving semicolons
It's not type safe.
The overloaded keyword "function"
the poor inheritance is still a problem with JavaScript, but there a good workarounds using
prototype or MooTools class model
Calculating in JavaScript is a mess. For example:
70*0.02 = 1.4000000000000001
The (slightly) different implementations (in conjunction with the DOM) in different web-browsers.
=== vs. == is quite confusing sometimes
syntax checking, type checking
The class-less object oriented programming is crap ...
(sorry, but I'm a C#/C++ coder :D)
- typos in object attribute's names break the scripts
- exceptions don't contain a text that I can serialize to a meaningful error message (using
JSON.stringify)
- a single forgotten try{}catch(){} is able to shut down the web server
global variables
jquery event bindings on DOM elements
doubled listeners, mixed events
different object oriented concept is baffling for users
Crappy language design
Lack of a standard module system, no syntax-level support for classes
OO model (prototype) different from that one of normal OO-Languages like Java. untyped.
different api implementation and limits. eg. webkit web audio api and mozilla audio data api
IDE problems (not well supported), differences in browsers, typeless language
the known JS fails:
- no block scope
- arguments object implementation differs in browser (not a js problem in fact)
Sometimes to verbose syntax and the scope sucks.
no inheritance, difficulty to write classical oo
adapt the layout to mobile and a lot of new number of devices and test the code
Too forgiving when introducing bugs or syntax errors.
Stupid Number type (.1+.2!==.3)
Type checking, creating members on demand if they didn't exist (mostly in arrays). And most of all
the scope and the 'this' variable, which is one of the hardest problems to learn about in javascript.
not statically typed, therefore no refactoring. bad tools.. javascript is ok for animating buttons or
minimal effects.. For real programming it is a nightmare
array handling
oop .. implemented, is not the oop it used to be.
while easy to start with, but the more you are involved, the more complicated the code
coming from a c# world, it is not easy to replace inheritance with prototypes. Also, i have some
problems with chained callbacks.
Object Oriented
it is much to complicate, C# is so much easier
OOP and other similiar technics will never be the strength of JavaScript because of fundamental
restrictions e.g. in the "typesystem". Same for any other language that is needing a "==="operator to compare.
Cache and old browser
Sometimes the syntax puzzles me.
Understanding the "OO" way of javascript and the scope issues
To use JavaScript, you need strict rules and reviews. With JavaScript, people need more time to
understand the code and you cannot just find good JavaScript developers on the market.
IDE-support
JavaScript does not help one to produce high quality and maintainable code. OO-Architecture, "type"
system.
IDE support. It’s a scripting language. It's cool, if you stay below 5000 LoC. After that it starts to suck.
So it's not for big stuff but great for small stuff.
- setTimeout is nice, but it is too much freedom sometimes..
In large projects it is easy to get lost, since IDEs aren't that as they are use to be for Java in terms of
code completion etc.
It happens that you are going to write the same lines of code twice because you simply couldn’t
found the other ones.
a lot of pitfalls
some strange traps
security, stability, ..
Learning curve
JavaScript itself harbors a lot of incidental complexity. Apart from that, the most difficult part so
far has been integrating different parts of the stack (test frameworks and runners, MVC and widget
frameworks, etc).
Very high accidental complexity
- Performance (DOM operations, depends, of course...)
async and timing problems, at moment i discover promises :-)
Caching in IE (AJAX-Requests), missing functionalities in older IEs, actually, the main problem is IE ;)
asynchron processing
Performance, Memory, Mobile Devices
Account for many different browser environments, device capabilities, input methods, etc. All of this
is solvable but can be a PITA.
* performance issues based on different engines (in browsers, from IE6 to latest Chrome V8),
"reflows"
* bigger applications requires a strong architecture pattern (because it is so dynamic/flexible, there
is more (bad) stuff possible than in Java).
I'd love to work with multithreaded and hardware-supported JavaScript. WebGL is a great step
forward for developing bigger and performance stressful scripts.
Javascript has a lot of quirks and some bad design decisions that went into it . Once these are
understood it becomes much easier to work with but varying implementations or lack support
different functionality, especially in regard to the newer HTML 5 libraries, which makes it sometimes
difficult to develop for multiple browsers and versions
Compatibility
Browser incompabillities, some wtf moments using API
Cross Browser Compatibility is not given, Internet Explorer always does things different... bad
browser...
differences in browsers, best practises, mixed logic in html and js
Browser Incompatibilites. INTERNET EXPLORER!!!!
Referencing JS in other projects in visual studio
* browsers' engines incompatibilities
Bad IDE support in Visual Studio
working with c# AND js AND HTML
incompatibilities in different platforms
Browser differences are a bit frustrating, too. Libraries like jQuery help a lot, but it would be easier, if
there weren't those tedious gaps.
Different browser results (for example error messages in Internet Explorer)
Lack of information / documentation / best practices
Programmers that are experienced in other language and try to use patterns that don’t work in js
I'm a JS noob and it's really hard to get into event oriented programming on node, most books
available are very basic and don't help for more advanced issues . I have to grab a lot of stuff
on various resources in the web and try to figure out which of them is crap.
There is only little documentation about the QA in JS (TDD / BDD with one of the countless
frameworks/tools), there are only a few good books and it's not easy to tell good from bad
applicants for a JS job apart.
Mostly it's about documentation when it comes to certain frameworks or so.
Better support for writing big programs: modules, packages, profiling.
Lots of libraries available but not much guidance.
Being on the browser, of course the way it is acts differently on every browser it's one of the biggest
challenges. Also HTML5 spec is still on the go and sometimes some issues raise from that.
Repeating certain structures of code takes more lines than in other languages,
some meta-programming tools are missing (but only until Harmony)
It is a leaky language in general.
"JavaScript is terrible and should be avoided at all costs. Enterprise development is all about 24/7
and predictable outcomes and JavaScript with no strong typing and all the browser compatibility
problems is more a problem than a solution.”
Don't feel comfortable with server side JS.
Testing & Debugging
debugging on mobile devices is a bit complicated
testing ist not so good..
Debugging it is hard. Especially for browser incompatibility problems.
Debugging JS on mobile browsers (with PhoneGap for example).
sometimes hard to debug
callback hell, no compile time checking.
The Bad Parts; event-driven programming is error-prone. Requires discipline, especially from
coworkers ;)
Server-side debugging is with callbacks (async) very confusing and problematic .
JS is hardly to debug, i.e. bugs are sometimes hard to find.
debug
Debugging can be hard if your developing for the web.
Also debugging is a hard thing but with Chrome Dev tools we get a pretty good tool at hand!
debugging can be more tedious than in java; differences between browsers
It is not so easy to understand why some code works, sometimes it is magic...
the more the project grows, the more difficult is maintaining the code. .
Tedious debugging.
Unit-Testing, UI-Testing
Debugging sometimes difficult
difficult debugging,
not that easy to test automatically, debugging is yet relatively hard
dislike: pain to debug
We commented this data insofar that we accentuated it with bold characters. By keeping the
repetitions we want to give you an impression of the importance of the single statement. We trust
that the reader of this survey can make their own judgments.
Our last question was: 12. "Will JavaScript become more important in the near future?"
47 % said: "DEFINETELY yes."
38 % of the persons questioned think "PROBABLY yes."
15 % do not think that JavaScript will become more important in the near future.
DEFINETELY yes
PROBABLY yes
no
85 % of the persons questioned think that JavaScript will gain importance in the near future. Most
probably this is depending on the further development of Html and browser technologies and their
use in the mobile field. One might be curious, too, what will happen concerning server-side
programming in the future.
We thank all participants of the survey and all blogger, media partner, twitter enthusiasts ... for
supporting us by advertising our survey!
©2012 infaktum Veranstaltungen ( http://www.infaktum.de)