Archive for the ‘JavaScript’ Category

File Under: Browsers, JavaScript, Programming
Feb
17
2012

Google’s New ‘Dart’ Language to Get a Starring Role in Chrome

By

Google has released an experimental version of the Chromium web browser with support for the company’s new Dart programming language. Dart, which is Google’s attempt to improve on JavaScript, has thus far not enjoyed much support outside of Google, but the company continues to push forward with its own efforts.

The new development preview version of the Chromium browser, the open source version of Google’s Chrome browser, contains the Dart Virtual Machine. This release, which Google is calling “Dartium,” can be downloaded from the Dart language website. At the moment it’s available only for Mac OS X and Linux. Google says a Windows version is “coming soon.” Keep in mind that this is a preview release and intended for developer testing, not everyday use.

Google originally created Dart to address the shortcomings of JavaScript and ostensibly speed up the development of complex, large-scale web applications.

While there is much programmers might like about Dart, it is, like Microsoft’s VBScript before it, a nonstandard language from a single vendor created without any regard for the existing web standards process. The new Dartium release is the first browser to include a Dart Virtual Machine and, based on the response from other browser makers to the initial release of Dart, likely the only browser that will ever ship with a Dart VM. For its part Google says it plans to incorporate the experimental Dart VM into Chrome proper in the future.

The company also has a plan for all those browsers that aren’t jumping on the Dart bandwagon — a compiler that translates Dart to good old JavaScript. In this scenario Dart ends up somewhat like CoffeeScript, a JavaScript abstraction that makes more sense to some programmers.

For more details on the new Dartium browser and the latest improvements to the Dart VM, be sure to check out the Google Code Blog announcement.

Tags: , ,
File Under: JavaScript
Feb
6
2012

A Rose by Any Other Name Might Smell as Sweet, But it Would Probably Be Larger

By

It may have started as a lark, but the annual JS1K contest has long since ceased to be a joke. This year’s contest is already in full swing and notable for a spectacular 3-D drawing of a rose rendered using less than 1,024 bytes of JavaScript.

The JS1K contest seeks the web’s best JavaScript creations, with one small catch — the code used must be less than 1k. It might sound insane considering that some JavaScript frameworks — just the frameworks! — are over 100k, but since it began several years ago, JS1K’s experiments have never failed to impress.

One of this year’s most jaw-dropping efforts to date is developer Román Cortés 3-D rendering of a rose. Relying on Monte Carlo methods to keep the code size down, Cortés’ code draws a very nicely shaded 3-D rose for the love-themed 2012 edition of JS1K. You can check out the live demo on the JS1K website.

One word of warning: Part of what makes Cortés’ rose so small is that much of the heavy lifting is handed off to the processor. The demo code brought my CPU use over 100 percent and kept it pegged there the entire time it was open in Safari. Firefox and Chrome both managed to keep the number down to roughly 93 percent, but suffice it to say that a procedurally generated 3-D rose will tax your CPU.

To see how Cortés created the code behind the rose, be sure to visit his blog which offers a very thorough tutorial explaining how and why the code works. There’s also a great write-up on Cortés’ previous JS1K effort, a 3-D Christmas tree. Also be sure to check out the other submissions to this year’s JS1K contest on the JS1K website.

If you’ve got some impressive but terribly small bit of JavaScript code up your sleeve, fear not; the JS1K contest will continue accepting submissions through Wednesday, March 14, 2012. Details on the rules and submission process can be found on the JS1K website.

Tags: ,
File Under: CSS, HTML5, JavaScript, Mobile, UI/UX, Visual Design, Web Basics
Jan
12
2012

Building a Responsive, Future-Friendly Web for Everyone

By

A handful of the many screens your site needs to handle. Photo: Ariel Zambelich/Wired.com

This week’s Consumer Electronics Show in Las Vegas has seen the arrival of dozens of new devices from tablets to televisions. Some of these newfangled gadgets will soon be in the hands of consumers who will use them to access your website. Will your site work? Or will it end up mangled by a subpar web browser, odd screen size or slow network connection?

