Is Javascript good now?
const f = async () => (
new Promise((resolve,reject)=>(
setTimeout(()=>{resolve(Math.random())}, Math.random()*3000)
))
)
async function kek() {
console.log('Waiting...');
let r = [
await f(),
await f(),
await f(),
await f()
]
console.log('Done...');
console.log(`Result: ${r}`);
}
kek()
I'm not sure why this exists when you could just do Promise.then
>53-bit integer that only do 32-bit bitwise arithmetic
>good
>2017
>even using bitwise arithmetic
>what is crypto
Have you even seen the shit libsodium.js and sjcl have to pull?
Javascript is even more of a clusterfuck than sepples at this point
can it do what op did, putting async calls where you'd normally have sync and block the thread? lf not, well, there's your answer.
>2020-3
>cyrrupto
What have you got to hide, goy?
ES2015 is really comfy to use desu
- arrow functions
- const, let / no retarded hoisting
- async, await
just use eslint and don't fall for the typescript meme and you're gonna have a good time
> don't fall for the typescript meme
elaborate
Not that poster but I read (the URLs for) studies that showed that static typing didn't improve code quality.
There are other options for (runtime) static typing if you want to (propTypes being my fav, but there's Flow and bunch of other shit)
I just don't want to introduce shitty MS tooling into my codebase.
it doesn't improve quality, but at least it prevents many bugs due to the type system
the new string interpolation and generator / lambdas are too good, js came a long way
You mean `this {shit}` ?
Back ticks are ugly, I prefer
$"C# {syntax}"
oh also I forget the whole destructuring, spreading and rest operators
also default parameters, super useful to write functions with one mandatory argument and whatever optional shit you can think of via an object argument with default parameters.
no more refactoring baby
shit is cash
ES6 and immutable.js made it a good language, yes.
> immutable.js
Seems like a meme to me.
Why not just use spread operator?
Object stays serializable and you don't introduce some 3rd party library
newState = { ...oldState, foo: 'bar' }
>immutable.js
>not writing vanilla
You fucked up bro
Doesn't it also make it easier to document your code?
I don't use TS (yet) but I assume doc systems automatically pick up the types?
I legitimately don't get what the JS community is smoking. I mean I get that this is "better", but this is fucking horrible.
I write JS in my freetime and also get paid to write JS.
Modern JS is sand-castles built upon sand-castles.
To use a modern JS framework you have to install and maintain at least five other modern JS frameworks/libraries. It's the modern PHP
Immutable.js is to replace data structures like Map, List, Set, etc.
Not plain objects.
You can write much cleaner code using these data structures than you can with plain objects.
And it prevents bugs while being much faster than the build in structures.
>replace data structures like Map, List, Set
I don't use that shit anyway, it's all sugar for primitives.
>I don't use that shit anyway
You really should.
It makes such a huge difference in your code:
No more need for temporary variables, for/while loops and all that mess.
It's the difference between writing JS like a Pajeet or like a professional.
Yeah, if by "modern" you mean "not yet released".
You can use es6 imports, let, promises and many other stuff, and if you aren't allergic to libraries you can sacrifice a couple lines for co which lets you use generators in place of async/await.
No thanks.
I don't care about line count or variable length.
Same reason I don't use linq in my C# ; if I can't tell what it's doing why use it? Every abstraction adds complexity and inefficiency.
>adds complexity and inefficiency.
It's easier to write and especially to read, and FASTER to execute.
But then you don't care about that do you, Pajeet?
No, keep fucking around with for loops and temporary variables.
>FASTER to execute
If you say so boss.
Not by a fucking long shot
It can. Asynchronous/Await is just syntactic sugar over promises. Just go see what your transpiler does with your code to make it work in es5 browsers.
JavaScript is the epitome of a bad programming language.
Programmers generally think that it is a good thing that a language has been adopted universally, but in the case of JavaScript it is so far from the truth. The fact that there is javascript executing in every modern browser is a little disturbing when you consider that malware written in javascript could, in theory, effect everyone.
>ES2017
Ecmascript 2017 was officially done few days ago. async await is part of it.
So then C and C++ are far worse than javascript by your definition of a bad language.
new js is shit, fuck it
How do I web development in my free time without javascript ? I don't want to get into this ES mess but every semi-basic functionality like dropdown menu is much easier with JS.
>Asynchronous/Await is just syntactic sugar over promises.
Nope.
Browsers have a sandbox. While there have been exploits capable of escaping it, it depends on engine bugs and different engines have different bugs.
The real issue here would be everyone moving to webkit + V8.
Either use a language that compiles to JS, create your own language that compiles to JS, or write a browser that doesn't use JS.
>malware written in javascript
You could build regular pages that don't do anything on the client side and maintain state in the server side instead.
Simply wait for requests and return responses.
I don't see it. you'd still need to write callbacks to achieve what is done in op without any callbacks.
>He doesn't know Windows script host
We had that already, something to do with pdf.js in modern browsers.
Yes, basically all of it that's effective.
Please educate yourself :^)
Yes. That's why it is syntactic sugar. You can write it in the ugly callback hell way or using async await. But in the end you can do the same things.
Fun!
...
Once again, no, async/await is not syntactic sugar over promises. Async/await allows a function to wait for a promise to fulfill without blocking the entire thread.
You can do anything you want without ever using your own callbacks. Don't downplay the importance of those things by saying they are syntactic sugar - they are proper new syntax that is convenient to use.
>Async/await allows a function to wait for a promise to fulfill without blocking the entire thread
Isn't that what a Promise does?
Async functions return promises
No, a promise is not capable of pausing the execution of a function. Async/await makes it possible for a function to literally wait until a promise resolves, then continue going from that point.
>they are proper new syntax that is convenient to use.
That's the definition of syntactic sugar.
I'm not saying they are bad. They are great and reduce the amount of code you have to write a lot and reduce bugs a lot. But still.
So what does a promise do?
Cont. To be clear, it WAS possible to implement before, but only if you used generators and the "yield" statement together with promises. Async/await allows you to implement this directly.
Async/await is literally implemented on top of Promises. It is just syntactic sugar for them to make it look like coroutines.
Promise allows you to call another function, a callback. async/await allows you to stop execution of current function without blocking and resume execution where you left after the async operation is done. The resuming part is not achievable with promises - you work around that by splitting your function into multiple small ones. Also see call/cc.
Async/await uses new functionality that could not have been implemented in JS before EXCEPT by using generators/yield, which are themselves fairly recent additions to the standard. These features CANNOT be implemented using just promises and not, at minimum, also generators in addition.
Calls a function you specify after certain conditions are satisfied. No resuming, calls the function from its very beginning.
No, new syntax is not always just syntactic sugar.
Then how do they work when transpiled to es5, genius.
That's not the same thing at all. When you compile to language you can do things you can't implement in that language natively. Python can be compiled to C and python has closures, that doesn't mean you can implement closures in C.
Probably the functions are broken up into smaller functions by the transpiler.
That's exactly what the ".then" part of the promise does.
>When you compile to language you can do things you can't implement in that language natively
I don't understand how that's possible
No. When you call .then() on a promise, the function in which you make the call continues to execute without waiting for the promise to resolve.
then allows you to call another function from its very beginning, no resuming involved. Please stop pretending to be retarded.
It isn't.
Read my post till the end. Do you agree with my reasoning about closures in C?
>the function in which you make the call continues to execute without waiting for the promise to resolve
This isn't really true. The execution continues, yes, but when the promise returns the code in the .then clock executes.
doWorkAsync(param)
.then( result => {
// this happens when dWA finishes
})
// anything here happens right after dWA is called
>this isn't true
>proceeds to demonstrate it literally is true
I usually am very polite in conversations on Sup Forums but how do you not call person a retard after a post like that?
Not him but what the fuck are you talking about?
What he posted was 100% correct AFAICT.
Also how come people who are wrong always resort to insults?
He admitted the execution of outer function continues right after the call to dwa, something that me and other user have been telling him along - and something that doesn't happen with async await. I resort to insults because i literally told him this multiple times as detailed as i could, and he still doesn't see it.
>the execution of outer function continues
So?
Just leave it empty if that brothers you.
This argument was abut the part that goes inside the .then
All you've shown is that promises are more versatile than await.
The only thing that is bothering me is your ignorance. We are talking about conceptual difference between promises and async await. Promises only allow you to call a function after certain conditions are met. async/await interrupts execution of function without blocking the thread it's in, and later resume the execution where it stopped - something promises don't do and can't do.
>Promises only allow you to call a function after certain conditions are met
This was the very thing that was upsetting you in my dWA example above.
There are things which MUST happen sync, and things which can happen async. Promises let you do both, or either. Below is contrived...
// assuming new user details are legit
createNewUserAsync(username, pass, email)
.then( loginLink => {
emailNewUser(username, email);
});
forwardUserToDashboard();
Emailing the user can happen any time, but you want them to be forwarded right away.
It's the necessary evil, unlike java that is the unnecessary but still used as fuck evil,.
Java > JavaScript.
Java accomplishes exactly what it intends to do, JavaScript is an overengineered and hacked together turd.
I edited this post for like 15 minutes and now it makes no sense because it's a Frankensteins monster. fuck this thread anyway, it's friday night
I don't see why you're trying to convince me that promises are better. I'm not arguing in favor of any, I'm arguing that promises and async/await are conceptually different, something you or user you took place of claimed to be false.
But what java does is not necessary unlike JS.
JS is only necessary because it's the only thing that browsers support.
wasm will save us.
>wasm will save us
no it wont
you still need js for web frontend
>I don't know what wasm is
>wasm
it will be used only for high performance requirements like games, js will be here forever
I will write whatever supports wasm soonest just to avoid writing javascript.
...
whats the different between a promise and doing something like this?
$.ajax({
url: "whatever.php",
method: "POST",
data: $("#form_id_here").serialize(),
success: function () {
//do something
},
error: function () {
//do something
}
});
As long as I can access the DOM, I will have no need to write any Javascript.
try doing 10 subsequent requests inside the success callback that depend on the previous ones
read up on callbacks vs promises
promises allow a nicer syntax but async/await blows both out of the water
lol js const. Pass that variable to another function, and voila it's mutable again.
>I don't understand what a reference type is
I don't need to write any js even today. I use typescript exclusively
u wot
Depends on the usecases, people here however are based autistics who will scold you for talking about the wrong hugbox.
exactly
how does a promise "fix" this then?
This is unironically what many of my Node.js scripts look like.
Although I'll break it up into separate functions when it becomes too crazy.
I fucked up, it's nearly 3am here, sorry guise