Comment by mkmcdonald | Hacker News Reader

Comment by mkmcdonald | Hacker News Reader

Parent Full thread

> This might go without saying, but simply knowing a JavaScript library isn’t sufficient any more. I’m not saying you need to know how to implement all the features of a library in plain JavaScript, but you should know when a library is actually required, and be capable of working with plain old JavaScript when it’s not.

I'd like to think this is because ideas of proper scripting have slowly propagated from goldmines like comp.lang.javascript and into the mainstream. People like David Mark have pulled back the jQuery curtain and shown developers that education really is the solution, not mindless abdication of responsibility.

> It wasn’t so long ago that it was entirely typical for servers to respond to XHRs with a snippet of HTML, but sometime in the last 12 to 18 months, the front-end dev community saw the light and started demanding pure data from the server instead.

Client-side templating was and still is a sham. It requires either an unstable "fragment builder" or `innerHTML` calls. Both are neither stable nor secure (IE is very strict with `innerHTML` in particular). I've dubbed `innerHTML` the "eval" of the DOM as it exposes an external parsing engine to do the developer's dirty work.

Server-side processing is still the best option, particularly because of powerful parsers and the ability to hide domain logic. OWASP has an article[0] that covers XSS and DOM scripting that's fairly interesting.

[0]: https://www.owasp.org/index.php/DOM_based_XSS_Prevention_Che...

So what's the big difference of doing it on server side v/s client side? You can get it wrong on both sides.

Especially what's wrong with a templating system? A templating system on server side can help avoid casual escaping bugs by doing automatic escaping of everything by default. Exactly the same thing can be done on client side.

OK, I think I found the quote that is troubling you:

> It has been well noted by the group that any kind of reliance on a JavaScript library for encoding would be problematic as the JavaScript library could be subverted by attackers.

So basically we are talking about the case where users machine has been compromised? In such a case I don't really see how you can be sure of anything - that user is screwed.

At the same time the article suggests multiple ways of encoding the data on client side... I'm a bit puzzled.

Maybe what they really meant was that you shouldn't hope at server side that the client side correctly performed the encoding, like hoping the client will escape you database query arguments... but that's just basic everyday knowledge.

I'm confused by the contrast you're drawing. Aren't you going to be using innerHTML if the server sends back HTML? That's how I always remember seeing it done.

Yes, there are only 3 ways to render HTML in a browser; through a page load, innerHTML, or DOM apis (mostly createElement and appendChild).

and iframe, though it's also page load

I'm not terribly plugged in to the front-end developer community, so don't take this as authoritative, but my preferred (and more reliable) method of handling server input is generally to append new elements to existing, 'container' elements already present on the DOM.

In context, I might have a 'tweets' div on the page that is empty on page load, but which will be populated by appending new div or li elements to.

But how are you doing that if the server sends back HTML? Like, say you ask for a tweet, and the server sends back the following:

  <div class="tweet"><div class="header"><div class="username">rihanna</div><div class="retweet"><img src="retweet.jpg" alt="retweet"></div><div class="tweet-body">Check out my new tattoo of a woman getting a recursive tattoo!</div></div>

You can't send that to document.createElement. Your only options AFAIK are innerHTML and writing your own DOM parser to build up a tree and use the DOM API to create the elements one by one (which will be OMGslow).

And of course appending a new element doesn't make a lot of sense if your changes are transformative rather than additive (e.g. collaborative editing).

So are you suggesting we give up entirely on single page apps and go back to a full refresh of the page whenever the search terms change on a page?

I am not quite clear of what you are suggesting here. How do you build a system like gmail with it's great response times without innerHTML at some step?

comp.lang.javascript was a very inhospitable place. David Mark's touted his "My Library" as the holy grail of libraries while bashing any others, yet kept it closed source (now abandoned).

> an unstable "fragment builder" or `innerHTML` calls. Both are neither stable nor secure

They are as stable as the code using them, just like their server-side counterparts. The parser isn't any less stable when called from innerHTML. Would you mind expanding on security?

> 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

> 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. ;)

> 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.

    To 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/joesixpack3

Maybe you should take your opinions about not using client-side code back to 1998

Reply on news.ycombinator.com