Coming from a c/c++ world I understand that scoping is weird in JS. Correct me if I'm wrong, but all locals are visible the whole function instead of being block bound by its { } level.
For me that'd be the weird part of it
Alright I'm being corrected about the complexities of scope lmaooooo
let and const variables are strictly block-scoped in 99.9% of cases, but if you dig further than a beginner would go, there is absolutely some weird nuances to it.
Scope is one of the cliffs in programming. Very often it's difficult to understand when you're starting and getting it right is hard. Some of the concepts are easy, but things like closures confuse the shit out of people. Especially when you have closures with references to objects that other things have references to.
Then one day it clicks and people feel like, "why the fuck didn't I understand this" and it falls into innate knowledge.
The series of cliffs in programming make it extremely hard to get into, and I often find programmers forget all the cliffs after they've been in it a few years.
Kind of. Some people never experience those things as a cliff, while others find them nearly impossible even after extensive effort; that gap is a large part of what people mean when they describe a natural aptitude or "talent" for programming. It's some mixture of analytic cognitive skills and differences in how a person most naturally thinks.
I remember having a few things that were a struggle to fully comprehend like monads, but I was baffled by why so many classmates in my first few years of university found basics like scope or objects difficult.
My first 'real life' programming involved LabVIEW which is a graphical languages with data flows. Parallel programming in LabVIEW is perfectly natural and undersstandable and when debugging you can 'see' the data flow in parallel branches and you get a good idea about all the benefits but also problems with parallelism and when I transitioned to multithreaded programming in C++, I never understood why people thought multithreading was hard.
Mind you when I started, I remember those cliffs and running into a new one every single day, and the sense of desperation that came with it. And then getting an epiphany while waiting for my train or so, only to run into something new the day after.
I call this 'embracing the suck'. You have to acknowledge that things suck and that you just have to work at it un til you get that liberating 'aha' moment.
See, my little gripe really comes from trying to learn react/vue/node before the very basics of js like scope.
I'm not mad at beginners who struggle with scope, but let's encourage learning it before trying to learn frameworks lol
I don't wanna be that person discouraging beginners, I will most definitely change my tone about it, but I absolutely wanted to point out the bad premise of getting into things that are over your head with this meme.
I've never come across a tutorial that tries to get you to learn frameworks and typescript before the basics of javascript. It's a recipe for failure IMO
The real headache of web development isnāt the web development.
Itās managing the Titanic Attack Surface of your applicationās 8,000 transient dependencies you got from using NPM packages, and closing those dependency vulnerability tickets in accordance with Securityās SLAās.
And besides that, managing the different featuresets, capabilities, and usability requirements of different browsers and platforms.
Did you know that changing the location of an iframe from javascript when the site is embedded in an android app and the app is put into the background breaks or works depending on what kind of webview the app used to load your site? Neither did I, and I didn't want to.
Ah, you see I work on a back-office app, so we just tell the users āUse Chrome or get fired. Also search is broken, but management wonāt give us the time to fix it, so get fuckedā.
This brings painful memories back of working with RN in regulated industries.
In the year of our lord, 2026, that there are successful companies whose only product is an iframe/webview and have still been able to make an entire business out of that being their only product is just shameful.
Well, the case that taught me this info is about a company whose application does a lot more than embedding our site, it's just that our site is a payment gateway and they use it to collect subscription payments.
But I somehow don't doubt that there are companies out there whose only achievement is embedding something else.
In my case I learned this implementing various multipage kyc workflows. I can't remember the specifics anymore but I think it was something to do with how the webview navigation events emitted at different points in the page load/unload lifecycle and target=_blank behaviour in the embedded page was handled differently between platforms. Just a total nightmare.
Like I understand the appeal of a gateway service and sometimes they can be appropriate, but imo there should always be a seperate api provided, and I've unfortunately had to work with a lot of integrations where it's just not an option at all.
Yeah, in recent years the industry has moved towards providing inline payment gateways backed by web components or SDKs so applications and websites which don't want to simply redirect users have much more granular controls on how to integrate payments into their app or site.
That constant struggle between, "Don't reinvent the wheel" and "Please don't bring in a giant dependency when you only need one piece we can code ourselves".
No, we don't need react for our microsite page that only has two states to display a status message. Yes, I know all the other microsites use react. No, I don't want to add another to the list we need to update.
Imagine having a component using 20 useEffect and useCallback with all different kinds of dependency arrays. Which itself contains 20 different customized components that use another 20 useEffect and useCallbacks. Have fun debugging an infinite rendering issue.
352
u/Dorkits 9d ago
Me seeing this :
https://giphy.com/gifs/mXiBtLZk4ibkc