domenicd

25 ms·

211.
by domenicd 11y ago
It's important to remember that ChakraCore only currently builds on Windows, so this is only for Windows Node.js builds. The ChakraCore roadmap [1] shows that they plan on porting the interpreter to Ubuntu, but not to Mac OS, and they
212.
by domenicd 11y ago
Chakra only works on Windows. They have on their roadmap plans to work on the interpreter on other platforms, but nothing about getting the JIT running. So I sincerely doubt we'd see a switch.
213.
by domenicd 11y ago
Although you're right in general, this sentence is pretty confused: > You can have custom elements in Angular without a shadow DOM, hence the existence of Polymer. Angular's "custom elements" are not custom elements a
214.
by domenicd 11y ago
This is just false. `class` is sugar over prototypes. Nothing is lost.
215.
by domenicd 12y ago
The good news is ES7 is actually named ES2016, and will come out in one year. The bad news is nobody has actually stepped up to champion such an addition, so it's looking unlikely that such a feature would be implemented in 2 browsers
216.
by domenicd 12y ago
Crockford is no longer in TC39 and hasn't attended for quite some time now (maybe a year).
217.
by domenicd 12y ago
Incorrect. We support the V8 versions shipping in stable Chrome and, to some extent, onward. Per http://omahaproxy.appspot.com/ current Chrome is on 3.30.33.16, so we support that. 4.1 is not quite supported yet, but it&#x2
218.
by domenicd 12y ago
Hi, can you point to where on v8-users you got this impression? In general we are much happier with how io.js aligns with supported V8 versions.
219.
by domenicd 12y ago
> a beta for the bleeding edge, stability for the enterprise And yet, Node.js is using unsupported versions of V8 and libuv, whereas io.js is on supported ones. I'm not sure that's exactly enterprise stability.
220.
by domenicd 12y ago
As does the Google Cloud Platform.
221.
by domenicd 12y ago
Nope. They're using V8 3.28.73 and libuv 1.0.2, both of which are abandoned by their maintainers.
222.
by domenicd 12y ago
We haven't started implementing proxies in V8. There was a prototype implementation of an old proposal but that's kind of dead code now.
223.
by domenicd 12y ago
It's not an experimental proposal for ES6, it's part of ES6, which is now finalized as of our most recent TC39 meeting last week. (There will only be editorial fixes going forward.) Regardless, it doesn't matter what language
224.
by domenicd 12y ago
The fiction that formal publications of standards matter should not be propagated. Implementations are well under way. (I say this as a member of the TC39 committee in charge of the ECMAScript standard.)
225.
by domenicd 12y ago
Ugh, please don't use that. The semantics of --harmony_arrow_functions are totally different from real arrow functions. Your code will break horribly.
226.
by domenicd 12y ago
In addition to the other responses, the pipe version will get initial chunks of data across the HTTP connection sooner, so that the user starts seeing data on their screen.
227.
by domenicd 12y ago
No, they shouldn't reinvent the wheel at all. They should reference the WHATWG specs, like they do IETF and Ecma specs. There's no "reusing" going on here, just plain old copying-and-pasting.
228.
by domenicd 12y ago
Exactly. Unfortunately they can't even bring themselves to do this. See e.g. http://www.w3.org/TR/html5/references.html#refsURL wherein they add in a non-normative note a link to the WHATWG URL spec, but in t
229.
by domenicd 12y ago
This is pretty much the opposite of how things went down. If browsers followed the W3C, we'd be living in XML utopia (XHTML2, XForms, XLink, XEvents, etc.). In 2004 a group of implementers (specifically Mozilla, Opera, and Apple) propo
230.
by domenicd 12y ago
Many of the foundational specifications of the web are authored and maintained by the WHATWG these days: https://spec.whatwg.org/ - DOM, HTML: obvious - URL, Encoding, Fetch: foundational building blocks - XHR, Fullscreen,
231.
by domenicd 12y ago
Yes, actually. We'd encourage the HTML working group to do original work. Many W3C working groups do that, e.g. the webapps working group worked on web components and various other specs, and it helps the web platform.
232.
by domenicd 12y ago
http://ln.hixie.ch/?start=1140242962&count=1
233.
by domenicd 12y ago
That is how the Push API works as well. In fact usually developers will be using APN or GCM when they use the Push API.
234.
by domenicd 12y ago
Permissions are per-origin.
235.
by domenicd 12y ago
I think that attack is exactly what HSTS ( https://en.wikipedia.org/wiki/HTTP_Strict_Transport_Security ) is meant to solve.
236.
by domenicd 12y ago
Some links: https://blog.mozilla.org/mrbkap/2013/08/12/the-old-html-pars... http://ln.hixie.ch/?start=1138169545&count=1 https://bugzilla.mozilla.org/show_bug.cgi?id=
237.
by domenicd 12y ago
Incorrect. HTML5 synthesized the exact behavior that was closest to the majority of browsers. But not all browsers agreed (e.g. Mozilla would change its HTML parsing behavior depending on network packet boundaries), so there was still effor
238.
by domenicd 12y ago
> Responsive images could have been an XHTML module with a javascript implementation. The browser vendors could catch up and provide native implementations in their own time, but that would not postpone immediate usage. This is exactly w
239.
by domenicd 12y ago
It wasn't really a choice in favor of "easier to author." It was a choice in favor of "will this actually get implemented, or just be fancy theorycraft?" No browser vendor was going to ship new features only in XML
240.
by domenicd 12y ago
This is a common strawman, with several examples to disprove it: - https://github.com/cujojs/curl - https://github.com/montagejs/mr - https://github.com/substack/wreq

More ›