A+ Ajax

Intel’s Parallel Extensions for JavaScript, code named River Trail, hooks into on-chip vector extensions to improve performance of Web applications. Details of Intel’s attempt to get on the JavaScript juggernaut emerged last month at its developer event.

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.

Continue reading »

There are a number of resources on the Internet for reading up on JavaScript but very few viable options for actually exchanging ideas with extremely knowledgeable JavaScript developers, especially when it comes to just wanting to know about JavaScript itself and not a specific JS library. This was a pain point I (Rey) personally felt when I wanted to learn more about the language and be able to have “mentors” that could help me better understand JS and ECMAScript.

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.

Continue reading »

The IE9 team announced that they’ll be hosting an open Q&A session via Twitter where developers can ask questions to the Chakra engineers about the new JavaScript engine.

In conjunction with the release of Platform Preview 7, we wanted to give the community the opportunity to ask questions of some of our IE and Chakra engineers. So we’re going to host a 2-hour Q&A chat on Twitter tomorrow morning beginning at 9am PST.

They’ll be fielding questions starting tomorrow Thursday, November 18th from 9-11am PST and you can participate by sending your questions to @ie and using the hashtag #ie9.

Check out the blog post for full details of the Q&A session.

Full Disclosure: I work for Microsoft.

Continue reading »

The JS1K conference wrapped up recently. One of the winners that jumped out at me recently was an implementation of Wolfenstein 3D…. in 1K of JavaScript:

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]

Continue reading »

Progressive enhancement is still a confusing matter for a lot of people who are very excited about the capabilities of JavaScript in modern browser environments. It can feel anachronistic to write your solutions for a non-JS environment and then once more enhances in JavaScript. I grew up like that so for me it is a simple matter of doing the right thing but with today’s world of JavaScript libraries and out-of-the-box widgets it can seem a drag.

Enter Dav Glass of the YUI team. He’s been turning the concept of progressive enhancement around in his head and as a JS lover and backend code “endurer” he set out to solve this issue once and for all in a pure JavaScript way.

Here’s the issue: you cannot assume JS to be available on the client side as your visitors might be on a slow mobile connection or are paranoid enough to turn off JS or actually have it turned off for them by company policy or many other cases.

So in order to use pure JavaScript to render a solution that works for everybody the natural thing was to move the JS solution to the server side and re-use it on the client when it is possible.

If you say server-side JavaScript you end up quickly talking about Node.js and so did Dav.

Check out the following demo:

All of what you see is driven by JavaScript – there is no server-side PHP fallback. Yet if you turn off JavaScript in your browser, you get the same experience.

The reason is that Dav uses Express.js and Node to render the HTML of the application server-side with JavaScript and YUI3. The code is available on GitHub and a video of him giving a talk about this is available soon on the YUI blog.

This is an exciting concept as it means that we can build progressively enhancing solutions using any widget library if we just think of the server-side case, too. This can mean a lot less code and easier maintenance as the only skill needed to build bullet-proof solutions is JavaScript.

The missing piece to the puzzle though is a fully fledged DOM renderer on the server side. DOMJS works but a C++ version would be much better in terms of performance and have all the features of DOM-2.

Continue reading »

Jack Vaughn posted on Ajaxian recently about a new blog series on building a Gameboy emulator using JavaScript. Now Parts II and III have been posted in the series:

• Part 1: The CPU
• Part 2: Memory
• Part 3: GPU Timings

In the Memory section, Imran Nazar builds up a JavaScript MMU that can interpret the different parts of the Gamboy’s memory:

In the previous part of this series, the computer was introduced as a processing unit, which fetches its instructions from memory. In almost every case, a computer’s memory is not a simple contiguous region; the GameBoy is no exception in this regard. Since the GameBoy CPU can access 65,536 individual locations on its address bus, a “memory map” can be drawn of all the regions where the CPU has access.

[CC-A by Michael Ngilen]

In the third part Imran is now ready to actually draw things to the screen, using the Canvas tag:

Nintendo’s internal name for the GameBoy is “Dot Matrix Game”; its display is a pixel LCD of dimensions 160×144. If each pixel in the LCD is treated as a pixel in a HTML5 <canvas>, a direct mapping can be made to a canvas of width 160 and height 144. In order to directly address each pixel in the LCD, the contents of the canvas can be manipulated as a “framebuffer”: a single block of memory containing the entirety of the canvas, as a series of 4-byte RGBA values.

Next in the series will be a blog post on backgrounds and patterns.

Continue reading »

Thomas Fuchs has some good performance things to say reflows and rendering. A video of wikipedia gives you an idea of how much happens when a basic page is rendered:

The advice?

The important thing is to always remember that reflowing and rendering HTML is the single most expensive operation browsers do. If your page feels sluggish it’s most likely a problem with rendering. While the easiest way to optimize is to get rid of as many nodes as you can, and trying to have simpler CSS rules, sometimes JavaScript is the culprit.

