Earlier quoted context omitted.
/disclaimer/disclosure/ (When you disclose something, it's a disclosure.)
You're correct - thanks! I've fixed it, for anyone else wondering what this is about.
(Using 'i.e.' when meaning 'e.g.' is similarly frequent.)
51–60 of 111 posts
Earlier quoted context omitted.
/disclaimer/disclosure/ (When you disclose something, it's a disclosure.)
You're correct - thanks! I've fixed it, for anyone else wondering what this is about.
(Using 'i.e.' when meaning 'e.g.' is similarly frequent.)
Earlier quoted context omitted.
This is too true. I've had a software engineer complain to me at how unfair his last interview was because they asked "esoteric javascript" questions in a front-end javascript development position. I asked him what questions he found tricky and a lot of them are really simple javascript 'things' (scopes, closure, iife, etc) that would come up sooner or later when you're working with the language
I think there is still a lingering mentality that you don't have to be an expert with JS to do front end work, and that's just not the case anymore.
I still remember being at a conference about 6 years ago. We were on lunch and talking shop with several other front-end developers. Of course jQuery comes up and people start asking if they should learn "vanilla" JS first before using jQuery.
Still remember one developer blurting out, "Yeah, jQuery is so easy to use, you just cop/paste the code, you don't even really have to know JS. I don't see any reason to learn the basics of JS." The crazy thing is there were a lot of heads nodding in agreement at the table. That's how it used to be, if a developer needed to do something with jQuery, they'd just look for a plugin and use that.
Today? No way can get away without knowing the language. Too many frameworks, too many options to mix/match languages to get a really good workflow process. You can't just jump in and not know how Angular directives work or Backbone collections work without knowing exactly how these things work.
IT's a different world out there nowadays.
Once every couple years or so something comes up that forces me to dip a toe back into 'this'. If Plan A (find a way to avoid it) fails, I go to Plan B: relearn the minimum necessary and forget it as quickly as I can. I'll never pass a JS job interview, but since another life goal is to never endure another job interview, that part's ok too.
I've been writing JS a long long time and my strategy has been to never learn the intricacies of 'this', or the other bad neighborhoods of that language (but especially 'this'). I just avoid those neighborhoods. I write functions at the top level, keep all the signatures explicit, and enjoy the things in the language that are straightforward. Once every couple years or so something comes up that forces me to dip a to…
I mean, I do know common pitfalls and I can use `this`, etc., it's just that I find it's easier to avoid them entirely and leads to more readable code IMHO. In a way my JS tends to just be very scheme-like.
I've been writing JS a long long time and my strategy has been to never learn the intricacies of 'this', or the other bad neighborhoods of that language (but especially 'this'). I just avoid those neighborhoods. I write functions at the top level, keep all the signatures explicit, and enjoy the things in the language that are straightforward. Once every couple years or so something comes up that forces me to dip a to…
Funny. JS is my main language, and I personally also don't know most of the intricacies of JS, and we seem to share the same mindset. I mean, I do know common pitfalls and I can use `this`, etc., it's just that I find it's easier to avoid them entirely and leads to more readable code IMHO. In a way my JS tends to just be very scheme-like.
Mine too! I've felt for many years that we were lucky that Eich happened to have read SICP not long before those fateful two weeks in 1995. For all that we all love to hate JS, the language of the web could have—and to judge by all historical precedents, should have—been much worse.
I've been writing JS a long long time and my strategy has been to never learn the intricacies of 'this', or the other bad neighborhoods of that language (but especially 'this'). I just avoid those neighborhoods. I write functions at the top level, keep all the signatures explicit, and enjoy the things in the language that are straightforward. Once every couple years or so something comes up that forces me to dip a to…
Earlier quoted context omitted.
You're correct - thanks! I've fixed it, for anyone else wondering what this is about.
NP, it's so common an occurrence on HN, I think it's self reinforcing. :) (Using 'i.e.' when meaning 'e.g.' is similarly frequent.)
I've been writing JS a long long time and my strategy has been to never learn the intricacies of 'this', or the other bad neighborhoods of that language (but especially 'this'). I just avoid those neighborhoods. I write functions at the top level, keep all the signatures explicit, and enjoy the things in the language that are straightforward. Once every couple years or so something comes up that forces me to dip a to…
What intricacies are you referring to? I feel like I wouldn't get very far without knowing at least certain things about "this". For example how to to use bind, call, apply. Or rather certain things would be more tedious.