HN user
Firstly, Hiccup is Clojure (so basically server only). Cloact is ClojureScript, that compiles to javascript (so browser, node.js, etc).
Secondly, Hiccup produces strings. Cloact typically creates DOM elements, through React, that change every time a component rendered. But it can also produce an HTML string using the same data, to pre-render a page on the server using node.js.
In a way. Using regular atoms you can only get a callback when they are modified, but not when they are deref'ed.
You could still use regular atoms, though, with some extend-type magic. But then you risk messing with non-Cloact code in horrible ways...
Thanks, again :)
Yes, exactly, Cloact tries to stay really close to plain React. But since it allows you to separate data from rendering, undo should be quite trivial to implement (if you keep all your application data in a single cloact/atom)...
With React, you get to choose the parts of your code that integrate tightly which each other. Choice is good.
And if you don't like html in js, you could always embed ClojureScript in ClojureScript :-):
I've been playing with React a little bit, and so far I like the experience a lot.
Rendering is incredibly quick, since React only touches the parts of the DOM that have changed. Components are very lightweight, so you can break down the UI in as many, self-contained parts as you like.
And you can do pretty much anything you like without ever having to use a single selector or DOM manipulation. That means that you only need classnames for CSS.
The only downside I've discovered so far is the extra tooling required to use the embedded HTML, and lacking compatibility with other tools, but I suppose that will become better with time.
Favorite part:
"Since the only computer language Richard was really familiar with was Basic, he made up a parallel version of Basic in which he wrote the program and then simulated it by hand to estimate how fast it would run on the Connection Machine."
I think their problem is much worse than just being a question of improving data quality. They seem to get data from a lot of very different sources, and those simply do not fit together.
For example, in Stockholm Apple's map still shows most buildings as lying in the middle of some street. On the other hand, only relatively few businesses seem to be located in some kind of building. There seem to be quite obvious, and systematic, errors all over the place.
Something like this would make a great addition to CoffeeScript.
Thou shalt not use the name of software failure in vain.
It doesn't seem to fix anything, unfortunately, as far as I can tell after a quick test.
Now, if they only could sort out the iPhone app as well. It uses a lot more CPU (and corresponding battery) than other audio players (probably due to its Vorbis use), and skips as soon as the os is busy doing something else.
No problem. It's lists all the way down.
That is quite a strong reason, though.
Allow me to be a little grumpy:
I hate tabloidy headlines with question marks. As in "Queen Elizabeth: Is She a Transvestite?", "The Moon: Is It Made of Cheese?" or "Linkbait: Will It Ever End?".
Also: Xcode 4.2
Calling Windows 95 an "abysmal failure" might be a bit too harsh.
And I can't even imagine what Siri and Wolfram Alpha will cook up together.
A bit off-topic, but now you don't have to follow the G+ name rules if you're famous enough. At least if "famous enough" means "being Madonna". [1]
I don't remember her last name, but I'm pretty sure it is not ".".
I'm a heavy Spotify user because it is so much more convenient than the alternatives. I love not having to care about buying, downloading, uploading, sorting, tagging and generally messing about with files.
Most of the time, I don't even have to make my own playlists: I just find someone else's that looks interesting, mark it for "Available offline", and listen to that for a while.
I'm not interested in "owning" music (whatever that means these days). I am interested in listening to it, and Spotify makes this very easy.
In comparison, the whole "locker" business seems very messy, and rather unnecessary. I can't for the life of me see what the advantage would be.
Pocket Casts is also very good.
That would be one of the cases of "not pre-installed on".
"Ambient sociability" is my new favorite expression. Thanks!
This should probably have been the top result:
http://www.wireandtwine.com/store/products/subtraction-hel.h...
"Tove pissed off Warren Beatty by asking his name not just once, but twice" is the funniest thing I've read in quite a while.
It seems that Nokia will "become by far the foremost WP7 phone maker" mostly because everyone else shuns it.
The author seems to want to frame Google's WebM move as a question of Good vs. Evil (as does Gruber btw.), which is not very helpful. As with most everything, there are both costs and benefits.
The main benefit is that Google's move may reduce the risk that the MPEG consortium goes crazy in the future, and starts to charge every possible user, causing havoc in the process.
The main cost is more certain: a huge inconvenience for content producers that were hoping to get away with going H.264 only, causing havoc in the process.
The interesting question is the usual one: is the benefit worth the cost?
Really? You must be much, much luckier than I. I just headed over to YouTube, disabled the (excellent) YouTube5 Safari extension, and tried 20 random videos. Only two worked (but fullscreen is still broken).
Maybe that is somehow what Google wants? It has cozied up to Adobe to the point of including flash in Chrome itself. And YouTube apparently can't be bothered to make html5 video work reliably.
I can't think of why anyone would want to promote flash, though.
Just use less.js for all your hsl needs in IE:
Here is the entire list of new stuff: