The shim, once loaded in a device’s browser, opens and maintains a socket connection to the server, according to to Shim’s developers. Shim was written in 2011 by Chris Marstall, Creative Technologist at the Boston Globe. The software has been open sourced. Write the Shim originators on git.hub:

Whenever a new page is requested, the page’s URL is broadcast to all connected browsers, which then redirect themselves to that URL, keeping all devices in sync. Shim info is available on git.hub.

The prototype JavaScript extension offered by Intel is intended to allow JavaScript apps to take advantage of modern parallel chip capabilities. Sequential gives way to parallel, at least in theory.

In-browser games and image editing are pitched as examples of application elements that would take advantage of new eight-core processors, blogs Intel’s Stephan Herhut.The software is said to ”play nicely” with the WebGL JavaScript API to OpenGL for 3D visualization in the browser. Intel has a beta Firefox extension for interested developers. Says Herhut:

You can download a prebuilt version for Windows and 64 Bit MacOS [from github] or build it yourself. For the latter, we have written a README that explains the process. Once you have the extension installed, take a look at our demos to see what is possible.

Why should the browser be a second fiddle to the operating system? As browsers, JavaScript, and HTML5 gain more influence, top-tier chip makers will start to adapt their libraries to Web application demands. More, including material on API design or the beginnings of  API documentation, is on a RiverTrail wiki.

• FuncUnit – Web Testing Framework
• Stand Alone Sub Projects – You can download only the tools you need
• Multi-Page builds – Optimize builds across multiple pages
• Less and CoffeeScript support – Use Less and CoffeeScript without having to refresh your page.
• New Folder Structure – A revamped file structure that makes it easier to build modular applications.
• Learn-ability – Much better docs, examples, demo, etc.

This new release also breaks out the framework allowing for individual subprojects which can be used independently instead of needing the whole framework. Each has their own github repo, documentation and support.

With 3.0, every part works standalone. So no matter the project, you can start benefitting from JavaScriptMVC’s goodies.

Big steps have been taken to improving the learning experience and getting developers up-to-speed. This includes:

• Updated and thorough documentation
• Demo app which shows how to start off with the framework
• Online tests
• An intro article to get you started

After chatting a bit with JavaScript expert Asen Bozhilov about this, we decided to fill that hole by launching a new mailing list called JSMentors that allows developers to get to know the language and find the expert guidance in a friendly and professional environment. The list offers developers a place to:

• Discuss ECMA-262 standard
• Discuss different implementations of ECMA-262
• Discuss different host environments of JavaScript
• Discuss implementation of algorithms in JavaScript
• Discuss your library design
• Review your code
• Review your book on JavaScript topic
• Review your article on JavaScript topic

We also wanted to provide a list that was professional, courteous, and friendly to developers of all skill levels. Too many forums, newsgroups and lists look down on beginners or questions deemed too introductory and we wanted to ensure that JSMentors didn’t fall into that same hole. So we created a set of simple rules. Via the JSMentors mailing list you must not:

• Insult other subscribers
• Post racism
• Spam publications

So far it’s been working great and developers are getting the mentoring that they desperately want and need. And the great thing is that the mentors are a who’s-who of the JavaScript world. Check out this list:

• Garrett Smith
• Juriy Zaytsev a.k.a. kangax
• Dmitry A. Soshnikov
• Steven Levithan
• John-David Dalton
• Stoyan Stefanov
• Benjamin Rosseaux a.k.a. BeRo
• Diego Perini
• Angus Croll
• Peter van der Zee
• Christian C. Salvadó
• Peter Michaux

One important thing to note is that the main focus of the list is the JavaScript language and while you can post about JavaScript libraries, you’re more likely to get a better answer in a library’s specific support forum or list than on JSMentors.com.

Asen and I would like to invite developers to join JSMentors.com and create a productive list to help everyone become better JavaScript developers and help push the web forward.

”All new input types introduced with HTML5 forms except search and tel benefit from internal validation.
Firefox 4 is going to support email and url and the validation will check if the value is a valid email or url respectively.”

Also discussed is added pattern matching support and a new pseudo-class that applies on submit controls when a form has an invalid element.

In computer science, a fiber is a particularly lightweight thread of execution.

Like threads, fibers share address space. However, fibers use co-operative multitasking while threads use pre-emptive multitasking. Threads often depend on the kernel's thread scheduler to preempt a busy thread and resume another thread; fibers yield themselves to run another fiber while executing. The article on threads contains more on the distinction between threads and fibers.

