The Blackberry Z10, So much right, so much wrong…

I’ve been using a blackberry Z10 as my main phone for about 2 weeks now, having used the Dev Alpha B for a few months before that, and I’ve pretty much made up my mind about it. My previous phone was a Galaxy Nexus, so that’s what I’ll be comparing it to mostly.

Hardware:

The good:

  • The button-less face is excellent. I’ve already forgotten how to unlock other phones.
  • Nice high res screen.
  • Decent performance (only ever really noticeable when playing 3D games, which run well).
  • Decent battery life, I get a day’s heavy use out of it without issue.
  • The back cover is nice and grippy, you can stick it on a dash and it won’t slide around (if you drive carefully).
  • The camera is excellent.

The bad:

  • The screen is kinda small.. Not iPhone small, that would be ridiculous, but it’s smaller than my GNex, even though the phone its self isn’t any smaller.
  • Looks like an iPhone. While this will help BB steal iPhone users, it makes me slightly embarrassed to be seen with it. I don’t see how they could not get sued by Apple, it actually is very similar, unlike previous phones that were a ‘copy’. It’s quite boring to look at.
  • The volume buttons feel cheap, and I don’t really know what the middle button is for.
  • The plugs are on the side. This is sometimes a good thing, but mostly it looks weird.
  • It has pulg*s*. It doesn’t need a HDMI out, the phone isn’t being pushed as a media device, so why dedicate an ugly port to it?
  • The ports are positioned weirdly, mostly on the body of the phone, but partly into the back cover.

Software:

the good:

  • The browser. It is the best. Ever. Literally nothing else is as good. Chome for desktop? Excellent, still not as good as the BB browser. I’m not kidding, it is better than Chrome, for both viewing and developing web applications.
  • Cascades (or whatever) is awesome. Once you swipe things around on this phone, you can’t help but accidentally swipe other phones, usually resulting in Google now. Something came in to the phone? Slide up, hold, slide to the side if you want a preview of the notification.
  • App-specific notifications. OMG they are awesome. Something happened in an app? Red icon. Something happened in an app in a folder? Red icon. Give the engineer who came up with this a raise, I love it.
  • the Hub is great, no matter what happened, it can always be found in the hub.
  • The app switcher is really fluid for switching between 2 apps.
  • The word flicking keyboard is a good idea.

the bad:

  • The apps. There aren’t enough. This should seem like an obvious, unavoidable issue, as with any new phone, but this phone should be an exception. Blackberry does not leverage their browser enough. Why isn’t there a way to turn any website into a chrome-less app?
  • Maps. They suck. Practically unusable. The app lags all the time. Why the hell would they not just use Google maps?
  • The phone has crashed probably 30 times since I’ve had it. At least once a day, but I have a feeling its probably more often than I realise.
  • Apps cannot run in the background. This is a big issue as it stops apps like llama (for android) working, which is a big issue because the phone is never in the right profile.
  • The phone is never in the right profile (like I just said). It is constantly going off when you don’t want it to, and never ringing when you need it to. This is because I don’t manually change the profile, because I am a human and any ‘smart’ phone should do this for me.
  • The keyboard needs the long-press-for-symbols feature that android has. Things like question marks shouldn’t be difficult to input.
  • It has a shit lock-screen. The only option is a password. Patterns people!

Development:

the good:

  • The browser, as mentioned, is amazing. The development experience is not just bearable, but actually BETTER than Chrome for desktop! The profile tab has better info than Chrome. Apps run fast, every feature you could want is available.
  • Native development: who cares, this is 2013.

the bad:

  • Java. Seriously? you need Java to create a web-app for this phone? Why? BB really needs to improve the tooling around turning web-apps into BB apps.

In summary, I really like some of the ideas that went into this phone, but I don’t think I can live with it. The few apps it does have are either crippled by the lack of OS support, or are just not very good. An example: Google talk lets you have only 1 account, and it notifies you of messages, even when you are using another device to converse with your contact. There is no Google latitude.

I realise that some will say “Well just make the missing apps yourself!” which is true, I could, and probably should do this, but I just don’t have the time.

Should you buy it?

If you are a previous BB user you will probably love it.

If you are a previous iPhone user you will probably hate it for the wrong reasons

If you are a previous Android user you will probably love some of the features, then get annoyed with the lack of applications.

Personally, I’m torn, If i go back to android, I will miss some of the amazingly good features like swipe to  unlock, swipe to notifications, and swipe to do pretty much anything. I will miss the excellent browser. That said the maps, lack of apps, Google talk, and frequent crashes are really getting to me..