No one wants to rewrite their website every time a new device or browser hits the web. That’s why approaches like responsive design, and the even broader efforts of the future-friendly group, are trying to develop tools and techniques for building adaptable websites. That way, when a dozen new tablets suddenly appear on the scene, you can relax knowing your site will look and perform as intended, no matter which devices your audience is using.

Even if you aren’t a gadget lover, CES should help drive home the fundamental truth of today’s web — devices, they are a comin’. Webmonkey has compiled helpful resources for creating responsive design in the past, but the field is new and evolving rapidly so here’s an updated list of links to help you get started responsive, future-friendly sites that serve your audience’s needs whether they’re browsing with a tiny phone, a huge television or the web-enabled toaster of tomorrow.

Basics:

  • Use @media to scale your layout for any screen, but remember that this alone isn’t really responsive design.
  • Use liquid layouts that can accommodate any screen size. Don’t simply design one look for 4-inch screens, one for 7-inch, one for 10-inch and one for desktop. Keep it liquid, otherwise what happens when the 11.4-inch screen suddenly becomes popular?
  • Roll your own grids based on the specifics of your site’s content. Canned grid systems will rarely fit the bill. The problem with canned grids is that they don’t fit your unique content. Create layouts from the content out, rather than the canvas (or grid) in.
  • Start small. Start with the smallest size screen and work your way up, adding @media rules to float elements into the larger windows of tablet and desktop browsers. Start with a narrow, single-column layout to handle mobile browsers and then scale up from there rather than the other way around. Starting with the smallest screen and working your way up means it’s the desktop browsers that need to handle @media, make sure older browsers work by using polyfills like Respond.
  • Forget Photoshop, build your comps in the browser. It’s virtually impossible to mock up liquid layouts in Photoshop, start in the browser instead.
  • Scale images using img { max-width: 100%; }. For very large images, consider using something like Responsive Images to offer the very smallest screens smaller image downloads and then use JavaScript to swap in larger images for larger screens. Similar techniques can be used to scale video.
  • Forget about perfect. If you haven’t already, abandon the notion of pixel perfect designs across devices. An iPad isn’t a laptop isn’t a television. Build the perfect site for each.

Further Reading:

  • Future Friendly — An overview of how some of the smartest people in web design are thinking about the ever-broadening reach of the web: “We can’t be all things on all devices. To manage in a world of ever-increasing device complexity, we need to focus on what matters most to our customers and businesses. Not by building lowest common-denominator solutions but by creating meaningful content and services. People are also increasingly tired of excessive noise and finding ways to simplify things for themselves. Focus your service before your customers and increasing diversity do it for you.”
  • Building a Future-Friendly Web — Brad Frost’s excellent advice: “Think of your core content as a fluid thing that gets poured into a huge number of containers.”
  • There is no mobile web — “There is no mobile web, nor desktop web. It is just the web. Start with the content and meet people halfway.”
  • Responsive by default — Andy Hume on why the web has always been responsive, but was temporarily sidetracked by the fad of fixed-width sites.
  • COPE: Create Once, Publish Everywhere — NPR’s Director of Application Development, Daniel Jacobson, walks through how NPR separates content from display and uses a single data source for all its apps, sites, APIs and feeds. A great example of what Frost talks about regarding content as a fluid thing.
  • Support Versus Optimization — It can seem daunting to support dozens of mobile browsers, but if you aren’t up to the challenge of a few mobile browsers now what are you going to do when you need to support car dashboards, refrigerators, televisions and toasters, all with dozens of varying browsers?
  • The Coming Zombie Apocalypse — Not satisfied thinking a few years ahead? Scott Jenson explores further into the future and tries to imagine what the web might look like when devices all but invisible.

Techniques:

Tags: , ,
File Under: CSS, HTML5, JavaScript
Dec
7
2011

Celebrate the Holidays With Advent Calendars for Web Nerds

By

The holiday season is upon us and for web nerds that means only one thing — advent tutorials.

Sure, it might be getting colder, possibly even snowing where you are, but the real way a web developer knows that the holidays are here is that 24Ways, the annual advent calendar for web nerds, is out. That means it’s time to learn new tricks, re-learn best practices and get a leg up on some of the year’s best ideas in web development.