Fibers describe essentially the same concept as coroutines. The distinction, if there is any, is that coroutines are a language-level construct, a form of control flow, while fibers are a systems-level construct, viewed as threads that happen not to run concurrently. Priority is contentious; fibers may be viewed as an implementation of coroutines, or as a substrate on which to implement coroutines.

The above is taken from Wikipedia, which is discussing the computer science concepts behind fibers.

Why do we bring this up? The Asana team (who we featured when they came out with LunaScript) continue their quest to make an ergonomic, productive, and performant framework for the Web.

Today they are discussing their patch to v8cgi that adds in support for their own fiber implementation.

It all ends up with this:

Few languages support fibers natively (though support was recently added to Ruby). We write most of our server code in JavaScript and run it under Google’s v8 engine, the same JS runtime that Chrome uses. Fortunately the v8 codebase is excellently structured, so we were able to add fiber support in just a few days. Our changes take the form of a patch (currently pending review) to v8cgi, a library of server-oriented extensions to v8.

Here’s a sample of the API:

PLAIN TEXT

JAVASCRIPT:

1.  
2. // Make a new fiber. The fiber will run the provided function.
3. var fiber = new Fiber('name', function() {
4.  
5.   // ...
6.  
7.   // Make another fiber runnable.
8.   some_other_fiber.becomeRunnable();
9.  
10.   // Suspend the current one.
11.   Fiber.current.suspend();
12.  
13.   // ...
14. });
15.  
16. // Make the new fiber runnable. It won't start until the current fiber suspends
17. // or joins.
18. fiber.becomeRunnable();
19.  
20. // Wait for the fiber to finish.
21. fiber.join();
22.  

That’s almost the entire API. We don’t need any synchronization primitives because only one fiber runs at a time and control only changes when suspend() or join() is called.

There is a tension between writing clear, well-abstracted code and writing code that makes efficient use of the database. Adding fibers to v8 allowed us to resolve this tension. In taking a small amount of time to solve this problem “right” up front, we’ve made our entire engineering team more efficient for the long run.

Read the post to get the background, and to see the refactoring that is done to get to this place.

Asana seems to be really enjoying rethinking the world of Web frameworks. I can't wait to see their products!

Dave Balmer (formerly YUI, currently working with me on webOS) has created a fantastic cross platform mobile Web framework called Jo. What do I mean by cross platform? webOS, iOS, Android, Symbian, Safari, Chrome, and even Dashboard Widgets. It's philosophy is:

If you want to jam an existing web page into an application framework, jo probably isn't for you. jo is designed to create applications. While it will play nicely with a mixture of new and old web development techniques, it uses HTML5 as a development stack and does not require direct DOM manipulation.

You can setup your views in JavaScript, or also declaratively using special tags:

Take a look at the code and how it plays in action:

Data Link

jQuery already supports a data API:

This is better than attaching data directly to data nodes for various reasons, e.g. storing non-string data and improving performance. And it also avoids memory leaks - when you remove an element, jQuery removes everything. Looking towards jQuery 1.4.3, the project had to decide if they want to remove data events, and they decided to keep them and make them more useful.

The new data linking plugin, developed in conjunction with Microsoft and released yesterday, supports binding between DOM objects and elements. Binding from an object to a form element looks like this:

Whenever "first-name" or "last-name" elements are updated, the form element is updated. You can also bind in the opposite direction, so that a form element changes when you change an object.

More info on GitHub.

Templating

Templating has become a big deal in Javascript, and there's now an official jQuery templating plugin, also released yesterday, which John tells me has a good chance of being integrated into the core at some point. John told me his original Micro-Templating library was considered at one point, but the new templating is more refined.

Pre-compiling template strings is possible too:

The most interesting feature is that elements retain the data that made them - you can ask an element "what data did you come from"?

John argues that developers try to create too much abstraction between HTML and the data model. At least in the client, the DOM "is everywhere" and you should be okay with storing your data against it.

More info on GitHub.

jQuery Mobile

jQuery Mobile, under development, aims for broad mobile browser support, which also means a high regard for progressive enhancement. John explains the need to target multiple mobile browsers by focusing on BlackBerry. Why support BlackBerry? Among other things, BlackBerry mobile traffic is rising (he shows this stat of 10% growth in the past 12 months), your boss probably views your apps in it, and targeting one mobile browser is like targeting one desktop browser. (i.e. wrong.)

