|
Totally agree man. It's JS we're talking about, so I'm about to yap a lot... 
In JavaScript async/await is especially important. JavaScript by it's very nature is meant to be non-blocking. Without getting too much into the history of it for one post, I'll just say that's a strength of JavaScript. But, it does come with some gotchas, as you mentioned. Here's the 30 second history of it dealing with non-blocking code in JS.
In the beginning, there were callbacks. The Lord spoketh, thy non-blocking code doesn't return. Thou shalt use callbacks. Now callbacks were great, but they don't chain. And things got convoluted real quick. JS will always be non-blocking, so then now what?
Promises! They came about to deliver us from callback craziness. They chained... all was well... until folks realized promised also go complicated too. You could have like 10 promises all with nested variables (closures helped with this a bit), but it got messy if a coder didn't modularize crap nicely.
Now, the reason I said all that was because, all async/wait is in JS is syntax sugar for promises. You can in fact return a promise and call it with await. It'll work. Even though it's just syntax sugar, it still cleans things up and makes variable scoping with return values, etc. muuuuuuch less cumbersome.
Oh side note, throwing an exception in an async function is no different than rejecting a promise. Just cleaner syntax.
Jeremy Falcon
modified 22-Aug-24 9:10am.
|
|
|
|
|
this. was trying to recall why I disliked asynchronous, and something with JavaScript, but seeing op post and then quick lookup "var response = await fetch(url)", that seems so easy.
Thinking I thought you had to do callback functions. So yeah, you can do both, oh neat.
But that whole callback thing urks me. It's more how the flow of data I see in my head
function
get this data
now with the data do X thing
but callback
function
get this data
end function
some other function
now do thing with this data
its that separation of functions which my internal mapping does not like
|
|
|
|
|
For sure man, no doubt JS is different. It's single threaded and non-blocking, so it comes with a shift in thinking. And wrapping your head around it might take some... effort.
Personally, my beef with anything is JS related isn't the language, is the childish behavior with some (not you) who see something different and just hate it because they're stuck in the past, refusing to learn, arrogantly assume they know everything, etc. Like, um... what? We're adults... I think.
Anyway, great post. Sorry for the mini-rant.
Jeremy Falcon
|
|
|
|
|
Jeremy Falcon wrote: single threaded and non-blocking
Sounds like it would be blocking, not non-blocking. I didn't see how you have non-blocking with a single thread. Unless they've redefined what blocking and non-blocking mean.
|
|
|
|
|
JavaScript has a very specialized execution engine that everything goes though. Not sure how much you wanna read up on it, but if you're curious Google "javascript event loop". Its entire runtime model is designed to be non-blocking and runs on a single thread.
Makes it brain dead simple to have several worker scripts running at the same time. Don't have to worry about inter-thread communication and still get the benefit of always being non-blocking. But, there are tradeoffs and that's where those new to JavaScript usually freak out.
Jeremy Falcon
|
|
|
|
|
Truly not interested in it.
Is it time-sharing one thread in the engine? Or does each process get one thread in the engine?
Unsure that the terms "blocking" and "non-blocking" truly apply to the situation.
|
|
|
|
|
PIEBALDconsult wrote: Truly not interested in it.
PIEBALDconsult wrote: Is it time-sharing one thread in the engine? Or does each process get one thread in the engine?
If I were to give it an oversimplification, the time sharing analogy fits perfectly. It's all in one thing, but no one particular bit of code will block the app in the traditional since, since they all get their orders from the event loop. Now, all of this is under the hood of course, and most peeps will never notice what's going on.
PIEBALDconsult wrote: Unsure that the terms "blocking" and "non-blocking" truly apply to the situation.
Fair enough. When I say non-blocking, I mean something along the lines of this:
JavaScript is also known for it’s non-blocking behavior. Non-blocking means that JavaScript doesn’t wait for the response of an API call, an Ajax request, an I/O event or a timer but moves on with the other block of code below it.
Stuff like methods, etc. can block execution, but a lot of peeps opted for routines that do not block and that's where callback hell came from. The event loop made this a breeze to deal with because of the way it scheduled execution and returns. So, I kinda just lump sum crap when I talk about it these days. Old age stuff.
Jeremy Falcon
|
|
|
|
|
OK. Seems OK given the language's primary usage. But backward for general purpose development.
We (many of us) keep asking for more and more cores and hyperthreading so we don't have to share a thread.
From my point-of-view, the caller should be able to request blocking or non-blocking behavior as appropriate for the current task.
If I have to wait for an asynchronous call to complete anyway, then why bother going through all that trouble. </rhetorical>
I would much rather spin up a thread on my side as needed. It seems you don't have that luxury.
|
|
|
|
|
For sure, but it's just a different way of thinking. Personally, I like both models and think JS (despite its beginnings) has come a long way and does some really interesting stuff.
Jeremy Falcon
|
|
|
|
|
Javascript is crap, and so are async functions, especially if you need to wait for something to happen before proceeding with execution, or return a value that isn't a Promise<blah blah>.
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-----
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-----
When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013
|
|
|
|
|
Yeah, I'm not interested in entertaining this nonsense man. You JS haters have nothing new to say and none of y'all experts in it. We're supposed to be adults man... supposed to be.
Jeremy Falcon
|
|
|
|
|
Whatever dude...
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-----
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-----
When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013
|
|
|
|
|
Spuddle: (17th century). To work ineffectively. To be extremely busy while achieving absolutely nothing.
Check out my IoT graphics library here:
https://honeythecodewitch.com/gfx
And my IoT UI/User Experience library here:
https://honeythecodewitch.com/uix
|
|
|
|
|
Glad to know what I'm doing has a word for it.
I’ve given up trying to be calm. However, I am open to feeling slightly less agitated.
I’m begging you for the benefit of everyone, don’t be STUPID.
|
|
|
|
|
I just spent all morning freeing up stack and compacting parameters by passing struct references.
The problem hasn't budged.
And I can't find a reliable way to measure how much stack space is being used on the device itself.
All that work and I've gotten nowhere.
Check out my IoT graphics library here:
https://honeythecodewitch.com/gfx
And my IoT UI/User Experience library here:
https://honeythecodewitch.com/uix
|
|
|
|
|
An expression though not a word, we all know so well.
"Spinning your wheels"!
No help, but its a good description.
"A little time, a little trouble, your better day"
Badfinger
|
|
|
|
|
The wall I've been beating my head against was a http call that fails in the code but if you take the same URL and jwt into Postman it works.
I’ve given up trying to be calm. However, I am open to feeling slightly less agitated.
I’m begging you for the benefit of everyone, don’t be STUPID.
|
|
|
|
|
I miss the days when you could test by telnetting to port 80 and issuing GET / HTTP1/1\nHost: foo.com\n\n
Check out my IoT graphics library here:
https://honeythecodewitch.com/gfx
And my IoT UI/User Experience library here:
https://honeythecodewitch.com/uix
|
|
|
|
|
Beat me to it, but I was busy spuddling! 
A home without books is a body without soul. Marcus Tullius Cicero
PartsBin an Electronics Part Organizer - Release Version 1.4.0 (Many new features) JaxCoder.com
Latest Article: EventAggregator
|
|
|
|
|
It was annoying. Microsoft provided a fix for me though.
Outlook now crashes randomly or goes to "Access Denied" after my computer suspends, forcing me to relaunch it.
Now I'm so annoyed by that the first problem seems inconsequential by comparison.
Thanks Microsoft.
Check out my IoT graphics library here:
https://honeythecodewitch.com/gfx
And my IoT UI/User Experience library here:
https://honeythecodewitch.com/uix
|
|
|
|
|
I guess the Outlook doesn't look promising?
Sorry couldn't resist.
A home without books is a body without soul. Marcus Tullius Cicero
PartsBin an Electronics Part Organizer - Release Version 1.4.0 (Many new features) JaxCoder.com
Latest Article: EventAggregator
|
|
|
|
|
Hold still Mike. We're going to have to hurt you now.
Software Zen: delete this;
|
|
|
|
|
The Outlook looks even worse now.
A home without books is a body without soul. Marcus Tullius Cicero
PartsBin an Electronics Part Organizer - Release Version 1.4.0 (Many new features) JaxCoder.com
Latest Article: EventAggregator
|
|
|
|
|
honey the codewitch wrote: I used to complain about Outlook marking my read emails as unread
My fix for that was to set the delay before marking message as read to zero. When messages are short, the default 5 second delay left too many marked as unread.honey the codewitch wrote: Outlook now crashes randomly
Is this the new Outlook or classic Outlook?
One of our corporate IT yabbos told us to start using the new Outlook, which is a rancid Swiss cheese mess of missing features, poor UX design, and random crashes. I finally got tired of it and asked one of local guys if I could go back to the classic Outlook. He looked at me dumbfounded and wanted to know what idiot suggested I use the new one. 
Software Zen: delete this;
|
|
|
|
|
Gary Wheeler wrote: My fix for that was to set the delay before marking message as read to zero.
It appears to be marking them as read and then unmarking them later? But I'll look for that setting and give it a shot.
Gary Wheeler wrote: Is this the new Outlook or classic Outlook?
I believe it's the new one. It's the one Windows 11 pushes on you.
Check out my IoT graphics library here:
https://honeythecodewitch.com/gfx
And my IoT UI/User Experience library here:
https://honeythecodewitch.com/uix
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