Basically…. I lied; I’m not sure yet.

A BB/Android blend would be the perfect phone.

Advertisements

Deploying a Web app in 14 days, No HTML.

Recently, at Sidelab, we developed and deployed signforms.com, an application for signing documents online, in 14 days. The application runs on a node.js back-end, using amazon web services. One interesting thing about the application is that it uses effectively no HTML.

There are a few static html files for the lander site, but once logged in, there is only one .html file. Other than script tags to load the application for the very first time, the file looks like this:

</head>
<body>
</body>
</html>

After that, no HTML is ever sent.

Don’t believe me? Sign up (its free currently), log in, then view source. You will see nothing but JSON.

Signforms uses no html

A typical page in SignForms.com

WAT!?

The front end of SignForms is build using an opensource framework called Gaffa. Once the application has been loaded, all navigation is achieved via requests for JSON resources.

Oh, so it’s client-side templating.

No, there are no templates, ever. When we work on SignForms, we never write HTML, or HAML, or any kind of ML. We write JavaScript ‘pages’ that are made up of ‘view items’ such as containers, textboxes, buttons etc. For cache-ability we serialize these pages to JSON for the application to consume.

In your browser, Gaffa takes the serialized page, inflates it into objects, then generates the DOM required to display the page, and adds all other functionality such as event handlers, page load, and autosave behaviours that are required.

Why?

I’m not a fan of HTML, it’s not something humans should write. One thing that people usually seem to forget is that HTML is a sibling to XML. The majority of people would prefer not to write XML, but have no issues writing HTML. This seems strange to me. The other thing people seem to forget is that HTML is a serialization format for DOM, it is verbose and inflexible.

One commonly seen flow of data for a web application is as follows:

Developer:

  • Write ‘Views’ in HTML
  • Add magic strings to tell the server where to put more strings

Server

  • Scan massive string, stringify data and concatenate the extra strings to the original string
  • Send massive string across the wire
  • Don’t cache it because it will change next time.

Client

  • Parse massive string
  • Correct any invalid HTML, take a best guess as to what it was supposed to be
  • Convert strings into DOM
  • Render the DOM

The way Gaffa handles navigation is different:

Developer:

  • Write code
  • File watcher auto-serializes to JSON

Server:

  • Serve JSON Page, cache for next time.
  • Serve DATA.

Client:

  • Parse JSON into ‘viewItems’.
  • Apply Data to ‘viewItems’.
  • render DOM (Or Canvas, or webGL, or google map markers, or any other logical view).

There are a few big advantages:

  • Only one HTML page is ever sent, once, and it’s tiny (2KB uncompressed)
  • Developers write code, not an XML derivative.
  • Application pages are cached indefinitely, and are tiny (17 KB uncompressed and unminified for a feature rich page)
  • The server only serves data, reducing load.
  • Page-weight is microscopic. (<0.5 MB per page for everything, including all images, css, and data)
  • Pages render stupid-fast (~1s for a complicated, data-bound page).

Gaffa achieves this by creating a declarative programming abstraction for the UI. If you want to display a textbox, and bind it’s value to the model, you would create a textbox viewItem:

var myTextbox = new textbox();

myTextbox.value.binding = '[myValue]';

Other views can bind to the same value in the model:

var myLabel = new label();
myLabel.text.binding = '[myValue]';

And the data can be manipulated before displaying it:

myLabel.text.binding = '(join " " "hello person, your value is" [myValue] "which is" [myValue].length "characters long")';

Then you add the viewItems to gaffa:

gaffa.views.add([myTextbox, myLabel]);

And you’re done.

Because viewItems are rendered as DOM, you can use CSS to style them as you normally would, and end up with a fast, feature rich web application in a very short period of time.

As to be expected from my previous post, this application forgoes the usual “Don’t think, include” librarys such as jQuery, bootstrap, etc, and instead uses small components that do exactly the job required.

A few libraries/technologies used:

JS:

CSS:

The DOM isn’t slow, you are.

Edited post-HN: Wow, big response! WARNING: May contain traces of opinion, and naughty words like ‘shit’ and ‘internet explorer’.

This blog post was written in 2013, and many things have progressed. The predictions made have generally come true.

TL;DR:

  • Use jQuery for what it is meant for, not everything.
  • If you do stupid shit with the DOM, it will perform poorly.
  • If your web-app is slow, it’s because of your code, not the DOM.