With most mobile browsers, there's a big problem: You can't do fixed positioning - John says it's just been added in Android 2.2, but not there in earlier Android, iPhone, etc. Some frameworks have done the complete simulation of scrolling to get around this, but it leads to massive amounts of code and doesn't work right - the subtle UI issues it causes are very noticeable.

Considering it unacceptable to simulate scrolling, jQuery Mboile always uses native scrolling. e.g. to show a select menu, it simply hides the rest of the page and makes the select list occupy the entire page.

There are toolbars available - user clicks to show and hide them, and it works nicely because it supports native scrolling. While you're scrolling, the toolbars are hidden, and they show again when the scroll action is complete (if they were cvisible before the scroll action began).

Developers can detect the various touch events:

taphold
tap
swipeleft
swiperight
swipe

Web Roundup

John finishes off with some highlights on the web in general:

• Performance improvements (showing Are We There Yet?)
• Web GL (he shows this ray-tracing )
• Audio (he shows some Nihlogic magic and the Beat Detektor).

The author mentions some of the features:

WOLF1K features a 32×32 map ( a 1024 cells grid ) with textured walls colored by orientation ( North, South, East, West ), fog, 3 transparent bitmap graphics in 8×8, 15 rainbow characters steering smoothly across the map, collision detection, probably the most crazy optimization tricks I ever wrote.

In order to get this into 1K some crazy things had to be done:

WOLF1K works exactly like the original Wolfenstein 3D and Wolf 5k. It is using the raycasting technique. The world is built from a uniform grid of walls and corridors. In order to draw the world, a single ray is traced for every column of screen pixels and a vertical slice of wall texture is selected, scaled and colored according to where in the world the ray hits a wall and how far it travels before doing so.

The sprites and graphics are stored in a small space using a clever trick:

The world of WOLF1K is a regular grid of 32×32 cells. Obviously storing these 1024 cells in one byte or one bit each is not feasible. It would use the 1024 bytes or 128 bytes if stored as bits. It actually is the result of a binary operation applied to the ASCII codes of the source code of WOLF1K plus a mural on each edge of the world.

[via Paul Kinlan]

The software recently gained preliminary support for anonymous modules. Looking forward, Burke has posted a design sketch and code on GitHub  ("rough at the moment, mostly scaffolding," he writes) for a Node-based package tool. Further ahead he sees a RequireJS 1.0 release in the offing.  

He writes:

The code has been very usable for a few releases now, but I have kept the release numbers below 1.0 to indicate that the final mix of features were being worked out. With the changes in this release, it feels like the major format changes have landed.

Do a search for JavaScript and you find a painful set of returns. The worst offender is having Java results show up. Ouch. (Remember: Java is to JavaScript as Ham is to Hamster!).

Compare to a search for Java, or C#, or Ruby, (or ....).

Ouch. We need better. To begin with the pirates of JSConf (lead by the awesome Mr. Chris Williams!) have started a grass roots Operation SEO at Promote JS. Go there, and help the cause by doing embeds like the following:

If we can do half of the work to promote this as we have with the awesome VaporJS library, then we should be in a better place.

Step 2: Come up with a fantastic landing area for JavaScript.

Editor's note: This was posted by Dion but he had no way to push it live. I am doing this now. To find out about my personal stance on this very cool idea, check out Why supporting promotejs is a good idea.

Note that the feature only currently works in Chrome.

Ryan begins with the following code:

Describing the code Ryan says:

From the code above you attach an ondragstart event listener to something you want to “drag out” and save to your file system. On the dragstart event you set the data using the new “DownloadURL” type and pass file information to it.

