4 ms·
> comp.lang.javascript was a very inhospitable place. To novices and the weak of heart? Sure. I've yet to find a greater source of technical depth regarding Ja
by mkmcdonald 15y ago
> comp.lang.javascript was a very inhospitable place.
To novices and the weak of heart? Sure. I've yet to find a greater source of technical depth regarding JavaScript.
> David Mark's touted his "My Library" as the holy grail of libraries while bashing any others, yet kept it closed source (now abandoned).
It seems that you've turned a blind eye. His code's been available in a multitude of ways (I've used it myself as a learning tool). There's a GitHub repository[0] as well.
> They are as stable as the code using them, just like their server-side counterparts.
The prime difference here is that most browsers do not throw markup errors or halt execution upon a bad tag; they're extremely lenient. Conversely, direct parser access via JavaScript can throw a host of errors and halt execution (as I noted with IE). Fragment builders are hampered because they're either too dynamic for their own good or need to keep a laundry list of valid attributes.
> Would you mind expanding on security?
Apart from the OWASP article I linked earlier, it's more of a statement towards older environments. Browsers today escape input nicely, but that's meaningless for Joe Smith, government bureaucrat on IE 6. I prefer direct node creation patterns via `createElement` et al. for this reason (especially text nodes).
[0]: https://github.com/cinsoft/My-Library https://github.com/cinsoft/My-Library
- subsection1h 15y agoTo novices and the weak of heart? Sure. I've yet to find a greater source of technical depth regarding JavaScript. I agree with you about the usefulness of comp.lang.javascript, but I disagree regarding David Mark's contribution to education. I had to killfile him years ago, mostly due to his use of sockpuppets. Here are just two of his Reddit sockpuppets that I made note of years ago when I still visited Proggit: http://www.reddit.com/user/DeathFromAbove2 http://www.reddit.com/user/DeathFromAbove2 http://www.reddit.com/user/joesixpack3 http://www.reddit.com/user/joesixpack3
- ricardobeat 15y ago> I prefer direct node creation patterns via `createElement` et al Which is exactly what many template engines do. > It seems that you've turned a blind eye Yup. Might have something to do with this: I believe jQuery [...] has been sufficiently debunked [...] dissected to show that there's nothing proficient or maintainable inside a community of inept imbeciles Shut up, idiot. You know better. (at another developer) Or more recently: Who the hell is "we"? I own this dump. ;)
- chc 15y ago> The prime difference here is that most browsers do not throw markup errors or halt execution upon a bad tag; they're extremely lenient. Conversely, direct parser access via JavaScript can throw a host of errors and halt execution (as I noted with IE). In practice, this just isn't really a problem. The situations in which it can happen are specific and limited enough that I don't know if you got really unlucky sometime or if you're exaggerating for effect, but I've been writing JavaScript since the '90s and have never found this to be much of an issue — particularly since libraries can easily smooth over it. And if you think innerHTML can throw errors, you should check out the DOM API. The set of valid inputs to the DOM API is far more limited than for innerHTML. document.createElement("oh no") will throw an error in every browser around.