Currency.io, a html5 currency converter - open sourced to learn from | Hacker News Reader

Currency.io, a html5 currency converter - open sourced to learn from

currency.io

86 pointsbenschwarz33 comments

It's not an HTML5 currency converter but an iPhone/iPod Touch currency converter. It doesn't work on iPad (and Android, and desktop browser, etc.). What are we supposed to learn from this? Bad practices? Arrogance?

I'm pretty sure its clear what 'platforms' its built for on the site… but, some of the takeaway learnings are:

• HTML5 Application cache • localStorage • Developing a 'installable' web app for iOS • Yahoo YQL • Building a sintra app

>I'm pretty sure its clear what 'platforms' its built for on the site

I guess then you should change the HN post title.

Ok, wait a minute. I always thought people preferred HTML5 over <insert platform specific API here> is that well, it's platform independent.

So I opened this app on my android phone... and nothing happened. Basically it said 'this (web) app is available for iOS only'.

Then what is the use of 'open web standards'? Am I missing something? Is this using a feature that android phones don't support yet?

It was built as a tech demo and will work on iOS, Android and WebOS… but we built it primarily for iOS as a bit of an experiment to try to make something that "felt native".

¬ Of course you can fork it and mess around with it to make the experience better for android now too.

Why the iOS jail? I can think of plenty of cases where it'd be useful to have this, even on a desktop...

I know it may be 'designed' for iOS and mobile screen formats, but it seems to me a seriously bad decision not to have a 'show it to me anyway' button, along with a disclaimer that it (might) be broken on $platform...

And saying 'fork it' for an issue this trivial is not a great way to promote yourselves.

Well… its built as a demo, and we learnt a lot from it.

I'm sure we could add a button to show it on devices that wouldn't experience what it was 'designed' for… but really, we open sourced it to share some of the things we learnt along the way—not pour time into testing over various fragmented devices.

I understand your sentiment (I'm not the one voting you down) and I hope you do understand where we are coming from. The whole idea of 'using HTML5 for an app' is based on the notion that 'that way all HTML5 supporting devices should be able to use it'. Which is the one thing you missed.

I think the idea of the app is awesome, and it's good that we can read the source. It's just a bummer that I can't use it in its current state.

Yeah I understand your angle here… for us it was about building a comprehensive application, and given the time (and budget) of a real world project–we'd have made sure it was squeaky clean on Android too.

"not pour time into testing over various fragmented devices."

If this is what people would have to do, why would anyone do that over native?

Technically it should work on Android (I believe we were testing against v2.2). What version are you running?

I think the main blocker with opening it up for desktop is having to design a more appropriate layout. Not impossible, just time-consuming. And as Ben says, it is intended as a tech demo.

It works for me on Android 2.2 on my HTC Desire (nicely, too!), but doesn't even pretend to work on any browser on my laptop.

It should work on android? Did you test that? If I visit the webpage there is nothing there except the message that this is a tech demo and that I should visit it on an iOS device. Pressing the Menu button doesn't reveal any kind of 'add to home' functionality. (I'm on Android 2.3.4)

The same counts for visiting the website with any other browser I have.

I can view a demo, and it looks like a nice app. But I hope you understand that 'apps' like this go against the entire idea that websites are available to anyone, on any device, which is the one thing that makes web-apps so awesome.

Yeah… it should work on android (we did some loose testing, but not on an actual device), as you'll note some other people on android have had no issues. If you'd like to take the time to give some details about your device then I'd be happy to try give it a run in the simulator with those parameters. https://github.com/benschwarz/currency.io/issues

> try to make something that "felt native".

I beg you to reconsider. I think this is the current problem with mobile web apps today; too many are trying to feel native. Instead try to make it feel smooth and responsive, as a web app.

Generally, don't be ashamed of being a web app. Embrace the web's strengths; users will appreciate it.

> _I think this is the current problem with mobile web apps today; too many are trying to feel native. Instead try to make it feel smooth and responsive, as a web app._

I think this is exactly what OP has done. It doesn't feel "native" to iOS to me, but it does feel like a well-made little web app. I don't have an Android device to test it on, but it does seem like it would fit in just fine on one.

Looking at the CSS, I see you're styling the id tags. I'm not a designer, but my experience is that you should only style your ids sparingly and use classes for most stuff.

Also you have a bit of code to recreate some jquery functionality. Maybe for your purpose it's unnecessary to load all of jquery, but consider that if you use Google's CDN, there's a strong chance the user already has jquery cached. Look at the HTML5 Boilerplate for a snippet on how to use Google CDN and fallback to the hosted version. Again, might not be necessary for your limited use case.

There are many schools of thought around using IDs vs Classes, some of the old was that "ID's are faster to parse", but really, its an old habit for many to use IDs. I think the answer is always "it depends", but I'm somewhat using classes and aria roles over IDs now anyway.

The "jquery functionality" you speak of is a query engine, but web kit based browsers have "querySelectorAll", which is native C code. jquery uses it (where available)… but being that we were trying to build something that downloaded very quickly on spotty 3g connections, we chose to write a couple of utility functions. (The total byte count for application.min.js is 3186).

In Firefox I see

- a link to a video

- a link to the source

Is the title misleading? "A html5 based iOS application to convert currencies" maybe?

Its a gorgeous app and works well. The touch events feel a little laggy though (samsung galaxy s, android 2.3.4 / dolphin hd).

Also I would love to try it on the desktop, this would make a great widget. Any reason not to allow it to run on desktop browsers?

While people argue over what things are and are not supported, I'm really happy you built this. I just got back from a 3 week holiday and it was disappointing that a lot of App Store apps require an active internet connection for EVERY calculation. Who can afford roaming internet when you're travelling abroad?

Nice app, it would be nice to see the current exchange rate that it's using on the app to calculate

Hate that I have to save it to my iphone desktop in order to use this ; not being able to try it out on my desktop was annoying as well, but I think enough people already expressed that sentiment. Other than that the app is ok, just not sure I'd necessarily want to spend much time learning from this source since it esssentially skips over what makes HTML5 cool in the first place.

Really impressed with how much this feels like a native app! I've always maintained that web apps are the way forward and native apps will die.

Looking forward to checking out the code on GitHub and playing around with it.

On the video you have an Indian Rupee as one of the options but in the actual webapp, it's not there. Instead I have South Korean Won. Is it because I have the korean keyboard installed?

Hey ben, nice demo, regardless of it working or not on other platforms.

I'd be interested in your feedback on why you used binary images and avoided jQuery. I know the code makes notes on these, but were you actually already experiencing loading issues without using those techniques?

In other words, was it to practice using the techniques or were you already hitting visible loading delays each time you started the app?

Also, you mention using ems for layout to handle resizing on the github info page, I've not heard of this technique, any chance you have a link explaining it?

Yea, we were hitting visible load issues on both the images and jQuery. Because the goal was to build something that felt like an iOS app, the longer the load screen was up, the less it felt like a real app.

The em technique is discussed in some detail here: http://clagnut.com/blog/348/

In practice what it also allows us to do is to set a font-size of 150% on the body and everything scales up proportionately.

Just curious, what software did you use to make the video? Thanks

I think we used iShowU (available in the mac app store) and the iOS simulator that comes with the iPhone SDK/XCode.

Perfect domain name!

This is great. Thank you.

Why not just name it a "JavaScript currency converter"? HTML5 is such a buzzword to make it seem new or innovative.

Maybe because offline apps and localStorage started as a part of specification which later became HTML5?

Reply on news.ycombinator.com