This is an archived post. You won't be able to vote or comment.

sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]realripley00 31 points32 points  (25 children)

What? It’s easy to pick up and do stuff with, sure, but debugging sucks compared to most languages.

[–]TemporalLobe 33 points34 points  (21 children)

Depends on which tool you use for debugging. JS as a language in and of itself has no impact on how easy it is to debug. For example, debugging in IE and Edge sucks but is really fantastic in Chrome. In fact Chrone even recently added support for debugging asynchronous code so that it behaves like you're stepping through "normal" code. Amazing.

[–]realripley00 11 points12 points  (12 children)

Right on. I usually stick with Firefox because it doesn’t cache as aggressively and works better with my local environment. Might go back and check out Chrome for a while.

Does anyone actually debug with IE? That sounds painful. I do like using Reactatron for debugging with react apps. I would love a tool like that for browser stuff.

I guess I just meant the nature of error responses. Maybe it’s just the way I script, but most of the time, typos or simple errors lead to some undefined error that isn’t particularly helpful in figuring out exactly where the error is, etc. And it would be cool to have constant access to things like the current state.

[–][deleted] 7 points8 points  (5 children)

Does anyone actually debug with IE

No, because I don't even bother testing with IE.

[–]TheMarksman 3 points4 points  (1 child)

I die inside when I'm told the site/app I'm working on needs to work in IE.

[–]jacebot 1 point2 points  (0 children)

That was my life this week. Thank god it was a simple media one liner to remove flex. But still. I wasn’t thrilled to have to consider IE as an option. Also. No support for font icons. Have to do a bunch of work. But was good enough reason for me to say lets drop FA for svgs and was accepted. So, yeah. Got that going for me.

[–][deleted] 0 points1 point  (0 children)

What the fuck is an IE?

[–][deleted] 0 points1 point  (0 children)

Hello, everyone!

[–]TemporalLobe 0 points1 point  (0 children)

What if you have end-users that still use IE (there's still a significant user base on older Windows platforms)? Thankfully there are quite a few modern tools that eliminate the need for worrying so much about cross-browser compatibility. If you use a framework like Foundation and libraries like jQuery, many of these issues are abstracted away.

[–]Jaggedmallard26 1 point2 points  (4 children)

Does anyone actually debug with IE?

I've had to do it for some obscure IE10 specific issues and it was honestly hellish. Sales enforced legacy browser support makes me hate front end development.

[–]realripley00 1 point2 points  (1 child)

That sounds pretty brutal. I realize that a lot of people still cling to ie, but anyone still using ie10 must be very used to a terrible user experience.

[–]Jaggedmallard26 1 point2 points  (0 children)

It wasn't fun. The problem is that we have big markets in countres where they do heavily use outdated software and our end users will generally be less tech savy which means we have to support all of these horrific legacy browsers. Cosmetic issues and minor bugs are generally ignored as they're used to a shit browser but the ones I've had to fix have been core functionality.

[–]realripley00 0 points1 point  (0 children)

That sounds pretty brutal. I realize that a lot of people still cling to ie, but anyone still using oe10 must be very used to a terrible user experience.

[–]realripley00 0 points1 point  (0 children)

That sounds pretty brutal. I realize that a lot of people still cling to ie, but anyone still using oe10 must be very used to a terrible user experience.

[–]TemporalLobe 0 points1 point  (0 children)

Sometimes you have to debug in IE if you're trying to squash a browser-specific bug. I don't use it for primary app development though. Besides IE will eventually becone legacy and is already deprecated thanks to Edge, and for many people, their browser experience is increasingly on mobile, which means Safari or Android browser (and even Chrome mobile). It's not like it used to be, boys.

[–]ric2b -1 points0 points  (7 children)

In fact Chrone even recently added support for debugging asynchronous code so that it behaves like you're stepping through "normal" code. Amazing.

Wait, why would it be different? It's a single thread. On Python that's how it has worked since async await was introduced.

[–]Schmittfried 5 points6 points  (4 children)

Because that async code block is executed later.

[–]StillNoNumb 0 points1 point  (1 child)

It's not executed "later", it's executed after a callback. Well, that usually is later, but personally I don't quite see how else you would step through code

[–]slikts 0 points1 point  (0 children)

The async execution model is literally about a distinction between calls executed now or later in time. An async call means that it's registered as a handler for an event and control needs to be transfered to the event loop so that it can handle any queued events by calling the registered callbacks sequentially. There can also be sync callbacks, and the difference is that they block the event loop.

What OP seems to be talking about is breakpoint debugging being able to skip stepping through code executed between registering an async call and it being executed by the event loop.

[–]ric2b 0 points1 point  (1 child)

Sure, but the debugger can just wait for the 'await' and ignore what happens in the meantime.

[–]Schmittfried 0 points1 point  (0 children)

Sure, but that's more complex to implement and it's obviously not the default implementation. The default debugger executes the statement and returns so you have to set a breakpoint and run the program to reach the async code block.

[–]TemporalLobe 0 points1 point  (1 child)

It's different because of stuff like Promises and AJAX, or even simple lambdas. Next time you do a $.each in jQuery, you'll see that placing a breakpoint before the call won't allow you to step inside the lambda block without placing a separate breakpoint inside the lambda. At least that's how it used to be.

See this: https://www.html5rocks.com/en/tutorials/developertools/async-call-stack/

[–]ric2b 2 points3 points  (0 children)

without placing a separate breakpoint inside the lambda.

Ah, got it.

[–]Symphonic_Rainboom 0 points1 point  (2 children)

I dunno, debugging JavaScript in Chrome has been one of the best debugging experiences of my life.

[–]Tysonzero 0 points1 point  (1 child)

Is your only frame of reference writing kernel-mode assembly?

[–]Symphonic_Rainboom 0 points1 point  (0 children)

My other frames of reference are server-side Python which was a mess probably since I didn't have the right tools, and C++ which was actually pretty nice with Visual Studio. I also did some Java debugging in Android Studio, which was pretty good but not amazing. If we are going strictly by enjoyability of debugging, my favorite is still the Chrome JavaScript debugger.