Support running in a browser

[matanlurey]

This would enable in-browser use, use in a service worker, etc.

[nex3]

We already isolate our dart:io dependency behind a configured import. I'm retargeting this to focus on adding a web-compatible implementation of the IO APIs we use.

This is something that would be nice to have, but I don't think I'm going to have time to implement or maintain it myself.

[matanlurey]

I think just having the capability would be enough, for now. A sass_browser package could always implement the gritty bits.

[nex3]

Since this is handled by a configured import, we can't really expose hooks for an external package. It has to be done in our codebase, since we handle the JS compilation.

[HopperMCS]

Would love to make SASS available natively to shared hosting, even if slow, by using a JS version in the site's files. DreamHost shared doesn't (easily, if at all) provide Ruby and has a cap on processes running, so nodeJS won't fly.

I love SASS's simplistic syntax and would love to run/compile it "natively" from my website, instead of uploading CSS files. Also, I don't know enough about Dart/node/JS to do this myself, otherwise I would. I'm struggling to figure out whether to learn Dart or Go, Dart seems to be more tempting PR/marketing-wise.

Oh, and as a student I don't have the resources to pay for a VPS or anything above, as I'm lucky to have shared hosting to begin with.

I'm really tempted to learn Dart to see if this is possible...

[yatsyk]

I think that one option could be if this module will ignore file parameter in compile api and use only data if there is no file system available as in case of browser.

There is also a drop-in replacement of node file system api for browsers: https://github.com/jvilk/BrowserFS . But even after enabling this module for fs replacement in webpack sass npm is not usable due to other globals misses in browser. I have no previous experience with dart: is it something like target (node or browser) we could change to fix result js? I've not found any information for npm build in readme.

[nex3]

@yatsyk It's more complicated than just dropping in a filesystem implementation. We'd probably want to do a separate compilation that targets the web. You'd need to start by adding a web-compatible implementation of the IO functions, but it's also not clear that the render() API would work great on the web—the importer API strongly assumes it's working with file paths, and it returns a typed array that may be difficult to work with in a browser context.

[jathak]

In terms of what sort of importers would be necessary for the web, I can think of two possibilities:

• an AsyncImporter that just fetches source files from URLs
• a non-async importer that just sort of fakes a filesystem with a map from filenames to source file contents

Do both of these sound reasonable? Are there others we'd want to support?

Also, is the goal here just to have a Dart library that can be imported on the web, or would we also want to distribute a compiled JS library that could be depended on by non-Dart web apps?

[loilo]

Based on @jathak's suggestion, I could also imagine an implementation agnostic file system abstraction "interface" that allows for asynchronous answers to request. On top of that, Sass code could be stored, fetched or even generated on the fly.

[nex3]

In terms of what sort of importers would be necessary for the web, I can think of two possibilities:

• an AsyncImporter that just fetches source files from URLs
• a non-async importer that just sort of fakes a filesystem with a map from filenames to source file contents

Do both of these sound reasonable? Are there others we'd want to support?

I think for starters, it's fine to just do this without any importers at all, and leave it up to end-users to write importers if they want them. If we do add first-party importers, I think they should probably be distributed separately from Dart Sass itself. Running client-side is already kind of a niche feature, and I don't want to devote a ton of API surface in this package to it.

Also, is the goal here just to have a Dart library that can be imported on the web, or would we also want to distribute a compiled JS library that could be depended on by non-Dart web apps?

Ideally both. For example, it would be super cool to be able to make examples on the Sass site editable by users, and that would be a lot easier if it was available as just a chunk of JS. But starting with Dart support is probably a good idea.