I'm not sure that's the best guess. While it would be the obvious choice, I don't think much could be said to be "earthshaking" there, and Knuth isn't one to throw out hyperboles. I think it will be something new, almost certainly in a different field, and it will involve looking at an unsolved problem in a way different than it's previously been approached from, much like TeX. I can't wait to see what he announces.
But then, it is not announced as an earthshaking announcement, but as an "earthshaking announcement."
The quotes make it sufficiently vague that it could be anything from "there was a typo in a comment in the metafont source", to "Vol. 4 is off to the printer."
Windows 7 costs $1.20 to make. 20 cent dvd + 20 cent packaging + 80 cent booklet (or whatever is in there.)
A high end CPU costs below $3 in material costs. (Numbers purely guessed)
Given these examples I find it wrong to accuse Apple for selling the iPhone at that price point. At least to me these "Product X costs Y USD in production" articles sound a bit accusing.
Here in Germany studiVZ is the leading social platform. studiVZ started off as a clone of facebook and they're still pretty much stuck on the initial version.
facebook only recently started to slowly gaining traction here.
Given that facebook is functionally (news feed, apps) and visually (less obtrusive adds) way superior to facebook the main reason for the slow adoption is surely that "everybody" is on studiVZ.
Given that facebook is real good executed I don't see any way it's getting serious competition anytime soon.
The article makes it sound like the author expects in-browser processing to be the only way it'll be used:
"Less.js is a JavaScript implementation of LESS that’s run by your web browser. As any JavaScript, you include a link to the script in your HTML, and…that’s that. LESS is now going to process LESS code so instead of including a link to a CSS file, you’ll include a link directly to your LESS code. That’s right, no CSS pre-processing, LESS will handle it live."
No mention that that would be ineffective for a production site. In fact, he claims that live processing won't have noticeable lag, which is just false.
I demand a benchmark. Saying that something is just false without numbers to back it up is not something I have high trust in, and is the start of the gossip that causes internet wars.
Fair enough. I'm running less.js from the command line using node.js on my old-ish MacBook pro:
A trivial CSS file (foo {a: b}) takes about 0.11s. This is probably mostly time spent spawning Node and loading the JS.
The combined CSS for GitHub, about 160K, takes about 1.6s. This is already longer than most HTTP requests.
The doubled CSS for GitHub (the same CSS twice in a row), about 316K, takes about 4s. This is quite large, although there are few sites that have this much CSS.
I tried to run it against the minified CSS for caring.com, but after 2m it hadn't terminated so I gave up. It's likely that this is due to a bug in the implementation rather than slowness.
This is real CSS handwritten by real people. It's not compressed, it's just not in a fully-expanded style. If your parser is slow for reasonably formatted CSS, then your parser is slow. The best case can be as fast as you want, but real-world use is what matters.
For what it's worth, -O2 brings the compile time for github.css down to about 1.5s.
No it's not. Look at it: it's one-selector-per-line, which is a very common style for handwritten CSS. If it were compressed, it would have no line breaks.
It's impressive that your benchmark compiles that quickly. However, as I mentioned elsewhere, the real issue is how fast real-world code compiles. My benchmark uses real-world code, and it's slow.
As it's cached, it's only the first load that will have the lag. I'd guess it will be quite small as well. If the CSS makes heavy use of mixins and the nesting ability then the lag may even be smaller than the time to transfer the compiled CSS.
First load is where it counts! This is when users first see your site: their first impression. This is an important time that should be kept as fast as possible. Subsequent loads, for most sites, are likely not as important speed wise.
Remember, we have to design our sites as if the user is poised over the back button.