This year’s 24Ways has a decidedly responsive design slant to it (so far anyway). Developer Jeremy Keith weighs in with a tutorial on how to use conditional loading for responsive designs. Adaptive images creator Matt Wilcox also has a great in-depth look at how his technique can serve up the appropriate image size without changing your HTML markup.

Other highlights include a great article from Rich Thornett on the hazards of relying on third-party widgets within your pages. Thornett’s solution is to load your widget content into a hidden <div> at the bottom of the page and then use a local script to move the loaded content from the hidden <div> to its display location. That way, should your third-party widget fail to load, at least it won’t stop the rest of your page from loading.

Also be sure to check out Drew McLellan’s walk-through of CSS 3′s unicode-range. By adding the unicode-range property to a @font-face rule, you can, for example, specify a different font just for fancier ampersands. McLellan covers how to make it work and how to handle the (inevitable) browser shortcomings.

Awesome as 24Ways is — and we’re looking forward to seeing the rest of it — it’s certainly not the only advent calendar around for web nerds. The Mozilla Developer Network has an advent calendar up with some nice articles on topics like WebGL, though in this case most of the articles listed are already up elsewhere on the web.

Somewhat more interesting, especially for those of you who want to get even nerdier than usual this year, is the Performance Calendar. This advent calendar is devoted to tackling the often confusing world of website optimization. All the posts are worth a read, but be sure not to miss Guy Podjarny’s article on why “inlining everything” is not the answer to your site’s speed problems. Also worthwhile is Tim Kadlec’s detailed investigation of mobile networks, appropriately titled: Carrier Networks: Down the Rabbit Hole.

Altoids Advent Calendar photo by Kim Taylor/Flickr/CC. For instructions, visit her blog.

File Under: APIs, HTML5, JavaScript, Multimedia, Web Standards
Nov
10
2011

Mozilla Reinvents Web Video With Popcorn 1.0

By

Video on the web has always been a bit disappointing. After all, it’s pretty much just like television, only smaller. Unlike the rest of the web, video is just as much a passive experience in your browser as it is anywhere else.

Mozilla would like to change that. The company’s effort to bring a more interactive video experience to the web is known as Popcorn.js and it recently reached 1.0 status. If you’d like to play around with Popcorn, head on over to the Mozilla site and download a copy. Popcorn uses HTML5 video features and at the moment works best in Firefox and Chrome.

At its core, Popcorn is about making HTML5 web video into something more than just another television.

While it’s nice to have a way to embed videos without Flash, HTML5 video is capable of much more than just, well, video. It’s HTML, after all. That means it can tap into things like WebGL, or use JavaScript to augment video in real time — annotating videos with information like location, details about the people and topics in the video, subtitles, Twitter feeds, current weather information, links and much more.

Popcorn is simply a JavaScript library that aims to simplify the process of adding external data culled from around the web to your video. To give an idea of what’s possible with Popcorn, Mozilla is showcasing the movie One Millionth Tower, a documentary film about an apartment building and how residents imagine the future. One Millionth Tower premiered online last weekend at Wired.com. If you haven’t seen it yet, head over to the Underwire blog.

One Millionth Tower uses some tricks beyond Popcorn (like WebGL for some 3-D elements), but most of its coolest effects — like the way the environment in the film changes based on the real-time weather conditions and time of day at the Toronto high-rises where the documentary was filmed — are all courtesy of Popcorn.

If it happens to be snowing in Toronto when you watch the film, it will begin snowing in the virtual world of One Millionth Tower. At other points in the film Popcorn pulls outside information from Flickr, Wikipedia, Google Maps and, of course, Yahoo Weather. Pretty much any web service with an API can be plugged into an HTML5 video in real time with Popcorn.

A more mundane but potentially more widespread use for Popcorn is subtitles. Using Popcorn, a set of subtitles attached to a video could be sent on to an online translation tool and converted to whatever language you wanted on the fly. Popcorn could then pipe the translation back into the video. In other words, subtitle your movie once and anyone will be able to understand it.

So how does Popcorn work? Well, Popcorn.js takes the native HTMLMediaElement properties, methods and events — collectively known as HTML5 video — and normalizes them into an API. The API has a plug-in system so developers can contribute and reuse code for common tasks. In fact, Popcorn already has dozens of plugins for most popular web services like Twitter, various maps, Facebook, Processing.js and, of course, all the services mentioned above in conjunction with One Millionth Tower.

