Please wait...
you always have a choice to use either `await` or the Promise API directly with .then()/.catch()/.finally().
My coworker, who does a lot more JS than I do, says "I find it a little easier to handle errors from endpoints with .then()." but I'm not sure what he means by that.
function my_function() {
fetch_function = async() => {
response = await fetch("/whatever/url");
the_data = await(response.text());
if (response.ok) {
do_something_with(the_data);
}
}
fetch_function();
}
Not perfect, but it definitely saves a few lines over manually setting up an XmlHttpRequest() and getting into callback hell. I am trying hard to avoid bastardizing the way the API is supposed to be used, so there's going to be some learning ahead.
Yes exactly. This guy posted a brilliant RANT on that subject: http://journal.stuffwithstuff.com/2015/02/01/what-color-is-your-function/
It's like the rant of all rants. I bow at the altar of this rant.
async/await is finding its way into other languages, now. Python, if I remember correctly. IT'S LIKE A VIRUS THAT MUST BE STOPPED! VERY 2020!
Hiccup.
Anyway, I had to do a bit more JS work a month or so ago. I was integrating the Orion CodeEdit widget with our project. So I took a look at our build toolchain. I could have just loaded the Orion dist bundle directly as an extra <script> tag, but I wanted to do it the "right" way, and learn a few things.
We use Elixir, node.js, webpack, and Babel.
Babel does some wonderful things like transpiling the more recent versions of ECMAScript (which support modules with `import`, and new things like async/await) down to whatever version of JS your browser supports. Including IE11, but my company doesn't support IE anymore. For example it can transpile an async/await down to a "switch/case" based event-handler.
Babel can also be a pain in the ass. Had to add an exclude rule to disable Babel on the Orion bundle in order to get webpack to load the bundle.
Generally you have to disable Babel on dist bundles, apparently, including everything under node_modules[5~/
Generally you have to disable Babel on dist bundles, apparently,
including everything under node_modules [5~/
I think this is because dist bundles have generally already been transpiled down to lowest-common-denominator browser JS, with some sort of CommonJS/AMD hybrid module loading convention. So you don't want to try to transpile them *again*... that way lies insanity.
There are so many JS module standards to choose from. Here's a list/doc that just scratches the surface:
https://requirejs.org/docs/whyamd.html
alt.javascript.die.die.die
In that article he uses the phrase "ever marching to the right callbacks". That's exactly the problem. When you get tied up in this async stuff ... well, the fetch/await stuff does make it easier to set up an XHR but it still only makes sense if you're reacting to an event (such as input from the user) and something happens in response. God help you if you have to come back down the callstack and then do something afterwards.
A pox upon the house of whoever decided to deprecate synchronous XHR. Sometimes it just makes sense. Sometimes you're ok sitting there and blocking, because the program isn't going to do anything useful until that transaction completes.
Thankfully I have lately been in a mood of "use the tool the way it was intended, don't bastardize it to match some other way of working that you had in mind."
In general, yes, but deprecating a function or method that, when used correctly, provides the proper experience, is not the way to go about stopping blocking "actions" in the loop. That says nothing for the reality that it hasn't stopped the blocking. I had a client's marketing "person" complain about the load times on a server that I host for the company - a quick scan with the inspector that you get with Chrome or Firefox quickly revealed that the slider he implemented synchronously loads sever images before rendering the carousel slider. PS I still think it's broken but he stopped complaining.
Synchronous XHR combined with a proper UI that lets the user understand what is going on is a reasonable use of the functionality if done correctly. It's certainly easier than implementing websockets which can have the same effect if poorly implemented.
Thu Dec 31 2020 11:22:25 EST from LoanShark
there are definitely problems with blocking the browser event loop though
if done correctly. It's certainly easier than implementing
websockets which can have the same effect if poorly implemented.
I'm not sure how true that is anymore. We use a bunch of framework stuff that kinda just takes care of the websockets for us, to a degree. This is not to say that every single API call we have is a good fit to be marshalled over a WebSocket; any kind of specific parameterized query, or a form POST, is better handled RESTfully, but if you just want to implement Live View, WS is the way we do that now, and once you start going down that path, you are probably doing quite a few things that make it a bad idea to block the event loop.
Our stack is hosted on Erlang/Elixir, and of course Erlang has a loooong background in serving up message-passing solutions. It's not that it makes everything easy, you still have to deal with replicating your message queue across every service node in your cluster--which is why we don't implement Erlang clustering yet, we literally just have a single service node. That fits our needs for the moment at this early stage.
I've seen poorly implemented websockets work worse (relatively speaking) than synchronous Javascript calls - it usually surrounds poor performance in the callback on the client side when the message is received - but to your point, that isn't necessarily the websocket's fault :) The last two go-rounds I've written websockets for were based on Java Spring, and they do a lot of the plumbing for you now, so it's much harder to screw up. I've also written websocket servers in C++ (the MS CPP REST API didn't support client or server at that point) but I wasn't dealing with a browser client - so I didn't have any performance issues there either (as it relates to the websocket - there was other crap code to "refactor").
Thu Jan 28 2021 16:25:05 EST from LoanSharkI'm not sure how true that is anymore. We use a bunch of framework stuff that kinda just takes care of the websockets for us, to a degree. This is not to say that every single API call we have is a good fit to be marshalled over a WebSocket; any kind of specific parameterized query, or a form POST, is better handled RESTfully, but if you just want to implement Live View, WS is the way we do that now, and once you start going down that path, you are probably doing quite a few things that make it a bad idea to block the event loop.
Our stack is hosted on Erlang/Elixir, and of course Erlang has a loooong background in serving up message-passing solutions. It's not that it makes everything easy, you still have to deal with replicating your message queue across every service node in your cluster--which is why we don't implement Erlang clustering yet, we literally just have a single service node. That fits our needs for the moment at this early stage.
That video is actually evidence of what I think is wrong with engineering at Big Tech. I would wager that all of the folks dancing (as well as many I could identify from the mediocre camerawork) are South Asians. Their (BigTech) HR departments go out of their way to hire other South Asians (H1Bs or otherwise) who generally are not challenged to innovate. Sure it's diverse in the sense that it isn't a room full of white men, there are plenty of other people being left out. They seem to fill their "diversity quotas" by hiring other races for other departments. I don't like to generalize on races or cultures but when everyone was taught the same way you tend to have the same silo of solutions, which, in some situations, can make the problem worse.
Before I landed at my 20-year IT gig there were projects where I was the only American, and certainly the only person in the complex who could be identified as "not entirely white". They nicknamed me "4:55" since I would check in my code right before 5:00 and be on the train heading home. A lot of those clowns (they weren't all south Asian, but certainly not US (permanent) residents) would be there until 7 PM working on roughly the same amount of work. I was later promoted to be team lead which I was fine with. it's not that I am a great programmer (even though I like to think that I am) as much as it was them attacking the same problems with the same solutions.
I won't waste my time with Big Tech - they don't want to hire me and I don't want to work there. They're more concerned with sorting algos and not how to solve the problem quickly and effectively. From the outside looking in it seems like the answer is to run crappy code on better hardware. No thanks. I've struggled though running my own shop for the past few years and I haven't burned out yet :)
Oh, and I believe it was intel that was/is in the midst of a lawsuit because engineering managers were mistreating employees based on the caste system.
https://www.latimes.com/business/story/2020-07-02/california-sues-cisco-bias-indian-caste-system
Wed Jan 27 2021 12:44:30 EST from ParanoidDelusions"Diversity"... it doesn't mean what Intel thinks it does.
https://www.youtube.com/watch?v=STT3kJXzeEA&t=36s
Wed Jan 27 2021 10:56:29 EST from darknetuser
They are much more interested in having lambs than in producing hardware or code at this point. It is super pathetic. I mean, they run a boot camp for finding people worth hiring, and they discard the guy who has commits on 5 am and the guy who is caught reading some software design pattern book because those guys are surely freaks.
Absolutely. Here is the thing - you'll notice that a majority of the South Asians are also female. This is a two-birds-for-one-stone proposition for Intel.
"A leader in hiring women and minorities in the Tech industry."
Yeah. Indian women. All other women and minorities are still under-represented at Intel. But they're not lying when they make this claim.
And they're bright women. I worked with them. But there is absolutely a monoculture of thought at Intel now - the values and culture that pervade Intel as an organization now comes largely from South Asia. They're a very "rule oriented," culture - even when the rules don't make sense. I actually had a good friend, who was Indian - who was born and raised in New Jersey - and he was the first one to suggest, "white guys are better at thinking outside of the box than Indians," to me. He didn't mean that as a stereotype. He is, for all practical intents and purposes, a "white guy" as he meant it. As a 2nd generation Indian, he is very adept at adopting the parts of his culture that work best in one situation, and the parts of "our" culture that work best in another - which is the absolute benefit of immigration and culture diversity. He got to pick and choose his values from two cultures and leverage whatever cultural approach is the best for a situation - in most cases.
And that *is* where innovation comes from. He left Intel a couple of years ago, voluntarily, during the last round of domestic layoffs. He had to beg to be let go and saved some 30-something white guy's job in the process. Every other white guy I knew over 45 was let go in that round of lay-offs, after decades of service.
He felt constrained by the emerging cultural shift at Intel - he felt they were cutting the lean and leaving the fat.
Thu Feb 04 2021 15:58:21 EST from DutchessMikeThat video is actually evidence of what I think is wrong with engineering at Big Tech. I would wager that all of the folks dancing (as well as many I could identify from the mediocre camerawork) are South Asians. Their (BigTech) HR departments go out of their way to hire other South Asians (H1Bs or otherwise) who generally are not challenged to innovate. Sure it's diverse in the sense that it isn't a room full of white men, there are plenty of other people being left out. They seem to fill their "diversity quotas" by hiring other races for other departments. I don't like to generalize on races or cultures but when everyone was taught the same way you tend to have the same silo of solutions, which, in some situations, can make the problem worse.
Before I landed at my 20-year IT gig there were projects where I was the only American, and certainly the only person in the complex who could be identified as "not entirely white". They nicknamed me "4:55" since I would check in my code right before 5:00 and be on the train heading home. A lot of those clowns (they weren't all south Asian, but certainly not US (permanent) residents) would be there until 7 PM working on roughly the same amount of work. I was later promoted to be team lead which I was fine with. it's not that I am a great programmer (even though I like to think that I am) as much as it was them attacking the same problems with the same solutions.
I won't waste my time with Big Tech - they don't want to hire me and I don't want to work there. They're more concerned with sorting algos and not how to solve the problem quickly and effectively. From the outside looking in it seems like the answer is to run crappy code on better hardware. No thanks. I've struggled though running my own shop for the past few years and I haven't burned out yet :)
Oh, and I believe it was intel that was/is in the midst of a lawsuit because engineering managers were mistreating employees based on the caste system.
https://www.latimes.com/business/story/2020-07-02/california-sues-cisco-bias-indian-caste-system
Wed Jan 27 2021 12:44:30 EST from ParanoidDelusions"Diversity"... it doesn't mean what Intel thinks it does.
https://www.youtube.com/watch?v=STT3kJXzeEA&t=36s
Wed Jan 27 2021 10:56:29 EST from darknetuser
They are much more interested in having lambs than in producing hardware or code at this point. It is super pathetic. I mean, they run a boot camp for finding people worth hiring, and they discard the guy who has commits on 5 am and the guy who is caught reading some software design pattern book because those guys are surely freaks.
LOL that is funny right there.
I had a manger at one job where right as the "bell" rang, he was gone. Expected us to be gone too "its quitting time, i dont expect you to have to be here either". He would fly out the door so fast we would watch him leave thru the front windows and see how for he got until his coat hanger would stop moving. We would take bets. One time he made out all the way out the parking lot. ( we were on a 2nd floor even.. )
Then we would all wander home shortly afterward.
Of course if something came up we all came in or stayed late, but he was a firm believer of not letting work life interfere with your personal life on a regular basis.
Thu Feb 04 2021 15:58:21 EST from DutchessMikeThey nicknamed me "4:55" since I would check in my code right before 5:00 and be on the train heading home.
It all started because when I jumped into that project, I had issues with Visual Source Safe.. it was only later that I discovered that the entire package is a flaming pile of dog poop.
I'm a firm believer in work-life balance, and some of the folks that I trained or managed over the years carry forward the same policies on their own teams - like no Friday deployments unless it's an emergency... or making the person who enabled the automated updates to the OS come in on the weekend to put out the fire caused by the latest "fix" from Microsoft :) I don't have time to tell that story now, but I'm sure it will grace the pages of this board soon.
Mon Feb 08 2021 10:15:20 EST from Nurb432LOL that is funny right there.
Of course if something came up we all came in or stayed late, but he was a firm believer of not letting work life interfere with your personal life on a regular basis.Thu Feb 04 2021 15:58:21 EST from DutchessMikeThey nicknamed me "4:55" since I would check in my code right before 5:00 and be on the train heading home.
In the old days VSS is all we had.
About a year ago i had it taken away at the office. Security people found out i was using it. New team mate started asking questions of how to get access, didnt listen to me. *dont tell anyone else, only me, or it will go away*. I wonder if ti was on purpose ). Had to migrate nearly 15 years worth of stuff to a file system, as i didnt have a license for the new stuff Microsoft that the real dev teams had migrated to. So i ended up losing all my history. just 'current'.
Couple of months later i unofficially i started using FossilSCM, under the radar. No server running, just as an exe with a local DB. Figured if i get yelled at "look, the exe and db are in the same network folders as the current files and are locked down. If they can get into the DB for history they have access to the files anyway" Ran it at home for years, so its something i knew would not freak out and eat my work one afternoon.
Oh, and the new guy, doesn't have access, or a clue of what im doing now :P
Oh and i didnt mean to imply that VSS was pirated. it was legal. It was just so old they didnt approve of it being used anymore.
What kind of stuff are you using websockets for? I thought that was only something you used when you need a real-time media stream.
That's a good question. I'm not sure I fully understand the answer; it's not entirely in my wheelhouse.
Our lead developer, and the UI team, have chosen to use WebSockets for a subset of our frontend API calls. Basically the ones with longer latency, I think, so that other calls can return back over a single TCP socket while waiting for the heavy one to process? I could be wrong, but I don't think we're actually using a Live View / Live Update type of pattern here, but our frontend is built on React, which is built from the ground up to support that sort of thing.
We also have a backend admin console, that *does* use WebSockets to actually push realtime data updates to the browser, in a couple different areas but to pick one example, a realtime debug log for a long-running job. And I believe the backend also uses Live View for data views that keep up-to-date with the data state on the backend.
It worked, and yes, it was all we had. I remember being enthusiastic about subversion, simply because it was marginally better then VSS. As I've gotten older and wiser, my love of command-line utilities has returned, and now I (almost exclusively) use GIT because most folks know how to use it and with a little work you can keep your work out of the hands of MS by running your own repository.
Tue Feb 09 2021 13:22:36 EST from Nurb432In the old days VSS is all we had.
That's pretty much all I am using websockets for.Some of the things my clients ask for require real-time data over HTTP/S - rather than create convoluted event loops in the browser, I would rather create a websocket as to avoid being in the plumbing business and focus on making the information pretty and actionable once they receive it :)
Tue Feb 16 2021 16:20:37 EST from IGnatius T Foobar
What kind of stuff are you using websockets for? I thought that was only something you used when you need a real-time media stream.