# Saturday, 05 April 2014

I was recently pointed to the article "10 Very Good Reason To Stop Using Javascript" It sure sounds like link bait to me, but I do think about some of the things so why not? Here's goes a reponse to each of their reasons

1. Javascript Hurts Your Mobile Visitors

This is quite true I suppose, I always have this nagging worry about the whole Single Page Application (SPA) website design which everyone seems to use to be cool. My worry is that a web browser's Javascript virtual machine isn't meant to be running for extended periods, and staying on the same page constantly manipulating elements would just drive it insane. A good example is of course.. the Facebook website, leave it open long enough and depending on your feed you should see your web browser start eating up a ton of resources.

But then again, some of this is just probably caused by bad code and design, so when done right, this is obviously not an issue. After all, if someone had to write 10,000 lines of Javascript to get a page to work, it might mean that he would need 10,000 lines of HTML to get a page to work without Javascript, so where would we be at then?

2. Javascript Hurts Your Robustness

This is true... but then again, this is true for any sort of developement platform if you use a third party library! If we only talk about it from the Javascript angle, the way I try to minimize the impact on my projects is that I prefer Javascript libraries that only have a single role such as to provide UI enhancements such as Bootstrap and avoid entire frameworks that might end up dictating the system design on the server side as well such as AngularJS

3. Javascript Hurts Your Security

The article mentions about security issues like XSS and XSRF, and yes these are legitimate issues. But again, it's a developer problem, like SQL Injection before it, it's a common issue that developers have to actively make sure they're doing their jobs properly to minimize security problems (The reason I didn't say ELIMINATE is that there's no such thing as perfect security... although most security consultants would of course tell you otherwise)

4. Javascript Hurts Your SEO

ABSOLUTELY true, ESPECIALLY true if you're implementing your site as a Single Page Application (SPA) Google has some guidelines on making your AJAX links indexable but that probably only works with Google. Surprisingly the solution I used which was to create an invisible link to a dummy non AJAX static page with listing of links worked pretty well, I later found out that this was an actual method which people have talked about called a snapshot.

5. Javascript Hurts Your Development Time