In addition to the Popcorn.js framework, there’s also Popcorn Maker, a web-based graphical user interface for creating Popcorn-based videos. Popcorn Maker is the newest member of the Popcorn family and is not yet a 1.0 release. Its goal is to offer the familiar timeline controls you’d expect in video editing software, but at the moment it’s an alpha release and can be a little buggy. Popcorn Maker is powered by another bit of JavaScript, dubbed butter.js, which could be used to add Popcorn editing features to any desktop video editing software, though as of this writing we aren’t away of any popular video editing apps that use it.

To get started making Popcorn movies head on over to MozillaPopcorn.org, grab the source code, read the documentation, check out the plug-ins and try Popcorn Maker. Also note that, if you prefer, Popcorn can be checked out through GitHub.

Homepage photo: jennie-o/Flickr

See Also:

File Under: JavaScript, Programming, Web Standards
Oct
10
2011

Google Throws New ‘Dart’ Programming Language at the Web

By

It’s not every day that someone tries to add a new programming language to the web. There’s a good reason for that. The great trinity of web development — HTML, CSS and JavaScript — while not perfect, has proved itself highly flexible and capable of adapting as it evolves, which, in the end, might be more important than perfection.

But, regardless of how well those three have served the web thus far, they are not enough for Google, which is hoping the web will now embrace Dart, Google’s brand-new programming language for “structured web programming.”

The first hint of Dart surfaced about a month ago when an internal Google memo was leaked onto the web (the memo itself dates from 2010). In it Google claims that “JavaScript has fundamental flaws that cannot be fixed merely by evolving the language.” The answer, for Google, was to go off and create its own homebrewed solution.

That solution is Dart, a “class-based optionally typed programming language for building web applications.”

Lars Bak, a software engineer working on Dart, says the language is designed to work with every thing from “a one-person project without much structure to a large-scale project needing formal types in the code to state programmer intent.”

In other words, Dart is aiming to be a one-size-fits-all solution for writing apps on the web. Dart has been built from the ground up with this goal in mind. Indeed Dart offers some interesting tools, including optional types and the ability to declare private methods via an underscore. Unfortunately for Dart, a couple of novelties don’t seem to be winning over programmers. The Hacker News discussion thread on Dart is full of rather barbed critiques with hardly a supportive voice to be heard.

Dart on the web

Appealing to programmers is only half of what Dart needs to succeed; it also has to work well on the open web. For that Google has two solutions.

The first and ideal solution will be to execute Dart code in a browser-native virtual machine (very similar to how JavaScript is handled today). Of course that means the rest of the browser makers need to join Google in supporting Dart. Because that isn’t likely to happen any time soon, nor will it ever happen for legacy web browsers, Google has a fallback plan — a compiler that translates Dart code to JavaScript.

While the JavaScript compiler solution will mean slower web apps, it also means that Dart apps would always be able to run, regardless of the browser in question. That’s good for older browsers, but it also raises some questions about where Google plans to go with Dart.

Essentially, Google has set up a two-tier system for running Dart in the browser, and that is where Dart might run afoul of the open web.

Prior Dart Art

How Standards Proliferate by XKCD

The leaked Google memo that appeared on the web last month created a tempest in the web standards community teacup. The idea that Google had a secret project designed “to replace JavaScript as the lingua franca of web development” did not sit well with those who support open web standards.

The company appears to have backed off that stance somewhat for the official release. In fact, Google hardly mentions JavaScript in its Dart announcement and Lars Bak tells CNet that Dart is “not going to replace JavaScript…. JavaScript is a cornerstone of the web today, and it will continue to be for a long, long time.”

That message may be too little, too late. Publicly, Google may now be pushing the message that Dart is complimentary to JavaScript, but the blunter language and goals outlined in the leaked memo are already out there, fresh in developers’ minds. That, combined with Google’s less than stellar track record with its “open” projects may make it difficult for Dart to find supporters.

