LINQ is much more sophisticated, translating as much of the query as possible to the target (server) language, like SQL. JAQT is not doing that. lodash, underscore, and others, had a great impact on javascript by introducing lots of functional paradigms. Most of that is now part of javascript itself. JAQT's main purpose is to allow you to filter arrays of objects and create custom objects, just like GraphQL. And be a bit easier to learn than Array.map/reduce/filter.
Author here, if you are comfortable with filter/map/reduce, than JAQT doesn't provide much benefits, I agree. My target audience is developers who aren't that used to that. I've had much more success with junior developers using JAQT, then trying to get them to use map/reduce.
The target audience for unit tests is not the client, it is the developer. Unit tests allow you to change code with more confidence. 100% code coverage is not a useful aim, you should aim for 100% confidence in your code. Unit tests can also function as example code, that can't get out of date, since then the tests will fail.
Testing for quality assurance is a different thing, usually called acceptance testing and sometimes including regression testing. One easy way to make clients angry is by re-introducing bugs that were fixed in earlier releases.
Hi, original author here, I just found out my old project featured here and love the thoughtful responses. If you are interested, I've been working on a new version of and on, called cobalt (https://github.com/poef/cobalt/). Hope was the proof of concept, cobalt is a more rigorous implementation. Specifically the range algebra is complete there.
It's still a hobby research project. There's a lot I've learned building and using it, about the things that HTML is good at, and what it isn't good at.
What I'm trying these days is to see if I can get a WYSIWYG editor with a user experience that comes close to the user experience of writing markdown. This isn't easy and its interesting to explore what makes that so.
The only reason I used a text format is because I wanted to keep the code as simple as possible. Only introducing extra complexity when I hit a wall somewhere. I don't know if the current format will scale to more complex use cases, but I really like the fact that you can read HTML and reason about it, so I kept to that in Hope as well.
As for the text part, that is simple. I like to be able to manipulate text as text. There are many many tools to work with plain text. I can use regular expressions to search through text, get ranges of the result and apply an annotation to those ranges. You lose a lot of that in any other format.
Agreed, you cannot edit one part without the other. But there are many situations where this is not a drawback. Nobody is writing Word documents in a text editor for example.
But I'm looking at a way in which you may be able to add annotations to a document that isn't under your control. If the document is either guaranteed not to change, you won't have a problem. Documents hosted on IPFS or a versioned URL to a Hyper document fit this bill.
If you want annotations to automatically change when a remote document changes, you need to be able to 'follow' the changes. Between when you originally 'linked' to the document and now, what has changed in the document. Which parts are deleted, which parts are added. If you know that, you can update the offsets in your annotations. So I'm looking into making a versioned document format to allow just that.
Hi, original author here. When I started out I wasn't trying to solve a problem. I was exploring a concept I was curious about. But in the end, we (me and a colleague) ended up building it into our WYSIWYG HTML editor as an alternative to the browsers execCommand editing API. When editing rich text, an API that is build around ranges for everything is a perfect fit.
The editor (https://simplyedit.io/) converts a contenteditable area's content to hope, we apply some markup (annotations) and convert the result back to HTML. I wrote the Hope-HTML conversion routine once, and all the range based manipulations are now one-liners instead of treewalking horror shows.
Original author here, this is exactly right. Hierarchy and contentless annotations don't mix well. This is the main disadvantage when compared to xml/html and the like. On the other hand, using annotations with offset pointers to the main text make things like overlapping annotations and multiple sets of annotations possible, which are difficult to pull of in xml/html.
I like where this is going, I have been thinking about similar problems lately and, inspired by a talk from Alan Kay, started writing down a research direction for a solution. I'm looking for feedback and other people interested in this. You can read the whole thing here: https://hackmd.io/kafpxBeqQua_rcrncP14tQ?view
TLDR: I'm thinking of building on top of the browser a universal document standard, which allows for interactive documents that contain the application you need to render it, but also to get data from it and link it to other documents. I'm thinking of using IPFS as a storage mechanism to get stable links. Iframes to securely compose documents, using a bootstrap javascript line as the only requirement for any document format. A message bus system, using iframe postMessage api, to connect all documents.
I'm in the pre-design phase, there is no code, just thoughts.
If you resize the image in steps, with each resize at least 50% of the previous step, you can do a pretty decent approximation of cubic resize using the canvas. Doing this for a year now, we've gotten no complaints and we have designers as clients :)