Riloadr - A cross-browser framework-independent responsive images loader written in Javascript

An Experiment with Mobile-First Images that Scale Responsively & Responsibly

Skeleton is a small collection of CSS & JS files that can help you rapidly develop sites that look beautiful at any size, be it a 17" laptop screen or an iPhone. Skeleton is built on three core principles:

I am pleased to announce that Issue 19 of The Monad.Reader, a special issue on parallelism and concurrency, is now available.

Issue 19 consists of the following three articles:

Mighttpd – a High Performance Web Server in Haskell by Kazu Yamamoto
High Performance Haskell with MPI by Bernie Pope and Dmitry Astapov
Coroutine Pipelines by Mario Blažević

Feel free to browse the source files. You can check out the entire repository using darcs:

darcs get http://code.haskell.org/~byorgey/TMR/Issue19

If you’d like to write something for Issue 20, please get in touch. The deadline will likely be in December; more details will be forthcoming.

Fluid grid layouts

Generic interface to many ruby templating solutions

Static site generator for Ruby

Convert Latex Equations into Images to Embed in Documents
Embed Equation in Web Page, Forum, Google Docs, Twitter
Render Latex Math Equations into Plain Text ASCII
Insert ASCII Eqn as comment in source-code or email
Convert your email or address to image to avoid spam
Supports (PNG, GIF, JPG, TIF, BMP, PNM, FIG, PS)
Control Equation Font Family, Size, Color, and Opacity

Back in February of 2010 I interviewed for a new job. It was the typical
Google hiring-process siege; I talked to six or eight people over the course
of the day. At least half of them asked me “Native vs Web apps on mobile; what
do you think?”

I think about it all the time. And I talk to developers all the time so I
think I know what they’re thinking. Thus this piece, which
goes on and on and on but that’s OK, blogging is for long-form pieces! Includes a case study with
screenshots.

Disclosures
I’m a Web guy. I started using it early, personally built one of the early
search engines, and staged one of the first million-hits-a-day sites.
I helped write the
architecture doc and
Chapter 6 of the
URI RFC.

The Web has provided me with a steady paycheck since 1994, and
there’ve been a couple of extra paydays along the way. So, I
understand the Web, I like it, and I owe it.

What Do You Mean by “Web”?
If you crank the pedantry and purism up, the Web is about
URIs and REST.
If you crank the controversy down, the Web is about using HTTP
for your network traffic. And if you ask an actual non-geek human, the
Web means there are links and forms and a “Back” button.

I’m not going to argue in this space about REST or URIs or HTTP because I
don’t see anyone wanting to take the other side.
Basically, almost everything on a mobile device
needs to use the network, and almost everything does it via HTTP. This has
nothing to do with whether the client is a browser or a compiled native app.

So the discussion is really about whether, on one hand, you build
your mobile app with JavaScript and HTML and CSS, or on the other, you ship compiled
code that talks to a framework like CocoaTouch or Android or WinPhone7.

I’m pedantic enough to be a little irritated by the common “Web vs Native”
usage. They’re all Web apps, and this argument is really about client platforms; no more,
no less.

Digression: Games
We’ve all seen the snazzy demos of this game or that being made to run
in a bleeding-edge browser. But at this point in time, few
game developers are interested in anything other than C/C++.
There’s a small reason for this, and a large one. The small reason is that
they think they’re going to get better performance than they can with Dalvik
or the Objective-C runtime. I’m unconvinced, but they don’t care what I
think.

The big reason is that they want to use existing game engines like Unity and
Unreal which are in C-family languages, and that they want to share code between, for
example, iOS and Android, which is perfectly possible at that level.

Speaking of Sharing Code
Of course, sharing is the single best argument for building on the browser;
doing it once is in principle cheaper and faster than building
multiple native apps. The cost saving depends on exactly what you mean by
“multiple”. Right now it might mean as little as 2: Android and iOS. If one
or more of WinPhone7, WebOS, and RIM get real platform traction, the value of
“multiple” goes up and so does the economic argument for browser-based clients.

Low-grade Problems
There are some concrete barriers today to going with the browser for your mobile
apps. First, the native frameworks have APIs that the
browser lacks (at least in standardized form): telephony, Bluetooth, USB,
location services, photography, and so on.
Second, compiled code runs faster than JavaScript.

