I wonder if this project, at least VCL compiler part of it, could've benefited from the use of a parser generator. I understand going slow, but using a parser generator would've allowed for faster development of VCL freeing up time to add more features so it isn't so hard to write for.
This really depends on what you care about. Flow is much better at ensuring type safety in your code while TypeScript has some pretty glaring holes in this respect. In particular, TypeScript allows covariant assignment and param passing which makes it really easy to write unsafe code.
The covariant param passing was fixed some time ago with the (now on-by-default) `strictFunctionTypes` option. Eg `function f(cb: (_: Animal) => void) { cb(new Dog()); }` can no longer be used as `function takes_cat(_: Cat) { } f(takes_cat);`
Assignment is still there though (ie you can still assign a `Cat[]` to an `Animal[]` and push a `new Dog()` into it).
Your example is identical to the case I covered in the second paragraph of my comment. ie your code compiles because it is legal to assign a `Cat[]` to an `Animal[]`, as I said.
When you mentioned "covariant param passing" I assumed you were referring to the long-lasting issue about callbacks, hence my original comment mentioning that that issue has been fixed. It's not useful to differentiate between "assigning a value to a variable of a certain type" and "passing a value to a function parameter of a certain type" because those are identical.
KaTeX strives to match LaTeX's behavior so it may actual be an issue with the screen readability of LaTeX. We're currently discussing ways to improve this in https://github.com/KaTeX/KaTeX/issues/1848. If you're seeing other issues please file a bug report.
My limited understanding of MathJax is that it uses the browser to measure glyphs. KaTeX on the other hand includes metrics for many of its glyphs. Where things get a little tricky is i18n. There are many languages which our current fonts don't cover and thus we have no metrics for them (we make some educated guess about some unicode ranges). It would be really nice if browsers implemented a Font Metrics API, unfortunately efforts to do so appear stalled at the moment.
> I've tended to view JIRA as "the worst of all project tracking tools, except for all the other ones"
I've seen heard this opinion a number of times and I don't believe it's true. TargetProcess is a better project tracking tool. It has a deeper hierarchy for organizing work. It has the concept of teams built-in and allows you to view work across multiple teams and/or projects. It also provides a way to do roadmaps built-in. Everything is included and everything is designed to work well together.
As for the specific criticism about not being able to get a high-level and low-level view in one tool, I think the reason why JIRA does poorly at the high-level view is that it has a very shallow hierarchy of work entities. It has epics => user stories => sub tasks. While projects can also be used to organize work, JIRA unfortunately binds the concept of sprints which is more of a team thing to projects. Thus it's difficult for one team to work on multiple projects or multiple teams to work on a single project.
TargetProcess on the other hand has a separate entities for teams and sprints which allows projects to be used for organizing work. It also has an additional level in the work hierarchy providing the following levels: project => epic => feature => user story => task. This deep hierarchy allows you to group work into larger groups allowing you to see both the high-level and the low-level.
Portfolio allows for multiple layers on top of epics. Boards can be set up to pull from multiple projects, and boards are what are tied to sprints, projects are not tied to sprints (mostly, there’s some oddities).
Portfolio is implemented somewhat badly (Why the hell can’t I do skip level relationships?) but it certainly has the features you say you’re lacking.
Target Process is worse for agile. It is at once too flexible and too rigid. For someone who doesn't take the time to learn the tool, they end up with frustrating and not very useful defaults. For someone who does, you run into limitations like your backlog is always on the left or top because it won't let you move it around. It also ends up that as a power user you end up with a wildly different view from what everyone else sees, which causes additional problems.
Having a few extra levels of issue types in jira would be nice, but if you treat epics like TP features, you can use portfolio to add however many layers the PM and management team want on top.
I think part of BuckleScript's speed may come from the source language, OCaml, being easier to parse. There may also be fewer passes necessary to transform OCaml to JavaScript.
BuckleScript using Reason (with a similar syntax than JS, slower parser than vanilla OCaml) is still one of the fastest around. Mostly a case of very careful and dedicated engineering here (I work on Reason with the author of BuckleScript). Additionally, we try to work smart and delegate most of the build process to Ninja, which itself is one of the fastests around.
But I believe the topic here was about runtime performance of using a language to compile JS, not about the build speed of working in that language itself. In which case you’ll still get some wins writing a JS toolchain in BuckleScript (compiled to JS), just from the JiT-friendliness of the BuckleScript JS output.
But realistically, you’d be compiling to native OCaml through the same codebase. We did see a 10-25x perf jump from converting a part of a Babel pipeline to native OCaml. I mean, these languages are basically designed over decades with AST manipulation in mind, so that’s not surprising.
The specifications are not nearly stable enough to be publicized yet. In particular, there are several possibilities for file layout, compression, etc. and we have barely started toying with some of them, so any kind of spec we publish at this stage would be deprecated within a few weeks.
If you wish to follow the development of the reference implementation, you can find it here: https://github.com/Yoric/binjs-ref/ . It's very early and the format will change often as we
While SVG can do a lot, there are certain things that it isn't optimized for. In particular animating lots of shapes simultaneously. The animation of the globe exploding into a bunch of triangles from the slides is a good (bad?) example of this. Also, there can also be inconsistencies is in the rendering of SVGs between browsers.
Ironically we found that IE had the best SVG performance for quite a while (by now the others have mostly caught up). And then they broke a lot of things behaviour-wise in Edge again for quite some time. Performance was still great, but if your image doesn't look like it should it doesn't help.
