IOS devices (iPods, iPads, iPhones) have no JavaScript debugger



  • iOS devices (iPods, iPads, iPhones) have no JavaScript debugger and no way of enabling remote debugging.

    If this was a brand-new thing, like if it had come out last year, I'd be like: "oh, ok. Apple just hasn't gotten around to finishing the debugger yet, I'm sure it'll be around soon." But no. iPhones have been around for almost 5 years now.

    Hell, the original iPhone concept is that you wouldn't need "apps" because you could just write your software using HTML+JavaScript. That's great, Apple, but how the holy shit are we supposed to do that without a JavaScript debugger!?

    Sorry there's no images or anything; we just got a client who wants to see our product run on iPads, and I was like, "sure, it's written in standards compliant JavaScript and should work fine in any browser." Turns out: nope. Also turns out: Safari runs it fine, so whatever the bug it only happens in iOS devices. So no, using Safari to debug is not useful. If you were about to suggest that. It pissed me off, so here's the post.

    I talked to a friend of mine who works at Apple, and he said, "send me the code, and I can give it to some WebKit people." Right. Because that's an acceptable solution. Idiots.



  • This implies that there's a good way to debug JavaScript on Windows.  My experience lately suggests otherwise.  (Specifically, when running JavaScript scripts without a HTML/browser context.)  If you know how to set it up, please see this question on StackOverflow and claim some reputation points.



  •  Consumer devices have no use for a javascript debugger, really.  That said some type of Safari-on-iOS emulator for a Mac desktop makes a ton of sense.



  • @Mason Wheeler said:

    This implies that there's a good way to debug JavaScript on Windows.

    No it doesn't, you're just fucking hijacking my thread for your own pet issue because you're too fucking cowardly to make your own.

    @Master Chief said:

    Consumer devices have no use for a javascript debugger, really. That said some type of Safari-on-iOS emulator for a Mac desktop makes a ton of sense.

    There's a "simulator", but the problem is:

    1) There's no Macs around here, and the client already balked when we charged them for the iPad. (Yes, I know, the Real WTF is that I work at a web company that doesn't have 57,000 Apple iDevices sitting all around.)

    2) The "simulator" probably wouldn't exhibit the bug, since desktop Safari also doesn't exhibit the bug. It's not an emulator-- it doesn't act the same as an actual iPad.

    3) Any software program that can be programmed needs a fucking debugger. Raise your fucking standards and stop putting up with shitty software. It's in-fucking-excusable for Apple to not offer a JavaScript debugger for iOS' Safari, even though I'm sure I'm going to get 57,000 idiotic replies to this topic telling me I'm wrong for 57,000 different idiotic reasons, all of which sum to: "because I don't give a shit."

    And just to stave off the next idiotic post, "herp derp how do you put a JS debugger on such a tiny screen derp derp derp," I'm not asking for a local debugger, I'm asking for any debugger.



  • @Master Chief said:

     Consumer devices have no use for a javascript debugger, really.

    wat

    Are you perhaps saying that they're unnecessary due to emulators? EDIT: which apparently don't exist for iOS mobile devices?

    @blakeyrat said:

    I'm not asking for a local debugger, I'm asking for any debugger.

    Zune devices have a remote debugger through VS. It takes like 5 minutes to load the context after hitting a breakpoint but it's pretty nice. No reason for Apple to not provide one for their mobile version of Safari.



  • @blakeyrat said:

    iOS devices (iPods, iPads, iPhones)
    I found your problem.

    Am I the only one who thinks that our profession would benefit greatly if Apple were to suddely disappear off the face of the earth? In this day and age of PCs, Windows, Linux and Android do we really need these greedy assholes and their shitty vendor lock-in crap?

    The only thing I appreciate about Apple is the fact that they've chosen to have their phones automatically encode current GPS coordinates in the photographs they take so I can feak out their fanboys by "hacking" their location.



  • A hacky round-about way (but allows you to use the native Webkit debugger! :D) is this:

    http://atnan.com/blog/2011/11/17/enabling-remote-debugging-via-private-apis-in-mobile-safari/

    Works in iOS 5. I'm trying to see if it will work on the device.. but it's still exactly what is needed.



  • That states it only works on the simulator.

    Also, pretty much that exact technique is outlined here, but of course, again, it doesn't work on the actual iPad.



  • However, with the link I provided.. it would be able to be ran in the Simulator, which should behave identically (although much faster) than the device.


    The original post only indicates that he tried it out in normal Safari, which does use a different JS engine. Simulator MobileSafari should behave like device MobileSafari.

    Also, trying it on a device.. It should work in a custom webView that's programmed, so long as that method is called. I tried to get it to work on the device, but the version of GDB that I have on my JB iPhone doesn't seem to have the debug symbols that it needs.



  • Well I also don't have a Mac, so whatever.

    For all practical purpose, it doesn't goddamned exist.



  • Apparently Android is in much the same boat. Hence, this thread is excellent because (a) most of the people replying fail at basic comprehension skills (b) I now have a valid reason to tell my employers that I will not develop webapps for a portable device, and if they have a problem with that, they can write their own damn JS debugger for said device and get back to me.

    Seriously what is this shit? Who in their right mind would think it's acceptable to ship ANY browser without JS debugging support? Especially on a portable device where the JS implementation is almost guaranteed to be nonstandard and buggy?



  •  It's not perfect, but iOS does indeed have a Javascript debugger, I've used it before myself. It's basically on a par with the IE Javascript debugger though.

    Interestingly, if you Google for "ipad javascript debugger", the first result is to a question on StackOverflow, and the only answer is a link to a graphical guide on how to enable it. I'd say that the real WTF is the Blakeyrat doesn't know how to use a search engine.



  • @Master Chief said:

    Consumer devices have no use for a javascript debugger, really.

    No, but developers do.

    In the same way that most end-users have no use for Javascript debuggers in their browsers, Firebug/WebDev Toolbar etc are still pretty popular plugins (amongst the dev community).

    TL;DR: "there's an app for that..." "er, no there isn't."



    1. Sucky troll is sucky.
    2. That's an error console, not a debugger. If you think the two are the same thing, you evidently fall into the same camp as the creators of iOS and Android... which incidentally means you should die in a fire.


  • It is called a debugger, not an error console. I didn't say it was a good debugger (quite the opposite in-fact). I call you on your 'sucky troll' and raise you by one 'dumbass who cannot read troll'



  • @The_Assimilator said:

    2. That's an error console, not a debugger. If you think the two are the same thing, you evidently fall into the same camp as the creators of iOS and Android... which incidentally means you should die in a fire.

    Well.. luckily I know the difference between Firefox's "Error Console" and a plugin called Firebug - I can certaily say they're not the same thing.

    Or are you of the opinion that FireBug/web dev toolbar aren't "proper" debuggers? Although I use them for (rudimentary) debugging, I'll concede the point that they lack functionality found in more full-blown IDEs.



  • Nothing like some good old fashioned printf style debugging!



  • @boomzilla said:

    Nothing like some good old fashioned printf style debugging!
     

    You mean, there's another way?



  • There's many ways to write "Got Here (1)!" to the screen. Let your imagination run wild!



  • @blakeyrat said:

    2) The "simulator" probably wouldn't exhibit the bug, since desktop Safari also doesn't exhibit the bug. It's not an emulator-- it doesn't act the same as an actual iPad.
    Really? probably wouldn't. Really?

    I am trying to think of more to say, but really, you didn't try the simulator before complaining here? Really?



  • @blakeyrat said:

    There's a "simulator", but the problem is:

    1) There's no Macs around here, and the client already balked when we charged them for the iPad. (Yes, I know, the Real WTF is that I work at a web company that doesn't have 57,000 Apple iDevices sitting all around.)

    IMO, having to buy the device for testing is retarded.  They should have a proper dev environment done up for it.

    @blakeyrat said:

    2) The "simulator" probably wouldn't exhibit the bug, since desktop Safari also doesn't exhibit the bug. It's not an emulator-- it doesn't act the same as an actual iPad.

    Then it's pointless on it's face, what the hell is the point of simulating if it's not the same as what it's simulating?  Might as well train airliner pilots in a helicopter simulator, since they're kinda the same.

    @blakeyrat said:

    3) Any software program that can be programmed needs a fucking debugger. Raise your fucking standards and stop putting up with shitty software. It's in-fucking-excusable for Apple to not offer a JavaScript debugger for iOS' Safari, even though I'm sure I'm going to get 57,000 idiotic replies to this topic telling me I'm wrong for 57,000 different idiotic reasons, all of which sum to: "because I don't give a shit."

    Again, I agree, but it doesn't have to be in the device.  Then it's just deadweight code that almost every consumer of said device will never use.  If Apple and Google are serious about getting these kinds of cloud apps working on their mobiles than they should be providing proper development tools.  But I suppose it's easier to garner more sales of the devices from web shops trying to work around their weird ass browser quirks (that's actually probably exactly what it is).

    @blakeyrat said:

    And just to stave off the next idiotic post, "herp derp how do you put a JS debugger on such a tiny screen derp derp derp," I'm not asking for a local debugger, I'm asking for any debugger.
     

    Again, it's deadweight to most users, on devices that are already typically low on power (for good reason).  Everything on a mobile platform has to be put against what it will do to battery life, screen space, user experience, performance overall, etc.

    Same reason you don't put Media Player on Windows-based car computers.  There's no point, it'l never get used.

     



  • @ASheridan2 said:

     It's not perfect, but iOS does indeed have a Javascript debugger, I've used it before myself. It's basically on a par with the IE Javascript debugger though.

    Interestingly, if you Google for "ipad javascript debugger", the first result is to a question on StackOverflow, and the only answer is a link to a graphical guide on how to enable it. I'd say that the real WTF is the Blakeyrat doesn't know how to use a search engine.

    I followed those steps and found the website in question. Then I nearly fell out of my chair. Nice one.

    @Master Chief said:

    Again, it's deadweight to most users, on devices that are already typically low on power (for good reason).  Everything on a mobile platform has to be put against what it will do to battery life, screen space, user experience, performance overall, etc.

    Same reason you don't put Media Player on Windows-based car computers.  There's no point, it'l never get used.

     

    Did you miss this?

    @blakeyrat said:

    I'm not asking for a local debugger, I'm asking for any debugger.

    Windows provides a remote debugger for Zune apps, it's quite good. Battery life isn't an issue because the device is connected via USB to the workstation running the debugger. Screen space isn't an issue because the debugging data is transferred to the workstation running the debugger. The user experience isn't affected because you have to enable developer options on the device. Performance overall isn't an issue because you're debugging and low performance is expected, and the results of said debugging will probably increase the performance of the debugee. All those things you listed are the responsibility of the developer creating apps, they are not important considerations when developing features for developers on your platform to use.



  • @Master Chief said:

    @blakeyrat said:

    1) There's no Macs around here, and the client already balked when we charged them for the iPad. (Yes, I know, the Real WTF is that I work at a web company that doesn't have 57,000 Apple iDevices sitting all around.)


    IMO, having to buy the device for testing is retarded.  They should have a proper dev environment done up for it.

    They do. On a Mac. Don't try to dictate your bullshit crazy ass ideas about what should be able to interoperate with their devices.

    Have you not been able to get Firebug Lite to work?



  • Dear God, every reply is somehow dumber than the one that came before it. Ok, in order:

    @ASheridan2 said:

    Interestingly, if you Google for "ipad javascript debugger", the first result is to a question on StackOverflow, and the only answer is a link to a graphical guide on how to enable it. I'd say that the real WTF is the Blakeyrat doesn't know how to use a search engine.

    That's not a JavaScript debugger, that's an error console. As I posted on Twitter, when the same kind of retarded replies were coming in: "console.log() is indeed useful, but it's not a JavaScript debugger".

    @ASheridan2 said:

    It is called a debugger, not an error console.

    I don't give a shit what it's called, what it is is not a debugger.

    @Rick said:

    I am trying to think of more to say, but really, you didn't try the simulator before complaining here? Really?

    Correct. I already explained why, I suggest you scroll up and actually read the fucking thread this time, then come back here and not be dumb, thank you.

    @Master Chief said:

    IMO, having to buy the device for testing is retarded. They should have a proper dev environment done up for it.

    Who is "they?" If you mean my company, then I agree. If you mean the client, then no I wouldn't expect that of them. Their site uses virtually no JavaScript, and the script on there is trivial analytics stuff, easy "debugged" using console.log() or from the server-side.

    @Master Chief said:

    Then it's pointless on it's face, what the hell is the point of simulating if it's not the same as what it's simulating?

    It still helps with things like getting the screen layout correct, previewing your animations, etc. Just because a simulator is useless for debugging JavaScript doesn't mean it's useless for all purposes.

    And of course, even if it were a proper emulator, it'd still need a JavaScript debugger! A perfect emulation wouldn't let me do any more than confirm the bug exists if I couldn't set breakpoints and walk through the code. So I see the whole simulator thing as a pointless aside here, the real issue is that iOS devices have no JavaScript debugger.

    @Master Chief said:

    Again, I agree, but it doesn't have to be in the device. Then it's just deadweight code that almost every consumer of said device will never use.

    Read the thread; it's already IN the device (as a built-in WebKit feature), there's just no way to activate it. And next time I see someone complaining about 20k of code on a device that ships with 16 GB of storage, I swear I will bust some skulls-- get a fucking sense of PERSPECTIVE for Christ's sake.

    @Master Chief said:

    If Apple and Google are serious about getting these kinds of cloud apps working on their mobiles than they should be providing proper development tools.

    But you just said they shouldn-- fuck it, next stupid post.

    @boomzilla said:

    Have you not been able to get Firebug Lite to work?

    Why would it matter if I did, since FIREBUG LITE IS NOT A FUCKING JAVASCRIPT DEBUGGER what the fuck is wrong with you people, how fucking stupid can this thread possibly get this is reducing me to a gibbering moron holy shit did you even bother to check if firebug lite was a javascript debugger before posting or does bullshit like that just dribble out of your brain through your ears...

    You know what? After this, I need some intelligent conversation. Hello cat. How are you. Meow? Yes, that's the smartest thing I've heard all morning. Here's some fancy feast as a reward.



  • @blakeyrat said:

    Why would it matter if I did, since FIREBUG LITE IS NOT A FUCKING JAVASCRIPT DEBUGGER what the fuck is wrong with you people, how fucking stupid can this thread possibly get this is reducing me to a gibbering moron holy shit did you even bother to check if firebug lite was a javascript debugger before posting or does bullshit like that just dribble out of your brain through your ears...

    Sorry. I've never used it and didn't realize how limiting it was. Mea culpa. Sort of like you didn't realize how limited your capabilities would be when trying to develop anything for an Apple product without having the full shebang of an Apple development stack. I mean, how much of a drooling ignoramus do you need to be to think you could do anything on an Apple platform on the cheap? Man, if I worked for a company that was that clueless, I'd totally quit in like three seconds. Why are you still there?



  • @boomzilla said:

    Sorry. I've never used it and didn't realize how limiting it was. Mea culpa. Sort of like you didn't realize how limited your capabilities would be when trying to develop anything for an Apple product without having the full shebang of an Apple development stack. I mean, how much of a drooling ignoramus do you need to be to think you could do anything on an Apple platform on the cheap? Man, if I worked for a company that was that clueless, I'd totally quit in like three seconds. Why are you still there?

    Dude, I JUST replied about how dumb your post is, and you responded with the dumbest thing yet.

    EVEN IF I HAD THE APPLE TOOLS, THERE IS NO JAVASCRIPT DEBUGGER ON iOS DEVICES. It doesn't matter if I have Microsoft tools, Apple tools, or God's Own Hand to guide me, there's NO JAVASCRIPT DEBUGGER ON iOS DEVICES.

    Are we clear now? Or do you have more retard "thoughts" to share with the group? Rub those two neurons together, I'm sure they'll shit out something new!



  • @blakeyrat said:

    It doesn't matter if I have Microsoft tools, Apple tools, or God's Own Hand to guide me
    Not true. As you said yourself, if you had a Mac, you'd be able to run the emulator.  The problem is that you don't have the right hardware.  You can continue to bitch like the little bitchy bitcher you are, or you can talk to management and try to aquire a Mac somehow to run the emulator.  How fucking stupid are you?



  • You have to be pretty fucking new to the internet to go around telling a client that it "should work" in a particular browser without testing the hell out of it first. I'd barely trust an alert() function call on another browser without testing it.



  • @C-Octothorpe said:

    Not true. As you said yourself, if you had a Mac, you'd be able to run the emulator.

    That doesn't exist. So, no, I would not be able to run the imaginary thing.

    And, as I explained above, even if an emulator did exist, it would still be useless for my purposes without a JavaScript debugger.

    @C-Octothorpe said:

    How fucking stupid are you?

    Based on this thread? Well above average.



  • @C-Octothorpe said:

    if you had a Mac, you'd be able to run the emulator.
     

    And do what?



  • @db2 said:

    You have to be pretty fucking new to the internet to go around telling a client that it "should work" in a particular browser without testing the hell out of it first. I'd barely trust an alert() function call on another browser without testing it.

    You bring up a fair point that is not stupid. Congratulations.

    But when I'm writing stuff here, remember I'm trying to make it entertaining, I'm not giving a literal transcript of what exactly I said... hell I don't remember what exactly I said.



  • @blakeyrat said:

    But when I'm writing stuff here, remember I'm trying to make it entertaining, I'm not giving a literal transcript of what exactly I said... hell I don't remember what exactly I said.
     

    We didn't assume you were being literal, we assumed you were paraphrasing. But even paraphrasing, you're basically saying that you told the client it should work without testing it on the device it was meant to run on. Nice one idiot. At least fools like you keep us professionals in a job.

     



  • @blakeyrat said:

    @C-Octothorpe said:
    Not true. As you said yourself, if you had a Mac, you'd be able to run the emulator.
    That doesn't exist. So, no, I would not be able to run the imaginary thing.

    And, as I explained above, even if an emulator did exist, it would still be useless for my purposes without a JavaScript debugger. @C-Octothorpe said:

    How fucking stupid are you?
    Based on this thread? Well above average.
    Based on the comments above (there were a few posters mentioning an emulator), it seemed like there is a debugger in the Safari emulator, but you need a Mac to run it, which you don't have.  My bad, I should've done some fact checking before doing a blackeyrant of my own.



  • @ASheridan2 said:

    Nice one idiot.

    Aw! I hurt his little feelings by calling his post dumb and now he's trying to hurt me right back! It's almost cute.

    @ASheridan2 said:

    At least fools like you keep us professionals in a job.

    And how do you "professionals" debug JavaScript on iOS devices? Oh wait, I guess "professionals" are the ones who are perfectly fine with the absolutely shitastic status quo-- which makes me proud to not be one. Stupid me; I'd assume "professionals" would demand professional tools like, say, debuggers.



  • I wasn't trying to hurt you, that was just a nice bonus. Thing is, when I was debuggin, rather than complain about lack of tools, I used the debugger in the iPad to find out what it though were errors in my code. You can call it what you want, that doesn't mean it's not a debugger. It's not a great one, but it is better than nothing. You're meant to be a human being aren't you? One of the defining bloody characteristics is that we can learn and adapt. I'm sorry that you're not spoilt for choice when you're developing for iOS, but them's the breaks, so suck it up and do what you can with what you've got. Everytime you come on here ranting about something you just come across as a little kid who's only just about been pulled away from his mothers skirts.

    Now if other developers can manage to write code for iOS and you can't, where's the problem? I'll give you a clue, you need to look a little closer to home.



  • @ASheridan2 said:

    I wasn't trying to hurt you, that was just a nice bonus. Thing is, when I was debuggin, rather than complain about lack of tools, I used the debugger in the iPad to find out what it though were errors in my code. You can call it what you want, that doesn't mean it's not a debugger. It's not a great one, but it is better than nothing. You're meant to be a human being aren't you? One of the defining bloody characteristics is that we can learn and adapt. I'm sorry that you're not spoilt for choice when you're developing for iOS, but them's the breaks, so suck it up and do what you can with what you've got. Everytime you come on here ranting about something you just come across as a little kid who's only just about been pulled away from his mothers skirts.

    Now if other developers can manage to write code for iOS and you can't, where's the problem? I'll give you a clue, you need to look a little closer to home.

    What if there's no error, but the browser is executing the Javascript in a non-standard fashion, resulting in undesired consequences? Your "debugger" doesn't help in that case, whereas a proper debugger would.



  • @lettucemode said:

    What if there's no error, but the browser is executing the Javascript in a non-standard fashion, resulting in undesired consequences? Your "debugger" doesn't help in that case, whereas a proper debugger would.
     

    Yeah, because heaven forbid we actually think outside the box a little and add a few output messages here and there to act as manual breakpoints.

    Sure, it's not the nicest of ways to debug, but it would have stopped blakey from giving the customer something that didn't even work.

     



  • @ASheridan2 said:

    You can call it what you want, that doesn't mean it's not a debugger
     

    Dunno, but when I say "debugger" I mean a thing that allows you to set breakpoints, step around in code and watch variables at the least.

    An error console is already 500% more helpful than nothing at all, but if your javascript application is complex, I really think a debugger is a minimal requirement, much like page inspectors are a minimal requirement for successful HTML/CSS development, and it's perfectly fine to complain about the lack of one.



  • And if the bug is in a click handler on a link? Or a form validator? Or in the beforeunload handler? What do you "professionals" do then?



  • @blakeyrat said:

    And if the bug is in a click handler on a link? Or a form validator? Or in the beforeunload handler? What do you "professionals" do then?

    My first comment tells you what to do. You put in statements that firstly tell you whether a certain bit of code is even being reached. Then, you can find out if its some weird data or what that's going on. Essentially, you're logging stuff to the console (or putting in alerts, or whatever) and making inferences based on that.

    It's not totally different than using a stepping debugger, but it can take a lot more time and effort, since you typically end up modifying your output and rerunning as you learn little bits and zero in on the problem bit of code. I have no clue what your stuff does or looks like, but isn't this sort of thought process debugging 101?



  • @ASheridan2 said:

    Yeah, because heaven forbid we actually think outside the box a little and add a few output messages here and there to act as manual breakpoints.

    Sure, it's not the nicest of ways to debug, but it would have stopped blakey from giving the customer something that didn't even work.

     

    It's not just "not the nicest of ways to debug", it's the obsolete way to debug because of debuggers. You can't step line-by-line and watch variables using output messages unless you place one after every line which prints each variable to the output window. It's tedious, time-consuming, and is only as good as the time you put into it. Those are exactly the problems that debuggers were created to solve.

    Saying that debuggers aren't necessary because of alert() is similar (not the same, but similar) to saying that DirectX isn't necessary because graphics cards have instruction sets anyway, or XML parsers aren't necessary because you can read it line-by-line yourself. You're technically correct, but c'mon. It's 2012.



  • Then break the test down further to determine where the bug is. Can the function you're calling be triggered by some other means? Can you use that event handler to trigger the simplest bit of code? I don't think this is complicated stuff I should have to explain to a developer.



  • @ASheridan2 said:

    Then break the test down further to determine where the bug is. Can the function you're calling be triggered by some other means? Can you use that event handler to trigger the simplest bit of code? I don't think this is complicated stuff I should have to explain to a developer.

    You're not.  Everybody (ok, most devs) knows how to put in print statements.  The point that blakey, lettuce, et al. are making is that it's slow and time-consuming, which is why debuggers were created in the first place.



  • @lettucemode said:

    It's not just "not the nicest of ways to debug", it's the obsolete way to debug because of debuggers.

    Except on awesome platforms like iOS, apparently!



  • @Sutherlands said:

    @ASheridan2 said:

    Then break the test down further to determine where the bug is. Can the function you're calling be triggered by some other means? Can you use that event handler to trigger the simplest bit of code? I don't think this is complicated stuff I should have to explain to a developer.

    You're not.  Everybody (ok, most devs) knows how to put in print statements.  The point that blakey, lettuce, et al. are making is that it's slow and time-consuming, which is why debuggers were created in the first place.
    Which is a valid argument and should be addressed, but in the end, doesn't get him anywhere.  It's just another form of procrastination, IMO.

    Doing it that way is slow and tedious, but is probably the only way it'll get done, which I'm sure he knows and will have to resort to anyway.



  • @Sutherlands said:

    The point that blakey, lettuce, et al. are making is that it's slow and time-consuming, which is why debuggers were created in the first place.

    Well, except that blakey's histrionics asking what a "professional" would do imply that he can't figure it out. To take his posts at face value, he'd rather make empty promises than figure out how to deliver something to a customer, or at least come up with a feasible plan to do so. I'm skeptical that this was his actual approach IRL and not just ranting on TDWTF.



  • @boomzilla said:

    @Sutherlands said:
    The point that blakey, lettuce, et al. are making is that it's slow and time-consuming, which is why debuggers were created in the first place.
    Well, except that blakey's histrionics asking what a "professional" would do imply that he can't figure it out. To take his posts at face value, he'd rather make empty promises than figure out how to deliver something to a customer, or at least come up with a feasible plan to do so. I'm skeptical that this was his actual approach IRL and not just ranting on TDWTF.
    I don't read the post where he mentions "professionals" to say that he can't figure it out.  It's just the normal blakeyrant about how tools are crap and people should be demanding better.



  • @ASheridan2 said:

    I wasn't trying to hurt you, that was just a nice bonus. Thing is, when I was debuggin, rather than complain about lack of tools, I used the debugger in the iPad to find out what it though were errors in my code. You can call it what you want, that doesn't mean it's not a debugger. It's not a great one, but it is better than nothing. You're meant to be a human being aren't you? One of the defining bloody characteristics is that we can learn and adapt. I'm sorry that you're not spoilt for choice when you're developing for iOS, but them's the breaks, so suck it up and do what you can with what you've got. Everytime you come on here ranting about something you just come across as a little kid who's only just about been pulled away from his mothers skirts.

    That was awesome.  You win the Internet today!

     



  • @boomzilla said:

    My first comment tells you what to do. You put in statements that firstly tell you whether a certain bit of code is even being reached. Then, you can find out if its some weird data or what that's going on. Essentially, you're logging stuff to the console (or putting in alerts, or whatever) and making inferences based on that.

    Except my point is, in the situations above, by the time you "see" the problem in the console, the page unloads 0.5 milliseconds later. Unless you're suggesting that iOS' JavaScript console logs to a file somewhere I can access, it's virtually impossible (if not actually impossible) to debug situations like those using console.log(). You need a debugger to pause execution in those situations.

    @boomzilla said:

    It's not totally different than using a stepping debugger, but it can take a lot more time and effort, since you typically end up modifying your output and rerunning as you learn little bits and zero in on the problem bit of code. I have no clue what your stuff does or looks like, but isn't this sort of thought process debugging 101?

    No, because I'm not a 5-year-old. Debuggers have been around since before I was born. I learned to program by stepping through code with debuggers. Every other system I deal with on a day-to-day basis, including all web browsers and including the non-mobile version of Safari-- they all have debuggers!

    How is any "professional" developer not using a debugger constantly?



  • @Sutherlands said:

    I don't read the post where he mentions "professionals" to say that he can't figure it out.  It's just the normal blakeyrant about how tools are crap and people should be demanding better.

    Looking at the thread, "professionals" was mentioned a couple of times. I definitely agree with you about his first post:
    @blakeyrat said:

    And how do you "professionals" debug JavaScript on iOS devices? Oh wait, I guess "professionals" are the ones who are perfectly fine with the absolutely shitastic status quo-- which makes me proud to not be one. Stupid me; I'd assume "professionals" would demand professional tools like, say, debuggers.

    I was really referring to this post:

    @blakeyrat said:

    And if the bug is in a click handler on a link? Or a form validator? Or in the beforeunload handler? What do you "professionals" do then?

    It either sounds like he has no idea, or maybe thinks no one else does, and it's a trick question. Perhaps we'll never know.


Log in to reply
 

Looks like your connection to What the Daily WTF? was lost, please wait while we try to reconnect.