They are going to have problems finding high calibre software developers (especially in London) who meet the eligibility criteria (No Class A drugs in the previous 12 months, no Class B drugs in the previous 6 months). Not even the UK Prime Minister himself falls into this eligibility criteria!
He recently stated that he hadn't used class A drugs since before he became Prime Minister. So, you know, back when he was leader of the conservative party, he did a bit of cocaine, because that's what political leaders do, and I'm fairly certain that the kind of person who did a bunch of party drugs and fucked a pig's head is totally honest about his current drug use.
The framework is good, however I got faster (fps wise) results using my own rendering functions on Canvas than I was getting using their rendering on both Canvas and WebGL. I think in their efforts to be basically a drop in replacement for Flash/AS3 they have really let themselves down.
Browsers have historically opted for hiding runtime management (debugging, etc) behind myriad APIs, most of which can't be accessed from the running program itself. I would love to see a cross-browser way to hook into these sorts of things without extensions or at least with standard APIs.
Overall this would be much better for us as coders. And this would open the way for all sorts of cool tools. Consider V8's live code reloading functionality. But imagine if it worked cross-browser and could be called from the program itself. Your webserver could send a signal over websocket, and you could perform hot-swapped deployments of your webpage, and all connected browsers would be updated. The browsers could be customers', or they could be inside that mobile device that's a pain to debug.
It would also be much easier to prototype new dev tools and ways of coding. For example, programming against Chrome's extensions APIs (as great as they are) is somewhat limiting - last I checked you lack direct access to the embedded CodeMirror editor for example. There are a lot of security-focused restrictions. So people workaround this. They rewrite editors and file managers from scratch so they can get the desired flexibility (lighttable, brackets, atom, etc).
Personally I love to see projects like MetaES because I feel like they are inching us closer to something that could be the next step.
Indeed MetaES may be a way to pave a path to new kind of development. Bret Victor's work, LightTable, Swift Playground and others proved that small improvements are possible. I believe though, that next bigger step requires new fundamentals and metacircular interpretation plus smart IDE and partial evaluation may be very interesting.
I don't know honestly what's going to pop up along the way, but with MetaES we can get smart completion and better debugging experience in popular editors for sure, it just requires more work and care.
True, however the higher the number of different software packages that participate in your application's operational environment, the higher the chances that one of these exposes security holes.
You have to make a trade-off between complexity and increasing security by isolating pieces of your stack.
Not off the top of my head, although I know the recommendation at least used to be that Node was not run with full public access.
I think it makes sense to separate the security and low level details of serving a public site, and the details of hosting an application though. This is common practice with Django, using gunicorn and nginx, and I believe with Ruby as well in a similar manner.
Django and Ruby /can't/ serve static content at any speed as they block their main thread. Node and nginx use the same model for io, as does Tornado and Eventmachine (though the latter two are nowhere near as popular).