JavaScript Errors: An Exceptional History | Hacker News Reader

JavaScript Errors: An Exceptional History

blog.appsignal.com

64 pointsLiriel28 comments

I remember that in IE all you got was a yellow alert sign in the status bar that there was a JavaScript error somewhere and you added alert boxes on every 100:ed line eg. alert("line 200") alert("line 220") until you had located the error. This is still how you do it on some mobile/tv browsers. Some browsers will not even tell you there is an error - and fail silently.

This was the 90's Javascript debugging experience and why I still hate JS to this day. The language felt like mush.

But these days the dev tools built into every modern browser rival the debugging tools in the best IDEs, and they’re free.

Yes, modern browser dev tools are great. But it's still Javascript.

I feel bad for javascript for it always blamed for the fault of the environment where it lives.

And to some extent the acts of bad actors using it.

I just got into webdev a year or so ago and on HN and other places the moral panic about JavaScript on the web is endless because some jerks are out there doing it wrong and everyone thinks of their US local news website (those are a mess) when they talk about it ... and they want to throw the baby out with the bathwater. Meanwhile I'm just trying to write some handy web apps that do it right but can't escape the "omg javascript" medium type articles.

I wonder if folks write some nasty stuff in C ... do people blame C?

People totally blame C (and C++). There's entire classes of use-after-free and buffer flow errors not possible in other languages, which is what leads to people advocating for Rust or Go (or ADA for that matter, though it's obviously not popular anymore).

People complain about c all the time. Javascript is 20% footgun.

> the moral panic about JavaScript on the web is endless because some jerks are out there doing it wrong

To be fair, the language allows them to do it wrong by default with all that implicit type conversion and whatnot -- even in the original equality operator! You can write good JavaScript, but you have to purposefully avoid weird behavior that just isn't present in some other modern languages like Python and Ruby. JavaScript had a weird history, got expanded upon accidentally (i.e. through some browser vendor or another deciding to implement something) many times, and has always valued backwards compatability more than languages that feel comfortable expecting the user to install the relevant runtime.

Python has

    > a = 100
    > a is 100
    True
    > a = 1000
    > a is 1000
    False

CPython stores integers above 256 as individual pieces of data, but a normal Python script doesn't. I think it's technically undefined behavior.

The language didn't have other error reporting mechanisms, traces or exceptions, so it was not "the environment where it lived", it was the language itself...

http://www.devsanon.com/rants/stupid-javascript/

Until Javascript removes the stupid from it's language, it will remain an embarrassment to developers. Completely inexcusable.

> http://www.devsanon.com/rants/stupid-javascript/

> Until Javascript removes the stupid from it's language, it will remain an embarrassment to developers. Completely inexcusable.

From that link:

> > typeof NaN

> > "number"

> > NaN == NaN

> > false

> > Ok, so the type of Not a Number is a number? And it also does not equal itself? Oh, well. Let’s try equality with other stuff.

Compliance with IEEE 754 is stupidity that is completely inexcusable? That NaN is non-reflexive is certainly irritating but a standards-compliant language is expected to adhere to that.

Makes sense to me. 1/0 is not the same as 2/0, etc.

> This is still how you do it on some mobile/tv browsers. Some browsers will not even tell you there is an error - and fail silently.

That sounds surprising, because I thought most of those were based on Chromium. Do they not allow you to expose a remote debugging port that you can connect to from a desktop instance of Chrome?

I'm fairly sure they're based on WebKit, actually. Can't say I've ever seen Chromium inside non-Android mobile/TV browsers, but I could be wrong.

Wait, so when did console.log start to appear?

I remember alert without console.log as well but I was too young to understand the context.

For ios mobile dev I use Safari as a debugger. If I have to use Chrome, I basically use a scrappy console that I made on the HTML page itself.

IIRC console.log was a non-standard addition made by FireBug.

Sometimes dumping data to a pre tag is the simplest thing, especially on mobile. I did it just yesterday :)

Be careful about using JSON.stringify on objects as a debugging technique though, because you may not be able to see properties on the prototype chain ('inherited' properties), and some objects customize their serialization to JSON (supply a custom toJSON method) which in some cases can be misleading. Things like that have contributed to a number of my grey hairs. Yes, I'm talking about you, Geolocation Coordinates! :)

Chrome has really nice support for remote debugging on Android.

If you can't get physical access to the device to configure them for remote debugging, there are some other nice remote debugging tools. One example: https://jsconsole.com/remote-debugging.html

I can remember when console.log would break certain versions of IE... I believe even in IE8, console.log would only work if you had the developer JS console opened up, unless you polyfilled it.

Thank god I don't have to support IE anymore, what a mess it was.

> If I have to use Chrome, I basically use a scrappy console that I made on the HTML page itself.

Back in the day when I was working on the Sage Notebook, there weren't good javascript consoles. I can't recall if Firefox had one at the time (around 2007, I think), but it was certainly missing from Safari, IE, and Opera. But, it was an interactive notebook -- so I hijacked the "input cell" we were using to concoct what was essentially a console.

I had no idea JavaScript shipped without Arrays. Too bad they didn't just let objects take anything as a key, like in Lua. Then you wouldn't have all the edge cases Arrays cause in JS. Oh well!

> Too bad they didn't just let objects take anything as a key

They do, except they get coerced to strings in whacky ways. Objects can be used largely like arrays, and Arrays are Objects, but Array is more suited for an ordered collection of numerically indexed elements, and so has relevant properties and methods, like length and indexOf.

Yeah, but the weirdness inherent to them being objects but also not objects leads to all sorts of bullcrap, like `Array.isArray` being a thing. I greatly prefer the Lua approach where you only have one map type (tables), and there are methods that allow you to easily use the tables as an array.

This (anything can be a key) was eventually added with the Map class. They're an iterable type too, so they're much more useful than Objects imo.

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

I agree! They are more useful! That's why I wish objects behaved that way to begin with!

The initial v1 JavaScript was written in about ten days:

https://thenewstack.io/brendan-eich-on-creating-javascript-i...

Reply on news.ycombinator.com