Posts in the ‘Javascript’ category

« Older Entries

Javascript compilation for SBT

Sunday, March 6th, 2011

Over the weekend I knocked up a little SBT plugin to wrap up the Javascript resources in our Lift projects and deploy them as one big minified file. Read on to find out how it works, then grab yourself a copy and take it for a spin.

The plugin scans your webapps directory and looks for files with the extensions .jsm or .jsmanifest. These files, called Javascript Manifests, describe lists of Javascript sources that should be combined into a single file. For example:

# You can specify remote files using URLs...

http://code.jquery.com/jquery-1.5.1.js

# ...and local files using regular paths
#    (relative to the location of the manifest):

lib/foo.js
bar.js

# Blank lines and bash-style comments are also supported

Manifest compilation happens in two phases: first, the plugin downloads and caches any remote scripts specified using URLs. Second, it feeds all of the sources (remote and local) into Google’s Closure Compiler, which concatenates them and minifies everything (and provides excellent services like static type checking to boot). The output from the compiler is a .js file with the same base name and relative path as the original manifest.

There’s not a lot more to it than that. The plugin hooks into SBT’s standard compile and package phases, so your Javascript gets rebuilt automatically alongside your Scala code. If this sounds useful to you, please feel free to grab a copy and take it for a spin. Full details are available in the README on Github.

I should point out that there are other useful SBT plugins that do a similar job. For example, I plagiarised extensively from Jon Hoffman’s YUI Compressor plugin and Luke Amdor’s Coffee Script plugin when writing my code. These two particular examples don’t do file combination, though, and that was an important feature for our specific use case.

Posted in Code, Front page, Javascript, Scala, Web development | 3 Comments »

Smooth Scrolling for Mobile Safari

Monday, January 24th, 2011

I recently wrote a jQuery plugin to do some smooth scrolling on the iPad, and I thought I’d share the code with everyone.

The effect you get is very similar to the iOS home screen. The user touches the screen and drags to scroll. Releasing the screen causes it to spring to the most appropriate page based upon the last dragging position and speed.

Gurus of front end development tell us that pretty much the only way to get smooth transitions on the iPad is to use 3D CSS transforms. After experimenting with jQuery animations and 2D CSS transforms, I pretty much concur: jQuery animations yield one or two frames per second, and 2D CSS transforms aren’t much better. 3D CSS transforms, on the other hand, are hardware accelerated and smooth as silk.

You can get the code from this Gist on Github (contributions and enhancements welcome). Use it with the following HTML:

    <div id="viewport">
        <div>First page</div>
        <div>Second page</div>
        <div>Third page</div>
    </div>

and the following Javascript:

    $("#viewport").scrollpane();

There’s a demo of it in action here. A couple of notes:

  • Because this hooks into touch gesture events and CSS3 3D transforms, it’ll pretty much only work on iDevices and possibly other Webkit-based tablets.
  • It works horizontally and vertically, but I’d recommend only using it horizontally in a regular web page because it interferes with Safari’s natural screen bounce. I had the benefit of a working on an offline brochure where the web page never scrolls naturally. In this environment the plugin really shines. If you are interested in doing something similar, take a look at the iPad app Delivery Site, which lets you customise various things like this.
  • There are a couple of options you can tweak to affect things like dead-zones before a drag will trigger a page transition. See the top of the source code for details.
  • When the first 3D transform is added to a page, Mobile Safari seems to transparently install an OpenGL panel to handle the effects. This causes a rendering glitch that’s just faintly visible if you’re paying attention. The plugin works around this by setting an identity transform on the scroll component on page load. Webkit is presumably frugal about 3D-ification for a reason, so you may find your web pages take more memory and CPU resources with this plugin active than without.
  • Really large (read “many-page, full-screen”) scroll panes can be very heavy on the browser. This is presumably due to the overhead of creating a texture buffer to 3D accelerate the transitions. I’ve managed five-page full-screen scrolling transitions without problems, but your mileage may vary.

Posted in Code, Front page, Fun, Javascript, Web development | 7 Comments »

The Rumour Starts Here!

Thursday, May 4th, 2006

Salacious rumour suggests the next version of Javascript will have tail recursion. We can neither confirm nor deny this rumour, but we can rock an old style w00t!

Posted in Javascript | Comments Off

More on the next Javascript

Monday, February 20th, 2006

Brendan Eich writes on Python and JavaScript. The first part discusses his plans to add generators and array comprehensions to Javascript. But that’s not the real news! It comes later:

I’m happy to announce that we are now working with Dave Herman, a fourth year graduate student at Northeastern, of PLT and lambda-the-ultimate renown, whom I invited as an expert to help ECMA TG1 develop sound specifications for critical parts of ECMAScript Edition 4 (ES4), also known as JavaScript 2 (JS2).

Go Dave!

Posted in Javascript | Comments Off

Ajax: I Fold!

Friday, January 27th, 2006

Ok, I fold. It’s time to admit I agree with what Matt has
been saying: Ajax is an immature technology. To save Matt
some effort I’ll list the things that most annoy me with the
current state of the art:

Matt’s already mentioned the (lack of) href="http://www.untyped.com/untyping/archives/2005/11/rich_web_client.html">type
system and href="http://www.untyped.com/untyping/archives/2005/12/printf_in_ajax.html">poor
debugging support, so I won’t go into them.