Whenever the native versus web argument arises, the biggest issue people usually have with web is performance. They quote figures like ‘60fps‘ and ‘scroll speed’, and, back when browsers were just getting good, i would say “OK, there’s work to be done, but they will get there”, which was met with anything from “Yeah maybe” to “No it will never happen!”.

ORLY?

Really? You don’t think it can be as fast? You think that your proficiency as a developer outstrips the devs working under the hood of chrome? firefox? Interne..wait yeah you’re probably better than IE devs… But for decent browsers, it is a ridiculous assumption that your average iOS or Android developer is going to be able to custom implement a function that a Chrome or Firefox developer provides to you via an API. Not to mention the fact that these abstractions are constantly being tweaked and reviewed by thousands of developers  every day.

But really, this point is redundant anyway, because when you get down to it, even C is an abstraction on assembly, and if you are an Android developer, you’re coding against Dalvik… which is just as much of an abstraction as JavaScript is anyway! Abstraction is more likely to increase speed, because someone smarter than you has written the bit that needs to be fast.

But again, this isn’t the topic of the post.

People often throw around the statement “The DOM is slow”. This is a completely false statement. Utterly stupid. Look: http://jsfiddle.net/YNxEK/. Ten THOUSAND divs in about 200 milliseconds. For comparison, there are about 3000 elements on a Facebook wall, and you could, using JavaScript, render the whole thing in about 100 milliseconds. In a recent project, we needed a list of groups of items that would filter based on a users input. There were about 140 items, and it had to be fast on a phone. Currently, the implementation is as follows:

On filter change:

  1. Delete everything.
  2. Render everything from scratch.

And it has absolutely no perceivable lag what so ever on a mobile phone. None. This is pretty much the worst implementation possible, but it was all that was needed because it was easily fast enough. Why then, do people say that the DOM is slow?

I blame jQuery.

These days, when hiring for a front end developer position, there is a very simple way to determine how good a candidate is. “What are your thoughts on jQuery?”. This simple question will cull about 80% of applicants off the bat. Some cull-able answers (which I have actually seen):

  • “I love JavaScript”. – Help them find the door, they will probably struggle on their own.
  • “It’s a really helpful framework” – A victim of group ignorance.
  • “It’s good but not as fast as HTML5” – Haha… get out.

I’m dead serious when I say these are all real answers from real people.

Yes, jQuery is the compatibility tool of choice these days, and for good reason; it solves the tedious problems it aims to solve in a really easy way. The problem is, most, and I do mean, the majority of ‘web developers’ think it is the only way to work with the DOM. It isn’t even that jQuery is slow; for what it does, it is quite fast. The issue is that a huge number of developers use it to do quite literally everything.

Actually, I blame developers…

This whole ‘DOM is slow’ is really just “I’m too stupid to know that what I’m doing is stupid”, and practically no one is immune. I once worked for a large ‘software’ company that came to me one day with a laggy screen in a ‘web app’ and said “fix this”. The bespoke JavaScript for this one screen was around 400 lines long, and had nearly 500 jQuery selections in it. Worse, many selections were being made within a loop, for no apparent reason! I ended up being able to delete about 90% of the selectors, by just assigning the selection to a variable, which resulted in a 1000% performance increase! Whenever you select an element (or elements) with jQuery, you’re instantiating a very feature-rich wrapper.

If all you are doing is making HTML elements, DO NOT USE JQUERY. About the worst possible way to create HTML is like this:

$(‘<div class=”imAMoron”><span>derp</span></span>’);

Not only will this be insanely slow in comparison to using the DOM method (document.createElement), it also leaves your code looking like a steaming pile of shit. If you need to make a lot of DOM in JavaScript, use a tool like laconic, or crel. And I do recommend creating lots of DOM in JavaScript, it is definitely faster than requesting the same structure from a server, then letting the browser parse the HTML to DOM, and then selecting the elements back out of the DOM to manipulate them.

What now?

First: ignore pretty much anything Facebook has to say about DOM performance. They really have no idea what they are talking about. Sencha was able to make a version of the Facebook mobile app with their framework, and it was FASTER than the official, native app, and Sencha isn’t even particularly fast.

Second: Stop using DOM libraries out of habit! If your target browser is IE8 or above, jQuery hardly provides any features that aren’t shipped on the host object anyway. document.querySelectorAll will pretty much do everything you need. jQuery is a tool, not a framework. Use it as such.

Third: Use document fragments. If you are changing the state of the UI in a loop, don’t change it while that DOM is in the document, because every change you make will cause a re-draw or re-flow.

Fourth: USE THE GODDAMN PROFILER! In almost every case, the bottleneck will end up being your code, not the DOM.