[HN Gopher] Modern JavaScript Tutorial
___________________________________________________________________
Modern JavaScript Tutorial
Author : Hbruz0
Score : 83 points
Date : 2022-05-15 20:24 UTC (2 hours ago)
(HTM) web link (javascript.info)
(TXT) w3m dump (javascript.info)
| taesu wrote:
| Preparing to interview with JavaScript. This is helpful, thanks!!
| mosdl wrote:
| having just gone through that, my pro tip is: look at
| implementing promise.all() as well as extending the code to
| have a limit on concurrent promises/etc. very popular question.
| j-james wrote:
| This is excellent. I think
| https://www.internetingishard.com/html-and-css/ complements it
| well as an introductory tutorial to HTML/CSS.
| Veuxdo wrote:
| In almost 10 years of professional development with
| Javascript/Typescript, I have never encountered a colleague using
| the call/bind/apply keywords (or "this" outside of classes). I'd
| say almost all professionals deliberately avoid 80%+ of the
| language in practice.
| cxr wrote:
| Relevant: "How (and why) developers use the dynamic features of
| programming languages"
|
| <https://doi.org/10.1007/s10664-012-9203-2>
|
| <https://users.dcc.uchile.cl/~rrobbes/p/EMSE-features.pdf>
| umvi wrote:
| I'm currently working on a game[0] similar to Untrusted[1] and
| I had to use bind (among other techniques like variable
| shadowing) in order to "sandbox" player provided code from
| interfering with other game objects or accessing the global
| scope (obviously there's no perfect sandbox, but it at least it
| makes it more difficult for players to do naughty things). Bind
| is useful because you can control the meaning of "this" when
| evaluating user-provided code, and I use it to deny player
| access to the parent scope by calling bind(undefined).
|
| [0] https://www.bryanpg.com/games/pragma_twice
|
| [1] https://github.com/AlexNisnevich/untrusted
| tim1994 wrote:
| Have you considered running "untrusted" code in a worker?
| That way the code can not interfere with the global scope.
| eBombzor wrote:
| Which is great. Mozilla does the same thing with C++. No reason
| to use complex footguns for simple tasks. Obviously there are
| use cases but mostly not for 90% of CRUD front end devs.
| Jasper_ wrote:
| Yeah, `call` got supplanted by `bind`, and `bind` got
| supplanted by arrow functions. `apply` got supplanted by spread
| parameter syntax.
|
| I've used them before for doing stupid reflection hacks
| (literally just used them today to build a debug UI where I can
| make sliders out of objects), but it's not code I would really
| want to ship in production.
| robgibbons wrote:
| They are very useful at the framework level, if you do much
| work with vanilla JS at scale they become useful for applying
| generic functions against various scopes.
| jollybean wrote:
| Kudos to the author ...
|
| ... but yes - a 'Modern' approach means calling out risks, or
| more abruptly - that which may even be considered 'anti
| pattern' inherent in a language as it evolves over time, with
| hindsight.
|
| Perhaps the most preeminent example would be pointers in C++ -
| which we generally know to use with 'smart pointers'.
|
| If C++ 'were designed today' - among other things, it'd be
| likely that 'smart pointers' would be 'default' and they'd be
| more deeply and seamlessly integrated, and 'direct memory
| reference' would be seen as a 'thing to do only if necessary'
| and a bit of a 'corner case'. Necessary, and common enough,
| surely as in that level of programming we are going to 'go
| there', however, it's something we wouldn't see as normal
| practice, rather something we do but with some other idioms,
| APIs and conventions around it ... possibly with demarcations
| of 'unsafe' a bit like Rust.
|
| I think it's important, because these are precisely the things
| that young developers may become entangled in. It should be
| more like: "By the way this is how this works, but you may want
| to think twice about using it, here are some cases where it
| might be 'ok', here are some cases where it's not".
|
| But I don't want to take away from good authorship either, we
| depend a lot on people stepping up to the plate and doing this
| work. As an aside, it seems almost perverse that 'Big Corps'
| just don't do this themselves. I mean, if AWS uses JS
| extensively, it'd seem reasonable (even from a selfish
| perspective) for them to 'just do' a comprehensive, JS set of
| docs.
|
| It's weird that the world depends on 'a few nice
| dudes/dudettes' to maintain something like 'caniuse.com' and
| the plethora of other such important works.
| serial_dev wrote:
| I also deliberately avoided using them as they (IMO) belong to
| the "bad parts", or at least the parts that most mortal
| frontend devs don't need to use outside of interviews.
|
| With frameworks, it's easy to avoid them and unless you write
| lots of vanilla or you roll your own framework, they just don't
| come up, and therefore I expect my colleagues (and me) to just
| mess things up when we try to use them.
| emteycz wrote:
| Not every tool a language offers should be used in your normal
| day-to-day dev work. Doesn't mean it's useless. I'm writing a
| dependency-less CLI tool with Node and just have used apply -
| super helpful ;-) I've also used it a lot when I wanted a
| dependency-less GraphQL server...
| markhaslam wrote:
| For me this is a great supplementary resource to the MDN docs.
| caseyross wrote:
| Some previous discussion from 2020:
| https://news.ycombinator.com/item?id=25333350
|
| This site is IMO the best reference out there for modern JS/DOM
| fundamentals. It's concise, clear, consistent, accurate, and
| well-organized throughout, which is no mean feat for how many
| topics it covers.
| dang wrote:
| Thanks! Macroexpanded:
|
| _A Modern JavaScript Tutorial_ -
| https://news.ycombinator.com/item?id=25333350 - Dec 2020 (292
| comments)
___________________________________________________________________
(page generated 2022-05-15 23:00 UTC)