Join devRant
Do all the things like
++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatar
Sign Up
Pipeless API
From the creators of devRant, Pipeless lets you power real-time personalized recommendations and activity feeds using a simple API
Learn More
-
IF PROGRAMMING LANGUAGES WERE DRUGS:
JavaScript = Methamphetamine:
Anyone can cook some up at home but only pros can make the good stuff without blowing everything up.
Under the influence it tries to do everything at once, in seemingly no specific order before running off and making plenty of promises - but you have no clue if it kept any until it returns.
C = Heroin:
It takes some prep before you can take a hit but when you do it's far more potent than expected. When prepped (compiled) correctly it will induce complete and utter ecstasy but any error or abuse may kill you, leave you on the floor, in a coma or wishing you were dead.
HTML = Paracetamol(Panado):
Some don't think it's a real drug and others do. Either way you should grow a pair and try something a little more hardcore.
--------------------------------------
I came up with these after I randomly explained asynchronous js to a junior as synchronous code on meth. These were just off the top of my head, please feel free to correct or expand on them :-)25 -
Okay, story time.
Back during 2016, I decided to do a little experiment to test the viability of multithreading in a JavaScript server stack, and I'm not talking about the Node.js way of queuing I/O on background threads, or about WebWorkers that box and convert your arguments to JSON and back during a simple call across two JS contexts.
I'm talking about JavaScript code running concurrently on all cores. I'm talking about replacing the god-awful single-threaded event loop of ECMAScript – the biggest bottleneck in software history – with an honest-to-god, lock-free thread-pool scheduler that executes JS code in parallel, on all cores.
I'm talking about concurrent access to shared mutable state – a big, rightfully-hated mess when done badly – in JavaScript.
This rant is about the many mistakes I made at the time, specifically the biggest – but not the first – of which: publishing some preliminary results very early on.
Every time I showed my work to a JavaScript developer, I'd get negative feedback. Like, unjustified hatred and immediate denial, or outright rejection of the entire concept. Some were even adamantly trying to discourage me from this project.
So I posted a sarcastic question to the Software Engineering Stack Exchange, which was originally worded differently to reflect my frustration, but was later edited by mods to be more serious.
You can see the responses for yourself here: https://goo.gl/poHKpK
Most of the serious answers were along the lines of "multithreading is hard". The top voted response started with this statement: "1) Multithreading is extremely hard, and unfortunately the way you've presented this idea so far implies you're severely underestimating how hard it is."
While I'll admit that my presentation was initially lacking, I later made an entire page to explain the synchronisation mechanism in place, and you can read more about it here, if you're interested:
http://nexusjs.com/architecture/
But what really shocked me was that I had never understood the mindset that all the naysayers adopted until I read that response.
Because the bottom-line of that entire response is an argument: an argument against change.
The average JavaScript developer doesn't want a multithreaded server platform for JavaScript because it means a change of the status quo.
And this is exactly why I started this project. I wanted a highly performant JavaScript platform for servers that's more suitable for real-time applications like transcoding, video streaming, and machine learning.
Nexus does not and will not hold your hand. It will not repeat Node's mistakes and give you nice ways to shoot yourself in the foot later, like `process.on('uncaughtException', ...)` for a catch-all global error handling solution.
No, an uncaught exception will be dealt with like any other self-respecting language: by not ignoring the problem and pretending it doesn't exist. If you write bad code, your program will crash, and you can't rectify a bug in your code by ignoring its presence entirely and using duct tape to scrape something together.
Back on the topic of multithreading, though. Multithreading is known to be hard, that's true. But how do you deal with a difficult solution? You simplify it and break it down, not just disregard it completely; because multithreading has its great advantages, too.
Like, how about we talk performance?
How about distributed algorithms that don't waste 40% of their computing power on agent communication and pointless overhead (like the serialisation/deserialisation of messages across the execution boundary for every single call)?
How about vertical scaling without forking the entire address space (and thus multiplying your application's memory consumption by the number of cores you wish to use)?
How about utilising logical CPUs to the fullest extent, and allowing them to execute JavaScript? Something that isn't even possible with the current model implemented by Node?
Some will say that the performance gains aren't worth the risk. That the possibility of race conditions and deadlocks aren't worth it.
That's the point of cooperative multithreading. It is a way to smartly work around these issues.
If you use promises, they will execute in parallel, to the best of the scheduler's abilities, and if you chain them then they will run consecutively as planned according to their dependency graph.
If your code doesn't access global variables or shared closure variables, or your promises only deal with their provided inputs without side-effects, then no contention will *ever* occur.
If you only read and never modify globals, no contention will ever occur.
Are you seeing the same trend I'm seeing?
Good JavaScript programming practices miraculously coincide with the best practices of thread-safety.
When someone says we shouldn't use multithreading because it's hard, do you know what I like to say to that?
"To multithread, you need a pair."18 -
Seriously? Javascript is the best?Javascript is the future?
Dont get me wrong. I have to use angularjs and nodejs in my work so I am quiet familiar with them. Js csn be usefull and make things easier and simpler but it comes with a price... You can do someting in third amount of effort but you have to debug three times more. Yes you can use typescript but thats not an option always. What about single threaded design yes you can use callback and promises but really? Thats the way it is should be working? And what about that if you need one functionality than you dowbload a module but with that you are started to depend from other 737373737 packages.
I am just simply not getting this hype around JS.24 -
Javascript promises: I JUST WANT THE FUCKING VALUE OF A PROMISE.
WHO THE FUCK THOUGHT PROMISES SIMPLIFIED ANYTHING?!11 -
Fuck you JavaScript with your blocks within blocks within blocks, your promises and callbacks, your million of libraries that are doublons or not finished. Fuck you with your assigning variable before functions, fuck you!11
-
When your egghead boss (who is a dev, BTW) fails miserably in understanding that JavaScript fetch does not behave like the default synchronous nature of requests in Python.
After failing to make him learn about the asynchronous nature of JavaScript promises, he ends the discussion by saying "that's why python is better than js"
*facepalm*2 -
I just want to throw out there for Javascript developers, async and await are the two best things to ever happen to promises.3
-
Too many broken promises then I don't care anymore.
Javascript has ruined humanity. Catch me on my way out. -
promises in JavaScript have really spoiled me
it's the most optimal way to do async without leaving much on the table
there's a promises library in rust and the guy who wrote it says it sucks because it spawns new thread every time you execute a bunch of promises
and I finally, through my fogged brain, managed to get the bright idea to write what I want to make in rust in JavaScript and holy hell it's sexy to work with promises. there's no performance left on the table. you do things as fast as possible
but if I take this JavaScript usability code I made and make it possible syntax-wise in rust I don't see how I would be able to do it without starting new operating system threads every time I execute any promises (or set)
I can take the overhead hit but this sounds retarded
and this isn't even touching upon how in rust everything needs to have a predetermined data type. so you can do lambdas and capture variables and send in variables into a thread that way, but to return the return object must be a consistent type (synchronizing the order data was sent in to the data sent out aside, haven't written that yet should be fine though)
which is fine if you are making a threadpool and it'll all be returning one data type
but this means you can't reuse a threadpool you made elsewhere in the program
the only thing that could fix async is to literally be compiler-enabled. it would have to work like generics and automatically make an enum of every type that can return, and only then could you re-use the threadpool23 -
JavaScript is new the PHP.
Reading a stackoverflow question about async functions and await-usage, and lot of well-intended answers show no understanding of the concept. Some fail to understand that the scope is about promises. They don't know that, yes, *every* async function *always* returns a Promise and that within an async function it's synctically the same to do either `return x` or `Promise.resolve(x)` or `return new Promise((resolve) => {resolve(x)}), and they fail to realize what await does or doesn't do and are oblivious about how awaiting at certain stages can have huge performance impact when compared to either Promise.all or Bluebird.map.
Grasping promises is hard in the beginning, I get that. But please don't share your lack of understanding as fact. -
A dev in the team just found out about JavaScript promises. Now he is putting them everywhere but never handling errors, so it's impossible to tell where the app is actually failing because the error points to the Babel polyfill and the stack trace is not long enough.1
-
I honestly hate dealing with promises in JavaScript. Asking permissions just to autoplay a video just like the client requested.6
-
I just bumped into a javascript problem that exceeds the stupidity of previous ones:
Because promises can be retained after they settle, and handlers attached thereafter are pushed on the microtask queue, a promise rejection can't be asserted to be unhandled until the promise in question is GC'd.
Of course this is nuts so engines will conclude that a promise rejection is unhandled if there are no handlers at the moment of rejection.
I hate this language.10 -
```
public someMethod(index: string): Promise<void> {
return Promise.resolve(someAsyncFunction().then(() => {
return;
})
.catch((error) => {
this.logger.error(error);
throw error;
});
```
Somebdoy doesn't know their async / await syntax but they wanted aboard the promise-hype train. There is an entire class in that style.1 -
So... what the fuck is wrong with people in this company for fucks sake!
Dudes use promises and always call resolve()
Me: And how do you fucking handle errors?!
Dude: Well we call resolve with 2 arguments and error goes first obviously!
Me: why no callbacks for fucks sake!!
Manager(defending the dude): you don't understand we told the client that we would use bluebird promises. Client liked it so much that is why we got the job in the first place!
Me: (jaw opened - silence)....
Dude:(goes out happy for winning the argument)3 -
Just use a promise that sets this variable, and then you can use the variable as long as its after the promise declaration.
No, just no. Thats not now asynchronous code works.2 -
There's a special place in hell for JS people using `.then()` and `.catch()` instead of simply `await func()`.
Why have 5 lines of code with an await, when instead you can have 5 nested `.then` callbacks.
And yes I know there are some cases where async/await isn't applicable, but that's rather rare25 -
I wrote my first proper promise today
I'm building a State-driven, ajax fed Order/Invoice creation UI which Sales Reps use to place purchases for customers over the phone. The backend is a mutated PHP OSCommerce catalog which I've been making strides in refactoring towards OOP/eliminating spahgetti code and the need for a massive bootstrapper file which includes a ton of nonsense (I started by isolating the session and several crucial classes dealing with currency, language and the cart)
I'm using raw JS and jquery with copious reorganization.
I like state driven design, so I write all my data objects as classes using a base class with a simple attribute setter, and then extend the class and define it's attributes as an array which is passed to the parent setter in the construct.
I have also populateFromJson method in the parent class which allows me to match the attribute names to database fields in the backend which returns via ajax.
I achieve the state tracking by placing these objects into an array which underscore.js Observe watches, and that triggers methods to update the DOM or other objects.
Sure, I could do this in react but
1) It's in an admin area where the sales reps using it have to use edge/chrome/Firefox
2) I'm still climbing the react learning curve, so I can rapid prototype in jquery faster instead of getting hung up on something I don't understand
3) said admin area already uses jquery anyway
4) I like a challenge
Implementing promises is quickly turning messy jquery ajax calls into neat organized promise based operations that fit into my state tracking paradigm, so all jquery is responsible for is user interaction events.
The big flaw I want to address is that I'm still making html elements as JS strings to generate inputs/fields into the pseudo-forms.
Can anyone point me in the direction of a library or practice that allows me to generate Dom elements in a template-style manner.4 -
Since I can't get my user stories today, I started on trying getting my angular frontend to communicate with my symfony backend. I now feel like I need a lot of climbing gear, because I get the feeling I went too deep into the rabbit hole.
getting quite confused with Observables and promises.1 -
Typescript is my new favorite and my grudge is the stupid scoping of type assertions. I have an async function that checks whether a variable is set and awaits a change event if it's undefined. This function is working javascript but invalid according to typescript, because it relies on the exact type changing while the function is running. I had to convert it to a mess of promises to bypass this because (and this is the best) the callback-based syntax of identical meaning will reset all type assertions, even locals that are never written after the callback's creation.8
-
I love and hate javascript. I set out to do a fully ajax/state driven form interface that operates with multiple interdependent data objects which all extend a base class.
React/Angular may have been a better call but I just didn't have time so I needed to rapid prototype in jquery /vanilla JS.
I'm in the midst of learning and refactoring all the ajax calls to promises and then to async/await, so it's a huge learning experience...
Meanwhile I've got to build objects to represent the data on the backend which is all legacy OScommerce/PHP
Hell of a ride. -
Ugh trying to refactor a Node.js MUD codebase to use mongodb. It currently accesses/stores it's data in json files via synchronous FS operations. Callback and/or .then hell, here I come!
-
```
Error: Resolution method is overspecified. Specify a callback *or* return a Promise; not both.
```
(ﾉ≧∇≦)ﾉ ﾐ ┸┸)`νﾟ)･;’.
Top Tags
Weekly Rant
View