Mobile web and sandboxing

I've had a few discussions in this blog about mobile web vs. native in app development.
One of the major problems with creating a mobile web app was performance. When an app needs to display a large list of items, rendering a huge DOM tree with lots of layers causes app performance degradation, resulting in poor user experience.
Well - The guys at sencha came up with a neat idea - 'Sandboxing', which means fragmenting your content items into small iframes.
The basic motivation behind this is that it's easier for the browser to render lots of smaller DOM frames than rendering one huge DOM tree. With multi core processors (And supporting OSs like iOS5/ Android 4 and above), this approach becomes even more effective.

You can read more about it here.

[Thanks Danny Livshits for the link]

Don't fall in love with frameworks

The javascript world is on fire!
You've got tens of frameworks, all made to enable making javascript and web development easy.
angular, backbone, less, _, GWT, wicket, the old and established extjs, prototype, yui, and jquery (To name a few) have become common names among developers.

Some frameworks are meant to make your life easier with dom traversing and manipulation and encapsulate javascript features (jQuery, prototype), some add UI functionality (extjs, yui), while others offer full application frameworks.

However, these frameworks come with a price.

Once you bind your application to a framework, it's very hard to get rid of it. It's very hard to change parts of your application, once your web application is fitted with the paradigm of a framework.
Binding UI to model is another problem - Some of these frameworks bind data to UI components.

While this makes your initial development easy, once your application surpasses some volume and features, programmers tend to break this model (Something which is quite easy with javascript).

Binding is also very hard to debug - Sometimes you'll get an impossible to understand and follow call stack, especially with frameworks which bind model to UI components via events.

Another reason is performance: If all you want is a 3 page application which loads json objects, parses them and presents them on screen, using a full fledged MVP framework is a little bit of an overhead.

... And now, for the worst part.
You've written a nice widget/ control/ viewer/ whatever.
Now someone wants that object in his legacy system.
It's very hard to integrate binded code.
You tell him you can't.
He asks you why did you use the framework, if your code isn't recyclable.
You say 'it is, but you need to rewrite your whole client'.
CTO approaches you with angry eyes.

The rest - You know.

So next time you consider using a flashy, 'easy' to use framework, please ask yourself these questions:
- Will you need to reuse this code somewhere else?
- How much overhead will the framework add? Is it really necessary?
- How intrusive is that framework, in case you want to replace it?
- How much time would it take your team to develop the features you need from the framework? Don't add a full fledged framework for the sake of a neat button!
- How cryptic is the code? (Angular.js is a good example - Great framework, but you need to go all the way with it in order for you to enjoy its advantages.)
- How easy is it to debug? I know some of them are really, really hard.
And, finally:
In 6 months from now, will it bring value to your system, or will you need a month of knowledge transfer just to get someone new to write features into your app.

Be responsible - Use new technology that brings value, not heartbreak...

Back from NYC... Chart talk.

I've just finished some work, requiring charts. After some research, I found that the only free 'complete' tool for html charts is the Google Charts API. A neat Javascript library, which enables you to create charts - Basically you create a data table structure, add some customization options, and the API generates the chart as SVG markup, and 'plants' it as an iframe inside the designated DOM element.

You can also hook some event handling, there are value tips, and lots of customization options.

Not to be confused with the Google Charts Image API, which is a little different:

The Chart Image API is generated via a GET/ POST URL request from Google servers, and is an image. It has more formatting options and better graphics, but is not interactive, and transfers your data via Google servers, something I am not too happy to do.

Though not everything is perfect with the Charts API, and there are few missing features (The ability to have 'zones' in a line graph, the ability to have more than one line in a combo chart etc.), it is good enough for most uses, and actually goes in line with the simpler look web applications are taking today.

So the next time you consider spending money on interactive charts, consider these tools. They will look better on your iPad, that I promise.

Tip: The JSP surgery

So, you've invested a whole lotta love and money in your java based web server.
And it's fine. Really.
But now it's time for an overhaul. The UI is dated, and you want to bring some fireworks back.
The problem - Your team has changed, it's been a while, and all your team has done so far were some bug fixes and some features. And the web layer is written in good ol' jsp - No one really knows how to rewrite it. Recently I've encountered a similar project - All the team left, the design was terrible, but I couldn't make changes to the back-end, only the jsp files.

What do you do?
My suggestion is to divide and conquer!

Here's a quick recipe on how to transform your server script code into a web service.

First off, see which data you need the server to really generate. Usually, it would be user details, a data table, plus some attributes.
After that, have your jsp code generate JSONs instead of html or javascript code.
This shouldn't be that hard.
Analyze all your code, and prepare new jsp files for each type of data needed. Use the current jsp function calls - There's no need to rewrite the java layer: All these files should do is write a JSON response. You can use Arrays.toString(), or a JSONArray, or you can generate the JSON explicitly from object attributes.


