Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

We are sorry to see you leave - Beta is different and we value the time you took to try it out. Before you decide to go, please take a look at some value-adds for Beta and learn more about it. Thank you for reading Slashdot, and for making the site better!

Book Review: Creating Mobile Apps With JQuery Mobile

samzenpus posted about a year and a half ago | from the read-all-about-it dept.

Books 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.

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.

Sorry! There are no comments related to the filter you selected.

That explains things (5, Insightful)

Anonymous Coward | about a year and a half ago | (#43899331)

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:That explains things (1)

Anonymous Coward | about a year and a half ago | (#43899415)

You say flamebait, I say "fuck you, your website is unusable so I'll go check your competitor."

Re:That explains things (1)

unimacs (597299) | about a year and a half ago | (#43899461)

The website seems to work fine on my smartphone which is almost 3 years old.

Re:That explains things (4, Informative)

h4rr4r (612664) | about a year and a half ago | (#43899455)

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 (0)

Anonymous Coward | about a year and a half ago | (#43899531)

This AC feels completely differently. This AC doesn't see what you call "incompetence" as a bad thing. It's a well documented visualization layer...just like every other write-once, run-everywhere layer that came before it--benefits and drawbacks included. Yes, it's for development teams that are "incompetent" as in "unable to support 6 different OS platforms as effectively as one" But just like every one of them before it, this layer has it's place in the grand scheme and in due time.

OP - Thanks for posting this review. I look forward to checking it out.

Re:That explains things (3, Insightful)

h4rr4r (612664) | about a year and a half ago | (#43899597)

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 (4, Funny)

ArcadeMan (2766669) | about a year and a half ago | (#43899621)

If I look at the current state of things, a mobile GeoCities would be an improvement.

Re:That explains things (1)

noh8rz10 (2716597) | about a year and a half ago | (#43900831)

i developed a mobile site that looks like web 1.0 - lots of white space, limited graphics, text, and a couple forms with some CSS so they look prettier. I feel unsure about it. on the one hand it's blazingly fast, meets all the usability requirements, and is totally mobile-agnostic. on the other hand it makes me feel kinda amateurish compared to some of the slick examples at one of the links in the summary. any thoughts on how I can get past this?

Re:That explains things (2)

ArcadeMan (2766669) | about a year and a half ago | (#43907653)

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:That explains things (1)

noh8rz10 (2716597) | about a year and a half ago | (#43908587)

so, what's a guy to do? give up? say, "i can't do it"? hire a design house, who will make a wasteful site anyway? pop quiz, hot shot: what would you do?

Re:That explains things (1)

ArcadeMan (2766669) | about a year and a half ago | (#43908617)

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:That explains things (1)

Krojack (575051) | about a year and a half ago | (#43899537)

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:That explains things (2)

h4rr4r (612664) | about a year and a half ago | (#43899583)

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:That explains things (1)

Krojack (575051) | about a year and a half ago | (#43899691)

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 (3, Insightful)

h4rr4r (612664) | about a year and a half ago | (#43899737)

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:That explains things (2)

Ash Vince (602485) | about a year and a half ago | (#43900611)

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 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. JQuery lets you do dynamic html pages far more easily and build user interfaces that more closely resemble stand alone applications.

Recently I had to create a page that lets users sort a list by clicking and up down arrow next to each item. When I did stuff like this before JQuery it was a PITA to get working and horrible to use, now it is much quicker and easier. For the same amount of time I put in previously I could have let them drag and drop stuff up and down now (I wanted to, but couldn't get it passed management).

Re:That explains things (1)

narcc (412956) | about a year and a half ago | (#43901981)

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 performance penalty.

Re:That explains things (0)

Anonymous Coward | about a year and a half ago | (#43907135)

For someone who hates jQuery so much, you sure devote a lot of time to coming here and bitching about it.

Just what do you hope to achieve? To kill it so you never have to look at it again? Ain't gonna happen.

Re:That explains things (1)

Ash Vince (602485) | about a year and a half ago | (#43913139)

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:That explains things (1)

narcc (412956) | about a year and a half ago | (#43916265)

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 just assumed you were a moron and explained in detail why your statement was foolish?

since you have just gone though all my posts replying to them all seperately

I should reply to them as a group? I don't even know what your expectations would be!

What's your objection anyway? You don't think that jQuery Mobile is too slow for real-world use? You really like jQuery and think that its performance problems aren't a big deal? Or is it that you just like jQuery and think everyone should ignore all the problems?

Re:That explains things (1)

ArcadeMan (2766669) | about a year and a half ago | (#43900665)

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 people with allergies needs to know what's in the food and people with medical conditions need other informations such as the sodium content, etc.

Re:That explains things (1)

narcc (412956) | about a year and a half ago | (#43900751)

Also please tell restaurants that all I want is your hours and menu.

Dear God, yes. Why is that so damn difficult?

Re:That explains things (0)

Anonymous Coward | about a year and a half ago | (#43901107)

Because it isn't actually true.

Re:That explains things (1)

Krojack (575051) | about a year and a half ago | (#43904841)

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 (4, Insightful)

JaredOfEuropa (526365) | about a year and a half ago | (#43900275)

Sucky Web 2.0 sites generally suck harder than "simple text webpages"; the technology gives developers a couple of new shotguns to shoot themselves in the foot with. But good Web 2.0 pages can be a vast improvement over Web 1.0 or pages of text. Don't knock the technology for mistakes made by incompetent designers. As always, it comes down to selecting the right tool, and applying it in the right way.

Re:That explains things (1)

noh8rz10 (2716597) | about a year and a half ago | (#43900871)

examples of mobile web2.0 done right? I built a web1.0 mobile page which works well but looks like it's from 1999. Would love to do something that looks current but doesn't blow chunks. any examples would be greatly appreciated!

Re:That explains things (1)

i.r.id10t (595143) | about a year and a half ago | (#43901759)

Sane shotgun (why do this? because I can!) but new ammo to put in it.

Re:That explains things (2)

Steve_Ussler (2941703) | about a year and a half ago | (#43910883)

Plenty of 3rd world countries have low bandwith. Web 2.0 is still very relevent there.

Re:That explains things (1)

Kielistic (1273232) | about a year and a half ago | (#43899777)

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:That explains things (2)

JaredOfEuropa (526365) | about a year and a half ago | (#43900415)

I tried a couple of their demos on a (recent model) smart phone on WiFi, and performance was good. Not lightning fast like a native app, but certainly not slow as hell either. It was decent on an iPad 1 as well.

Re:That explains things (1)

erikkemperman (252014) | about a year and a half ago | (#43902813)

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 on to developing native apps.

But I've read about some approach (some google guys, can't be bothered to find the link just now) to getting around this issue, and if that works out I'd gladly go back to JQM.

Re:That explains things (2)

oever (233119) | about a year and a half ago | (#43902975)

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:That explains things (1)

erikkemperman (252014) | about a year and a half ago | (#43903575)

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 document [google.com] by some google guys. Sounds like it might help resolve this major annoyance.

Re:That explains things (2)

oever (233119) | about a year and a half ago | (#43908967)

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) {
                        evt.stopImmediatePropagation();
                }
                if (evt.stopPropagation) {
                        evt.stopPropagation();
                }
        }
        return false;
}
ontouchstart = function (event) { .......
            return claimEvent(event);
}

Re:That explains things (0)

Anonymous Coward | about a year and a half ago | (#43900099)

I think some of your options for mobile web development are jQuery Mobile, Sencha Touch, Appcelerator Titanium, HTML5 Mobile Boilerplate, and a bunch of other stuff.

Here is a slideshow/review you might find useful:

http://www.slideshare.net/stevedrucker/mobile-platforms-19979061 [slideshare.net]

One thing to keep in mind: I don't think any of these tools will give you a true mobile app experience. So if you are looking for that you might want to look into other tools instead.

Re:That explains things (1)

marsu_k (701360) | about a year and a half ago | (#43902769)

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 highway"-type of framework, if you try to work outside the conventions you're just asking for it.

OTOH, if you're familiar with MVC-based frameworks and GUI programming with something like Swing (or any modern GUI toolkit really), you should be able to pick it up fairly quickly, and it offers a quite rich selection of GUI elements one would expect in a mobile device. You can use traditional OOP with subclasses and so on, which can help to make your code more maintainable. And theming with Compass is just great. HTH, HAND.

Re:That explains things (2)

ArcadeMan (2766669) | about a year and a half ago | (#43899551)

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, which means your stupidly low monthly quota gets eaten up by incompetent programmers

The worst is when people a half dozen jQuery plugins on top of jQuery itself. But hey, look, it's amazing when I test all this shit locally on my company-paid-latest-version-iToy!

Re:That explains things (1)

Anonymous Coward | about a year and a half ago | (#43903057)

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 a miracle. Your life sucks around the phone. Why are you so mad at it? "

www.youtube.com/watch?v=16Gcxb-6DNE

Re:That explains things (1)

ArcadeMan (2766669) | about a year and a half ago | (#43906785)

Waiting 2 to 3 seconds is normal. Waiting for 10 seconds or more means the website is bloated.

Re:That explains things (1)

Steve_Ussler (2941703) | about a year and a half ago | (#43910843)

No way,.... If they were correct, they would not post as an AC.

Re:That explains things (2)

Spy Handler (822350) | about a year and a half ago | (#43899535)

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:That explains things (1)

Steve_Ussler (2941703) | about a year and a half ago | (#43910949)

you forgot about Ruby!

Re:That explains things (1)

narcc (412956) | about a year and a half ago | (#43899559)

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.

I'm going to assume that was hipster irony. (0)

Anonymous Coward | about a year and a half ago | (#43899785)

You know the site you just linked requires javascript bloatkits from blogger.com and blogblog.com, right? You're being ironic or something?

Because your point is correct - actually learning a language should let you generate faster and better output than learning some toolkit. But maybe the average jQery user is not actually a programmer? All the people I know who use it are web developers who don't know any programming languages at all, just markup languages.

Re:I'm going to assume that was hipster irony. (1)

unimacs (597299) | about a year and a half ago | (#43900101)

Then you don't know enough people using jQuery. Just because I'm quite capable of writing straight javascript or creating my own library doesn't mean that jQuery doesn't have benefits for programmers. Smart programmers don't reinvent the wheel just because they can.

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 so it doesn't need to be downloaded every time you visit the site.

Re:I'm going to assume that was hipster irony. (2)

narcc (412956) | about a year and a half ago | (#43900403)

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 some simple CSS. The result will be faster, lighter, and easier to maintain. (If you don't understand CSS, there are tons of generators online.)

What about Ajax? Again, vanilla JavaSript is the clear winner. A few lines of simple and easy-to-maintain code is all it takes. As a bonus, your code will be infinitely more readable, and won't break when jQuery makes it's regular set of breaking changes.

Aside from the obvious performance benefits you get from dropping jQuery, you also get MUCH more readable code. Nothing is worse than "optimized" jQuery as far as readability is concerned. Under the unlikely assumption that you actually save time during initial development, you'll easily lose it all maintenance.

What about supporing old browsers? Well, jQuery is dropping support for IE6, 7, and 8. Have fun with that.

Re:I'm going to assume that was hipster irony. (1)

Ash Vince (602485) | about a year and a half ago | (#43900709)

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 PC's are so powerful and underutilized. You can complain about this all you like but you are just pissing into the wind, it will never change now even phones have quad core cpus.

(BTW - I actually think everyone should learn to write more efficient code but am old enough to know that most people who pull the strings don't care.)

Re:I'm going to assume that was hipster irony. (2)

narcc (412956) | about a year and a half ago | (#43900929)

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 "computers are getting super fast" line has always been the cry of lazy and incompetent developers. Don't fall in to that trap!

Writing super efficient code is just not worth wasting time

That's why you should AVOID jQuery! You get a massive performance boost simply by avoiding it! You waste tons of time and effort already trying to get acceptable performance out of jQuery -- which ultimately leaves you with slower, less readable, and less reliable code in the end.

In short: Cutting out jQuery will ultimately save you development time, improve the overall quality of your code, and significantly improve performance. Why would you even bother with jQuery in the first place?

Re:I'm going to assume that was hipster irony. (1)

Ash Vince (602485) | about a year and a half ago | (#43903421)

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 much guaranteed to hate it in that case. You can write beautiful simple jquery if you are careful, like in any language. Once you get used to Jquery you can often find that it is easier to read than the pure JS alternative (see my example above).

Your users care. They care a lot

Most users know fuck all, and even if they do they don't pay the bills in web development, the client does.

That's why you should AVOID jQuery! You get a massive performance boost simply by avoiding it! You waste tons of time and effort already trying to get acceptable performance out of jQuery -- which ultimately leaves you with slower, less readable, and less reliable code in the end.

I have never had any performance issues with the stuff I have been creating, if I did I would dive straight into pure JS to get it done as I have been doing this for a while so can do either. Maybe if you were having Jquery performance issues it was with very old versions or you were not writing decent code?

Re:I'm going to assume that was hipster irony. (0)

Anonymous Coward | about a year and a half ago | (#43906737)

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.

jQuery is written in JavaScript, so it just stuffs the same code into a function. You can write your own function and type far fewer characters too!

Re:I'm going to assume that was hipster irony. (1)

narcc (412956) | about a year and a half ago | (#43907723)

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 that assertion. Very simple tasks take significantly longer in jQuery vs. vanilla JS. You can find any number of performance tests online, or even test for yourself with a profiler. You do use a profiler, don't you? If not, start using one!

Re:I'm going to assume that was hipster irony. (3, Informative)

steveb3210 (962811) | about a year and a half ago | (#43900869)

1. jQuery core is hardly bloated, its 32k.. If you are willing to drop support for older IE, you can use jQuery 2.0 which is even more streamlined than its ever been.

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 .on().. Much of the bad javascript I come across is from people who are trying to write it all themselves and have onclick handlers hard coded into tags in a giant unmaintainable mess. Unobtrusive Javascript is for the win and you'll save yourself alot of headache using jQuery to write it.

Re:I'm going to assume that was hipster irony. (1)

unimacs (597299) | about a year and a half ago | (#43900899)

We use jQuery because it allows us to deliver what our users want in a significantly shorter period of time. Not only they get it sooner, it costs the company less and we can focus on doing things that jQuery doesn't do. Especially in our case since we have a limited set of hardware and browsers to support. Wringing the most speed out of a site that we possibly can isn't necessary.

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 for those things that make the most sense to use it for.

Re:I'm going to assume that was hipster irony. (4, Informative)

Jason Levine (196982) | about a year and a half ago | (#43901113)

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:I'm going to assume that was hipster irony. (1)

narcc (412956) | about a year and a half ago | (#43901593)

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 that it may have had in the past. You don't want to see your favorite "tool" die, so you feel the need to protect it from reality.

jQuery has promised, but never safely delivered cross-browser support. With 2.0, it gave up on that goal entirely. Besides, once you drop support for IE6, there's very little you need to do to maintain cross-browser compatibility. So little, in fact, that using jQuery actually *increases* the amount of work you need to do as you get to deal with cross-browser problems in jQuery and cross-jQuery problems with your plugins!

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

For some reason, you mentioned writing reusable functions as a benefit of using jQuery. Using jQuery guarantees that your code will not be reusable. Sure, you can refuse to upgrade and artificially extend the life of your code, but you'll inevitably end up maintaining multiple jQuery versions, eventually loading multiple versions of jQuery on the same page! (If you use a lot of plugins, things will go to hell even faster...)

Think I'm joking? It's such a common problem that jQuery includes features to help you cope with it's instability (see: noConflict). There are a host of tools (like jQuery Quarantine [github.com] ) to help you manage the hell that you created because you swallowed a load of nonsense about a crummy library back in 2006. Er, sorry, read that as "thought you could save some time by using a popular library."

You could wind up essentially rewriting it, but chances are it won't be shorter/more efficient.

That's just absurd. jQuery primarily consists of functions that are common across browsers, wrapped in an incredibly inefficient library. It's primary (and only useful) feature was its selector engine, but that hasn't been an advantage for a very long time now. Once you learn more about JavaScript and the DOM, you'll realize how little jQuery actually offers you.

This is all off-topic. My original point was that jQuery Mobile is best avoided as it's too slow. (No surprise, no one is willing to defend THAT mess!) This turned in to "defend jQuery against the unbelievers!" thread, which I'm rapidly losing interest in.

Re:I'm going to assume that was hipster irony. (1)

nullchar (446050) | about a year and a half ago | (#43904971)

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:That explains things (1)

Dracos (107777) | about a year and a half ago | (#43900149)

JQuery Mobile is ridiculously slow.

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 (3, Interesting)

steveb3210 (962811) | about a year and a half ago | (#43900797)

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:That explains things (1)

drerwk (695572) | about a year and a half ago | (#43903419)

I like that: re-event the wheel. I'll see if I can't use that in my next jqm ui presentation.

Re:That explains things (0)

Anonymous Coward | about a year and a half ago | (#43904085)

I've had to write dynamic DOM manipulation for form pages that were pretty simple. The original developer used vanilla JS to provide this functionality. 60-80 line methods to do really simple crap. I rewrote those methods since they weren't bug free with jQuery. Usually they were around 10 lines.

Re:That explains things (1)

Steve_Ussler (2941703) | about a year and a half ago | (#43911041)

don't be a showoff@!

Re:That explains things (4, Interesting)

K. S. Kyosuke (729550) | about a year and a half ago | (#43899873)

No, it's because of the whole WWW thingy. Virtually all the functionality you get in the HTML+JS combo was runnable on a 1990's Macs in HyperCard. Your portable device is actually an order and a half of magnitude faster than what it would need to be if you didn't have all the intermediate layers in the SW stack.

"virtually" (0)

Anonymous Coward | about a year and a half ago | (#43900717)

I mean... pretty much... Well, maybe not support for PNGs with true-alpha opacity... Or web-workers... Or any number of other features that you probably don't actually know anything about

I used HyperCard. A lot. And what you just said is truly silly.

Re:"virtually" (1)

K. S. Kyosuke (729550) | about a year and a half ago | (#43901141)

Tell that to the VPRI people, if you consider them silly. They're essentially doing what you've just described. Except those Web Workers, *those* are really silly. That's exactly one of those extra layers, replicating an OS in your browser.

Appeal to authority, awesome (1)

Anonymous Coward | about a year and a half ago | (#43902525)

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, including HyperCard, would be the property of a wholly owned subsidiary called Claris.
>>...Claris, in the business of selling software for a profit, attempted to create a business model where HyperCard could also generate revenues. They wrote a new "viewer only" version, the HyperCard Player which Apple distributed with the Macintosh operating system, while Claris sold the "full" version commercially.

I've met people like you who say "oh this is just HyperCard" without knowing what they're actually talking about. The low level language stuff wasn't even baked in until the 2000s. It's just obvious by the simple wrongness of your statement that your casual dismissal of HTML and JavaScript is rooted in ignorance. The people that modded you up should be embarrassed.

Re:Appeal to authority, awesome (1)

K. S. Kyosuke (729550) | about a year and a half ago | (#43903261)

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 end of the 1980's. It sure isn't a step forward today. It's only useful because most other things are even worse, not because it's somehow intrinsically good, for many values of "good".

Re:That explains things (0)

Anonymous Coward | about a year and a half ago | (#43900187)

This. Developers are so obsessed with making things pretty that they forget to make them usable. Frameworks like these are designed to make it easy to gobble up all the power available to you, and devs need to start being competent about their use of that power.

Woe be to the dev who's competent enough to write their own framework, however. jQuery is basically the linga franca of the inept web developer world: it does everything for them, so they don't have to know their trade. Forget the fact that it's a bloated mess unfit for mobile or low performance devices (even jQuery 2). And that's just jQuery. Try an even more bloated library :S

Re:That explains things (1)

foo4thought (681400) | about a year and a half ago | (#43905407)

You could be describing the linked article or m.slashdot.org itself, which is agonizingly slow and unusable on my old iPhone.

Re:That explains things (1)

Steve_Ussler (2941703) | about a year and a half ago | (#43910805)

And how does that deal with the book?

Is it because I am old? (1)

wonkey_monkey (2592601) | about a year and a half ago | (#43899771)

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 (1)

jtara (133429) | about a year and a half ago | (#43900637)

" 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 server running on the device, but even if no server, you are typically serving pages out of a local (device) filesystem. The "slow link" problem goes away.

Then, it can also depend on what technology you are using to create a hybrid app. PhoneGap apps are typically programmed mostly in Javascript, possibly using native extensions. Rhodes apps, for example, are typically written mainly in Ruby, with JS for front-end only. Depite Ruby's reputation for being "slow", you can typically build a webpage in Ruby (in Rhodes) more quickly than you can on client-side, say, from JSON data, and using templates or ad-hoc code.

jQuery Mobile tries to work in all of these environments, and so isn't optimized for any one of them. You have to know which pieces to use in which environment.

It doesn't help that most developers seem to treat jQuery Mobile development like they do all JS development - as cut-and-pasted snippets to be copied from blog posts and samples. Most don't seem to bother to read the documentation, let alone learn what parts are efficient and which are not.

There are two mistakes that are the most common cause of JQM project failure - using IDs (a problem because JQM loads "pages" into the document, and if one builds a JQM site without thinking, one will wind-up with duplcate IDs in the DOM, and this is not allowed in HTML and will give unpredicatable - but almost always wrong - results. Yes, it's 2013, and HTML does not deal with "pages" at all, and so JQM and others have had to come up with hacks). The other is creating a site/app using the "multi-page" feature, which is very limiting, because your entire site must fit in one document. But developers don't bother to read the docs, and then don't understand why they can't link from a single-page document to a multi-page document. (Because it's not designed to be used that way!) Both mistakes are easily fixed at almost no cost, if you deal with it from day 1, and become prohibitively expensive once you have built-out a full site while sweeping the problems under the rug.

On the JQM support forum, probably half the problems posted are due to one or both of these issues. And the developers are quite stubborn once told that their approach won't work. They insist they have to use IDs, because "classes are two slow", and that they need a multi-page "because I want page switching to be fast".

I'd rather have a site that actually works, myself, than one that doesn't work, but is marginally faster than one that does. And multi-page isn't needed to cache pages in the document and/or pre-fetch pages. Multi-page does nothing that can't be done with single-page and some options, but it does bring with it a maintainence headache. (As does the use of IDs.)

It is true that the documentation stinks, and has only gotten worse. So, there certainly is a need for a good book or two.

Frist \5top (-1, Troll)

Anonymous Coward | about a year and a half ago | (#43899865)

EFNet servers. members all over Around are in need there are dying. See? it's Become obsessed it a break, if During which I had at lunchtime

*Shudder* (3, Insightful)

guruevi (827432) | about a year and a half ago | (#43900011)

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:*Shudder* (1)

Anonymous Coward | about a year and a half ago | (#43900169)

"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:*Shudder* (1)

BurfCurse (937117) | about a year and a half ago | (#43900501)

"If your site doesn't work with JavaScript disabled, then it's a bad site" No its not. Its just a site that has accepted that it may have alienated a certain percentage of potential users. For many websites, that percentage of their customer base can be extremely small and have decided a degraded experience isn't worth it. The rest potentially benefit from a better user experience.

Re:*Shudder* (4, Informative)

josh12358132134 (2725235) | about a year and a half ago | (#43900521)

You may want to consider coming into the modern decade of web development; it is not the early 2000s anymore. Business logic has been rapidly shifting from server-side technologies into Javascript.

Re:*Shudder* (0)

Anonymous Coward | about a year and a half ago | (#43900743)

what happened to my battery life?

Re:*Shudder* (0)

Anonymous Coward | about a year and a half ago | (#43900841)

Get a bigger battery you crybaby.

Re:*Shudder* (1)

Alex Baron (2922485) | about a year and a half ago | (#43901809)

I'll just put one into my iPhone. oh wait....

Re:*Shudder* (1)

SwedishPenguin (1035756) | about a year and a half ago | (#43904965)

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:*Shudder* (0)

Anonymous Coward | about a year and a half ago | (#43900891)

Not only that, friend, but if want to anything half way interesting on a mobile device from a web back end, like GPS, local storage, etc., you will be embracing js. Yea, you could do an app, but not every web experience necessitates jumping through those hoops.

Re:*Shudder* (0)

Anonymous Coward | about a year and a half ago | (#43900759)

Seriously dude it's 2013. Who doesn't have access to a browser that can read JS? I'm sorry if you can't parse my website on your Commodore.

Re:*Shudder* (1)

guruevi (827432) | about a year and a half ago | (#43902497)

Ever heard of blind people?

Re:*Shudder* (1)

Shados (741919) | about a year and a half ago | (#43900777)

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 design products with. Then we had to take it and make it mobile. What else do you want us to do? Use Flash? put a phone number and ask users to call us and tell us verbally what they want to be made?

Now, for that to work they have to have javascript enabled. If they're going to be required to have scripts enabled anyway, may as well make the site feel a bit more native... And the site still pops up as #1 for countless common search terms, so....

Re:*Shudder* (0)

Anonymous Coward | about a year and a half ago | (#43903081)

the platforms that don't have perfect JS support such as machines (Google...

Googlebot has had the ability to execute Javascript for almost a decade now.

Packt is back! (0)

Anonymous Coward | about a year and a half ago | (#43900761)

Packt Publishing. FUCK YEAH!

And so began the great jQuery wars of 2013. (1)

rok3 (1133003) | about a year and a half ago | (#43901747)

*breaks out the beer and popcorn*

Javascript needs to die (1)

XcepticZP (1331217) | about a year and a half ago | (#43903719)

Please can we just get over this whole javascript fad? It's clunky, odd to use, and non-standard from the times I've used it. Replace it with a real programming language such as Python, which is vastly superior to javascript. Or better yet, allow website developers to use both so we can have language competition driving simplicity, functionality and leanness instead of bloat and that awful thing we call javascript syntax.

Re:Javascript needs to die (1)

Steve_Ussler (2941703) | about a year and a half ago | (#43911057)

no way!
Check for New Comments
Slashdot Login

Need an Account?

Forgot your password?