mannix

Second take: whhhhhaaaaaaaat native color pickers!!? That is really neat, must have missed that addition.

Here's my take: this is very valuable on sites that dynamically load new pages without an actual browser navigation (read: pjax).

It is not useful (and indeed it is an anti-pattern) for static sites in which case you'd want to just use the browser loading mechanism, that the user (hopefully) understands and is used to.

True, its purpose is a port scanner, not a website scanner.

Go to the Sources tab and click the || button to pause javascript. If you're wondering where the code is, just curl the URL :) (or, with Web Inspector open, refresh the page, go to the Network tab and select the only request.

Probably to bust possible caching.

It's fewer DOM manipulations from Javascript yes. The browser will still internally change the styles associated with the DOM elements, just without the JS overhead.

(Rereading again..) The JS claim is silly. He is saying that because we are dynamically creating a single style, that show/hide logic will be faster. I disagree with this, since adding a CSS selector to the page means the page needs to rematch that new selector against every element of the page and re-render each matching element, same as if we had just changed the matching elements with javascript.

EDIT: thinking on this some more, it actually should be a bit faster for huge collections, since javascript has to update items individually, whereas the browser has probably optimized this code path.

You don't need to use javascript to hide/show matching elements. He also mentions something about it being faster than just an indexOf(), but gives no real benchmarks, so take that with a grain of salt.

in js: console.log("\u062E \u0337\u0334\u0310\u062E")

You can also cmd(right)-click on the titlebar, and choose a parent.

No, but you can make it much more difficult by passing something like a frame of the game state, where some variables (like Timer) are passed in plaintext, and others (which are calculated in an aggregate way at runtime, e.g. can't be easily guessed) are hashed for double checking by the server. Of course double-submission is still an issue, but nonces and server-side duration checks should help you here as well. Compress the &*!# out of your source and.. it will at least take an attacker a lot of time to break.

afaict (would loved to be proven wrong here) Firebase gives you basic protection but any script kiddie will still be able to defeat it.

Edit: grammar

Table-based layouts will bite you down the road. Ever try to make a div that completely fills a td? Ever try absolute positioning in a table? It is tempting to use them because they are so simple and "just work", but they come with unforeseen consequences.

Yeah, after you click a huge "VOID MY WARRANTY" button. I am surprised they made this change after the recent tor exit node exploit...

Yes, the only reason I'd use __defineGetter__ would be a fallback for Object#defineProperty.

I'm curious if the IE8 limitation could be worked around, using something like:

    if (ie8)
        RactiveBaseModel.prototype = HTMLAnchorElement.prototype;

Crap. you're right. that's probably a dealbreaker.

I have a question, since this has been bugging me with other js MV* frameworks lately... Is the set() method necessary for updating single attribute? All browsers have supported getter/setter APIs (__defineGetter__ and Object.defineProperty), why not take advantage of them? Being able to say this would be cool:

    div.color = 'blue';

instead of:

    div.set({ color: 'blue' }); or div.set('color', 'blue');

Or would this cause other problems that I'm not thinking of?

Edit: my ruby cap is on a little tight today. Javascript programmers might not expect extra logic to be run just by updating a property. I still think it would be cool though :)