A Baseline for Front-End Developers
> 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.<p>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.<p>> 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.<p>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.<p>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.<p>[0]: <a href="https://www.owasp.org/index.php/DOM_based_XSS_Prevention_Cheat_Sheet" rel="nofollow">https://www.owasp.org/index.php/DOM_based_XSS_Prevention_Che...</a>