HN user
Large sends seem to crash the playground with a JSON parse error. eg change the first example 'Simple send' to send `10000000000000000000` (`send [USD/2 10000000000000000000]`) and there's a crash
A quote from an Ecma presentation
"ECMA for instance has made all the standards for DVD and optical disks. There were 5 recording formats. So there you are a little bit uneasy, of course. And again after a few beers I can ask the people in the room. Why do you want to have 5 formats? Do you still call that standardization? The answer is always the same: You are well paid. Shut up"
or big.js
Yes, that's right. It requires someone to wrap the HTML in '<Book>' tags but then it can autodetect the CSS Rules applied and display them.
I'm working on a new version of the homepage -- it's a hard concept to describe.
Thanks, I believe it's fixed now. (Chrome on iOS is essentially Safari so I guess the similarity of errors was expected)
This should be fixed now, let me know how it goes
This should be fixed now
(sorry but it took a while to find an iOS device to test on)
I'll fix this asap
No they usually work.
Your website is completely broken at higher resolutions
If you include the hash of application.js in its filename, I don't see the problem.
Then, and I'm not meaning to sound harsh here, but you don't understand how to generate permanently cachable URLs, and that's what's required here.
If dependencies aren't included in calculating that hash then some users may run several different versions of the application at once (with all the errors that entails).
for a page with 2.4MB of JS spread over 296 files.
Fair point, there is always sweet spot in benchmarks like this. That said there are examples of delays that they mention which seem to be independent of the amount of requests.
> I believe you misread. They use a shallow tree in their scout js file; all of the resources a page will need are declared there
Being shallow doesn't fix the problem when resources are split up at all and that's what the article (correctly) suggests to benefit from HTTP/2 features. As we move away from a single bundle.js file we need to think more about how to manage splits. E.g. The article talks about splitting into `application` and `vendor` hashes, and you mention grouping by churn or functionality. So presumably we agree that being able to split files without significant speed loss is a major feature of HTTP/2.
All I'm suggesting is that the filename hashing strategies need to be improved to avoid application errors when splitting.
If we don't improve filename hashing strategies then we'd still have to rely on small HTTP cache durations, or we'd get temporary errors while caches expire, which is a problem because the whole point of the article is to have extremely long cache durations. As they say,
"Files loaded by the scout can have extremely long cache times because [...]"
Then as the article says,
"This can be solved by using hashes of the file contents rather than version numbers: vendor-d41d8cd98f.js. If a file has not changed, its hash will remain the same."
This is bad advice because they don't talk about dependencies affecting hashes. Even if that file hasn't changed but it depends on another file then its hash needs to change too, or else application.js will will have different contents depending on when it was loaded. Eg.
application.js has a requirejs import of vendor.js
requirejs(["vendor.js"], function(vendor){ });
So if we generated a naive hash as suggested then application-45345345345.js might look like,
requirejs(["vendor-3455345ABCDFFF.js"], function(vendor){ });
Then vendor.js changes but application.js doesn't, and so application-45345345345.js is updated to read,
requirejs(["vendor-f2ab4cde6f55.js"], function(vendor){ });
And now you can see the problem that application.js didn't change but it's dependencies did, so application-45345345345.js will have different data depending on when you access it which is exactly what you don't want with long HTTP cache durations. This can cause mismatches in what version of a file is imported, and cause application errors.
The only way to have permanent URLs with content that doesn't change (a prerequisite for long HTTP cache durations) is to include dependencies in the calculation of filename hashes. Or you could have an dynamic resolver (eg. based on a manifest file) but ES6 and SVG have static imports. More to the point though, if you can resolve it at build time why not?
When they say "This can be solved by using hashes of the file contents" this is a fundamental mistake and it's simply bad advice.
It's been found that resource concatenation is still more efficient http://engineering.khanacademy.org/posts/js-packaging-http2....
And 'building for http2' seems to be advocating hashes in filenames without neccesarily walking the dependencies, which can have cache problems http://holloway.nz/r/hashes-in-filenames/
ES6 imports are static (you can't use JS to dynamically include a file) so this means transitive dependencies need to be resolved at build time, not by using a manifest file which resolves paths clientside. This also applies to (eg) SVGs that reference JPEGs because you probably don't want JS involved there either. Manifest files are a bad idea, except perhaps for instructing webservers to tell browsers to preemptively download files. AFAIK there isn't a standard for this yet so a manifest doesn't solve the problem.
Ps. I've got a gulp build for http2-style packing and I'll release it on my github in a few weeks (same account as my username)
crossorigin.me
Yes, at least 26 people
Alternative is my Docvert http://github.com/holloway/docvert-python3 software... it works on Linux/Windows/OSX though it's mostly for reading DOCX/DOC/ODT and not for writing.
Hi I've added a side-by-side view. Just click 'view source' and start typing.
http://holloway.github.io/doctored/
It's the first version so things will change and it's a bit buggy right now. Should stabilise in a couple of days, cheers :)
Just added a [+] to each block element
I'm not really that familiar with Xopus so I can't really comment. Judging from the screenshots (E.g. DITA) it looks like it has a lot of per-schema customisations which my software doesn't have.
tldr; I'm going to allow double <enter>, and I'm going to add a [+] to the top-left of every block but that's not done yet and in the meantime you'll have to edit the XML ('view source') to make those kind of changes.
Long answer: Currently hitting <enter> clones the current block element but when there are block elements within block elements (such as chapter > para) there's no way to know what <enter> should mean. Other software (some wordprocessors) use double <enter> to step up a level, and I guess I'll support that. For UI reasons though I think that I'll also add a [+] button to the top-left of block elements (above the vertical label, above the nodeName). And I should also support pasting XML more (it kind of works right now but it needs more work).
I'll be a bit busy for the next week on a live split-view of the XML, but after that I'll work on cloning nesting block elements. I'll say when it's done on @hollowaynz -- cheers :)
Something like a Select2 dropdown? Not a problem. I'll do that.
edit: Actually selectize.js looks a bit nicer
I'll add a side-by-side view this week :)
I'm not sure how JSON would be displayed in this kind of interface. Any ideas? I'll have some attempts and get back to you.
Hi, it (sort of!) already does support arbitrary schemas, or were you meaning that you want to be able to give it a schema through the interface (URL/file upload)? It doesn't currently support the later, although there's no reason why it couldn't.
Currently if you wish to add a schema just needs a thin wrapper where you tell it the elements that are to be displayed as inline (rather than block).
Specifically, an .RNG or .XSD file just needs a tiny reference to a schema family: https://github.com/holloway/doctored/blob/master/doctored/sc...
And that config file is a pointer to these schema families https://github.com/holloway/doctored/blob/master/doctored/js... that name the inline/block config.
It would be interesting to know if that was just the low-spec hardware that FirefoxOS targets. E.g. would a different approach also be relatively slow on that hardware.
Prism might only be part of it, there are ways of breaking up projects in budgets obviously. It could just feed the data into another system
I think that's a bit generous. They look over the request but if the result set is too large it couldn't be reasonably vetted by lawyers. Eg, they would have a look at it but we don't know how rigorous they are or could be.
Exactly, there's enough wiggle room in non-technical terms like "direct access" that both the accusation and the denials could be true. Does it mwan root access, SQL access, or if PRISM involved a search API (thin wrapper around the db) would that count?
The new Opera (using Chrome) lacks vertical tabs unfortunately. Can't seem to find any info on whether it'll come back
An argument in favour of the W3C policy is that DRM video plugins could be retired but what about all those sites that attempt to prevent right-click|save-as on photos, or on JavaScript, and why wouldn't they use DRM too? The EME draft doesn't just handle video, does it?
The label is a bit weird, I agree, but personhood is an established legal concept with clear interpretations and case law so I just think of it as lawyer speak. Extremely disabled people may lack clear communication and yet a person who makes decisions on their behalf is guided by similar principles. The argument in favour of personhood is that the benefits of that legal history outweigh the superficial qualms by using a slightly wrong title.
While other animals have sentience too this is about the thin edge of the wedge, and what's achievable in politics. You go for the creatures that are nearest to human and then increase it as is appropriate. It's important to establish precedent and not to go too far at once or else the first step will fail and politicians won't touch it again for a long time. I see it more as practical political expediency rather than a lack of understanding of how non-apes may be sentient too.