While Dart is open source and available for anyone to use, Google does not have a strong record of fostering open projects; that is, projects where the community can not just download and compile code (Andy Rubin’s “definition of open“) but can actually have a hand in creating features and guiding the direction of the project.

Until the latter component is well established, don’t expect other browser makers to adopt Dart. So long as Google controls the strings it’s unlikely its arch rivals like Microsoft and Apple will support Dart.

Without that support, Dart won’t be running in a virtual machine; instead it will fall back to running as JavaScript. That effectively means that, while Dart will run in any browser, it will likely have subpar performance in any browser lacking the virtual machine.

What standards proponents fear is a web where only Google’s Chrome browser ever fully supports Dart. That would mean that, while Dart apps would work everywhere, they’d be significantly faster in Chrome. That would send the web back to the bad old days of “works best in Internet Explorer” websites, only this time around it would be “works best in Google Chrome.”

Future Dart

It’s possible that Google will use Dart to finally create a true community-driven project. The company has already said it plans to eventually submit Dart for standardization, which would certainly help.

It’s too early to write off Dart, but it’s also too early to say it will be anything more than a novelty Google uses in its own apps (like WebP or even SPDY). Even if Dart can convince both developers and browser makers to jump on board, don’t look for Dart to become the “lingua franca of web development” any time soon.

See Also:

Tags: ,
File Under: JavaScript, Programming
Aug
15
2011

Scratchpad Puts a JavaScript Editor Inside Firefox

By

Firefox 6 is set to make its move from beta to final release this week, and we’ll look at the latest version once it’s official, but in the mean time the Mozilla Devtools blog has posted details on a new feature for JavaScript developers: Scratchpad.

If you’re a JavaScript developer you probably use tools like web console or Firebug or some combination of both to test and debug your code. Both are handy, but both are primarily line by line tools, what do you do when you want to test massive scripts?

Firefox’s new Scratchpad is different from Firefox’s other JavaScript dev tools in that it is just, as the Mozilla Blog puts it, "a text editor that knows how to run JavaScript." Scratchpad gets its own window and makes life much easier when you’ve got a long script to debug.

To use Scratchpad, head to Tools >> Web Developer >> Scratchpad, which will bring up a new, smaller window with a rudimentary text editor in it. Write your code, select some (or all) of it and then select one of three options from the Execute menu: Run, Inspect or Display. Scratchpad can also save your scripts or even load external JavaScript files.

Scratchpad is never going to replace your favorite text editor, but it just might make it a bit easier to test long scripts in the browser. For more info on everything Scratchpad can do, head over to the Mozilla Devtools blog.

See Also:

Tags: ,
File Under: CSS, JavaScript, Mobile, UI/UX, Visual Design, Web Basics, Web Standards
Jun
9
2011

Tips, Tricks and Best Practices for Responsive Design

By

Unless you’ve been too busy wake boarding the Alps to notice, there’s a movement afoot amongst web designers — Responsive Design. Ethan Marcotte coined the term responsive design to describe the process of using liquid layouts and media queries to scale websites so that they fit any screen size. If you’ve never heard of responsive design before, Marcotte’s introduction is well worth a read.

In a nutshell, responsive design means using fluid grids, fluid layouts and @media queries to adapt your website to the plethora of different screen sizes on today’s (and tomorrow’s) web. Whether your visitor is on a phone, an iPad or a gargantuan desktop monitor, your website adapts.

Responsive design becomes an even more appealing tool when you start, as Luke Wroblewski says, designing for mobile first. That is, start with the small screen. Strip your site down to its essence and then build from there. Starting from the bare bones ensures a great mobile site, and it forces you to really focus on what matters to your visitors.

