Javascript Toolkits and Frameworks

By SuperUser Account on 12/14/2013

Today was choose a Javascript toolkit or framework day.  It took days for me to get this far after setting up PhoneGap to build on my laptop with the Android SDK, push up the samePhoneGap app to build it for iOS on the PhoneGap build server, and then figure out effective ways to debug PhoneGap apps, but I’m still not home yet.  I began the day by comparing Javascript tool kits and I found myself thrown back in time to days I wrote C, C++ and Java.  I gave those languages up in favor of Visual Basic 3.0 and then .NET because of all the time I lost with toolkit and framework dilemmas using those languages.  Oh, and the confusing syntax, memory leaks, etc. etc.  Now I’m back there with several of those problems again with Javascript.  I read and read and read and the more I read the more I found to compare.  I think there’s two camps of programmers, the ones that think this good and ones that don’t.  One group thinks that these vast choices represent power and flexibility.  I agree with that.  However, there are others that are facing deadlines and doing more in their lives than just geeking out on code.  They feel it is better to be provided a single set of tools, although a big set, that are tested and designed to work together.  I also agree with that.  One of the things that is killing us is spinning our wheels making comparisons, learning options etc.  On the other hand it is also driving technology forward faster.  So what does this have to do with the decision as to which Javascript tookits and frameworks to use?  Well, that leads to what I learned today.  There is difference between a “toolkit” and “framework”.  I’m more of a framework guy, coming from a .NET background that makes sense.  A framework could be called a very large toolkit.  Frameworks are jacks-of-all-trades, toolkits are specialists.   I like frameworks because I’m lazy.  I want to learn one basic thing and have tons of tools included with it that are all designed to work together on top of the core.  Toolkit guys want to go get the latest fad technology of the week from here, and there, and over there and mash it together.  Consequently, toolkit guys are not lazy.  They want to invest in a never ending cycle of discovery and learning for the sake of raising the bar constantly.  One of the things I’ve learned is toolkits work best for applications that are small in scope while frameworks work better for bigger applications.  Still, today the frameworks are loosing ground.   There are so many devices, web services, etc. that even the largest frameworks like .NET are loosing their relevance.  Ultimately, it is getting harder to be a lazy programmer.  You have to really enjoy all this reading and comparing to be a professional programmer.  You have to like reading technical blogs after work and waking up early Saturday and Sunday to geek out on a new toolkit or framework.  If you don’t, you’re not making the right decisions when it comes time to start a new project.  So back to what this blog post is about, I chose to go with Dojo.  Yes, I tried jQuery, knockout and studied AngularJS, Bootstrap and several others.  The thing I learned is Dojo has been around a long time and is a framework, not a toolkit like the others.    Another thing that swayed my decision is ESRI.  I’ve been developing GIS applications for ESRI for over 13 years and the ESRI Javascript API is based upon Dojo.  Dojo provides a lot of sample apps, widgets, a mobile version etc.  I can use Dojo with PhoneGap.  So, that’s my plan.  I’ll let you know how it turns out.

 

This entry was posted in Uncategorized on December 13, 2013.

Ripple, a step forward in debugging and testing

Leave a reply

While researching and comparing javascript frameworks I found Ripple.   If you are developing web-based mobile applications, including PhoneGap apps, you should probably install the Ripple Chrome Extension.  It emulates mobile devices in Chrome and does a pretty good job of it.  This saves a ton of time since you can test your mobile web apps in the browser without pushing the app to your device every time you build and test (a process that takes three minutes for me on my wimpy laptop).  The version I installed says it is “beta” and was posted up around March 2013. Ripple is an Apache project here.  I took a look at the git repository and could see there were commits about a month ago back in November, so that means there is someone working on it, sometimes…  I hope they release it again soon because it really cool, but falls short when it comes to device emulation for PhoneGap 3+.  For example, when running my hot-rodded Hello World PhoneGap app in Ripple I get a message that says “not implemented” when the camera.getPhoto functions is called.  So I spent about four hours fighting to fix that because I read some perhaps misleading information that indicated Ripple is supposed to pop-up a dialog box and prompt to browse for an image when the camera is invoked in a PhoneGap app.  Well that led me on the chase and so I followed up on all the tweaks and tricks I could find to get that to work, but they all seemed to be lore, at least for me.  I even went to the Apache site and looked at the build instructions.  The instructions warned the project would not build on Windows. So I looked into the Jira bug track and found an in-progress ticket to get it to build on Windows.  I also browsed the code comments and could see someone checked in some stuff to support PhoneGap 3 a while back.  So, there’s probably good stuff waiting to be released, but the release cycle looks to be very loooong so don’t hold your breath.  In the mean time, if you know anyone with a newer build of Ripple out there, please let me know.  Still, I encourage adding Ripple to your tool set.