Tag Archives: javascript

Installing Angular.js on Windows

If you’re new to Angular.js and are trying to follow their example app (see http://docs.angularjs.org/tutorial/), chances are you might get an error like this:

node ./scripts/web-server.js
module.js:340
 throw err;
 ^
Error: Cannot find module 'C:\Users\<user>\scripts\web-server.js'
 at Function.Module._resolveFilename (module.js:338:15)
 at Function.Module._load (module.js:280:25)
 at Function.Module.runMain (module.js:497:10)
 at startup (node.js:119:16)
 at node.js:902:3

What the tutorial failed to mention is that you need to be in the directory of the angular-phonecat directory – so the sequence is :

cd angular-phonecat
node ./scripts/web-server.js

Then access your browser at localhost:8000 and it will work. Remember if you’re using Windows that port 80 is typically reserved for IIS so unless you want to mess around with IIS default ports….

http://docs.angularjs.org/tutorial/

Adobe and the future of Flex

On the 15th November 2011, Adobe effectively announced that it no longer saw Flex as a long term going concern and would push it into the community/open-source domain (semantics aside), as it realized that HTML5 combined with comprehensive Javascript libraries such as JQuery were the future. There was mixed reaction from the Flex community, covering both positives and negatives of this announcement, but after the dust has settled what does this really mean for Flex, Adobe and the community?

It’s a beautifully ugly thing

I’ve always had mixed feelings about Flex as a platform; on one hand I found the to be much elegance and simplicity of the architecture – XML for layout; Javascript-u-like for code seemed a fantastic approach, particularly as it opened up the possibility of writing your own Flex app without the need of a $$IDE. However the delivery through what is basically a Flash container always concerned me as it limited the available platforms (no need to rehash why Flash/Flex doesn’t run native on Apple mobile devices).

So Moving Off Flex Is Good?

Strategically speaking this is the right move for Adobe; Using HTML5 + JS….

  • Removes the run-time dependencies of Flash
  • Creates a wider base of developer community
  • Standardises on technology/architecture
  • Adds more pressure on the less compliant browsers to man-up (Internet Explorer – why are you even still here?!?)
  • Allows touch-capable mobile devices able to consume applications

However there are still challenges:

  • We’re back to the browser inconsistency world; implementation of HTML5 is not standard across all browsers
  • There isn’t yet one “go-to” Javascript framework implementation or standard

So there are still a few key open issues that need to be solved, buying Adobe some time to continue to support Flex with a view to moving folks to the next big platform. Once could argue that there needn’t be one Javascript framework as we’ve all managed fine for some time – but to have a reference implementation that is open and standard (as possible) would be a great thing.

Should Adobe Acquire?

If I was Adobe I would be deep in discussion already with the likes of the folks who make JQuery, mooTools, 960Grid, etc. with a view to acquisition. These Javascript frameworks have built a reputation of quality and capability which has made many developers lives so much easier.

JQuery would undoubtedly be everyone’s first choice as it has gained popularity in the community and has many extensible attributes and add-ons covering both User Interface elements and mobile device support. However, I cannot pass up an opportunity to mention and often overlooked framework which came out around the same time as JQuery and in my personal opinion, has a some architectural advantages (though cool architectures don’t always make happy users) …. I refer to MooTools. You can draw many parallels between mooTools and JQuery, although the former takes a hit in terms of adoption. There are many “versus” articles out there (here, here, here) for you to make up your own mind. I speculate JQuery will win if only for popularity.

Adobe did try their own framework of sorts (Spry) with limited success; partnering with a JS Framework might be a good first step, but without acquisition or co-ownership they lose control of the roadmap. Producing their own framework might be a bit late in the game, so it stands to reason that obtaining a popular and well supported framework such as JQuery with its’ vast community would be the best thing to do.

So What’s Next?

I foresee a roadmap to a new Adobe application which will allow the creation of HTML5 applications in replacement of the Flex Builder product. It will be a hybrid that takes MXML (layout/UI) and ActionScript (action / code)  and (somehow) compiled /assembled into an HTML5 app. We’re likely to see an announcement over the coming months.

jQuery and MooTools

Building faster TTL sites with Frameworks – jQuery and MooTools

About a year or so ago I decided to peg my web work against a framework model to save reinventing the wheel for every site I developed – the two frameworks I chose were:

Selection Process

During the selection for the JS frameworks I also looked at

  • Dojo – Excellent but rather large and not as well structured. IBM has since got involved with this project and it promises many good things.
  • Scriptaculous – Good implementation but the features were seeming to head in the wrong direction (for me at least).
  • MochiKit – Same as Scriptaculous
  • Prototype – The granddaddy of them all – solid but not as extensive.
  • ExtJS – Great library but not truly opensource
  • Spry – Coming from Adobe it has to be pretty good, however compared to the other libraries seemed a bit bloated and less well supported from the community.
  • jQuery – Great framework that still had some performance issues and lacked some functionality that MooTools provided.

Even though MooTools won,  it would be foolhardy not to keep one eye on the competition and see how they grew. In the last quarter of 2008 there seemed to be an increase of jQuery posts both on Digg and dZine. Shortly afterwards jQuery 1.3 was released and my attention turnedto the explosion of articles that popped up on this framework.

jQuery grows up!

jQuery’s implementation of a frame work is slightly different to that of MooTools e.g. extensive promotion of chaining (moo can do this too); its’ community approach seems to be more about plug-ins into the 15k core script to expand its’ capability (MooTools currently weighs in at around 68k with lots of the options turned on). If you search many of the agggregate developer sites (e.g. dZine) you’ll find there’s more article son jQuery than MooTools.

That’s not to say that MooTools is irrelevant – far from it. It’s still an impressive and comprehensive framwork with lots of community support (check out ClientCide or the MooTools forum), and the development team for MooTools is extremely passionate about its’ development. However I now think that jQuery has done significant work to make it a very mature, production level framework, just as MooTools.

Today I checked out the jQuery tutorials and am now in the position of deciding whether to implement my next site design on MooTools or jQuery – both offer advantages and very little disadvantage (when you add all the plugins I’m looking to use there’s not much difference in filesize. I’ll post again when I’ve had chance to check both out head to head.

Conclusion

There’s no one perfect framework – each site you build needs to have a set of goals and that will help you drive the framework of choice. That being said 80% of the time it will probably be MooTools or jQuery.

Regards the CSS framework choice – again Blueprint is not for everyone – there’s lots of other options out there; Tripoli looks great; Yahoo UI (YUI) is really solid (but crosses into the Javascript framework field too – when you add all those together it gets really bloaty)… you’ll have your own weapons of choice, but regardless of which one you choose, you’ll be building compelling websites much quicker than handcranking.

As for those against frameworks – yes, you don’t get optimized code, but the trade off is well tested, well supported code which most people access using high enough speed networks, so the difference to the end user is negligable.

Why do we have to have Browser exceptions to use Javascript?

The irony of Web programming was that it’s concept was to remove all the processing on to the server so the client was thin and only had to worry about the presentational layer (i.e. the browser). However, as web applications have become more complex and feature rich, it has been necessary to push that ideal to the limit.

Today’s Browser

A modern browser will need at the minimum the ability to handle XMLHttpRequests (Ajax), Adobe Flash and Javascript – Shockwave is less important, some sites seem to want to include WMV content (I don’t know why…), SVG is the panacea that never was.

If you look at the majority of modern websites, they are increasingly reliant on javascript to provide richer services – unfortunately each browser may have it’s own flavour of javascript which means those programming for the web have to create exceptions and conditions throughout their code. This in turn creates significant overhead and repetition, increased risk of issues, etc.

A common Javascript Platform?

Doesn’t exist. In the days when Netscape and Microsoft fought it out, NS has it’s ECMA script, whilst MS had JScript – similar implementations but there were clear differences which meant that in the early days Javascript was relegated to the more simpler functions in web pages.

Nowadays the implementations are much closer – it’s far easier to write Javascript x-browser fashion, however the implementations of the browsers means that there are still differences exposed. Add to this that Microsoft has continued to extend JScript to be a .NET compatible language (for scalability), whilst Mozilla (the Firefox people) are now working on an open source high performance engine called “Tamarin” (see http://developer.mozilla.org/en/docs/Tamarin), not to mention the other two versions of Javascript they maintain.

The simple but hard solution

For HTML we have the W3C committee who agree the standards which the browsers then break… THERE IS a similar quasi-independent body that determines the standard for javascript – this is called ECMA (http://www.ecma-international.org), but unfortunately its’ success thus far has been limited. If all parties could just agree that the core javascript implementation was browser neutral then all browsers would (eventually) have to fall in line; all the browser quirks like DOM implementation incompatibilities would diminish as each browser’s interfaces would be standardised… wouldn’t it? Once could argue that the very core JS is pretty much standard and the quirks are at a higher level – then perhaps the issue also lies with the browser implementation and we need standards there…? The problem is, in creating standards development becomes slower as players like Microsoft, Adobe, IBM, BEA, Mozilla et al come to the table, all with their own agendas – understandably.

Light on the Horizon

The good news is that the big players are finally getting it together. IE8 is supposed to be the most pure implementation of browser standards and Firefox 3 also claims they’ll be there. The major players currently support ECMA 3 (well, support in a loose sense maybe…) and are working towards ECMA 4. To quote their overview paper:

ES4 is compatible with ES3 and adds important facilities for programming (classes, interfaces, namespaces, packages, program units, optional type annotations, and optional static type checking and verification), evolutionary programming and scripting (structural types, duck typing, type definitions, and multimethods), data structure construction (parameterized types, getters and setters, and meta-level methods), control abstraction (proper tail calls, iterators, and generators), and introspection (type meta-objects and stack marks).

Ironically this means we’re getting closer to a Java implementation, although the concepts can be mapped to .NET, so by default both sides of programmers will grasp the concepts, even if the syntax is closer to Java. Unfortunately no release date is mentioned, so this could mean we’re some time way off a release proper.

There is a pre-release verision available here -> http://www.ecmascript.org/download.php

Conclusion

I think Javascript has become incredibly important in the delivery of modern websites that the standards and compliance needed are increasingly important. ECMA4 (ES4) seems to be going in the right direction and once released I’m sure will see very clever code patterns being developed – this will create its’ own set of challenges with things like Browser storage capability needed (such as those currently available in Firefox and to a lesser degree IE). Existing frameworks such as MooTools, Scriptalicious, Dojo, et al will become key ingredients in modern designs – It wouldn’t suprise me if one of those frameworks gets snapped up by MS, Google or Adobe…