No shit, but then again it's the same as with any development language which a person is unfamiliar with. But while it's true that Javascript code can get VERY complicated and messy (ESPECIALLY true if you're using MVC libraries) Tools are getting better, developers are getting more experienced.

As for cross browser / cross platform compatibility and testing, my approach to it is that if the web application NEEDS to be pretty much powered by Javascript with no fallback possible, I'll inform the client that only HTML5 level browsers are supported, and that means IE < 8 is totally unsupported, IE < 10 will see some visual discrepancies, but major functions will work. You might argue that there are ways to get everything to work and look exactly the same but in that case you're just setting yourself up to be hit by this issue as well as the issue #2.

6. Javascript Hurts Your Testing Costs

Again, this is very true. From my experience this seems to be mainly caused by the fact that traditional testing systems are unable to test Javascript heavy sites because they are unable to execute the Javascript in the context of a webpage. So it gets very complicated and expensive to bring in the resources necessary to test the system.

7. Javascript Hurts Your Website Performance

Aaaa.. the TIMELESS battle between the developer and the client arguing that the page must finish loading before X seconds or MILLIONS of users will be lost!!! You don't need Javascript to cause this issue, but of course, again it's all up to the developer to do a proper job to deliver better performance. And it's up to the Project Manager to tell the client that their expectations of a page just APPEARING in the browser is not physically possible.

8. Javascript Hurts Your Software Investment

"Client-side technology is doomed to fail" Wow... that sounds exactly like how people use to argue that ThinPCs would become a thing and normal x86 desktops would fade into obscurity. Let's break down the original article's examples.

Java applets failed primarily because the additional cost of the runtime download made it a barrier to entry for normal users BEFORE the broadband age, although once we DID have the bandwidth Oracle didn't seem to be interested in paying much attention to the applet usage of Java anymore. It also didn't help Java's case that a HTML5 browser's capability has caught up to MOST usage scenarios for a Java applet.

During it's time Flash had a smaller runtime download and could deliver impressive multimedia capabilities and features when compared to Java, that's what made it the dominant plugin previously. There's a chicken and egg argument about the role Apple played in Flash's demise when they choose to chase the HTML5 standard instead of Flash, but without a doubt HTML5 once again had most of the important features which someone would use Flash for but WITHOUT the additional runtime download.

There's only one thing that Flash is currently still ahead compared to HTML5, and that is it's ability to manipulate and playback video files. Due in part to everyone still trying to figure out how to standardize video manipulation based on patented video codecs I believe.

The main risk for Javascript boils down to WHICH library or framework do you bank your future on? Because you don't want to back a library where the developers decide to abandon it after a few releases and stop patching bugs... But again, this is an issue that isn't exclusive to Javascript only.

9. Javascript Hurts Your Software Architecture

This is true, write Javascript long enough and you'll know that it's incredibly messy to get any sense of order once your application reaches any sort of scale. A lot of people are trying to solve this issue by coming out with new languages like Typescript and DartScript. But those feel more like band aids to me. I try to avoid hitting this issue by avoiding the SPA metaphor (Because this is the simplest reason to cause your application to scale) and I will never use any sort of Javascript library that exerts influence into the backend server design.

10. JavaScript Is Not Needed

Absolutely FALSE!!! While it is true that almost anything you can do with Javascript can be done on the server side (The author of the original article seems to be ignoring any sort of UX requirements and filing them under "new" and "cool") Proper used of JavaScript allows many performance gains and UX improvements.

The NEED for Javascript should never be questioned. The question is that can the developer be entrusted with the power of Javascript responsibly?

I like to mention that if there ever was a language worthy of the phrase "With great power comes great responsbility" It would be Javascript.

And that's it... damn.. this rant is longer than the original article, well, hope it helps to provide some insight to this topic!

Saturday, 05 April 2014 23:18:37 (Malay Peninsula Standard Time, UTC+08:00)  #    Comments [0]  | 
# Monday, 31 March 2014

The Acer W4 and other 8" Intel Atom "Baytrail" tablets are interesting little things. They're small, compact, yet they run on x86 processors. And the obvious thing which you'd want to do on an x86 is to play games on it! Playing games on a keyboardless device in the Modern UI is not an issue, but when it comes to games that run on the desktop such as via Steam or what not, here are a few tips to help you get the best gaming experience out of your device.

Gaming | Gear
Monday, 31 March 2014 11:01:31 (Malay Peninsula Standard Time, UTC+08:00)  #    Comments [0]  | 
# Thursday, 20 March 2014

After seeing all the Nerf guns lining the toy store shelves, you finally decide you want to buy some to play with your kids. But which one should you buy? Here're some tips to help you make the call.

Thursday, 20 March 2014 14:01:38 (Malay Peninsula Standard Time, UTC+08:00)  #    Comments [0]  | 

Got this about a month ago, after all this time using it I'll say that YES, it does make the phone feel a bit bulkier to grip but it's designed well enough to not get too much in your way. Also, the built in screen protector while it does impact screen sensitivity, you kinda get used to it, also the screen protector protects against any WATER sippage if your kid drools on the screen! Highly recommended if you need the protection and don't mind the bulk.

Thursday, 20 March 2014 13:57:01 (Malay Peninsula Standard Time, UTC+08:00)  #    Comments [0]  | 
# Thursday, 06 March 2014

There's a lot of buzz surrounding the whole NoSQL buzzword, and I've recently been able to give both Memcached and Redis a quick try and look over. And here are my initial findings follow some tests and poking around. Note that I'm by no means have very in depth experience of both these systems, I'm just recording my findings down so I can look back at it in the future to see if I still think of them the same way next time.

Memcached is the simpler one to explain, it's essentially an in memory store of key/value pairs. Which basically means it you're essentially storing values in the form of usersession.xyz="some session data" in it. This usually leads to questions about why one would need to use an external service to cache simple key/value pairs in memory when your platform might already have something similar (ie. the Cache collection in ASP.Net) but the nifty thing about Memcached is that you can configure it to be redundant and highly available spanning across multiple servers among other tricks.

Redis like Memcached is also about to store key/value pairs as well, but it is also able to store structured data, lists and weighted lists. Which you can then manipulate and perform some simple operations on them like sorting, joining, calculating. Conceptually I'm more inclined to just call Redis a simple In Memory Database, but I think that's complicating it a bit much! But not only is Redis an In Memory Database, you can configure it to persists it's memory contents to disk ensuring that data can be preserved between server restarts and applications crashes. But wouldn't that make it behave just like a traditional database then, not quite I'd say.

Both Memcached and Redis excel in the fact that retrieval and storage of data is LIGHTNING fast compared to a traditional database, and why wouldn't they be considering that all the data is held in memory instead of on disk. So what kind of problem would arise from using them? Why, memory usage of course! Since the 2 systems will just keep writing to memory, if you don't keep an eye on them they WILL take everything if you just keep stuffing them full of data.

I'll say that it's easier to handle Memcached's memory usage, since it's main role is to cache data. If it reaches the memory limit, it'll just drop older values to make way for any new values. After all the whole idea of a cache is that while it exists to speed up data access, it can easily be discarded and rebuilt from the original source.

But with Redis it's a different, as mentioned Redis is cooler than Memcache in the sense that you can perform data aggregation on it, in fact you might be tempted to just run your website ENTIRELY off Redis, but then there are a few caveats about it. The first being the fact that Redis doesn't support the concept of ACID very well, so you can't use it for anything where data atomicity is a must. The other more important caveat is that Redis is an In Memory database, the WHOLE database needs to be in memory at the same time so if you want to speed up the look up of that 6GB customer DB file with Redis? Sure you can do that, but you're gonna have to dedicate 6GB of memory to hosting that database and that's not something you might be able to do.

UPDATE 7th March 2014 : Just figured out that in Redis you can ALSO set it so that when it approaches a memory limit, it can auto discard elements and thus it can also work like a cached store as well instead of having to define everything to expire explicitly.

The way I look at it is that Redis is great for caching datasets which require constantly manipulation but you don't want to burden the database with the queries. And it'll work great as long as you can give it the memory to work with. Such as... an item listing database which you want to allow users to sort according to different criterias.

And that was my quick look at Memcached and Redis, interesting stuff and I can't wait to work with them some more... ok, not so much on Memcached probably, it's features are a bit too specialized. :P

Thursday, 06 March 2014 17:24:48 (Malay Peninsula Standard Time, UTC+08:00)  #    Comments [0]  |