nxn

I'd ignore excitement -- if you are actually dying to work on something then put the motivation to fruition. If the problem you're working on isn't fulfilling then challenge yourself by trying to solve it by using a non-conventional approach.

I'm sort of confused, because TLS 1.1/1.2 support across browsers looks to be quite poor at the moment. Especially when given a large number of IE visitors that will likely upgrade to IE11 (first version that will have TLS 1.1/1.2 enabled by default) sometime around the year 2016.

With that said, I was under the impression that sites will need to support TLS 1.0 for a good long while, and if that is indeed the case, would they not be better off using RC4? From my understanding, the RC4 attacks seemed less practical than attacks against the implementation of CBC mode in SSL 3.0 / TLS 1.0?

Trying to pick between omgrofl and lolcode with one life left can be likened to deciding which color wire to snip.

There is an "Oldest First" button that resorts the timeline.

My guesses are: 1) maybe it's a mockery of the redundancy of using "www" in URLs, 2) a clever prank on anyone that attempts to communicate the site's address verbally and doesn't know that the sub-domain portion is optional, 3) a way of making the link catch the eye and create enough curiosity to result in a click.

Just guesses though, I really couldn't find anything concrete about it.

Same is true for drivebyacct2

Which is not the same thing as node's modules. There's nothing stopping me from making global variables within a module "pattern". Contrast that with a node.js module where even if a variable declaration leaves out a 'var' by accident, the global will not show up in anything that imports that module. I.e., there is no chance of name collisions because each node module gets its own unique and clean global scope.

I think the author means that it's not implemented in all the browsers that have a significant share of the browser market.

> On WebGL, we can reinvent presentation and styling entirely without sacrificing performance. Maybe keep parts of HTML, and ditch CSS entirely in favour of something better, and use a JS lib to render it all on GLES hardware, the same in every browser

I'm not sure I follow you when you say "keep parts of HTML". Are you suggesting that we should have a canvas element that spans the entire region of the page, store the actual markup of the page hidden somewhere on the page, and then parse and render that markup to the canvas element using JS+WebGl+<some CSS alternative>? Or are you saying that the browser should simply give up on rendering HTML markup, and give it over to your JS App which will render it itself using WebGL?

> We now have many competing programming languages, competing frameworks, and so on, with a few mainstream ones and improvements/replacements all the time. Rendering entire websites in WebGL enables having the same world-wide innovation in presenting web sites and web apps to users.

If the rendering is done in user/app space, I find it hard to believe there would be any uniformity at all. Everyone would end up having their own unique dialect of HTML that behaved and displayed differently in their own customized WebGL based rendering engine.

EDIT: Disregard that last bit, I misread what you were saying to imply that it would be more uniform than what we have now.

If I was in charge of Toptal's marketing department I would have responded with a new set of ads featuring shirtless Fabio lookalikes.