I'm intrigued by this style in javascript but it seems like swimming uphill. Note all the annotations in comments he has to give so that he can understand how his functions will compose correctly.
I think it's a style that you ultimately shoot yourself in the foot the first five times you attempt it, but eventually you end up in a better place for it.
Overall, I feel that the idea of looking at Events as Streams is a step in the right direction and having well composed functions is a key piece of making that dream a reality.
Any summary/writeup for this talk. 36 minute is a long time to find out whether it matters to you, even a quarter of that is too long. There should be some summary.
Underscore makes iterable the first argument, and function the second. The speaker thinks this is backward, since making function the first argument and iterable the second gives you automatic currying. This is the order followed by Ramda (https://github.com/CrossEye/ramda), as well as Python's standard library (https://docs.python.org/2/library/functions.html#filter)
If you watch the first two minutes, he explains what the talk is about.
But I'll save you two minutes: Underscore describes itself as affording Functional Programming, but in fact.. it doesn't.
He then goes over several examples of common FP patterns, like currying, composition, and functors, and shows how underscore fails in these regards, and how you can do so much better if a few things were done differently in the library.
I learned Javascript from that book with around zero prior knowledge of Javascript as a programming language. So, to be more specific, I'd throw in that it's a perfectly fine book for a beginner to Javascript per se. It will probably confuse you, though, if you are not merely desiring to learn Javascript, but you are a beginner to programming in general and learning a programming language is a novelty to you in and of itself -- by the time I picked up the Crockford book, I was proficient in a variety of other programming languages and had a computer science degree.
If there is anything I could complain about, it would be at the other end of the spectrum: it ends after covering just the basics of the language itself; I don't even think it covers the browser DOM. But if you buy it at a physical bookstore, the thickness of it should tip you off as to what you're getting. As far as it goes, it's a great book.
The talks at FutureJS were consistently fantastic. I highly recommend all of them.
A good starting place would be A Conceptual Future For The Multi-Device Web, which covered a plethora of new APIs like WebRTC, Geolocation, and Orientation, combining them in rather novel ways.
Also excellent was Invent The Future, Don't Recreate The Past, which looked at the evolution of JS and possible future consequences of the decisions being made in ES6 and ES7.
Overall, fantastic conf with excellent speakers (Jeremy Ashkenas, Reginald Braithwaite, and David Nolen, to name a few personal heroes).
I have a question about the talk by Philip Roberts ("Help, I'm stuck in an event-loop").
In the following code, assuming that there are no read errors, is the load callback guaranteed to be always executed? I.e. are DOM events dispatched only after the call stack is cleared?
let main = () => {
let reader = new FileReader();
reader.readAsText(file);
reader.addEventListener("load", callback = (event) => console.log(event.target.result));
};
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.
This JSConf.Asia 2013 talk about NodeJS in Photoshop [1] is very good as well, e.g. "Generate > Image Assets" is a Node script that automatically extracts PNG & JPEG when the PSD is saved, so combine it with gulp watching the output folder to livereload images of the site you're testing by editing a PSD: imho that will sure help designers work with programmers.
I'm about halfway through Crockford's second video which is pretty damn good. I'd say it's a good overview and introduction to JS, but if you really want to learn books are the way to go. That's how my brain operates, at least.
I'm still relatively new to JS and have really enjoyed Secrets of the Javascript Ninja.
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.
The Douglas Crockford videos were suggested to me when I was interning at Cisco and had never touched Javascript before. While it didn't exactly teach me how to program the solution for my particular problems in Javascript, it provided excellent context for why things are the way they are and gave me an overall familiarity with the language.
Note, your use of “meta” here is not standard usage in the programming community at large, and is therefore probably confusing to many readers (I’d avoid it in this context).
The sense you mean is a shortening of “metagame”, a term used since the early 2000s or maybe before by Starcraft I players to describe the broad trends in overall strategy and play-style evolving over time as the whole community of players adapt to each-other’s games. The term may have been used in other similar contexts before that time, but as far as I can tell that’s mainly where it was popularized.
So is your description, Meta is an ancient greek preposition that in English roughly means a concept that is an abstraction from another concept (though originally in Greek meant "after").
It is also used commonly to mean something that is knowingly circular or self-referential "That film director doing a movie about film directors was so meta", I don't like this usage but it is common.
In either case your usage is considerably narrower and not at all the standard usage.
He's saying "oh, this person just used meta like it means 'something that is all the rage', which is some strange emergent usage from a gaming subculture. I'd better explain that so it makes any sense at all."
I would imagine most people here know what the word meta actually means, so just saying "this isn't standard usage" is sufficient.
I wouldn't say it's "wrong", any more than, e.g., this site's use of "hacker" is wrong - just jargon that isn't present in this community.
It's reasonable for the term metagame to encompass the evolution of the strategy of a game over the years (character matchups in fighting games, use of certain "builds" in real-time strategy, etc.), as it's beyond the scope of individual matches or players; it's then reasonable to abbreviate that to "meta", as many gaming communities do, and applying it to long-term trends in things other than games is only a small semantic shift.
Of course, that means little if the term doesn't actually exist here, but if it could come to exist without any especially gross abuse of language, I wouldn't call it wrong.
I'm picturing JavaScript strapped to a chair with its eyelids forced open undergoing aversion therapy as it undergoes multitudes of revisions to eliminate all those pesky bad parts.
Control-F "asm.js", found nothing, Control-F "emscripten", found nothing, closed window.
Dude, JavaScript is the new assembler. Forget about JavaScript. It's irrelevant. Cat's out of the bag, IE+Safari are going to have to step up, and when that happens, it's game over. I, for one, welcome our new compiler overlords.
The Java/Python/C people aren't those who startend learning JS in the first place. Many came Form Ruby and PHP, I Guss. They don't need this kind of la er.
https://www.destroyallsoftware.com/talks/wat