7 ms·
Douglas Crockford on JavaScript and HTML5
- liamk 16y agoI'm wondering if security was ignored, when introducing HTML5, simply because it isn't as sexy as adding new features? Removing XSS seems like a win to me, especially -- as Crockford points out -- with new technologies like web storage being introduced.
- scrrr 16y agoApparently everyone is happy with Javascript, or there would be different scripting languages on the client-side. Apparently it wasn't an issue whether Javascript should be used in HTML5. Technically a <script type="text/python"> shouldn't be impossible either.
- RyanMcGreal 16y agoIt's not technically impossible but it would be challenging to get all the browsers to support embedded Python, not to mention versioning issues (does IE10 target Python 2.5, 2.6 or 3.1?).
- bobds 16y agoThis feature is already here: Appcelerator's Titanium It supports Python, Ruby, PHP and you can do things like <script type="text/python"> or <script type="text/ruby" src="myfile.rb"/>. They have made an underlying object system that can act as a bridge between Javascript and Python/Ruby/PHP, it's called Kroll. Kroll's source code has been released: http://github.com/appcelerator/kroll http://github.com/appcelerator/kroll Obviously, there are bound to be multiple gotchas when using such a bridge between languages, nevertheless I thought it was pretty impressive the first time I saw it. http://developer.appcelerator.com/doc/desktop/python http://developer.appcelerator.com/doc/desktop/python Scroll to the bottom of the page for an example of using jQuery via Python.
- olavk 16y agoI don't think everyone is necessarily happy with JavaScript, but it is the de-facto standard, and there is no realistic alternative. Sure, we could add a new language, but with various competing implementations we will probably get at least the same amount of interoperability problems as we have had with JavaScript. And because of backwards compatibility browsers will still have to support JavaScript indefinitely in addition to the new language.
- anedisi 16y agoyup crockford is my hero :) his book showed me how to love javascript.
- pornel 16y agoHe's wrong about security being ignored in HTML5. HTML5 added postMessage that allows to isolated DOMs to communicate (previously you'd have to give up isolation), sandboxed iframes (you can embed untrusted content and e.g. disable plugins in it), blocking of link referrers (webmail links won't leak your inbox URL), cleaned up content sniffing, defined exactly how browsing contexts and window proxy objects behave (very tricky balance of backwards compatibility and isolation of pages). Almost every section of the spec has "Security considerations" subsection and whole thing is plastered with security warnings: http://www.whatwg.org/specs/web-apps/current-work/multipage/ http://www.whatwg.org/specs/web-apps/current-work/multipage/ All new features have same-origin restrictions, and are going to support CORS: http://www.w3.org/TR/cors/#origin-header http://www.w3.org/TR/cors/#origin-header There have been other advancements, like CSP and STS: https://wiki.mozilla.org/Security/Features#Origin_Header_.2F_Sec-From https://wiki.mozilla.org/Security/Features#Origin_Header_.2F... which are going to be standardized by AppSec WG at W3C (http://www.w3.org/2010/07/appsecwg-charter http://www.w3.org/2010/07/appsecwg-charter). If there's something missing, he could report a bug (I don't recall anything reported by him): http://www.w3.org/Bugs/Public/enter_bug.cgi?product=HTML%20WG http://www.w3.org/Bugs/Public/enter_bug.cgi?product=HTML%20W... It's even possible to report bugs without registration straight on the spec page: http://www.whatwg.org/specs/web-apps/current-work/multipage/ http://www.whatwg.org/specs/web-apps/current-work/multipage/ And many fundamental issues are really unfixable, i.e. a "fixed" browser would "fail" to work "properly" with many major websites. Lots of simple payment gateways (including some of PayPal) rely on CSRF vulnerability to pass payment data. Google-hosted jQuery relies on XSS vulnerability. The only practical solution is opt-in to new, stricter security models, which is what HTML5 and other WGs are developing.
- olavk 16y agoI think he is referring to a specific issue: He wants a security model that allows "sandboxing" partially-trusted code so that it cannot take over the whole page. Today, if you execute a piece of JavaScript you have to trust it fully. This is an issue with e.g, ads. If an ad includes JavaScript, it can steal your users passwords. He mentions Caja (http://code.google.com/p/google-caja/ http://code.google.com/p/google-caja/) which is an attempt to provide such a security model. I guess this is a serious issue for the big ad-driven sites like Yahoo and Google. He is frustrated that the other parties involved in standardization (primarily browser vendors) does not prioritize this issue. I do agree that it is disingenuous to state that security was ignored.
- makeramen 16y agoQuoted from the video on JavaScript: "eventually i discovered that there is actually brilliance in this language, that it's right in a way that very few other languages ever get right" Can someone please explain this? As someone who is not familiar with JS, I'm very curious to what he means in this sentence.
- pornel 16y agoIt's "Lisp in C's Clothing" (http://javascript.crockford.com/javascript.html http://javascript.crockford.com/javascript.html) JS has first-class functions with closures. This is simple concept that enables lots of interesting constructs — callbacks, methods, currying. It makes event handlers/callbacks very easy (so easy that node.js can rely on them for everything). It allows very flexible "fluid interface" like in jQuery. Mixed with JS dynamism and prototypes allows you to invent your own OOP variants (and JS's standard prototype-based OOP isn't bad either).