Memory leakage is perhaps the biggest obstacle to
creating long-lived Ajax applications. The reasons for
memory leaks are discussed href="http://www.mozilla.org/scriptable/avoiding-leaks.html">here
and href="http://blogs.msdn.com/ericlippert/archive/2003/09/17/53028.aspx">here.
These leaks are a result of a flaw in the implementation of
(to my knowledge, all) existing browsers. This puts us back
into the bad old days of manual memory management. Either
we be very careful in our programming, or our long lived
application will eat memory till the browser crashes.

Browser incompatabilities and inconsistencies, admirably
documented at Quirks
Mode, are a major hassle. We have to worry about both
browser and version — my code works in Firefox 1.0.4,
but will it work in Internet Explorer 5.0 (probably not)?

With the benefit of experience Javascript could be improved in a number of ways. href="http://calculist.blogspot.com/2005/12/dynamic-scope.html">Javascript’s
crazy scoping rules are just bad; there’s no way of
getting around that. Javascript would really benefit from coroutines for writing all those animation loops (or heck, let’s get full continuations). Javascript’s syntax is unnecessarily hard to parse, mostly due to the semi-colon insertion rule .

Finally, current implementations of Javascript are slow and
resource hungry, a major impediment to creating really
featureful applications.

Ok, so where does this leave us? We still want to build great Internet applications, but the tools are a bit suck. There are three paths forward:

  • Build libraries. Requires the least amount of time, but offers the least return.
  • Build a better Javascript. This has already started. Just wait two years for the standardisation committee to finish, and then another five Internet Explorer to catch up.
  • Use the existing language as the target, but build a better language that compiles into Javascript. Less effort than standardising Javascript, but more effort that writing libraries, this option has some attractive benefits.

So which path are we going to follow? Tune in next time!

Posted in Javascript | Comments Off

printf in AJAX? Sorry, that’s not debugging.

Thursday, December 22nd, 2005

This post is one in a continuing series where we internally debate the merits of the over-hyped promise of AJAX…

Debugging Ajax Requests in Prototype:

How do we debug our Ajax applications? The Rails Weenie has taken the Ajax Responder feature in Prototype…

I’d like to remind Noel that the distance of the Atlantic and business of the Christmas holidays are not going to keep me from pointing out that AJAX is an immature and dangerous platform to build a business on. Yes, I’m glad that GMail is there… and I suppose the Yahoo! Mail beta. However, these are fragile technologies to build upon.

How do we debug things written using the Prototype framework? printf. I mean, I’m glad that with AJAX and Rails I can whip something up quickly that “just works.” However, it doesn’t “just have test cases,” or “just get internationalized”, or “just stand up under load.” They’re rapid-prototyping tools, certainly nothing more. AJAX breaks usability standards, pushes data and computation to an unreliable substrate (the client’s web browser), and as the post above provides some evidence for, there are no good debugging or tracing tools available for developers working in heterogeneous browser environments in Javascript.

So, Noel, riddle me this: why should developers be willing to take eight steps backwards and be shafted with printf as their primary debugging tool when working with AJAX?

Posted in Javascript, Web development | Comments Off

Rich web clients

Friday, November 4th, 2005

Matt likes to provide the dissenting Ajax voice here on untyping.

As overhead on Slashdot:

‘Zimbra’s chief executive, Satish Dhamaraj, says that when he started his company in December 2003, “I really thought that Ajax was just a bathroom cleaner.” Now his San Mateo, Calif., business has amassed $16 million in funding from venture-capital firms including Accel Partners, Redpoint Ventures and Benchmark Capital, the firm that famously funded eBay Inc. Peter Fenton, an Accel partner, says Ajax “has the chance to change the face of how we look at Web applications” and could boost technology spending by corporations, because Ajax is also being used to develop software for big companies, not just for consumers.’”

Ajax is a dangerous and immature technology. It is, in fact, a hack—a kludge—to provide rich-client functionality in the browser.

(more…)

Posted in Javascript | Comments Off

The Birmingham Course: OpenLaszlo to the Rescue!

Thursday, September 15th, 2005

We needed to deliver a prototype on-line exam quickly. Despite their simple appearance, on-line exams can have some complex interaction modes that are annoying to deal with in a client/server model. OpenLaszlo provided an excellent framework for quickly going from idea to solution.

(more…)

Posted in Javascript, Web development | Comments Off

A little OpenLaszlo lovin’

Thursday, August 18th, 2005

No doubt I’ll be playing with this technology more in the future, so I thought I’d introduce it now.

OpenLaszlo, released unto the world by Laszlo Systems, is an interesting combination of languages and ideas. It is an XML-based language for specifying the layout and behavior of rich internet applications. For example, I wrote a tabbed slideshow for photographs that you can find on my personal weblog, here….

(more…)

Posted in Javascript, Web development | Comments Off

Transferring Transferring Behaviour with Javascript

Wednesday, August 10th, 2005

Gordon Weakliem references Patrick Logan who references Philippe Bossut who references Alex Russell’s OSCON talk on AJAX. The little tid-bit that gets me excited is the quote "Best data type to return: JavaScript instead of XML". I want to add an emphatic "yes!" to that. Only a crazy fool manipulates XML on the client-side when manipulating Javascript is so much easier. And, yes, I also want add another link to this long chain of attributions.

Posted in Javascript | Comments Off

« Older Entries