Book Review: Creating Mobile Apps With JQuery Mobile 91
sagecreek writes "You can judge this book, at least in part, by the lengthy tagline on its cover: 'Learn to make practical, unique, real-world sites that span a variety of industries and technologies with the world's most popular mobile development library.' jQuery might not be your favorite framework on the long, long list of JavaScript possibilities. But Shane Gliser unabashedly describes himself as a jQuery 'fanboy...if it's officially jQuery, I love it.' Gliser is an experienced mobile developer and blogger who operates Roughly Brilliant Digital Studios. He also has some background in mobile UX (user experience), and both qualities show in this smoothly written, well-illustrated, 234-page how-to book that focuses on jQuery Mobile, a 'touch-optimized' web framework for smartphones and tablets." Read below for the rest of sagecreek's review.
Don't be surprised when you extract the book's code examples and related items from a ZIP file that is almost 100MB in size. Gliser covers a lot of ground, and he covers it well in his 10 chapters. And each chapter contains a project.
| Creating Mobile Apps With JQuery Mobile | |
| author | Shane Gliser |
| pages | 234 pages |
| publisher | Packt Publishing |
| rating | 9/10 |
| reviewer | sagecreek |
| ISBN | 9781782160069 |
| summary | Takes the reader from mobile prototyping and creating templates to mobile development and creating versatile mobile sites, with a project in each chapter. |
The first thing you don't do in Chapter 1, "Prototyping jQuery Mobile," is work at a computer. In the true spirit of UX, Gliser briefly has you work with a pen and some 3x5 note cards. (Remember those?) Your initial goal is to roughly sketch out some designs for a jQuery Mobile website for a new pizzeria. But why the ancient technology? "We are more willing to simply throw out a drawing that took less than 30 seconds to create," Gliser writes. And: "Actually sketching by hand uses a different part of the brain and unlocks our creative centers." Furthermore, those on your team who are not coders can contribute comments, suggestions, and corrections to the emerging design.
In Chapter 2, "A Mom-and-Pop Mobile Website," you step over to your computer with Chapter 1's paper prototype in hand. You start converting the sketched design "into an actual jQuery Mobile (jQM) site that acts responsively and looks unique." You also begin building "a configurable server-side PHP template," and you work with custom fonts, page curl effects using CSS, and other aspects of creating and optimizing a mobile site.
"Mobile is a very unforgiving environment," Gliser cautions, "and some of the tips in this section will make more difference than any of the 'best coding practices.'" Indeed, he wants you to be aware of optimization "at the beginning. You are going to do some awesome work and I don't want you or your stakeholders to think it's any less awesome, or slow, or anything else because you didn't know the tricks to squeeze the most performance out of your systems. It's never too early to impress people with the performance of your creations."
Chapter 3, "Analytics, Long forms, and Front-end Validation," moves beyond "dynamically link[ing] directly into the native GPS systems of iOS and Android." Instead, Gliser introduces how to work with Google static maps, Google Analytics, long and multi-page forms, and jQuery Validate. As for static maps, he says, "Remember to always approach things from the user's perspective. It's not always about doing the coolest thing we can." Indeed, a static map may be all the user needs to decide whether to drive to a business, such as a pizzeria, or just call for delivery. And, as for Google Analytics: "Every website should have analytics. If not, it's difficult to say how many people are hitting your site, if we're getting people through our conversion funnels, or what pages are causing people to leave our site."
Meanwhile, desktop users are familiar with (and frequently irritated by) long forms and multi-page forms. Lengthy forms can be real deal-breakers for users trying to negotiate them on mobile devices. The author presents some ways to shorten long forms and break them "into several pages using jQuery Mobile." And he emphasizes the importance of using the jQuery Validate plug-in to add validation to any page that has a form, so the user can see quickly and clearly that an entry has a problem.
The focus in Chapter 4, "QR Codes, Geolocation, Google Maps API, and HTML5 Video," is on handling concepts that can be "applied to any business that has multiple physical locations." Gliser uses a local movie theater chain as his development example. It is "considering throwing its hat into the mobile ring," so a site is created that makes use of QR codes, geolocation, Google Maps, and linking to YouTube movie previews. Then, he shows how to use embedded video to keep users on the movie chain's site rather than sending them off to YouTube.
In Chapter 5, the goal is "to create an aggregating news site based off social media." So the emphasis shifts to "Client-side Templating, JSON APIs, and HTML5 Web Storage." Notes Gliser: "Honestly, from a purely pragmatic perspective, I believe that the template is the perfect place for code. The more flexible, the better. JSON holds the data and the templates are used to transform it. To draw a parallel, XML is the data format and XSL templates are used to transform. Nobody whines about logic in XSL; so I don't see why it should be a problem in JS templates."
Next, he shows how to patch into Twitter's JSON API to get "the very latest set of trending topics" and "whittle down the response to only the part we want...and pass that array into JsRender for...well...rendering" in a manner that will be "a lot cleaner to read and maintain" than looping through JSON and using string concatenation to make the output.
Other topics in Chapter 5 include programmatically changing pages in jQuery Mobile, understanding how jQuery Mobile handles generated pages and Document Object Model (DOM) weight management, and working with RSS feeds. Gliser points out that there is still "a lot more information out there being fed by RSS feeds than by JSON feeds." The chapter concludes with looks at how to use HTML5 web storage (it's simple, yet it can get "especially tricky on mobile browsers"), and how to leverage the Google Feed API. Explains Gliser: "The Google Feeds (sic) API can be fed several options, but at its core, it's a way to specify an RSS or ATOM feed and get back a JSON representation."
Chapter 6 jumps into "the music scene. We're going to take the jQuery Mobile interface and turn it into a media player, artist showcase, and information hub that can be saved to people's home screens," Gliser writes. He proceeds to show how "ridiculously simple it can be to bring audio into your jQuery Mobile pages." And he explains how to use HTML5 manifest "and a few other meta tags" to save an app to the home screen. Furthermore, he discusses how to test mobile sites using "Google Chrome (since its WebKit) or IE9 (for the Windows Phone)" as browsers that are shrunken down to mobile size. "Naturally, this does not substitute for real testing," he cautions. "Always check your creations on real devices. That being said, the shrunken browser approach will usually get you 97.5 percent of the way there. Well...HTML5 Audio throws that operating model right out the window."
Since "mobile phones are quickly becoming our photo albums," Gliser's Chapter 7, "Fully Responsive Photography," begins with creating a basic gallery using Photoswipe. Then, in a section focused on "supporting the full range of device sizes," he shows how to start using responsive web design (RWD), "the concept of making a single page work for every device size." The issues, of course, range from image sizes and resolutions to text sizes and character counts per line, on screens as small as smart phones and tablets, or larger.
In Chapter 8, "Integrating jQuery Mobile into Existing Sites," three topics are key: (1) "Detecting mobile — server-side, client-side, and the combination of the two"; (2) "Mobilizing full site pages — the hard way"; and (3) Mobilizing full site pages — the easy way." Gliser avoids some potential "geek war" controversies over "browser sniffing versus feature detection" when detecting mobile devices. He zeroes in first on detection using WURFL for "server-side database-driven browser sniffing." He also shows how to do JavaScript-based browser sniffing, which he concedes may be "the worst possible way to detect mobile but it does have its virtues," especially if your budget is small and you want to exclude older devices that can't handle some new JavaScript templating. He also describes JavaScript-based feature detection using Modernizer, plus some other feature-detection methods.
As for mobilizing full-site pages "the hard way," he states that there is really "only one good reason: to keep the content on the same page so that the user doesn't have one page for mobile and one page for desktop. When emails and tweets and such are flying around, the user generally doesn't care if they're sending out the mobile view or the desktop view and they shouldn't." He focuses on how "it's pretty easy to tell what parts of a site would translate to mobile" and how to add data attributes to existing tags "to mobilize them. When jQuery's libraries are not present on the page, these attributes will simply sit there and cause no harm. Then you can use one of our many detection techniques to decide when to throw the jQM libraries in."
Mobilizing full-size pages "the easy way" involves, in his view, "nothing easier and cleaner than just creating a standalone jQuery Mobile page...and simply import the page we want with AJAX. We can then pull out the parts we want and leave the rest." His code samples show how to do this.
Chapter 9, "Content Management Systems and jQM" looks at the pros and cons of using three different content management systems (CMS) with jQuery Mobile: WordPress, Drupal, and Adobe Experience Manager. "The key to get up and running quickly with any CMS is, realizing which plugins and themes to use," Gliser writes. "For WordPress, I would not recommend a jQuery Mobile plugin. As I was experimenting for this chapter, it broke the admin interface and was, in general, a miserable experience. However, there are several jQuery Mobile themes that will serve you well. Some are free, some paid." He explains how to use mobile theme switchers.
Meanwhile, Drupal offers some standard plugins that provide contact forms, CAPTCHA, and custom database tables and forms, and enable you to "create full blown web apps, not just brochureware sites." But: "The biggest downside to Drupal is that it has a bit of a learning curve if yo want to tap its true power, Also, without some tuning, it can be a little slow and can really bloat your page's code," he says.
As for Adobe Experience Manager (AEM), Gliser merely introduces it as a "premier corporate CMS" and a "major CMS player that comes with complete jQuery Mobile examples." He doesn't show "how to install, configure, or code for AEM. That's a subject for several training manuals the size of this book." He adds: "If you work for a company that can afford AEM, you'll already be well-versed in the mobile implementation. The power this platform gives to content authors is astounding."
Chapter 10, the final chapter, is titled "Putting It All Together — Flood.FM." Using what you've learned in the book, including paper prototyping the interfaces, you create "a website where listeners will be greeted with music from local, independent bands across several genres and geographic regions."
Along the way, Gliser introduces Balsamiq, "a very popular UX tool for rapid prototyping." He discusses using Model-View-Controller (MVC), Model-View-ViewModel (MVVM), and Model-View-Whatever (MV*) development structures with jQuery Mobile. He introduces how to work with the Web Audio API , and he illustrates how to prompt users to download the Flood.FM app to their home screens. He finishes up with brief discussions of accelerometers, cameras, "APIs on the horizon," plus "To app or not to app, that is the question" and whether you should compile an app or not. Finally, he shows PhoneGap Build, the "cloud-based build service for PhoneGap."
Shane Gliser's book does indeed cover a lot of ground, clearly and with good examples. If you truly demand that some nits must be picked, I can report that an occasional dash is missing or a comma sometimes shows up out of place, such as this example in Chapter 2: "A practice is only best until a new practice, [misplaced comma] comes along that is better." In the printed book's table of contents, there are style and spelling glitches in the heading for Chapter 3. "Analytics, long forms, and frontend validation" should be "Analytics, Long Forms, and Front-end Validation." And, in Chapter 5, Gliser refers to the "Google Feeds API" when it's actually "Google Feed API." But the term "Google Feeds API" commonly is misused by developers on Stack Overflow and other sites.
I am not a mobile developer. I am a tech writer, frequent book reviewer, and occasional coder. I have played with some of the code examples in this book, but I have not tried them all. So I can't say if there are code glitches. However, the book was reviewed before publication by at least four software professionals with impressive resumes.
Aside from occasional spots where the text needed tighter editing, this book is, in my view, well written and rich with information, examples, sources, and tips for working effectively with jQuery Mobile. I intend to put it to good use as I continue learning.
You can purchase Creating Mobile Apps with jQuery Mobile from amazon.com. Slashdot welcomes readers' book reviews (sci-fi included) -- to see your own review here, read the book review guidelines, then visit the submission page.
That explains things (Score:5, Insightful)
You know, your website that's supposed to work on my portable device but has an interface which reacts way too slowly to be usable at all?
Fucking frameworks upon fucking frameworks. We have GHz CPUs and megabytes if not gigabytes of RAM but your laziness makes it all worthless.
Re: (Score:1)
You say flamebait, I say "fuck you, your website is unusable so I'll go check your competitor."
Re: (Score:2)
Re:That explains things (Score:5, Informative)
For once an AC is correct.
This stuff just eats battery and makes performance suck. Stop pushing the heavy lifting onto the client. With a desktop it is one thing, but on a mobile device it smacks of incompetence.
Re:That explains things (Score:4, Insightful)
Here is how you support 6 different OS platforms, make a simple text web page. Stop trying to make everything look like the bastard child of geocities.
Re:That explains things (Score:5, Funny)
If I look at the current state of things, a mobile GeoCities would be an improvement.
Re: (Score:1)
Re: (Score:3)
Too many coders and programmers think they can design websites. There's people going to school for years to learn how to design things. And even most of these designers can't make good interfaces anyway.
Re: (Score:1)
Re: (Score:2)
You're in luck, because these days it's all about "minimalist website design". After you've looked at a few dozen websites it should give you at least a general idea of what to do with your own website.
Re: (Score:2)
What would you recommend? Not tryin to be a prick but just curious as I'm at a crossroads with my company. We're considering diving into mobile web development. I myself have taken a look at and toyed with jQuery Mobile and was considering it. I use the standard one on all full size websites and love it.
Re: (Score:3)
I would recommend Web 2.0 die in a gutter somewhere. Instead of killing my battery with animations and sliding infographics, just give me a nice simple text webpage.
Re: (Score:2)
Well sadly, web developers have to make it how the paying clients want it. They have no real choice if they want to get paid.
Re:That explains things (Score:4, Insightful)
Then take this as a message to those buying websites.
Also please tell restaurants that all I want is your hours and menu. A simple text page can do all that in one page and it you can save a fortune on dev time.
Re: (Score:3)
Then take this as a message to those buying websites.
Also please tell restaurants that all I want is your hours and menu. A simple text page can do all that in one page and it you can save a fortune on dev time.
The problem is that people like yourself are a tiny minority. Most people go "wow, look at pretty swirl that follows my mouse pointer around, isn't it neat!" (this is a piss poor example)
Seriously though, most people love jquery as it means we don't have to do basic animations in flash any more and can do ajax type stuff. Without things like jquery you would be stuck with whole page refreshes just because you wanted to add a row to a form. I have done this sort of stuff in raw JS (I have been a web dev for
Re: (Score:2)
Seriously though, most people love jquery as it means we don't have to do basic animations in flash any more and can do ajax type stuff. Without things like jquery you would be stuck with whole page refreshes just because you wanted to add a row to a form.
Surely, you're new to web development.
I have done this sort of stuff in raw JS (I have been a web dev for almost 10 years) and it was just not worth the effort making it cross browser without doing whole page reloads that were slow for the average user.
You were probably just doing it wrong. I dug up an old ajax project of mine from 2006 not long ago and, well, it wasn't pretty. jQuery doesn't offer any real simplicity, once you know what you're doing -- I'd even argue that (vs xhr2) the jQuery equivalent is harder to read.
Really, I haven't found a single case in recent years where jQuery has made development easier. In the few places you can make a legitimate case, you usually can't justify the extra weight and per
Re: (Score:2)
Surely, you're new to web development.
Nope, far from it. But if it helps you carry on being arrogant you're free to believe it if you like.
I did have a longer post that this answering some of your other points but since you have just gone though all my posts replying to them all seperately I am convinced you are just a troll or something now.
Re: (Score:2)
It was a joke, in case you didn't notice. You felt the need to tell me how long you've been doing web development; which I immediately quoted. It's not an uncommon gag. It's particularly funny as you made an obviously absurd statement, to which one would assume that you were new and simply didn't know any better.
Without things like jquery you would be stuck with whole page refreshes just because you wanted to add a row to a form.
See how absurd that statement is? It's not even a tiny bit true! Rather than tell you what I presume you already knew, I made a lighthearted joke. Should I not have done that? Should I have ju
Re: (Score:2)
Not only restaurants. If I'm checking a company website on a mobile device, here's what I'm probably looking for:
- locations with contact information such as the phone number. It's even more helpful if each location has a link to Google Maps
- opening hours for chosen location, unless they're all the same
As h4rr4r said, restaurants needs their menu online but I would add that they need to put things like prices, the list of ingredients in each item and the nutritional information. Vegetarians, vegans and peo
Re: (Score:2)
Also please tell restaurants that all I want is your hours and menu.
Dear God, yes. Why is that so damn difficult?
Re: (Score:2)
You can give them all the recommendations you want. When they see a neat flashy competitors site, they want one just the same or better. In this business you do what the masses thinks is 'cool' not what the small fraction of tech nerds want.
And yes I would prefer a small simple html site as well but that doesn't happen in the real world anymore.
Re:That explains things (Score:5, Insightful)
Re: (Score:1)
Re: (Score:2)
Sane shotgun (why do this? because I can!) but new ammo to put in it.
Re: (Score:2)
Re: (Score:2)
I don't really have anything better to use but I would warn you to stay as far away from jQuery Mobile as possible. Even the simple UI demos on their site are slow as hell on a desktop machine. That just screams 'stay away' to me. I was going to use it for a mobile project I was working on. Scrapped it within 2 hours and wrote my own (still using jQuery).
Re: (Score:3)
Re: (Score:2)
We used to develop mobile apps using jQueryMobile and Cordova (formerly PhoneGap)... Combined with HTML5 application cache the performance was actually pretty good, with one nasty exception; There is a delay of several hundred milliseconds before the framework receives touch events -- from what I understand this is not actually something jQM can do much about, it comes from the way the underlying layers distinguish swipes, taps, etc. But it utterly kills the experience. So much so that we have since moved o
Re: (Score:2)
You can avoid these delays by overloading the ontouchstart and ontouchend events. These are instant. onclick is not triggered until the mobile browser is certain that you are not inputting a gesture.
Re: (Score:2)
Thanks for replying! Yes we tried some of the more obvious workarounds, but couldn't prevent clicks from sometimes being synthesized "after the fact". So for example we would do a page transition in response to a touchstart event, but if those same X,Y coordinates on the new page would cover a clickable item, THAT would receive a spurious event.
By this time we had to get some apps out the door and we went native. To my regret, as I was just getting excited about HTML5. Then, later, I ran across this documen [google.com]
Re: (Score:2)
The dance needed to avoid an event from propagating is quite occult.
function claimEvent(evt) {
"use strict";
if (evt) {
if (evt.preventDefault) {
evt.preventDefault();
}
if (evt.stopImmediatePropagation)
Re: (Score:2)
We're currently using Sencha Touch [sencha.com] - there are some downsides, the documentation can be woefully incomplete or wrong even (be sure to use the online docs so you get the user comments as well), we've had some issues with migrating between very minor revisions, up until recently it only supported Webkit (2.2 added support for mobile IE as well, I think mobile FF is still not supported) and programming for it is quite different than traditional web programming - Sencha Touch is very much a "my way or the highw
Re: (Score:3)
On mobile, everything is limited:
- device battery life, some are quite frankly crap on this point, having to charge twice daily is not what I would call useful
- device processing power, the parent AC is right, not everyone has the very latest device, a heavy website means the interface will not be responsive
- user wait time, bigger downloads means it takes literally seconds before I can use the website
- device download time, doing everything on the client instead of the server means more shit to download, w
Re: (Score:1)
Literally seconds? seconds? really?! Wow! that's amazing!
I got so used to waiting tens of minutes for the new version of whatever software I wanted to download, yelling at people at home to stop picking up the phone until finally giving up and waiting till late at night and everyone was asleep so I can do some serious downloadin'
a few quotes from Louis CK
"You noncontributing product sponge cunt. Can you just wait?!?! Can you just wait? And just take a little breath."
" The shitiest cellphone in the world is
Re: (Score:2)
Waiting 2 to 3 seconds is normal. Waiting for 10 seconds or more means the website is bloated.
Re: (Score:1)
Re: (Score:3)
you should come visit my website. We make your computer/phone load jQuery, Prototype, yUI and my own custom libraries. (although not all at once on the same page)
this is not a joke
Re: (Score:1)
Re: (Score:2)
No kidding. JQuery Mobile is ridiculously slow. [blogspot.com]
You'd be crazy to use an inefficient and over-weight library like jQuery anyway. Adding jQuery mobile to that is just asking for trouble.
Let's face it: jQuery has long outlived it's utility. It's not even viable for dealing with old browser compatibility issues on the Desktop.
Just learn JavaScript. Your users will thank you. I'll bet that you'll even ultimately save time and effort as you'll spend less time trying to squeeze acceptable performance out of
Re: (Score:2)
We use jQuery for actual in house web applications rather than a site that gets infrequent visits from random users. The difference being that we can use an application cache to store things like a minified version jQuery library on the client
Re: (Score:3)
Smart programmers don't reinvent the wheel just because they can.
Then why are you using jQuery?
For the bulk of real-world jQuery use, you can use getElementById, querySelector, and querySelectorAll. Take a look around the web. It's disturbing.
Moving on, for stuff like animations, smart programmers use lightweight special purpose libraries rather than slow, bulky, buggy general purpose library like jQuery. Even better: When they can, they use CSS instead! Instead of jQuery + some heavy-weight plugin for a dropdown menu, you could do the same thing very quickly with so
Re: (Score:2)
Then why are you using jQuery?
For the bulk of real-world jQuery use, you can use getElementById, querySelector, and querySelectorAll.
Jquery is just quicker to write so takes less dev time.
Also, out of your list of pure JS replacements about you missed document.createElement(). Once you start having to create elements of the dom tree on the fly JQuery comes into its own in terms of writing less code and hence developers producing quicker results.
Nobody cares about efficiency any more as cpu time is just so much cheaper than the man hours put in to creating code. Writing super efficient code is just not worth wasting time over when modern
Re: (Score:3)
Once you start having to create elements of the dom tree on the fly JQuery comes into its own in terms of writing less code and hence developers producing quicker results.
Looks like it takes the same amount of code to me. Also, the pure JS version is significantly faster as you can see from any one of several tests [jsperf.com] online.
Let's not forget about maintenance. The unreadable mess that jQuery forces you to write (to try to compensate for its absurdly poor performance) coupled with the ever-shifting API dramatically increases maintenance costs.
Nobody cares about efficiency any more
Your users care. They care a lot. The host of slow laggy UI's and the associated user complaints are a strong testament to this. The "
Re: (Score:2)
Looks like it takes the same amount of code to me.
Did you look at any?
Compare:
$('body').append('<div>A div with content</div>');
With:
var newDiv = document.createElement("div");
var newContent = document.createTextNode("A div with content");
newDiv.appendChild(newContent);
document.body.appendChild(newDiv);
Whatever else you may say you cannot possibly miss that jquery let you do the same thing but with far few characters being typed.
The unreadable mess that jQuery forces you to write
Granted Jquery does let you make a mess, but I gather from your sig that you are not a fan of OOP so you are pretty m
Re: (Score:2)
Whatever else you may say you cannot possibly miss that jquery let you do the same thing but with far few characters being typed.
Savign a few seconds worth of typing isn't exactly a good reason to use a library! If the physically typing code is a bottle-neck in your development process, I'd love to know where you hire!
Most users know fuck all, and even if they do they don't pay the bills in web development, the client does.
They know when an app is slow and clunky. That's why you don't use jQuery Mobile. Of course, it looks like you hate users, so I'm not surprised that you're not concerned about their experience. I'll let you work out the ethics.
I have never had any performance issues with the stuff I have been creating
You'd be the first. Well, or you just haven't noticed.
Maybe if you were having Jquery performance issues it was with very old versions or you were not writing decent code?
I do have objective data to support
Re:I'm going to assume that was hipster irony. (Score:4, Informative)
2. Animations are not part of jQuery, they are part of jQuery UI which is a totally separate library and which I agree, sucks.
3. Native JS syntax for ajax is convoluted..
$.ajax({
url: '/some/url',
success: function(o) {
}
});
Is much more maintainable to me than several lines of new xmlhttprequiest()... blah blah blah... every time you need to make an ajax call...
4. Jquery has lot of powerful stuff that lets you write less code much of the time such as
Re: (Score:2)
And just because you're using jQuery for some stuff doesn't mean you have to forget how to write native javascript or use css
Re:I'm going to assume that was hipster irony. (Score:5, Informative)
If you just need to call getElementByID once or twice then you're better off doing that rather than loading jQuery. If you need to do some more massive JavaScript/DOM manipulation and querying then calling getElementByID and the others repeatedly will lead to extremely long code. It will also lead to unmaintainable code if you just put everything in one big code block. To keep your code short and to enable easy reuse, you'll need to encapsulate this code into functions. Once you start making functions whose purpose it is to manipulate the DOM in a similar way across many different browsers, you are better off going with jQuery. You could wind up essentially rewriting it, but chances are it won't be shorter/more efficient. As a bonus, if you link to jQuery using the code.jquery.com URL, people's browsers will likely have it cached.
As for jQuery breaking code when they release new versions and/or dropping support for IE 6/7/8, you don't need to upgrade. I used jQuery extensively for an Intranet site and stayed on 1.4.3 for a long time. Recently, I decided it was (long past) time to upgrade so I reviewed our code, upgraded jQuery little by little, fixing things as they broke, and finally went live with jQuery 1.9.1. We'll likely stay with this (or another in the 1.x branch) until IE8 support no longer matters. (IE6 and IE7 support has been dropped already.)
You aren't even forced to upgrade if you use the code.jquery.com URL. This link [jquery.com] has all of the jQuery versions from 1.0.1 to the current version.
Re: (Score:2)
If you need to do some more massive JavaScript/DOM manipulation and querying then calling getElementByID and the others repeatedly will lead to extremely long code. It will also lead to unmaintainable code if you just put everything in one big code block. To keep your code short and to enable easy reuse, you'll need to encapsulate this code into functions.
You do realize all of that applies when you use jQuery as well, right?
Maybe you don't...
. Once you start making functions whose purpose it is to manipulate the DOM in a similar way across many different browsers, you are better off going with jQuery.
In the context you're trying to support the use of jQuery, it very obviously offers you no benefits what-so-ever. But you know that, right?
Well, I can't blame you for trying to make such a non-argument. It's VERY difficult to defend the use of jQuery. See, what this all boils down to is that you're comfortable with jQuery, not so comfortable with JavaScript, and already know that jQuery has long outlived any utility t
Re: (Score:2)
As a bonus, if you link to jQuery using the code.jquery.com URL, people's browsers will likely have it cached.
Please don't!
1) NoScript users hate you :-P
2) You are now depending on another site's availability for your site to function
3) I'm sure jquery.com or google.com or whoever is hosting your 3rd party script(s) loves your traffic information
I do agree that you should always specify an exact version of jQuery. Never use jquery.latest in place of jquery.1.2.3.
Re: (Score:2)
I remember reading this when jQuery Mobile was just starting up; John Resig was very aware of it, and there was considerable effort put into addressing performance issues. I waited for this to be mentioned in the review, but it wasn't. There are several JS mobile frameworks out there, but jQuery's desktop popularity and large number of plugins available would seem to lend jQM a clear advantage for development if performance was not still an issue.
Re:That explains things (Score:4, Interesting)
No kidding. JQuery Mobile is ridiculously slow. [blogspot.com]
You'd be crazy to use an inefficient and over-weight library like jQuery anyway. Adding jQuery mobile to that is just asking for trouble.
Let's face it: jQuery has long outlived it's utility. It's not even viable for dealing with old browser compatibility issues on the Desktop.
Just learn JavaScript. Your users will thank you. I'll bet that you'll even ultimately save time and effort as you'll spend less time trying to squeeze acceptable performance out of Resig's cludge -- and less time trying to debug the nasty one-liners you're forced to write to get those tiny improvements.
This is dumb for a variety of reasons. jQuery lets you abstract away a ton browser inconsistencies. It also makes you alot more productive b/c you don't have to constantly event wheels...JS by itself is extremely tedious syntax wise . (do you really like document.getElementById riddling your code to the point of unreadability? I'm sure you'd say oh, i'll just write a helper. Well congrats, there you go inventing wheels) Some of the worst code I run across on the web always seems to be the guy that insists on doing things with pure javascript and he has tons of onclick handlers directly on tags and all sorts of other crap which makes sites completely unmaintainable...
Re: (Score:2)
Re: (Score:1)
Re:That explains things (Score:5, Interesting)
Re: (Score:2)
Appeal to authority, awesome (Score:1)
I don't feel like enumerating all the things one can do with HTML + JavaScript that one cannot do with 1990s HyperCard because the comparison is silly on its face.
When VPRI rolls out a technology that runs in any number of browsers without installing plugins, is open, free and accessible, widely used and the standards are either well supported or easily extended by polyfill techniques, then I'll give you some credence.
From Wikipedia:
>>Then, Apple decided that most of its application software packages,
Re: (Score:2)
When VPRI rolls out a technology that runs in any number of browsers without installing plugins, is open, free and accessible, widely used and the standards are either well supported or easily extended by polyfill techniques, then I'll give you some credence.
You've completely missed the point of their effort. (You've also completely (almost spectacularly, I dare say) missed the point of my first response, but I should have written it there outright - that was my mistake, of course.)
It's just obvious by the simple wrongness of your statement that your casual dismissal of HTML and JavaScript is rooted in ignorance.
My casual dismissal of HTML and Javascript is based on having been given pointers by Alan Kay as to why HTML was a bad (and vastly unoriginal) idea in the first place. The problem isn't that I don't consider it useful. The problem is that HTML/WWW wasn't a step forward even at the en
Re: (Score:1)
You could be describing the linked article or m.slashdot.org itself, which is agonizingly slow and unusable on my old iPhone.
Re: (Score:1)
Another book (Score:2)
Interested parties should also check out Build Mobile Websites and Apps for Smart Devices [sitepoint.com].
Is it because I am old? (Score:2)
Creating Mobile Apps With JQuery Mobile
Wait, is it about creating apps or creating websites? Are they the same thing now? Bloody kids with their ridiculous ideas...
Re:Apps vs. websites (Score:2)
" Wait, is it about creating apps or creating websites? "
Both, and that's part of the problem.
HTML/CSS/JS can be used to create "hybrid" applications (native apps that use a WebView for the UI), "webapps" (website content locally-installed) or traditional websites.
The needs/problems with each are quite different. For websites, it makes sense to shift some of the burden to the client, if that means significantly less data is sent. Especially for mobile.
For native apps, you might (or might not) have a local s
*Shudder* (Score:4, Insightful)
JavaScript/jQuery is supposed to do small things on a web page that make functionality easier. Not be built out of it. If your site doesn't work with JavaScript disabled, then it's a bad site not only for the ever growing list of people running some type of ad-blocker and/or script-blocker but also for all the platforms that don't have perfect JS support such as machines (Google is just the beginning, wait until Watson-type machines start getting more popular...). If a machine can't parse your site without executing something on it's side, it's a useless site and can't be found.
I am a web developer and I do use jQuery but it's to make a user's job easier such as a date/time picker (which for some reason still isn't fully implemented in the stock jQuery) or sortable tables (which is a UI and therefore client-side thing, not a server thing), not to make it more difficult to parse out the data. A server-side script generating CSS and HTML is far more capable and responsive for presenting data than jQuery's internal routines to generate the same HTML from an XML-source, if you really want to do that (parse XML into other XML) we have XSLT.
Re: (Score:1)
"JavaScript/jQuery is supposed to do small things on a web page that make functionality easier."
In 1997 this was true. It has not been true for quite some time.
Re: (Score:1)
Re:*Shudder* (Score:4, Informative)
Re: (Score:1)
Re: (Score:2)
Unless we're talking heavy calculations here, doing them locally will likely drain less battery than a lengthy network request, especially over a laggy 3G network...
Re: (Score:2)
Ever heard of blind people?
Re: (Score:2)
While jquery mobile does suck, you can still have meaningful semantic markup while using it, so while the search engine doesn't see exactly the same thing as a user would, it generally is good enough for SEO purpose. Mobile phones also have fairly advanced browsers (at least compared to older browsers), and virtually no one that would be your customer will block scripts on them.
Then there's more advanced systems... On our site we have a full client side (no flash bullshit) wysiwyg editor for customers to de
And so began the great jQuery wars of 2013. (Score:1)
Javascript needs to die (Score:1)
Re: (Score:1)