nex3

17 ms·

1.
Announcing Dart Sass(blog.sass-lang.com)
32 points by nex3 10y ago|0 comments
2.
by nex3 14y ago
We're also working on improving the compilation speed of the canonical implementation. 3.2 will have some improvements that should help considerably.
3.
by nex3 14y ago
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.
4.
by nex3 15y ago
No, since they can be opened inline.
5.
by nex3 15y ago
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.
6.
by nex3 15y ago
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.
7.
by nex3 15y ago
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
8.
by nex3 15y ago
(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
9.
by nex3 15y ago
(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 norma
10.
by nex3 15y ago
(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/FileSys
11.
by nex3 16y ago
I'm working on one. I'll upload it once I have the chance to finish it up.
12.
by nex3 16y ago
Haml keys can be plain strings. #main_page{"data-role" => 'page'} `data-` attributes are also special-cased: #main_page{data: {role: 'page'}}
13.
by nex3 16y ago
> 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.
14.
by nex3 16y ago
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 direc
15.
by nex3 16y ago
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
16.
by nex3 16y ago
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 la
17.
by nex3 16y ago
There's a built-in listing of which applications use what proportion of the battery.
18.
by nex3 16y ago
GitHub no longer builds or serves gems.
19.
by nex3 16y ago
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 re
20.
by nex3 16y ago
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.
21.
by nex3 16y ago
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
22.
by nex3 16y ago
Don't forget the accessibility considerations: screenreaders typically don't run Javascript either.
23.
by nex3 16y ago
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.
24.
by nex3 16y ago
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 p
25.
by nex3 16y ago
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-wor
26.
by nex3 16y ago
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 negl
27.
by nex3 16y ago
Unfortunately, sass.js is pretty incomplete and has no support for SCSS.
28.
by nex3 16y ago
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 Git
29.
by nex3 16y ago
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.
30.
by nex3 16y ago
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 i

More ›