Following changes to the page, a Javascript query like someElement.offsetHeight will block execution – to give you the right answer, any pending reflow has to be executed first. So code like this:

could be twice as fast if you wrote it like this:

because there are two reflows in the first example, and only one in the second.

Continue reading »

[Image CC-A by Terry Johnston]

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.

Continue reading »

Yahoo invites to their campus in Sunnyvale, California on the 27th of August to hear Douglas Crockford talk about “Loopage”.

In his own words:

Software development is hampered by a specific set of design mistakes that were made in the first programming languages and repeated in everything that has been done since. And, somewhat miraculously, JavaScript is going to make it right, radically transforming the way we write applications. Again. In the Loop of History, it has all happened before, but it has never happened like this. This is why you should care about the emergence of server-side JavaScript and the excitement around projects like Node.js — not because they’re at the sharp end of a trend, but because they’re paving the road toward the next big revolution in software.

You can sign up for your free ticket on Meetup and there are still a few places left. As with all the BayJax talks the video will be available later on, too.

Continue reading »

It floors me what young, talented developers are building these days. Kit Goncharov, who only recently turned 17, just cranked out Quilt, a JavaScript preprocessor written in JavaScript.

Quilt is very similar to the Sprockets JS preprocessor in that it allows you to improve code organization by logically separating your code into multiple modules within their own specific directories. Instead of having one massive JavaScript file with all your source code in it (increasing the potential for errors and complications), you can break out your code into separate physical files and at build time, allow Quilt to roll it all up, line by line, into a single file, ready for deployment. Via support for directives, you can tell Quilt about dependencies to ensure your builds are structured the right way.

In addition, if you use third-party frameworks in your code, Quilt allows you to specify a “load path” or “search path” which tells the preprocessor where to look for your specific lib. Then, when you build the final concatenated output, the library is included right in the source code.

Although Quilt was heavily inspired by Sprockets, it does have several significant differences. Perhaps the most obvious is that it’s written in pure JavaScript (as opposed to Ruby) and runs on Rhino. This means it’s very portable and easy for JS developers to understand. Quilt also uses a slightly different syntax than Sprockets for including files (for instance, it allows single-quoted pathnames, and uses backticks instead of angle brackets for specifying third-party code), and can strip multi-line comments as well as single-line ones.

As our client-side applications continue to grow, these types of solutions are becoming increasingly important for having a well-structured and maintainable codebase and it’s great to see that the future development leaders are taking that into consideration. Be sure to check out Quilt along with Kit’s other projects on GitHub.

Continue reading »

We have a screwed up tensions on the Web. The size of your source code really matters for performance. The larger your .js…. the longer it takes it to get down the pipe. This has a perverse incentive to write terse uncommented code. Add to this the problem of having to work cross browser, and having to do so all at runtime, and you end up shipping a ton of code to browsers that will never touch it.

This is where Mike Samuel of Caja, and Lindsey Simon of Browserscope come in. They have a plan to help reverse code bloat with JavaScript:

Lots of compilers (incl. (JSMin, Dojo, YUI, Closure, Caja) remove unnecessary code from JavaScript to make the code you ship smaller. They seem like a natural place to address this problems. Optimization is just taking into account the context that code is going to run in to improve it; giving compilers information about browsers will help them avoid shipping code to support marginal browsers to modern browsers.

The JavaScript Knowledge Base (JSKB) on browserscope.org seeks to systematically capture this information in a way that compilers can use.
It collects facts about browsers using JavaScript snippet. The JavaScript code (!!window.JSON && typeof window.JSON.stringify === 'function') is true if JSON is defined. JSKB knows that this is true for Firefox 3.5 but not Netscape 2.0.

Caja Web Tools includes a code optimizer that uses these facts. If it sees code like if (typeof JSON.stringify !== 'function') { /* lots of code */ } it knows that the body will never be executed on Firefox 3.5, and can optimize it out. The key here is that the developer writes feature tests, not version tests, and as browsers roll out new features, JSKB captures that information, letting compilers produce smaller code for that browser.

The Caja team just released Caja Web Tools, which already uses JSKB to optimize code. We hope that other JavaScript compilers will adopt these techniques. If you’re working on a JavaScript optimizer, take a look at our JSON APIs to get an idea of what the JSKB contains.

You can see graphically how this works and learn more about how browser detection info is packaged:

Definitely feels like there is a lot of room to do more with a compilation step that only sends down the right JS for the given browser.

Continue reading »

We have posted about ray tracing before, and now we have another example by Jonas Wagner:

The environment is mapped using cube mapping. I store all the values of the cubemap as floats. I increase the definition range by multiplying all values bigger than 0.95 with 2. This makes sure that the bright parts of the image are also very bright in the reflections. You can think of this as faking hdr. I do not calculate any lighting, it is all coming from the environment map. To make the animation look a bit more fluid and hide the aliasing I apply some fake motion blur by blending the current frame with the previous one.

You can check out the code to see how it all works. What frame rates are you getting?

Continue reading »