So how do you go about building a good responsive site? Well, that depends on the individual website, but there are some common patterns that are starting to emerge. To help you get started with responsive design, here are a few nascent best practices we’ve gleaned from a variety of sources around the web:

  • Use @media to scale your layout for any screen, but remember that this alone isn’t really responsive design.
  • Use liquid layouts that can accommodate any screen size. Don’t simply design one look for the iPhone/Android, one for tablets and one for the desktop. Keep it liquid, otherwise what happens when some new, intermediate screen size suddenly becomes popular?
  • Roll your own grids based on the specifics of your site’s content. Canned grid systems will rarely fit the bill. The problem with canned grids is that they don’t fit your unique content. Create layouts from the content out, rather than the canvas (or grid) in.
  • Start small. Start with the smallest size screen and work your way up, adding @media rules to float elements into the larger windows of tablet and desktop browsers. Start with a narrow, single-column layout to handle mobile browsers and then scale up from there rather than the other way around.
  • Use the Respond or CSS3 Media Queries JavaScript libraries to bootstrap @media query support into older browsers that won’t otherwise know what to do with it. Starting with the smallest screen and working your way up means it’s the desktop browsers that need to handle @media, make sure older browsers work by using polyfills like Respond.
  • Forget Photoshop, build your comps in the browser. It’s virtually impossible to mock up liquid layouts in Photoshop, start in the browser instead.
  • Scale images using img { max-width: 100%; }. For very large images, consider using something like Responsive Images to offer the very smallest screens smaller image downloads and then use JavaScript to swap in larger images for larger screen.
  • Embrace lazy loading. There may be items on your site, auxiliary content that’s nice to have, but not essential. Load that content using JavaScript after the primary content is done loading.
  • Forget about perfect. Even with these suggestions you’re still leaving out users who have old browsers with JavaScript disabled. Such users are increasingly rare and if they see the mobile layout on their desktop, guess what, it’s not the end of the world. Your site is still perfectly usable.

Keep in mind of course that responsive design is a young idea and new ideas — and new tools — pop up everyday. Think of these not as hard and fast rules, but guidelines to build on.

See Also:

Tags: , ,
File Under: HTML5, JavaScript
Jun
2
2011

Load Only What You Need With Yepnope.js

By

If you’ve started using HTML5 and CSS 3 in your projects, chances are you’re using Modernizr to detect for features and gracefully degrade for those browsers that don’t support the latest and greatest on the web.

Modernizr adds classnames to your page which you can then use for browsers that support the HTML5 features you’re using. It’s a great tool, but it does have some overhead; wouldn’t it be cooler if you could just test for features and load polyfills all in one step?

That’s the thinking behind the powerful (and cleverly named) Yepnope.js. Yepnope is an asynchronous conditional resource loader which loads only the scripts that your users need. And at 1.6kb it won’t add much overhead to your page.

In fact, Yepnope.js is so handy it will be integrated into Modernizr 2, which is currently a beta release.

That said, Yepnope.js isn’t right for every situation and the project freely admits that some other conditional loaders are a bit faster. One gotcha to be aware of is that Yepnope.js requires that your server sends proper cache headers. Hopefully your sever does, but with some shared hosting setups that just isn’t possible.

If Yepnope.js doesn’t do quite what you want there are other options like the larger, but more feature-rich RequireJS.

See Also:

File Under: CSS, JavaScript, Software & Tools, Web Standards
May
25
2011

Review: Hype Animates the Web, No Flash Necessary

By

To create animations using web standards like HTML5, CSS 3 and JavaScript requires writing code. That’s fine for programmers who love nothing more than the blank space of a new document in their favorite text editor, but it’s a problem for designers accustomed to the visual, drag-and-drop workflow of animation apps like Flash. There’s nothing quite like Adobe’s Flash application for designers who want to stick with web standards.

Hype is hoping to change that. The new Mac OS X application uses many of the familiar interface elements that Adobe Flash offers — timelines, keyframes and drag-and-drop editing — but generates web standards output consisting of HTML, CSS and JavaScript. In short, Hype hopes to be to standards-based animation what the Flash app is to creating Flash movies.

While the initial release of Hype is impressive, it’s far from a Flash replacement. Perhaps more disappointing is that animations created with Hype suffer some of the same drawbacks you’ll encounter when using Flash.

The Good

For those with a background in Flash, the Hype learning curve is very short. Hype’s menu layout and palette structures are different, but the basic elements are essentially the same. To use Hype you drag objects — images, videos, vector art, etc — onto the stage and then you animate them by creating keyframes. One thing that’s different from Flash is Hype’s very handy “record” feature. To animate an element, just get everything where you want it for the first frame, add a new keyframe and then click record. Everything you do after that is recorded and translated into CSS and JavaScript-based animation.

