nex3

We're also working on improving the compilation speed of the canonical implementation. 3.2 will have some improvements that should help considerably.

I'm the primary author of Sass. Hampton came up with the original idea, but he hasn't worked directly on the language in years.

No, since they can be opened inline.

It looks like they're leaving out everything in the spec I linked above. Currently this is the only way to persist File objects locally, although it looks like they're planning to make that possible through IndexedDB instead.

The specific requirement for being whitelisted is that it shouldn't have a MIME type that Chrome wants to open inline. Give me a list of extensions that you'd like to see supported and I'll see what I can do.

I can't comment on unannounced engineering efforts, and I certainly didn't mean to imply anything about them.

All I can really say is that if they wanted the primary Gmail client to support offline, then it's my personal opinion that the only tenable way to do that is by having a single code path. Whether there are plans to actually do this I don't know and couldn't talk about if I did.

(Offline Gmail team member here)

Attachments should work, with a few caveats. Due to some annoying quirks of the HTML5 FileSystem API, there's a whitelist of supported file extensions. This includes everything useful we could think of, but it's not exhaustive.

(Offline Gmail team member here)

One thing we learned early on was that making any existing system (especially one as big as Gmail) work offline had some very difficult, fundamental issues. The biggest of these is that everything that normally happens server-side must also be able to happen client-side when there's no network connection.

This is a problem not only because there is a lot of server-side complexity in Gmail, but also because it changes all the time. New features are added, old behavior is changed, and if the offline code path isn't changed along with it, things have a tendency to break horribly. The only solutions to this involve having every Gmail engineer modify the offline code path whenever they touch the online, which is a large burden that we weren't willing to lay on them.

(Offline Gmail team member here)

The primary reason this is Chrome-only is because other browsers don't yet have complete implementations of relevant specs (for example the FileSystem API: http://dev.w3.org/2009/dap/file-system/pub/FileSystem/). I can't make any promises on the team's behalf, but I personally would like to see it working on Firefox as well at some point.

I'm working on one. I'll upload it once I have the chance to finish it up.

Haml keys can be plain strings.

    #main_page{"data-role" => 'page'}

`data-` attributes are also special-cased:

    #main_page{data: {role: 'page'}}

> Javascript doesn't really have native concurrency operations

Except for Web Workers, also part of HTML5. The way Google Gears handled this was to allow synchronous database operations only in worker contexts.

It's not actually true that Sass and Less have the same features. Each has some features the other doesn't, with Sass having substantially more than Less. Notable examples include the ability to use variables in selectors, the @extend directive, and a wealth of useful built-in functions. It's because of these and other features that Compass can be built on Sass, where it couldn't be built on Less.

Disclaimer: I'm the author of Sass.

That's the difference between reference documentation and introductory documentation. You go to reference documentation when you want to look up the details of something you already know; you go to introductory documentation if you want to learn it for the first time.

Software patents have a strong tendency to be both vague and obvious. Although these are supposed to make something unpatentable, this doesn't happen in practice with software patents (possibly due to the relative novelty of software and lack of understanding among non-technical people).

There's a built-in listing of which applications use what proportion of the battery.

GitHub no longer builds or serves gems.

Yes. While combining minification and gzip doesn't produce as dramatic an improvement as either does above plain text, combining them does usually yield some additional improvement (especially if minification handles things like variable renaming in JS or property folding in CSS).

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.

I was assuming compiling to JSON wasn't an option since the point of the post was the usefulness of avoiding a manual compilation step. With such a step, yes, you could avoid all the parsing headaches. I'm not sure how useful it would be to manipulate the JSON client-side, but there are probably a few clever things one could come up with.

I'm certainly not afraid of compilers. I write Sass, so I'm pretty intimately familiar with what's going on. My point was not that compilers are inherently scary and/or slow (although I stand by my original point that if it's compiling to CSS it will always be at least somewhat slower). I was just making the claim that the current speed of less.js is too slow for practical production use.

Don't forget the accessibility considerations: screenreaders typically don't run Javascript either.

I agree. I'm objecting to the implicit suggestion in the article and more explicitly in comments here that this is in fact fast enough for production. Running it server-side is an excellent solution.

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.

It's also worth mentioning that plenty of people who care about page load times would still care about 130ms. It's not as glaringly awful as 1.5s, but it's definitely comparable to the sorts of times under discussion. See http://developer.yahoo.com/performance/rules.html and http://code.google.com/speed/page-speed/docs/rules_intro.htm...

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.

You're right, that was too broad a statement. However, it is undeniable that in-browser compilation of CSS will always be slower than precompilation, as long as the compilation outputs CSS. For some people, this speed hit will never be negligible. But for those who don't need to squeeze every bit of performance out of their sites, it's sufficient that it only be an order of magnitude or two faster than the HTTP request.

However, that's not the case right now. Maybe in the future Javascript's string parsing will become dramatically faster, but in my benchmarks elsewhere on this thread, it's clear that for large files less.js is pretty slow relative to HTTP.

As for serving it up as JSON: no one wants to write stylesheets in JSON. The reason Less became popular as an alternative to Sass was that it had a CSS-like syntax.

Unfortunately, sass.js is pretty incomplete and has no support for SCSS.

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.

The first load is the important thing: it's when people first see your website. I've done plenty of speed testing of less.js, and on large CSS files it's seriously slow. I'll post the exact numbers elsewhere in the thread.

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.

Running a compiler in the browser in production will never be a good idea. If you care about the speed that your website displays -- and you should -- the slowdown caused by parsing, processing, and concatenating large amounts of CSS will dwarf over-the-wire time. People who seriously care about the usability of their sites have been spending a lot of effort recently figuring out how to get load times as fast as possible, and this is a leap in the wrong direction.