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.
Wow small world! Thanks to you for taking the time to explore this topic and putting such a great presentation together. I'd wager it's a must-watch for anyone who keeps asking "what the heck is the event loop anyway?" haha
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.
That's interesting given there's no licensing certainly on my video :) I will be asking scotlandjs to update the Vimeo page to ensure there's a Creative Commons non-commercial license specified as I'm not _super_ excited about people charging for access to my work.
That is certainly not our intent either (and I'm certainly not charging for this page). What we change people for is the ability to upload content (we can do that, just not done in this case), group the content (uploaded and elsewhere), and distribute (link a web page or send email). All the videos are still hosted from their original location (vimeo and youtube in this base).
If you want me to remove something, email me at chrisb(AT)unitymg.com and I'll get rid of them.
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 :)
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.
Thanks for response! You are right, I have just done some tests with a time-expensive "for" loop placed right before the addEventListener() call and the callback appears to be fired after the stack is cleared / the main function returns.
Thanks, it was actually the READMEs on GitHub that I was referring to originally. I'd bet those don't get the same level of care the website does.
I'm really not trying to be annoying, but I'd point out there was a week there in April where ampersand-state jumped from 0.5.0 to 3.0.1. Perhaps it's just that the initial decision to one-dot was premature and now you're locked in by semver?
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.
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
I hate to say it, but there is a nugget of truth to this; the post is a giant wall of text when there should really be a summary of what the project is first, with the 'why' second.
It took some browsing of the GitHub repos for me to figure out what this is. But I like it, and will probably use it, so the code is not the issue, just the presentation. :)
You don't link to it clearly enough. I also had a "just show me the code" reaction, and all I saw was the example of how to create a restful collections module.
I think it's good that people explain why they created something. If you don't know WHY they created it, WHY would you use it? And when you know the 'why', the 'what' becomes much more clear.
I think the problem is the article lacks a clear hook. I had to go to the site to find out why I should care. In the post itself, the list at the end is the most engaging part - but you've probably lost a lot of readers before you get there.
> Sorry, we just wanted to give the background to the project and why in the post, rather than focussing too heavily on code.
Your landing page should contain what your users want to see, not what you want to put there. You might be excited about the motivation behind your project but nobody cares, really.
I clicked on the link and I spent ten minutes reading a wall of text hoping to find good reasons why I should switch from Angular, Backbone or Ember. Instead, I just closed the window without knowing anything about your framework.
> There's plenty of API docs for the core components
Still not a substitute for a user manual, even tiny.
A little harsh, don't you think? The link is to a blog post - not a landing page - and it seems to me it can contain whatever the author wanted it to. The post wasn't submitted here by anyone from &yet, but by Jeremy Ashkenas (the creator of Backbone which is partly the basis for ampersand).
But the landing page doesn't say much as well. The first section is "Why?," and the only "what" is "Ampersand.js is a well-defined approach to combining (get it?) a series of intentionally tiny modules."
I don't know what that means, and the reasons for it are "simplicity of tiny modules and npm dependency," which are not exactly convincing by itself, as I can do that just fine with plain Browserify. Then, going to the "Learn" page I get my hands busy.. with something I know nothing about.
This is heavily marketed towards Backbone users, I'm guessing.
> 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.
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.
> You can access model properties without .get('name') and .set('name', value) and events and things just work.
[when IE >= 9]
Honestly though I'm excited by getters and setters. I always disliked calling them explicitly in Backbone—it feels like a hack.
On the other hand, there's something nice to be said about explicit setters (you might not expect events to fire when it doesn't look like a function call).
Still, I'd rather have real looking code than a bunch of xxx.set('propA', yyy.get('propB')) nonsense.