To create a more complete movie-like animation Hype uses scenes, which break up your content and allow you to create transitions. For example, to create a slideshow, just drag your images into Hype and then create a new scene for each image. Add some transitions and you’re on your way. (That’s not the only way to create a slideshow, but it’s one of the simplest.)

Hype doesn’t offer everything you’ll find in Flash. Most notably there is no concept of MovieClips — self-contained movies within movies. There’s also no equivalent to Flash’s customizable tweens and advanced filters for blending objects.

Hype does offers plenty of canned elements, like buttons, boxes, and text boxes, to speed up simple tasks like adding text and other elements to your animations. To add elements to your page you just head to the Insert menu, select what you want and then you can style it with the properties palette just like you would any other element in Hype.

Hype's Flash-like IDE makes animating easy

Hype is simple enough to use that I was able to download a copy, watch the intro movie and five minutes later I generated the simple animation at the bottom of this post. Naturally to create something more interesting and useful will take you a bit longer, but it’s nothing compared to writing out the CSS and scripts by hand.

While Hype is primarily a visual editor, there are options to access properties like an element’s innerHTML and the Identity palette allows you to customize element IDs so you can target that element from other scripts. This is particularly handy if you want to create some custom CSS on top of what Hype generates.

The Bad

Hype, despite what its marketing materials claim, does not generate HTML5. It generates good old (standards compliant) HTML 4, CSS and JavaScript. That shouldn’t detract from from what Hype is capable of, but it’s disappointing to see the amount of HTML5, ahem, hype, surrounding Hype. Hype doesn’t even use canvas elements (animations are wrapped in div tags), nor does it use any of the new APIs (like say History or Web Workers).

Perhaps most disappointingly Hype doesn’t use the HTML5 History API. Because of the way Hype documents are embedded in a page, like Flash animations, Hype breaks the browser’s back button. What’s even more disappointing about Hype breaking the back button is that it’s not necessary. If Hype supported the History API, Hype documents could easily update the URL and not break one of the most fundamental elements of the web (see Mark Pilgrim’s excellent write up in the History API for more details on how to use it).

In some use cases that won’t matter, but if you’re thinking Hype would make a great slideshow creator, well, keep in mind that no one will ever be able to link to your individual photos without some extra effort on your part. Similarly, any transitions that happen in any Hype animation won’t be accessible via the back button.

Hype does offer an embedded editor so you can hook up the JavaScript yourself and take advantage of the History API, but then you’re back to writing code yourself.

Hype also makes some assumptions about your site structure when it generates HTML and JS. If you’ve got FTP access to your server then there’s nothing to worry about. But to embed my simple Hype animation in this post I had to change quite a few file references in the code. Hype assumes that all the resources it needs are in the resources folder it creates. Since I don’t have FTP access to this domain there is no way to get that folder on the server. Instead I uploaded the three required files through WordPress and then had to edit the generated Hype code to add the correct file paths. It wasn’t all that hard, but it did mean digging into the code, which at least partially defeats the purpose of Hype.

Another things to keep in mind is that Hype is heavily geared toward the WebKit rendering engine. While most of the effects work just fine in other standards compliant browsers, there are a few things that only work in WebKit. Where possible Hype falls back to pure JavaScript (for example in browsers that don’t understand CSS 3). Fortunately the Hype export function will warn you about any browser incompatibilities when you publish.

Conclusion

Despite some publishing hiccups and a few missing features, Hype is still one of the easiest ways I’ve seen to create Flash-free web animations. It’s like having most of what’s good about Adobe’s Flash app, without the downside of publishing to the Flash file format. Sadly Hype still falls prey to some of Flash’s weaknesses, but this is a 1.0 release and no doubt Hype will improve as time goes on.

Hype is currently available for $30 in the Mac app store. If you’ve been wanting to transition from Flash-based animations to web standards, but haven’t wanted to wade through the complexities of JavaScript and CSS 3, Hype is the droids you’ve been looking for. Just bear in mind that it has a few shortcomings of its own.

Hype Example

Here’s a very simple example of an animation created with Hype. Use the WebKit Inspector or Firebug to see how it works.

Tags:
« OLDER POSTS