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
-
@M1sf3t Yeah, but simply declaring something won't cause a memory leak, at worst gc will take care of it, and there's a good chance minifier will remove that declaration anyway.
If you're concerned about serious memory leaks, there are tools like TypeScript, eslint, closure compiler, ... to detect potential problems at build time; however, if you're not employing any build steps, there's simply no way to check for potential leaks, which isn't just a JS thing, but a thing with interpreted languages in general. -
@Root true. But, based on this rxjs tutorial, it seems like they're just okay with bad code.
-
@M1sf3t I used to write tutorials as a summer job for a few months. And API docs, update logs, help pages, little info popups, whatever they needed. Being technically literate but completely oblivious to the clusterfuck that was the internal logic of the app, after a thorough explanation of the problem domain I could write text that outsiders would understand.
Alright so I have been trudging around in javascript land for a bit and one thing kind of bothers me (correct me if I am wrong I would love to be wrong on this). It seems like a lot of javascript, or at least frameworks, leave a lot of possibility for memory leaks. Like you can create an anonymous object with a method that just kind of hangs out and acts with no way to retrieve it and turn it off. Am I wrong here? Please tell me I am wrong. And for the record I know I can assign anonymous objects to variables in various ways, but I am not forced to.
rant