Thanks for the shout out! I'm still amazed how well that talk struck a nerve and it's a real kick seeing people getting something out of it 8 (!) years later.
Not the poster, but the creator: if anyone has suggestions on how to package this up for windows, or wants to suggest the best instuctions/test on linux(es) do let me know!
Also keen to hear suggestions for improving the security section of the readme so people understand the risks etc.
I'll add, most of my understanding was done this way: somewhat experimentally. Come up with a hypothesis of how things might work, figure out a way to prove it, and see if I was right.
Great question, and one i am not totally sure of myself. I guess the question is: if an event doesn't have any handlers listening for it, does it get queued and processed regardless? This is something I've often wondered about myself but never properly tested/been sure about.
My _guess_ would be yes, this would work. Regardless of how fast the file loaded. One way to test it would be to stick a large while loop between readastext and addeventlistener to block the stack for a few seconds and guarantee that the file is read before the handler is bound.
I'll try and take a look when I am back at a computer if nobody else responds either way :)
That works for native types but gets trickier for custom datatypes, and ones where you want to specify custom getters and setters for example, and then specifying some as strings and some as constructors gets messy.
We do need to do some more documentation/cleanup around custom datatypes though for sure.
> You might be excited about the motivation behind your project but nobody cares, really.
Yes we'll try and improve the content on the homepage to make it more focussed. Though I guarantee if we didn't talk about the motivation we'd have people saying "why did you make another framework?!"
> Still not a substitute for a user manual, even tiny.
I'm not suggesting we've got it perfect by any stretch, but I'm not sure exactly what you're hoping to see? There's also http://ampersandjs.com/learn with some more detail around the various pieces.
Sorry, we just wanted to give the background to the project and why in the post, rather than focussing too heavily on code. There's plenty of API docs for the core components in http://ampersandjs.com
Ampersand has evolved out of the client and product work we've done at &yet over the years. So there are a number of client projects with various evolutions of it in production, as well as our own products: http://andbang.com and http://talky.io, and https://otalk.im/
That's true, although many of the core backbone components have been significantly modified/basically completely rewritten, keeping a fair amount of similarity with the backbone APIs but extending them too, for example:
* Views have declarative data bindings for updating your html with model data automatically; out of the box, sensible render and remove methods just work; collection rendering is easy.
* Models have explicitly declared properties and types, as well as evented + cached derived/computed properties. You can access model properties without .get('name') and .set('name', value) and events and things just work.
It's not made clear from my post, because I felt it was entirely irrelevant to the context of the post itself (which was merely intended as an interesting meander through the thought process and experiments my mind went through over time) but I stripped a number of comments from the screencap wherein the question was in fact answered.
Had I suspected the quality of my team, or my discipline would be under question, I would have left them in :)
Arguably the thing that tripped me up for the majority of the time was latching on to the fact that == and === are different, and trying to _always_ satisfy the two conditions, rather than just spotting that I can change the reference to b from within the first valueOf call. I'm not sure how much I'd read into the "if I was more of a mathematician and less of a dumb programmer this would have been solved trivially" argument.
I worked through the 7 languages in 7 weeks book, and solving a sudoku with prolog blew my mind. I think the first "real" programming I did was a sudoku solver in Excel and VBScript (yeuch).
- Expand to more platforms, to increase the total market we can hit.
- Improve the product to make it easier for the general market to understand. We are hitting early adopter types pretty well, but the majority struggle because it's a complex problem/product.
- Figure out how to scale the marketing (the really hard bit ;) )