But these aren’t a big deal in the big picture. The browser tribe is
working hard to onboard and standardize those APIs, and they’ll get
there. JavaScript continues to get faster, and anyway many business apps just
aren’t performance-limited.

The Big Problem
It’s about tooling and culture. The Android and iOS frameworks are
built by elite, energized teams working with a laser focus on making it
real easy for developers to build snazzy native apps.

If you want a database-backed list, or a scrolling image panel, or an
alpha/translation animation, or a modal checkbox dialog, or a map with some
graphics drawn on top, there are recipes to follow and open-source code to
re-use. If you need to run a background service or react to something being
plugged into something else, same story. There are IDEs and debuggers and
profilers and screen designers and they’re free and they’re good and they have
user communities hundreds of thousands strong.

In the browser, there are ways to do most of these things, and some of them
may even be better than the native-SDK alternatives. But the story
in terms of tooling and recipe-ware and mobile orientation is
weaker.

Also, there’s a paradox-of-choice issue: Consider
EveryJS, which lists
21 different JavaScript toolkits, and I bet most of them are really good, and
I also bet there are lots more I’ve never heard of. Which are you going to
bet on? (At the moment, near as I can tell, almost everyone is using jQuery.)

Obviously, lots people of are working on browser client tech; but I don’t know
of any effort out there that’s close to the pedal-to-the-metal intensity and
focus of the native-framework teams.
It’s far from obvious that the browser is catching up.

So yeah, it’d be nice to just build everything once, but if you’re stuck
with multiple native-app engineering projects, you’ll be working
with really first-rate tools that are getting better fast.

Cross-platform?
There are tools out there like
PhoneGap and
Appcelerator which aim to
improve the trade-offs. The idea is that you can work mostly
with shared code and still have some native-app look and feel, and be
native in the sense that you appear in app stores.

This area is so fast-moving that I’m reluctant to say too much. The
problem these guys is trying to solve is really hard; much harder than it
seems on the face of it. On the other hand, the upsides are big; it’s an area
to watch.

Case Study
TripIt is the most important
not-from-Google app on my
phone. It’s a travel organizer; I
can’t say how well it compares to the competition because I’ve been using it
exclusively for over a year. Its best feature is that when you book travel,
you just forward the acknowledgment email to TripIt and it gets auto-added to
the app.

When you go to tripit.com in your Android device’s browser, you’re given
three choices: Download an app, use the mobile site, or visit the full
site.
So let’s have a look at the front page of the site in all three
presentations:

The mobile browser can’t squeeze the whole front page onto
the handset screen very well, but a little bit of double-tapping and
zooming does make it usable.

Let’s zero in on a single trip. Once again, full site, mobile site, and
native app:

On the mobile site and the app, you can zoom further in to a single leg of
the trip:

So, having seen all that... what do you think? Did TripIt really need to
invest both in a mobile site and a native app?

There’s absolutely nothing in this app that requires access to
the mobile-device hardware or to Android-specific APIs. In fact, someone
sufficiently skilled at browser-based development could probably come very
close indeed to replicating the look-and-feel of the native app.

Here’s another piece of evidence: On my phone, I use the app always, the
website never. Also, I’m a paying customer, and it was the slickness of the
native app that helped push me over the free-to-paid line.

What do you think?

Further Reading
You can bet that I’m not the only person thinking about this.

Why Mobile Apps Will Soon be Dead,
by Christopher Mims in technology review.

Why “Web vs. Native” Isn’t a Black-and-White Battle,
by Colin Gibbs in GigaOM.

Mobile Web vs Native App: Give It a Rest,
by Josh Clark in Global Moxie.

HTML5 Is An Oncoming Train, But Native App Development Is An Oncoming Rocket Ship,
by MG Siegler in TechCrunch.

How to do a Java -> Clojure rewrite

Flashes with compojure/ring

CAcert.org is a community driven, Certificate Authority that issues certificates to the public at large for free.

A Clojure library to display and validate HTML forms.

An Erlang web server MVC framework

Clojure websocket demo with Jetty 7