The redesign of JQuery DOT COM site recently gained a huge amount of comments; unfortunately most of them were not positive. Developers who have come along with the library feel unhappy with new slogan “Be a Javascript Rockstar” that, said, makes them look unprofessional.

Response to a post on Ajaxian, shypht commented:
Hate to say it, but image is everything. If I was trying to sell my manager on using jQuery, Prototype, Mootools or Dojo, and sent them to those sites, I think based on look alone jQuery would be at a disadvantage. “Write less, do more” is a great slogan, “Be a Javascript Rockstar”, not so much.
Strikes me as being an amateur, and more focused on flashy effects than functionality. I love jQuery, it’s helped me loads on my most recent project, but that header just makes me cringe a bit on the inside when I see it.
While Glen Lipka described his feeling in more colorful words on his blog post:
Truthfully, I feel alienated by it. It doesn’t resonate with me. It makes me feel old and lame. My hair is not long and flowing. The rockstar isn’t me. jQuery is me. It’s different.
Obviously John Resig & team did listen to the community and decided to kill the “JavaScript RockStar” on JQuery site.
Read the rest of this entry »
If you are web developer you may have noticed that the latest version of Yahoo’s User Interface toolset and widgets (for web development), YUI 3.0, is now available as a preview release. YUI has long been a popular “Ajax” library both because of its liberal BSD license, and because of the number of features it provides.
The big news about YUI the third are that it changes from the root and (unfortunately) is not compatible with YUI 2.x APIs as Eric and Matt stated on developer blog.
YUI 3.0 builds off of the YUI 2.x codeline, but we’ve evolved most of the core APIs in working toward the five key goals described above. As a result, migrating from YUI 2.x to 3.x will require effort at the implementation level.
However, YUI 3.0 will ship with a limited compatibility layer for the current YUI Core that will allow you to run some of your YUI 2.x-based implementations (Yahoo Global Object, Dom Collection, and Event Utility) on top of YUI 3.0.
These radical changes are toward 5 goals:
- Lighter (less K-weight on the wire and on the page for most uses)
- faster (fewer http requests, less code to write and compile, more efficient code)
- more consistent (common naming, event signatures, and widget APIs throughout the library)
- more powerful (do more with less implementation code)
- more securable (safer and easier to expose to multiple developers working in the same environment; easier to run under systems like Caja or ADsafe)
Read the rest of this entry »
Posted on : 08/25/2008 | By :
Jimmy Vu | In :
SolutionRizqi Ahmad from Germany has introduced a nice solution for client-side template based on JQuery. The Chain.js allows you to use any piece of HTML (or embedded HTML string) as template to display data dynamically.
In introductory post, he went through some common approach like server-side data binding, injecting preformatted HTML (into well-known DOM property innerHTML) and directly manipulating DOM, then explained why Chain.js is better way:
- Easy and compact (as it uses JQuery for manipulating DOM)
- Preserve event(s) on updates
- Allow dynamically add/remove data
To use the engine, you’ll need to download JQuery (better the latest version) and Chain.js then add script tags to load them.
<script src="path/to/jquery.js" language="javascript"> </script>
<script src="path/to/chain.js" language="javascript"> </script>
Practical Example on Chain.js

Now, we’ll create a practical example that allows user select a programming language and display recommended reading books accordantly. This is almost similar to another example I created for PURE library.
First, build a template table to display book list:
Read the rest of this entry »
Related Reading:
- ExpressionEngine 2: A Quick-Start Guide
In this book, noted expert Ryan Irelan walks you through creating an online news site, Engine City T... Read More »
- Templatesprache: Php, Xsl Transformation, Javaserver Pages, Template Engine, Haml, Openarchitectureware, Apache Velocity (German Edition)
Kapitel: Php, Xsl Transformation, Javaserver Pages, Template Engine, Haml, Openarchitectureware, Apa... Read More »
- Engine- Small Repair Service Company Business Plan Bundle (Sample Business Plan, Template, Guide, Worksheets, and More.)
Easily create a professional small engine repair service business plan with this bundle. Great for a... Read More »
Mozilla has just introduced a new JavaScript optimization feature to Firefox 3.1 development code base (Shiretoko) that well enhances JavaScript-based web apps performance by a 2x – 20x fold compared to the Firefox 3.0, according to JavaScript performance tests ran and published by Mozilla’s Brendan Eich.
I’m extremely pleased to announce the launch of TraceMonkey, an evolution of Firefox’s SpiderMonkey JavaScript engine for Firefox 3.1 that uses a new kind of Just-In-Time (JIT) compiler to boost JS performance by an order of magnitude or more.
Here are some of the charts from Brendan’s blog:

Assorted benchmarks

SunSpider micro-benchmarks
However the best way to evaluate it is to see it in action via simple JavaScript image editor that lets you adjust a picture’s contrast and brightness with a couple of sliders created by Mike Schroepfer. By default, TraceMonkey is disabled (as it is still buggy), there is a very noticeable delay while sliding. Turn it on (javascript.options.jit.content = true in about:config) and the thing works like charm, very smoothly.

JavaScript Image Editor
Going into significant detail on how all of this came about, Brendan notes some key points:
Read the rest of this entry »

What is Harmony?
Many web developers have felt relief to hear that EcmaScript 4 (ES4) standard project fell apart. Through quite a long post “The Only Thing We Have To Fear Is Premature Standardization“, Douglas Crockford told us why EcmaScript standard must be revised to cope up with changes on modern web but ES4 has not been mature enough to be realized.
In deeper details, John Resig explained how current ES4 will not reach a sensible result and why it should be merged with ES 3.1 to create the next specification (code name Harmony).
The ECMAScript 4 specification development was very ad-hoc in nature (primarily tackled by Adobe, Mozilla, Opera, and Google): Implementors agreed upon a set of features that they wished to implement and a specification was molded out of the remaining consensus. Building a specification tailored by implementation is a very pragmatic means of reaching a reasonable result.
However there was a fundamental split related to how much of the specification should be implemented. Enter ECMAScript 3.1. This working group (lead by Microsoft and Yahoo) set out to implement some minor changes and bug fixes to ECMAScript 3 while remaining as a subset of full ECMAScript 4 functionality.
These two groups continued to work side-by-side but a struggle was inevitable. The ECMAScript 3.1 group wanted to add changes to the language that would affect the result of ECMAScript 4. This struggle over the past year finally came to a head this past month at the meeting of TC39 (the committee responsible for both ECMAScript 4 and ECMAScript 3.1). Dubbed “the Oslo meeting” this discussion between the two groups saw an ultimate conclusion: The two efforts had to be merged, otherwise neither one would succeed.
You may be confused with the “name soup” of JavaScript, JavaScript 2, ECMAScript (3, 4 and 3.1), ActionScript, Tamarin etc. Right? Just find clear explanations of such terms from another post by Alex Russell.
So, now (near) future of JavaScript can be seen via the Harmony project with some new features we can certainly expect:
Read the rest of this entry »
0