Please create an account to participate in the Slashdot moderation system

 



Forgot your password?
typodupeerror
Books Book Reviews

Book Review: Creating Mobile Apps With JQuery Mobile 91

Posted by samzenpus
from the read-all-about-it dept.
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.
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.
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.
This discussion has been archived. No new comments can be posted.

Book Review: Creating Mobile Apps With JQuery Mobile

Comments Filter:
  • by Anonymous Coward on Monday June 03, 2013 @03:01PM (#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.

    • by Anonymous Coward

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

    • by h4rr4r (612664) on Monday June 03, 2013 @03:21PM (#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.

      • by Krojack (575051)

        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.

        • by h4rr4r (612664)

          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.

          • by Krojack (575051)

            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.

            • by h4rr4r (612664) on Monday June 03, 2013 @03:53PM (#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.

              • by Ash Vince (602485) *

                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

                • by narcc (412956)

                  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

                  • by Ash Vince (602485) *

                    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.

                    • by narcc (412956)

                      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

              • 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

              • by narcc (412956)

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

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

              • by Krojack (575051)

                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.

          • by JaredOfEuropa (526365) on Monday June 03, 2013 @04:52PM (#43900275) Journal
            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.
            • by noh8rz10 (2716597)
              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!
            • by i.r.id10t (595143)

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

          • Plenty of 3rd world countries have low bandwith. Web 2.0 is still very relevent there.
        • 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).

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

            • by oever (233119)

              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.

              • 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]

                • by oever (233119)

                  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)

        • by marsu_k (701360)

          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

      • 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

        • by Anonymous Coward

          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

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

      • No way,.... If they were correct, they would not post as an AC.
    • 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

    • by narcc (412956)

      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

      • by Dracos (107777)

        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.

      • by steveb3210 (962811) on Monday June 03, 2013 @06:23PM (#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...

    • by K. S. Kyosuke (729550) on Monday June 03, 2013 @04:07PM (#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.
    • You could be describing the linked article or m.slashdot.org itself, which is agonizingly slow and unusable on my old iPhone.

    • And how does that deal with the book?
  • Interested parties should also check out Build Mobile Websites and Apps for Smart Devices [sitepoint.com].

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

    • " 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)

    by guruevi (827432) <evi@smok[ ]cube.be ['ing' in gap]> on Monday June 03, 2013 @04:21PM (#43900011) Homepage

    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.

    • by Anonymous Coward

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

    • by BurfCurse (937117)
      "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* (Score:4, Informative)

      by josh12358132134 (2725235) on Monday June 03, 2013 @05:34PM (#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.
    • by Shados (741919)

      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

  • *breaks out the beer and popcorn*
  • 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.

A computer lets you make more mistakes faster than any other invention, with the possible exceptions of handguns and Tequilla. -- Mitch Ratcliffe

Working...