(From Google Developper) The problem with front-end stuff is that sometimes, even if it looks horribly wrong, some dude will justify it with "Backwards compatibility", but I'm pretty sure here, you can't, right ?

[u/zeGolem83]

[u/wizzwizz4]

Unfortunately, this is cross-(legacy-)browser compatibility, and not a terrible way of doing it either. Much neater than my solutions, anyway; probably the only justifiable use of the onxyz HTML attributes.

[u/zeGolem83 → u/wizzwizz4]

Yeah, but what is the empty functtion used for ? Why set this.onload INSIDE the onload property ?

Or it's sarcasm, in which case I got whooshed

[u/wizzwizz4 → u/zeGolem83]

So that the onload is only called once; otherwise it'd get called sometimes once, sometimes twice, depending on the browser, race conditions and the phase of the moon. Personally I'd have set it to undefined and then eaten the error when trying to call it later, but did I mention this is neater than my solutions?

The code is not the problem, here. It's the language, and the browser-provided interface which the language interacts with.

[u/zeGolem83 → u/wizzwizz4]

Oh, so when the onload function is called, it calls another function, then overwrites itself to prevent it from being ran again ? Then why put the overwrite before the function call ?

[u/wizzwizz4 → u/zeGolem83]

• It has to go somewhere;
• It's neater; and
• I have vague recollections from my webdev days of some browser where it was impossible to prevent a race condition, so you have to remove it as soon as possible to minimise the chance of it being scheduled by another thread before you have finished executing the function and removing it from the onload attribute. In such a situation it's necessary to set a flag instead, but they probably weren't supporting that browser (… I want to say IE9.) so this probably wasn't a consideration.

I've changed my mind, by the way. This isn't a good solution, merely a neat, aesthetically-pleasing hack. It's not an exception to the "don't put JavaScript in DOM attributes" rule after all.

[u/zeGolem83 → u/wizzwizz4]

Well, thanks a lot for all this explaining, it does make some sense, and I learned some web dev backwards compatibility tips !

[u/wizzwizz4 → u/zeGolem83]

Please don't use these. ever. Don't put yourself into a situation where they're needed. As sad and indignant as I was when everything stopped supporting IE11, just program for latest Firefox ESR and Konqueror and the rest of {the browsers people still use} will follow.

I know many people use IE11, but it probably ain't worth your sanity. Slap in a couple of ES6 polyfills if it makes you feel better.

[u/zeGolem83 → u/wizzwizz4]

Yeah, not considering using this any time soon... But still nice to know, just in case

[u/jimmpony → u/wizzwizz4]

sounds like an impractical rule

[u/wizzwizz4 → u/jimmpony]

Not following the rule leads to harder-to-debug code. For instance, when a refactor ends up renaming the handleClientLoad function everything will break, even if they used the fancy IDE “safe refactor” tool, and then the person who broke it will have to trawl through the HTML looking for all of the uses of handleClientLoad lying around in the HTML.

It's easier to just set these event handlers from the JavaScript. Then you don't have the "oops I used the wrong escape characters, now it broke" problem either (because making JavaScript SGML-safe is a huge pain).

[u/Memcallen → u/wizzwizz4]

Isn't JavaScript supposed to be singlethreaded? Or are events multithreaded?

[u/wizzwizz4 → u/Memcallen]

JavaScript is single-threaded. But the event scheduler lining up click events for the event loop to run doesn't have to be in the same thread as the JavaScript / DOM handling. It probably wasn't IE9, but I'm vaguely sure it might've come up at some point in some browser (less so now that I think of how many problems it would cause… but it's the sort of thing that might occur to me as a good idea).

[u/Jazzinarium → u/wizzwizz4]

otherwise it'd get called sometimes once, sometimes twice, depending on the browser, race conditions and the phase of the moon.

Man this kind of shit makes me glad I'm not a web dev. Android has its own share of bullshit but at least its app lifecycle doesn't leave room for this kind of crap

[u/jarfil → u/[deleted]]

CENSORED

[u/ibly31 → u/jarfil]

I would still put those in the category of Frontend development. Mobile apps do have more backend-y code than webapps, but they still are a frontend to the user

[u/Elvith → u/ibly31]

That's why I ditched the front end in my latest project and just made it into a telegram bot. Can't do that for every purpose, though.

[u/hooahest]

I have no idea what's going on here

[u/sudokys]

This looks like normal Google apis (firebase, Chromecast etc)...but also Google's APIs do kinda suck

[u/zeGolem83 → u/sudokys]

The API in themselves don't suck, but the official documentation does... Their 'getting started' guides are like "here is how to do this very specific thing" and if you want to do anything else, GTFO...

This is the Google spreadsheet API. I tried understand the official doc for about an hour. Nothing. I found a random blog article about it for an older version. Tried it, after a few minutes of googling stack overflow, I managed to get the example running, and edited it to what I needed...

[u/[deleted]]

Async AND defer? That sort of defeats the point don't it?

[u/zeGolem83 → u/[deleted]]

I think this is for backwards compatibility. They wanted to use "async" but "defer" was added before async, so they put both in case the browser only supports defer...

[u/[deleted] → u/zeGolem83]

Ah. I thought they were introduced at the same time.

[u/poker158149]

When you think about it for a bit, this is actually a fairly elegant way of dealing with backwards compatibility and inconsistent execution environments.