It is quite interesting to see how technology moves in circles. With canvas being the new fun toy to play with for creating browser-based games we have to find solutions to fake a 3D environment to be really fast (sure there is Canvas 3D but it is overkill for most games). The trick is to dig into the tricks arsenal of old-school game development on machines full of win like the Commodore 64 or Amiga.
We have been long term fans of Román and the fantastic demos and samples that he puts together, usually involving CSS goodness. We messed up the other week though when we linked to his work on a scrolling coke can. I do these postings as a labor of love, and since Ajaxian isn't my day job, that means that the labor often happens at 2am. In this case I made the rookie mistake of grabbing an iframe to his demo so it would run inline. Román then looked up to see his servers getting pummeled and a bill is associated with that traffic. He quickly rick rolled us (thank you for not going for something much worse ;) and Christian Heilman (who is in Europe along with Román) saw it and kindly switched in an image of the code can effect.
I woke up the next morning to learn about this all and see a post that Román did talking about our hot linking. I immediately responded saying how sorry I am. I aim to highlight the great work that is done, not cause an issue.
Román is a great guy and kindly offered to collaborate and show friendship with Ajaxian (and myself) by putting together more amazing demos to share on the blog. Inline. Not hot-linking. :)
Here they are
These effects are CSS level 1 and 2.1 only. There is no javascript, css3 or whatever, just html and css.
They are all based on the CSS 2D displacement map technique that Román Cortés discovered when he created the infamous CSS Coke Can effect. Since displacement maps are very versatile, Román Cortés wanted to show us more and different applications of these.
This is simple displacement map usage to distort the borders of the prism, with a transparent .png image on top to add the shadows, orange semi-transparent bg and the Ajaxian's "a" logo. The background painting is an original artwork by Román Cortés. Move the area around to see the effect the prism has on the underlying painting.
There some comments in the original code can posting that the spinning direction was unnatural. So, here he did spin as the commenters wanted it. To make it possible, he had to mirror the label texture and adapt the source code.
By using several cylindrical displacement map layers with a growing radius and png transparent textures, it is possible to do voxel surface rotations like this one.
Thanks for Román for being so reasonable, and for creating such fun examples for us all. We hope to go deeper on the implementation of some of these examples in the future.
When I was a part of Mozilla Labs day to day, I always loved the vision and team behind Weave. I kept wanting the implementation to match the vision, but it is a tough problem and it takes time to bake. Well, it is getting there now.
Weave is special because it offers a series of back-end services (more than just sync) that are build with users (and their privacy) in mind, rather than business models. I have talked to a couple of entrepreneurs recently and thought that there ideas could be implemented nicely on top of Weave.
It is still early days, but I am jazzed to see the platform getting opened up. I am hoping to get clients for Safari, Chrome, and IE.... and look forward to a webOS client too :)
Aaron Boodman created Greasemonkey back in the day. He also worked on Gears. And most recently he created Chrome Extensions. I have a funny feeling that folks were pinging him daily "hey, when ya gunna give me Greasemonkey on Chrome" and he just delivered:
One thing that got lost in the commotion of the extensions launch is a feature that is near and dear to my heart: Google Chrome 4 now natively supports Greasemonkey user scripts. Greasemonkey is a Firefox extension I wrote in 2004 that allows developers to customize web pages using simple JavaScript and it was the inspiration for some important parts of our extension system.
Ever since the beginning of the Chromium project, friends and coworkers have been asking me to add support for user scripts in Google Chrome. I'm happy to report that as of the last Google Chrome release, you can install any user script with a single click. So, now you can use emoticons on blogger. Or, you can browse Google Image Search with a fancy lightbox. In fact, there's over 40,000 scripts on userscripts.org alone.
Not all of the scripts will work. The deeper the integration, the less chance of success. We now have user scripts supported in a variety of browsers, and hopefully they get more and more portable.
If browsers could surface the functionality to mainstream users, good things could happen beyond us power users.
A Googler and a Facebooker were in a pub discussing the complexities of building out a rich modern Web application. There are a ton of dependencies, and you need to be proficient in multiple languages and tools (JavaScript, HTML, CSS, SQL/NoSQL, backend languages, build tools, etc).
Well, they may not have been in a pub.... but a deadly duo did get together to try to solve this problem.
All of us on the Asana team have deep backgrounds writing rich web applications at companies like Google and Facebook. We've been continually frustrated by how long it takes to write software, and by a nagging feeling that in some deep sense we've been writing the same code over and over. Even when using the latest and greatest frameworks and disciplines, writing fast, highly interacting web applications involves a lot of accidental complexity:
First you need server code to figure out what data the browser needs. Hopefully you have an ORM layer, but you still need to carefully structure your code to minimize your backend dispatches, and you need to carefully keep that in sync with your front-end code lest you don't fetch enough data or hurt performance by fetching too much. If it's a Web 2.0-style app, you re-implement a ton of that server-side code in JavaScript, once for creating the page and then again as controller code for keeping it up to date and consistent. And when the user changes something, you bottle that up -- typically in a custom over-the-wire format -- and send it as an XHR to the server. The server has to de-serialize it into different data structures in a different language, notify the persistence store, figure out what other clients care about the change, and send them a notification over your Comet pipe, which is handled by yet more JavaScript controller code. Offline support? More code.
This is not a one-off task: it's rote work that adds complexity to every feature that you build in every application. By the time that you are done with all this, the important and novel parts of your application are only around 10% of your code. We wondered whether we could build a programming system in which we just wrote that 10% -- the essential complexity -- and a compiler handled the other 90%.
And this lead them to their solution:
Inspired by incremental computing, we're building Lunascript as a simple way to write modern web applications. Lunascript has a syntax and easy of use reminiscent of JavaScript, but a powerful pure-functional lazily-evaluated semantics historically confined to academic languages.
A Lunascript application specifes a data model and a function from the model to the view or user interface, annotated with handler functions from user inputs to model mutations. From this the Lunascript compiler produces a functioning Web2.0 application -- the client-side JavaScript, the server-side SQL, and everything in between -- complete with real-time bidirectional data synchronization. There's no need to write separate code to help the server figure out which values need to be sent to the client: the server can do this by simulating the UI. Because a LunaScript application only specifies how the UI should look given the current data (rather than how the UI should be updated as changes happen) it's impossible to write a UI that loads correctly but does not stay correct as changes are made.
"What does it look like?" I hear you cry. Time for a hello world, and since Comet is in the mix, that means a chat server:
You will notice the protobufferness at the top, and the fn of less characters, and E4X-like.
To learn more, let's listen in to Dustin as he gives us a walk through the world of LunaScript:
I talked to the guys and asked a few questions which they answered..... what questions do you have for them though? Are you excited about what a higher level abstraction could give you? Or do you like to be close to the metal?
The following post is a reprint from my personal blog. It is editorial in nature and even delves into random politics. I apologise. You can deal with it though :)
Steve Jobs didn't hold back when talking about Google and Adobe. That is great. Life is so much more fun when people speak their mind. I remember hearing a story when Sir Steve was asked why mac keyboards where the way they were. He grabbed a PC keyboard and started to rip out "stupid keys" (print screen, F keys, and the like) and swore a lot.
We love to paint with broad black and white brushes these days don't we? Whenever I hear people talking about Google being "evil" or not.... I sit back and think about how interesting it is that companies become "people", especially in this country.
Corporations are recognized by the law to have rights and responsibilities like actual people.
That may have been a convenient (and often almost genius) abstraction by lawyers, but it is screwed up. It feels like the times when you use inheritence in a way that isn't a ISA relationship, but it does kinda make the code nice. We have all done that, until we learned to favor composition. Corporations ISA Person? No. They are composed of them though.
I have been thinking about this ever since the recently surprise court decision the other day that "allows corporations and unions to pour unprecedented amounts of money into elections."
Lawrence Lessig had some interesting commentary:
The court decision does feel totally wonky to me. Right now, $ has a direct bearing on elections, and allowing multi-nationals (who have the money) to rain it down makes no sense.
Fun aside
My renaissance friend Graham Glass talks about how corporations can be considered a single conscious in his series on "the mind".
The issue with the vast number of corporations is that they are profit driven entities whose charter is to bring financial reward to shareholders. While you could argue that we as a species are driven by the selfish gene, corporations are driven by profits. Duh. Capitalism.
Google is a company. It is driven by this same goal. Now, there are various paths to a particular goal to make profits. Some companies sell things that kill people (weapons, cigarettes, etc). Others offer medical devices. All companies are not equal. Having spent time at Google, I do feel like the place isn't just an evil cult. The people that make up the consciousness were very driven strong willed people that cared about the company mission (universal access to information and all that) more than just the $. Sure some folks are focused on that. Also, although the wool could be placed over your eyes, the guys at the top of the chain have their hearts in the right place. While Larry and Sergey are there, decisions will be made that aren't solely based on profit. They want to create a different kind of legacy and company.
That being said, I think it is quite easy to fall into a trap such as:
If we do something here to block competition, we can make more $ and since we are Good Guys we can do better things with that money!
Google will sometimes do things that could be considered "evil" by some. That is life.
The good news with Google is that their search and ads business deals in a trust economy. It doesn't take much to switch from Google to Bing. Google knows that. Even though they have some HUGE advantages (technical [data centers, talent], brand, etc) the low barrier to change is huge.
Not all corporations are profit driven
I had the huge pleasure of working for Mozilla, which is a mission based corporation. Wow does that make life different. While you have to sustain yourself, it does mean that you think of the world very differently. You would rather go out in a blaze of glory doing something great for the mission, than just slowly die not doing much. Every choice you make .... you think of the mission.
It was interesting to work there knowing that I actually wouldn't want Firefox to be a 90% browser. You can fall into the similar trap as above and think:
We are mission based! If we had that domination we would use it for good!
But, not having that power in one hand is even better. Imagine working somewhere thinking "in my wildest dreams, the market would be shared somewhat evenly with the competition." The Open Web is amazing in that there is NO SINGLE VENDOR. If we are able to keep a decent balance between browsers (and thus the platform as we know it) then we have a balance of powers. Sure, in some ways you can't move as fast as a dictatorship, but there is a reason we don't want dictatorships in our government (even if the trains run on time!)
And, this brings me to the Adobe half of the Steve Jobs equation. Flash isn't dead. HTML5 is slowly going to put a dent into it if we ever get some of the use cases just right (e.g. video), but Adobe has a good penetration and can move at the speed of a dictatorship. The iPhone/iPad combo not shipping Flash will have an interesting dynamic here too, hopefully helping the HTML5 video cause. There is still much more work to be done. Flash and browser plugins have had a long history at forging new paths, and the Web can come in behind them and standardize. May that continue.
I do watch for single-owned platforms such as Flash, Silverlight, or now the Apple platform (even though they do great work on the HTML5 side of the house). I don't want any of those vendors to have too much power. The thought of a Web that required the use of their technology makes me shudder (we have a piece of that with Flash video). Right now I can turn off those plugins and life moves on. Sure I can't Hulu or Netflix, but that will change. I would miss some of the Flash sites that my kids use, but they could even be partially ported over to HTML5 these days.
I don't want to "kill" these other platforms as they offer competition and spur on the industry. I just don't want any one of them to take over. It may seem like the world would be better if we all just used Macs and iPhones and iPads, but would it? Do you think Steve would be a benevolent dictator?
Erm, no.
And thus I find myself torn. I really want to go out and by that iPad....... but when is it "too late". Surely I have a few years right? I can enjoy the shiny new toy? :)
What can you do if you want to enable a fullscreen experience on the Web? You can't. Or, use Flash. Some claim that you shouldn't offer this ability as it is a security liability. Someone can put a fullscreen view that tricks the user into giving it information.
However, as much as I think user security is important, it doesn't seem like we can punt and not do anything because of this. A user agent can do a lot of things to help out.
Some (majority?) of the use cases revolve around full screen video. Eric Carlson has a WebKit checkin that enables that one case. You can webkitEnterFullScreen() on a HTML5 video element and be on your way.
You can see this in action on the SublimeVideo HTML5 player. Play the video in WebKit nightly and alt-click the "full size" arrows.
Video is great, but what about general purpose? What if you could fullscreen any element? Robert O'Callahan threw up a strawman:
Should be convenient for authors to make any element in a page display fullscreen
Should support in-page activation UI for discoverability
Should support changing the layout of the element when you enter/exit fullscreen mode. For example, authors probably want some controls to be fixed size while other content fills the screen.
Should accommodate potential UA security concerns, e.g. by allowing the transition to fullscreen mode to happen asynchronously after the user has confirmed permission
While an element is fullscreen, the UA imposes CSS style "position:fixed; left:0; top:0; right:0; bottom:0" on the element and aligns the viewport of its DOM window with the screen. Only the element and its children are rendered, as a single CSS stacking context.
enterFullscreen always returns immediately. If fullscreen mode is currently supported and permitted, enterFullscreen dispatches a task that a) imposes the fullscreen style, b) fires the beginfullscreen event on the element and c) actually initiates fullscreen display of the element. The UA may asynchronously display confirmation UI and dispatch the task when the user has confirmed (or never).
The enableKeys parameter to enterFullscreen is a hint to the UA that the application would like to be able to receive arbitrary keyboard input. Otherwise the UA is likely to disable alphanumeric keyboard input. If enableKeys is specified, the UA might require more severe confirmation UI.
In principle a UA could support multiple elements in fullscreen mode at the same time (e.g., if the user has multiple screens).
enterFullscreen would throw an exception if fullscreen was definitely not going to happen for this element due to not being supported or currently permitted, or if all screens are already occupied.
Much talking of exact API issues and more security.... but hopefully inertia does it job and we get something.
As part of an upcoming article on geo location I am putting together a few Geo Toys for myself and here is the first one. Addmap.js is a JavaScript that analyses an elements text content, finds geographical locations and links them to Google Maps. It also adds a map preview and a list of the found locations to the element.
See addmap.js in action below - all the content in the green box is generated from the paragraph of text above it. You can try it out for yourself by clicking the screenshot.
Using addmap.js is easy - sign up for a Google Maps Key and provide it as a configuration parameter. Then call the analyse function with the ID of the element to analyse as the parameter:
The Freeciv.net crew has benchmarked a path in their canvas game. It is one data point, and tests more than just Canvas itself because a lot of code is running in the game. Thus, it ends up testing the union of a particular JavaScript path and the rendering of the canvas.
Here are the results:
With Bespin we had slightly different results, and the bulk of the bottleneck was in the blitting of the canvas. Optimizations were made to canvas over the initial phase of Bespin so the various browsers would leap frog each other. Good times :)
Román Cortés is having a lot of fun with CSS tricks these days. He just built an example rolling CSS coke can that uses background-attachment, background-position, and a few other tricks to get the effect. No fancy CSS3 needed here!
I love programmers like Alex Miltsev. He won the Jetpack 0.5 content by prototyping access to the GPU from JavaScript!
Alex’s work is an alpha-prototype that shows the feasibility of the project and it requires a custom build of Firefox to use — it’s not easy to demo. However, the code sample below shows how the technology works. In this example, we are transposing a matrix at lightening speed:
People are using the internet to collaborate more than ever before. Collaboration on the internet has been evolving at a rapid pace, and the applications and technology that will drive the next wave of internet collaboration will require even greater technical complexity and more significant computing resources than is currently available through the browser environment today. While text documents, videos, music, and image-base forms of collaboration are now common place, there are many needs require a level of compute performace beyond the web platform as it exists today, such as:
consumption of high-quality digital video or music streams,
complex image or speech recognition,
manipulation and processing large pictures of nature or space,
processing large sets of tabular data locally in the browser,
complex animations with DOM elements (via DirectX or OpenGL),
exploring 3D worlds, such as SecondLife or an OpenSim Grid,
real-time audio and video editing,
having an integrated development environment that runs entirely in the browser
There are endless examples of such complex uses of the internet platform that are just not feasible with the status quo web platform. Developers have tried to overcome such barriers in the past with client-side enhancements like ActiveX, Netscape Plugins, Java Applets, but each in its own way was flawed and failed to gain mass adoption. It is possible that the Native Client project will change all this, but standardization of such initiatives across the browser landscape is a lengthy endeavor. For the near future the tools that the developer uses to provide a rich user experience remain JavaScript and ActionScript, plug-ins, such as the ones previously mentioned, are significantly limited by the architectural mismatch of performance requirements they place on the CPU.
Ben tends to get a little giddy when he hears about GPU access :)
The study asks some interesting questions revolving around the development side of the tablet. Are developers going to develop for it? What are they looking for? What are they excited about from a technology perspective?
I found it interesting to see the type of companies looking to build apps:
Games will still probably be huge on the device, but it is great to see other types of apps at the ready.
Then we have the feature requests:
Even if there is a way to run iPhone apps, it is clear that people will be spending effort creating truly native experiences. There are core differences beyond screen size here. Very different capabilities to take into account.
We are seeing an increase in consumer devices. I recently talked about the table stakes of 2010 and beyond. As a consumer it is exciting to see the vision of connected devices become real. As a developer, although there is new opportunity, it is incredibly daunting. How many proprietary SDKs can one learn and fund development on?
This is where the Web comes in. The Web has the potential to become the unifying platform across devices. This isn't about write once run anywhere, but it is about offering advanced solutions to deliver experiences across the devices using shared code, services, and APIs.
Back to Appcelerator. They publish this study right before the tablet launch. Hmm.... something tells me that Titanium (now in mobile and desktop versions) will support Tablet. As companies struggle with the pull of delivering functionality to many devices, Titanium has an opportunity of helping developers out. We have heard that Titanium is going to GA some time soon (probably in March) and we will then see pricing plans and some new products (probably around analytics and metrics). Apparently more desktop and mobile applications will be developed using Titanium than Adobe AIR this year. That would be quite a feat.
What are your thoughts on the Tablet and the Web? What did you get out of the survey?
Here is Jeff talking about their work with Scoble:
Sometimes you need to compromise, but at others you need to lead and take a stance. Our politicians do far too much via polls, and I often find myself wishing for more leadership. I could start talking about Obama and the healthcare issue in the US..... but this is a technical blog so I won't put you through that.
With Chrome and Safari supporting H.264 (and not open video formats such as Ogg Theora) some users and developers have asked for Mozilla to support it too in Firefox. Mozilla is certainly a user-centric group (which is how they have gotten so far with Firefox) but remember that they are mission based: to keep the Internet open.
Here is some of RoCs opinion. I am glad he shared it:
Taking such positions is nothing new for Mozilla and history has proved us right for doing so, in particular regarding ActiveX and Web standards in general.
Perhaps it's not widely known, but Gecko has had code to support hosting ActiveX controls, dating back as far as 1999. ActiveX controls are very much like system video codecs. ActiveX support would have been very useful to users ever since 1999, and still would be now --- certainly in corporate intranets, and everywhere in China and South Korea. Enabling ActiveX support would probably boost our market share significantly. Most users have useful ActiveX controls on their machines. But for the last ten years, even during Mozilla's most desperate days, we have consistently refused to turn this feature on, because we believe that ActiveX is not good for the Web.
I'm not suggesting that the consequences of exposing system codecs to the Web would be identical to exposing ActiveX. That's unlikely, and unknowable. But favouring our principles over short-term gains for users is nothing new for Mozilla, and when we've done it in the past, history shows it was the right thing to do.