Then you can begin writing your client from scratch, and use these jsp as a web service. You may later write some Java servlets to replace them, or (Better off) use jax-rs to completely get rid of the jsp.
Step by step, you'll see your web application transform into something a lot more comfortable to use and maintain. A real web service, without rewriting your back-end. And when you do get the time to update your server, you'll be able to do it with only minor client modifications.

Have a good development week, and stay tuned for more!
y.

Three nice tips for web developers.

Actually, two basic dev tips and one neat resource site.

First tip is regarding dynamic HTML. We've been encountering some rendering performance problems with huge tables, and after some investigation, here are some pointers:

• Do not use tables. They're bad for you, especially large ones, and nested tables. By the way, YUI creates lots of inner tables. You can read some more with this link, top answer has some great detailed arguments for you. I know it's a corny advice, but there are lots of frameworks out there that use tables, even gwt.
• Do not create each dom element separately - If you need to create a very large table/ chunk of html, it's better to create a huge html string and then insert it into dom for processing, rather than use the dom to create each element, and the append them. Think of it as using 1000 'native' calls from a VM rather than 1 long call. The overhead for each dom element is huge.
• Establish a maximum size for a list and browse through results. Google does that with search results, why don't you? You can cache results in javascript, or keep an index to the query and go back to the server to fetch the next n entries, but displaying one thousand items for a user is highly ineffective. 

Second tip is rather basic - Regarding server/ client processing and separation. As we're moving towards cpu consumption related billing rather than permanent hosting, we need to rethink what we do on the server and on the client side. The main principal would be having the server perform validation and data (model), and do the rest in the client:

• Your server code should not create html. It should either create status/ session/ json, but not html. This is just a waste of server cpu. It speeds up server response, and when written well, makes client experience better. It scales a whole lot better.
• You must think of your client and server modules as replaceable. This means that if you're writing a server, imagine that you need to write two completely different (Say html and iOS) clients for it.
• If you're afraid that competitors may reverse engineer your client html/ js/ css code, you can always minimize it, or get an obfuscator.

Final tip is this site. Microsoft is putting a lot of effort these days - It's great to see them as the underdog. You'll find Azure php sdk, nice html5 references, and lots of useful resources. Check it out. I'm considering Azure for a project I'm working on, the php sdk seems quite cool.

Have a great week!
y.

Adobe is going html5... Update on flex/html showdown

In perfect timing with my previous post, Adobe has pre-released Edge, which is probably the base for their next-gen authoring tool, which creates animations and interactions in html5 standards.

So after Microsoft put Silverlight to rest, looks like Adobe flash is on its way...

FLEX vs HTML5... The showdown.

I've been asked this question more than a few times lately, so I've decided to write some notes comparing between the two platforms.
I am currently leaving out other competing environments like gwt (not good enough), silverlight (why would you?) and javafx (not nearly there).
But first off - Before comparing between the platforms, you should be focused on your needs and target devices:
Does your application require heavy graphics processing? Animations?
Is it supposed to run over smartphones and tablet devices? Netbooks? Power desktops?
Are you able to deploy your application to app stores? Do you have the budget to target several platforms?
What are your performance goals?
Perform that analysis, and you will be able to compare between the two, and find the platform that suites your needs.

So, without further delay, let's begin:

Ease of development:
Advantage flex. Though html is very easy to learn, deploy and even debug, flex can be faster, especially with form based apps. flex has a nice WYSIWYG editor, with fast link to simple code. flex also has great built in graphs and charts, to which data could be easily linked. html is gaining ground, though, with new and better development environments in the pipeline.

Performance:
Advantage html. html is 'native' to browsers, while flex runs inside a browser, over a virtual machine. flex has several garbage collection problems (To which you need to go deeper into actionscript studying), is very cpu and memory greedy, and even takes more time to initialize and load.
If you need to run over tablets and netbooks, html should be the way.
If you do go with flex, consider this: Internet Explorer 8 and up has the best flash performance (According to several benchmarks I've performed). Chrome and firefox are slower, and android web browser is even slower then that.


Deployment:
Advantage html. This one is easy. flash needs a plugin. flash doesn't work over iOS. Flash builder 4.5 is supposed to have an iOS 'workaround' - running flex apps over iOS air runtime environment. IE10 is supposed to be closer to webkit browsers that to IE9, which will bring less browser compatibility issues.

Richness and graphics:
Advantage flex. Though html5 and css3 bring canvas, svg, effects and some other great stuff, flex and flash are still better. html is gaining ground here, though - there are lots of neat canvas javascript libraries out there.


Interop:
Advantage html. Need to open an office document via your app? A java applet? Can't do that on flex.

Documentation and development environments:
For flash builder, you will need a license. Knowledge base is quite large, but not nearly as large as html. To develop html, all you need is a notepad and a web browser.

To summarize:
In my opinion, html is the way to go. Faster, better performance in most cases, cheaper development and setup. Runs over every device, and besides - Everybody wants to develop better and faster browsers, rather than faster flash players...
So on the overall, for now, html wins by points.
But as the time goes by, html is getting better and better. So unless you're doing something that requires the flash platform or requires flash graphics, go with html.