Note though that in order to pass the correct data to the dragstart event you need to provide a download URL that can be passed to the setData("DownloadURL" call. Ryan uses the HTML5 data-* attribute to pass this custom data in:

The custom attribute uses three different fields of data separated by colons:

The files mime type, the name you wish it to be saved as (this can be anything) and the url to where the file can be downloaded from.

Nice find Ryan!

Yet another snippet:

[Disclosure: Mark Pilgrim owes me money; just kidding]

A fun post for a Tuesday morning, Aaron Newton shares his path to becoming a JavaScript ninja, and how you can too. Some of his tips (I encourage you to read the whole article):

1. Study design and designers. I’m not saying you have to have the talent to be an awesome graphic designer, but you should pay attention to people who are. When you are surfing the web, pay attention to what works. What looks good? What communicates to you that you can do something on a page? A great example here is this video of Bill Scott’s work on UI patterns. He gives great examples of what the “interesting moments” are in UI design. But in general, you should pay attention to the sites you visit and notice when they get things right and wrong. I often ask interview candidates what sites they admire and why.
2. Study JavaScript. I mean really dig into it. Watch all those awesome Crockford videos – ALL OF THEM! – on the YUI theater. For that matter, watch all the OTHER videos there. Seriously awesome stuff. I don’t agree with 100% of what they all say, but they are educational for sure. Read Crockford’s JavaScript: The Good Parts. Again, I don’t agree with it 100%, but it’s a seriously solid overview of the language.
3. Study JavaScript Frameworks. Note that this is plural. The single most important thing I’ve done in my education with the language was to write the original documentation for MooTools. To do this, I had to read the entire library’s undocumented source and figure out what it was doing and why. I’ve learned a lot since then, but nothing I’ve done has ever resulted in as big a jump in my knowledge. When I wrotejqueryvsmootools.com I did it again, this time with jQuery. I read the entire source so that I could understand it. I did it again with Dojo when I put together a talk about programming to patterns that I first gave in tandem with Dylan Schiemann of the Dojo team (the talk wasn’t about frameworks so much as it is about the value of abstraction, and I wanted to make sure it wasn’t just a MooTools focused talk). I’ve done the same thing with other frameworks to learn the lessons that I can from other people’s development styles. Don’t just use jQuery or YUI or MooTools. You need to study all of them to understand what makes them the same, different, and interesting. Don’t stop until you understand everything that these frameworks are doing and, more importantly, why. Don’t hesitate to ask their authors for explanations; most are happy to talk about their work.
4. Get involved with a framework. The second most important thing I’ve done with JavaScript was getting involved with the MooTools project itself. Working with open source projects is a HUGE boost to your resume and, here’s the thing, you don’t need to really know that much to get started. You just have to be willing to spend the time. Right now, there are dozens of bugs open on every framework out there. Go fix some! Go write test cases! Go write a blog post about how you use it! Do these things and get committer status and I promise you you’ll start getting a ton of interesting job offers.
5. Release some of your own code. I can’t stress this enough. If you don’t have code on github (or google code or your own site or whatever) you’re wasting a big opportunity. Releasing your own code allows me, a potential employer, to know your capabilities before I hire you. This stuff gets people interested in you. If you release a lot of your code, you may even get others to help you maintain and grow it. This is how open source projects get going. I almost consider it a red flag to see a resume without a url to github or something similar.
6. Blog about it. Write down everything you learn as you learn it on your blog. Next thing you know, 3 years have gone by and you have this huge body of work. Stuff on your site draws the attention of other developers who are struggling with similar problems. You become an expert without really meaning to. If you blog constantly about what you are doing, what you are studying, you’ll find that people come to you with work to be done expecting that you are awesome because, well, you’re explaining all this stuff to them. I can’t stress the value of this enough, though it is very time consuming. This is especially valuable if you’re a freelancer.
7. Build something interesting. I once spent a month or two writing a photo gallery in PHP just to have an excuse to learn PHP better. I learned Smarty with that little project, too. I’ve built a lot of things for the excuse to learn it. I built Iminta.com with a friend and we chose Ruby on Rails mostly because neither of us had built anything with it and wanted to learn it. Forcing yourself to do things with new languages and environments will grow your skills faster than anything. Don’t rely on the skills you have; always look for chances, excuses really, to do things in new ways. Working with emerging technologies will make you debug that technology itself and maybe contribute fixes back to it. It can be painful, but it also makes you really learn how that technology works.
8. Join a startup. I know, this one can be tricky, especially if you don’t live in the SF Bay area. But joining a startup will make you tackle problems that aren’t in your domain because, well, there’s no one else to do it. If you’re not experienced enough to be the 2nd or 3rd person at a startup, aim for being the 10th or 20th. You’ll be asking for long hours and low pay, but you’ll get a mountain of experience. Think of it as an extended college education that pays you a little cash and (if the stock takes off) might buy you a house.
9. Take the time to learn why solutions work. When you’re working on something and you get an error and find the solution on Google, take the time to really understand what the problem was. When you are starting up an app server – ruby on rails, django, lamp, whatever – and you get a stack trace, take the time to dig into it and understand the problem and what the logs are telling you. Debugging stuff on the command line will teach you a ton. It’s slow, thankless work, but it’ll greatly improve your value when you take on more challenging tasks at new jobs.
10. Be curious, and fight off laziness. This is a bit of a weird one, I know. What I mean by it is that you should look at tasks that require you to do new things as opportunities. Recognize when these moments come along and cherish them. There is nothing more awesome than having a job that pays you to learn. If you have coworkers that know things that you don’t, and vice versa, trade them. When I was in college I told the guy who was building the web site for my school that I’d help him design it and show him how to use Photoshop if he would teach me HTML. I joined Cloudera 18 months ago and knew zero Python and now I’m pretty decent at it. If you have a job that uses technologies you don’t know, don’t just stay in your little JavaScript world; find ways to expand your knowledge however you can.

1. Create a fancy pancy Javascript demo
2. Submissions may be up to 1k. (And not crash)
3. Externals are strictly forbidden, unlike "some" contests. (Good luck minifying jQuery though!)
4. Must work on current fx, sa, ch and o. (Let's level the playing field)
5. Minification and hacks allowed. (Go nuts)
6. Bonus points if your submission fits in one tweet ;)
7. Last day to submit is 10 September 2010

This looks like a fun way to test your skills out so be sure to check it out. There's already five submissions and the contest runs through September 10th, 2010.

Notice three things:

• canto() returns an abstraction of the canvas - a "Canto" object.
• As with jQuery and similar libraries, there's method chaining; each method called on a Canto also returns the Canto.
• lineTo() has been extended to support multiple lines being drawn in a single call.

Instead of setting the ink properties and then painting it, you can do it all in one step:

And plenty more syntactic sugar - check out the API in the source code comments. Sweet!

Thanks @pkeane.

• Touch event support for mobile interfaces including flick and move gestures
• Browser capability loading - which means that every browser gets the least amount of code necessary to make it work
• Transition support for the animation module - meaning only browsers that don't support CSS3 transitions get the JavaScript animation fallback
• An update to the CSS grids to allow for more flexible layouts
• A ScrollView widget similar to the one in Apple iOS
• The uploader has been transitioned over from YUI2 to YUI3

So check out what is on offer and give the YUI team feedback on what would be nice to have and what is broken. In their own words:

The goal of a preview release is to make it as easy as possible for all of us in the community to evaluate progress of the upcoming release and provide feedback. Please take some time to test 3.2.0pr1 and let us know what you find by filing tickets in the YUI 3 bug database marked as “Observed in version” 3.2.0pr1. We’ll do our best to address preview-release questions on the YUI 3 Forums, too.

There are three ways to get started with the preview release: YUI 3.2.0pr1 is available on the CDN via the 3.2.0pr1 version tag — so you can reference preview-release files like http://yui.yahooapis.com/combo?3.2.0pr1/build/yui/yui-min.js. If you switch to this seed file for the preview release, all subsequent use() statements will continue to load YUI 3.2.0pr1. Or You can download the full YUI 3.2.0pr1 from YUILibrary.com, including source code and examples for all components. Or you can simply explore the functioning examples roster.

Testing rich, dynamic web applications sucks. At Jupiter, we've tried almost every testing solution available (qUnit, Quick Test Pro, Selenium, JsUnit, Env.js, TestCase) and all of them suffer from some fatal flaw.

Problems:

• Manual - A tester has to run the tests manually on every supported browser.  People are lazy. 
• Unit Tests Only - We need to test the app as a whole and complex UI behavior like drag-drop.
• Low fidelity - We need to make sure the tests are reporting accurate results.
• Difficult to write - We sling JS like a ninja monkey throws poo.  We want to write tests in a nice JS API.
• Expensive - A QTP license is 5k a person!  I'd rather buy a vacation.
• Support - We want to test Mac and Linux browsers.

We've solved all of these problems in our upcoming FuncUnit testing framework. It's a mashup of qUnit, Selenium, Rhino, and Env.js. But its core library, Syn, which does the work of simulating user actions with very high fidelity, is what we are releasing today.

So by using code like this:

you can simulate clicking an element with id='hello', typing "Hello World", and then dragging your mouse from that element to an element with id='trash'.

Pretty cool stuff. Check out their demo to see how playback occurs.