If you’ve ever needed to connect to a remote server without installing any desktop software or doing anything other than opening a new browser window, then you need to check out Gate One. Gate One is a web-based terminal emulator and SSH client that will work in any modern web browser.
The brainchild of developer Dan McDougall, Gate One is the result of nine months of coding. While Gate One may not be the first project to put a terminal emulator in your browser — existing options include Shell in a Box and Ajaxterm among others — it has quite a few features that go well beyond the basics found in other emulators. For example, Gate One uses WebSockets rather than traditional polling so it’s able to keep SSH connections open without spiking your CPU and grinding the browser to a standstill. Gate One also has the ability to resume sessions after being disconnected.
Throw in multiple simultaneous terminal sessions, a way to save SSH bookmarks, a plugin architecture and the ability to play back, save and share terminal sessions and you’ve got a pretty respectable replacement for Putty and its ilk. Not that Gate One is intended to replace a desktop SSH client, but for situations where you can’t run a desktop app Gate One just might be the emulator you’ve been looking for.
The front end of Gate One is written entirely in HTML5 and JavaScript, which means it will work in any modern browser. Behind the scenes Gate One uses HTML5 WebSockets to connect to a Python-based SSH server.
Gate One is available from GitHub and is dual-licensed under either the AGPLv3 or a proprietary license.
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.
Responsive design is no longer just something you’ll find on the portfolio websites of the designers and developers who pioneered the idea. These days using media queries to adapt to varying screen sizes is well on its way to being a mainstream design goal.
Head over to a responsive design showcase like Media Queries and you’ll find plenty of “real world” websites — like Opera or Arizona State University — using media queries to build responsive websites.
But while media queries are a big part of responsive design, they don’t solve every challenge the small screen presents. For example, many otherwise great responsive websites still serve full size images to mobile browsers. Many responsive sites use the max-widthimage scaling technique which dynamically re-sizes your image to fit the screen, but sadly that doesn’t downsize the actual image file.
Using the max-width trick neatly handles images on varying screen sizes, but, by itself, it doesn’t address the bandwidth issue. In fact, loading big images and forcing mobile browsers to scale them is the worst of both worlds — large image downloads and processor-intensive downscaling. And, not only are large images a waste of bandwidth for mobile users, with mobile data caps becoming more common, you may well be costing your visitors money.
A far better approach is to use the max-width trick, but also serve smaller images to smaller screens — that means less bandwidth and little or no downscaling. Mobile platform consultant Peter-Paul Koch has a nice overview of how JavaScript can be combined with media queries to swap out your mobile-size images for larger ones on larger screens. The developers at Filament Group refined this approach with the Responsive Images project.
However, as nice as the Responsive Images approach is, it requires maintaining two sets of images on your server. For existing websites with content management systems already up and running, and tons of images tied to existing content, it can be difficult and time consuming to go through and create a second set of smaller images.
The burden of an existing CMS led developer Matt Wilcox to take a different approach to the mobile image problem. The result is what Wilcox recently decided to call Adaptive Images. The Adaptive Images script works much like the Filament Group’s Responsive Images code, but Adaptive-Images manages its own image resizing so there’s no need to do anything to your existing website — just drop in the Adaptive Images code and you’re done.
There is, however, one other big difference between the two that’s worth noting — the Filament Group’s Responsive Images takes a mobile first approach while Wilcox’s Adaptive Images does not.
That is, if JavaScript is disabled, Responsive Images falls back to using only the small image. Adaptive Images on the other hand will fall back to the large image. While we generally suggest taking a mobile first approach, in this case the convenience of slipping Adaptive Images into an existing site outweighs the advantages of a mobile first approach. However, if you’re building a new site from scratch and your CMS can’t handle tracking separate image sizes, chances are you’re using the wrong CMS.
To get Adaptive Images up and running on your website you’ll need to have an Apache 2 server with PHP 5.x installed. For more info, head on over to the Adaptive Images website or you can grab the code from GitHub.
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.
Google has released Chrome 14 to the Chrome beta testing channel, which includes, among other new features, the initial beta release of Google’s "Native Client" technology, first announced in 2010.
If you’d like to try out Chrome 14 beta, head on over to the beta downloads page.
Chrome 14 has several improvements including the much better OS X Lion integration we mentioned previously, along with print-preview support for Mac OS X users. But possibly the biggest news is that Google’s Native Client technology is getting closer to prime time.
Native Client is a set of open source tools that allow Chrome to run compiled C and C++ code the same way the browser currently runs JavaScript or other common web programming languages. Native Code offers both a security sandbox and a set of interfaces that provide C and C++ bindings to the capabilities of HTML5. That means web application developers will be able to tap into desktop libraries to create faster, more powerful web apps.
For example, imagine you wanted to create a video editing web app along the lines of Final Cut Pro. You could building the user interface with HTML, CSS and JavaScript, but the actual processing of video would likely be very slow if you handed off the job to the server. You could try to use JavaScript in the browser, but again speed would be an issue. Native Client would allow you to do the video processing in the browser, but running native code. Then all you need to do is push the final changes up to the server, which makes for a much snappier web app.
How much faster Native Client will be is open to debate. Certainly JavaScript performance has improved since Google first announced Native Client in June 2010. The past year has seen huge JavaScript speed improvements in nearly all the major web browsers, which means Native Client feels less necessary than it might have when Google first began working on it. Of course there are still plenty of web apps, especially computationally intensive apps like non linear video editors, that could benefit from Native Client.
The problem for web app developers is that thus far Native Client is only available in Chrome. Google has created an API, dubbed Pepper — Native Client is abbreviated NaCl, which is also shorthand for table salt, get it? — which allows the browser to talk to Native Client and means that any web browser could, in theory, implement it. Thus far, however, none have.
For now, if you want to test out some Google’s sample code, grab the latest Chrome beta and head on over to the Native Client demo page. In my testing Native Client was indeed quite speedy, but running it for any length of time sent my laptop’s fan into overdrive.
Conway's Game of Life running in native client
While Native Client is still a beta release, if it catches on with developers and other browsers embrace it, it could open the doors for a whole new generation of faster, more powerful web apps.
Browse Our Tutorials
Cheat Sheets
Color Charts
Cut & Paste Code