Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Already on GitHub? Sign in to your account

Preprocessors #176

Closed
remy opened this Issue Jun 16, 2012 · 52 comments

Comments

Projects
None yet
Owner

remy commented Jun 16, 2012

JS Bin v3 was written to support preprocessors. It's pretty simple to add new ones: 0fdf06

I originally imaged that I could get SASS working locally, but I'm not 100% convinced.

I wanted to put this out to the public as to which preprocessors you think should be supported by default (note that "by default" means you'll be able to write plugins for jsbin that add new preprocessors - along with other things).

Current thinking:

  • HAML (using ported JS version)
  • Jade?
  • SASS (if possible)

Anything else? Are these bad ideas? I know jsfiddle has support for JavaScript 1.7 - is there demand for that too?

Contributor

keithamus commented Jun 16, 2012

SASS support would be great (Node port here), also to remain impartial, LESS and Stylus support would be good.

Jade would be awesome too!

Not sure if it is possible but it'd be amazing to also support Traceur Compiler which aims to be a ES Harmony preprocessor. Imagine demonstrating usable samples of Harmony code with HTML+CSS as well.

subhaze commented Jun 16, 2012

LESS/Stylus support would be awesome.

I think Sass would see a lot of use.

Contributor

bundyo commented Jun 17, 2012

According to this recent CSS Tricks poll, SASS/SCSS and LESS are almost equally popular. It will be good to have them both.

Owner

remy commented Jun 17, 2012

Offline, I've got the following working:

  • CoffeeScript
  • LESS
  • Stylus
  • Traceur (originally tried some insane tricks, ended up being very simple though :)
  • Jade

SASS is the harder one because I have to use a port that works entirely in the browser (so @keithamus - I can't use the node one you pointed out frustratingly).

@ghost ghost assigned remy Jun 17, 2012

Owner

remy commented Jun 17, 2012

@aron sorry chap - some of these upgrades require more changes on the Node side! :)

@remy , @keithamus pointed to node-sass, as far as I understand you, you're saying node-sass won't work because it's provides node bindings to a local install of a sass parser... but have you seen sass.js? https://github.com/visionmedia/sass.js/tree/

Sorry if you already saw it, I just read the main file https://github.com/visionmedia/sass.js/blob/master/lib/sass.js and it looks like its a .js built tokenizer and parser... I didn't see anything that wouldn't work in a browser.

I tried to drop it into a bin and couldn't get it to work, if I could get it to work would you consider it?

Owner

remy commented Jun 18, 2012

visionmedia's version looks doable - I just have to patch in exports (which I've done for Jade). My only concern is the last update was a year ago. Can anyone confirm how out of date it is?

If it covers most SASS usage, then it's worth including, otherwise I'd rather target a new (or more maintained) implementation.

Owner

remy commented Jun 18, 2012

@weisjohn just tried out and got visionmedia's SASS working, but it's really old and doesn't render any of the examples on the sass web site, so I'm going to say that's a no goer.

@remy thanks so much for trying!

balupton commented Jul 8, 2012

Author of DocPad here, from our experience sass.js is a bad choice due to it's poor support for the sass spec. You're better off using node-sass or use node-compass.

Alternatively, JSBin could leverage DocPad for its rendering. That way you get the same simple API for all the different renders, and just need to specify the type of file you want to render. And have the DocPad community maintain all the rendering code.

An example of this would be:

npm install docpad
npm install docpad-plugin-coffee
npm install docpad-plugin-eco
npm install docpad-plugin-haml
npm install docpad-plugin-jade
npm install docpad-plugin-sass
npm install docpad-plugin-stylus
require('docpad').createInstance(function(err,docpadInstance){
    docpadInstance.action('render', {text:'here is some **markdown**',filename:'markdown',renderSingleExtensions:true}, function(err,result){
        console.log(result);
    });
});

What are your thoughts?

Not sure if JSBin plans to support multiple html files, but then you could even start implementing other aspects of the docpad rendering engine like layouts, partials and meta data processing.

Member

aron commented Jul 9, 2012

I'm up for looking into this when I get a chance, I like the idea of using shared code for the rendering and the API looks nice and clean.

Not having looked at the DocPad code what else does require('docpad').createInstance() initialize? As ideally we'd only want the renderer.

Owner

remy commented Jul 9, 2012

@aron note that we'll only render on the server side when we absolutely have to. This means SASS only. Jade, CoffeeScript, HAML, etc can all be done on the client side.

We'll have to duplicate it on serverside to support direct links (I think as per another issue I've opened), but I don't want to be making round trips to the server on every key press.

I think docpad might be a nice quick and easy drop in way to support requests to jsbin.com/abc.less => abc.css / jsbin.com/abc.coffee => abc.js, etc.

That said, if done right, the processor.js file should be reusable too...maybe...

Contributor

keithamus commented Jul 9, 2012

Really what we need to do is fork TJ's SASS.js and make it work reliably in both node and client side, right? There is utility beyond JSBin for having a SASS.js library. Who's game?

weisjohn commented Jul 9, 2012

@keithamus , I think I would be... However, I took a look at getting it working for a few hours one night and was able to get it working a bit, but... It's basically building a compiler, tokenizer, and parser. It's difficult stuff, but if you want to take point, I think I could lend a hand.

@remy remy closed this in c71835a Jul 13, 2012

Owner

remy commented Jul 18, 2012

@balupton regarding DocPad - do the instances run in a close/sandbox environment? i.e. if someone wanted to, they could use the Jade language to run server side code when the JS Bin was rendered and delivered in the "full preview".

@remy there is no extra sandboxing than what is already provided by the template engines themselves. Which is fine as they only have access to the templateData that they receive (so no require to gain file system access etc.) so can be considered secure. If a templating engine turns out to be insecure, it wouldn't take long at all to wrap the rendering functionality in a sandbox environment (using node's vm) if needed.

Could you use emscripten to convert libsass to JavaScript?

Owner

remy commented Aug 23, 2012

We'll let you go first :)

Contributor

remybach commented Dec 17, 2012

+1 for SASS/SCSS! Any progress on this?

skube commented Jan 30, 2013

http://codepen.io/ and http://cssdeck.com/ both have SASS/SCSS working

edit: sorry I see Remy wants client-side

Owner

remy commented Jan 30, 2013

codepen has SCSS on the server side - and piped back to the client. I want
SCSS client side.

On 30 January 2013 17:34, skube notifications@github.com wrote:

http://codepen.io/ has SCSS


Reply to this email directly or view it on GitHubhttps://github.com/remy/jsbin/issues/176#issuecomment-12901724.

How about Stylus until SASS-JS is viable? It may not be as popular, but Stylus is JS-based and really a more advanced syntax than SASS, ie the macro syntax makes everything look like regular CSS.

Owner

remy commented Jan 31, 2013

I thought stylus was already in there as a CSS processor.

On Thursday, January 31, 2013, Michael Mahemoff wrote:

How about Stylus until SASS-JS is viable? It may not be as popular, but
Stylus is JS-based and really a more advanced syntax than SASS, ie the
macro syntax makes everything look like regular CSS.


Reply to this email directly or view it on GitHubhttps://github.com/remy/jsbin/issues/176#issuecomment-12921297.

Oh my bad! Didn't notice the processors were already implemented.

Owner

remy commented Jan 31, 2013

Over 6 months ago :)

On Thursday, January 31, 2013, Michael Mahemoff wrote:

Oh my bad! Didn't notice the processors were already implemented.


Reply to this email directly or view it on GitHubhttps://github.com/remy/jsbin/issues/176#issuecomment-12936202.

Doh was assuming it's not there yet with this issue being open. I will look forward to using this new and exciting preprocessor technology of yours!

ckizer commented Mar 25, 2013

I feel like client side is often slow, with the client side size it does quite a bit of freezing of webkit browsers with anything more than a few lines, where as ones doing it on the server do not… hmm

lolmaus commented Apr 26, 2013

It's the Compass ecosystem that makes SASS really shine.

So once you implement SASS, you should make it possible to import popular Compass extensions.

See how SassMeister does that: https://github.com/jedfoster/SassMeister/blob/master/plugins.yml

Owner

remy commented Apr 29, 2013

@lolmaus sassmeister do a network request for the compilation, as do
jsfilddle and codepen. JS Bin is entirely in the client side (and so is the
preprossing) which is why SASS hasn't been added yet.

On 26 April 2013 15:08, lolmaus notifications@github.com wrote:

It's the Compass ecosystem that makes SASS really shine.

So once you implement SASS, you should make it possible to import popular
Compass extensions.

See how SassMeister http://sassmeister.com/ does that:
https://github.com/jedfoster/SassMeister/blob/master/plugins.yml


Reply to this email directly or view it on GitHubhttps://github.com/remy/jsbin/issues/176#issuecomment-17076350
.

scamden commented May 14, 2013

plus one for sass when you can make it possible :)

lolmaus commented Jun 13, 2013

Okay, after waiting years for any HTML/CSS playground to support SASS with Compass extensions, i had to implement it myself:

Online service: http://sassbin.com/
Source: https://github.com/lolmaus/sassbin

Spreading the word is greatly appreciated. Please retweet this and post to your blog!

ckimrie commented Aug 7, 2013

+1 for SASS.

Although the being able to use the Compass mixins and utilities is great, my use case is for quick demonstrations that will rarely warrant them. The speed of the HTML editing with Emmet coupled with SASS would make for a killer combination for quick demos of ideas.

Was Stylus dropped? Not seeing it in the CSS dropdown now on JSBin.com.

Owner

remy commented Sep 12, 2013

Because it was consistently crashing/casuing infinite loops: https://twitter.com/phuunet/status/377735455670030336 also here: http://remysharp.com/2013/09/11/how-i-fixed-an-anonymous-infinite-loop-in-jsbin/

I intend to bring support back and add SASS, et al - but it means creating a queue/daemon process to do the pre-processing.

ckizer commented Sep 13, 2013

This is the most important feature for retaining users. JSBin is my favorite but every design/CSS nut like myself are forced to use something inferior for online code without stylus sass support. I know you wanted to use only JavaScript. Message TJ Holo the stylus creator on twitter, he would be very helpful in showing you easy stylus parse. Let me know if I can do anything UX/CSS wise to make JSBin better!

Sent from my iPhone

On Sep 12, 2013, at 5:35 AM, Remy Sharp notifications@github.com wrote:

Because it was consistently crashing/casuing infinite loops: https://twitter.com/phuunet/status/377735455670030336 also here: http://remysharp.com/2013/09/11/how-i-fixed-an-anonymous-infinite-loop-in-jsbin/

I intend to bring support back and add SASS, et al - but it means creating a queue/daemon process to do the pre-processing.


Reply to this email directly or view it on GitHub.

Owner

remy commented Sep 13, 2013

We did. No response.

And the reason stylus was taken out wasn't due to the client side infinite
loop, but the server side infinite loop.

I'm perfectly aware that taking features away is going to upset the
balance, but if it's at the cost of preventing the whole of jsbin going
down, it's a simple decision.

Like I said before, I hope to reinstate support, and add sass, compass and
what have you, in the same update.

On Friday, September 13, 2013, Court K wrote:

This is the most important feature for retaining users. JSBin is my
favorite but every design/CSS nut like myself are forced to use something
inferior for online code without stylus sass support. I know you wanted to
use only JavaScript. Message TJ Holo the stylus creator on twitter, he
would be very helpful in showing you easy stylus parse. Let me know if I
can do anything UX/CSS wise to make JSBin better!

Sent from my iPhone

On Sep 12, 2013, at 5:35 AM, Remy Sharp <notifications@github.com<javascript:_e({}, 'cvml', 'notifications@github.com');>>
wrote:

Because it was consistently crashing/casuing infinite loops:
https://twitter.com/phuunet/status/377735455670030336 also here:
http://remysharp.com/2013/09/11/how-i-fixed-an-anonymous-infinite-loop-in-jsbin/

I intend to bring support back and add SASS, et al - but it means
creating a queue/daemon process to do the pre-processing.


Reply to this email directly or view it on GitHub.


Reply to this email directly or view it on GitHubhttps://github.com/remy/jsbin/issues/176#issuecomment-24365710
.

— Remy

I did the emscripten thing to create a local js implementation from libsass/sassc. Compilation had some warnings - so it might be prone to catastrophic failures, but seems to work for me. It loads a 1.6MB file, so its not recommended for production... It's a quick hack that could be done better.

note, because of limitations in emscripten, import libraries (such as bourbon) need to be compiled in. I added in bourbon because it seemed useful; to use it, add 'import "bourbon/bourbon";' to the top of your sass script. Also, compass cant/wont be supported because it has ruby dependencies.

https://github.com/asteadman/jsbin

image

marlun commented Jun 9, 2014

Is SCSS/SASS support being worked on?

lolmaus commented Jun 9, 2014

For Sass with Compass, there is http://sassmeister.com/ .

Owner

remy commented Jul 18, 2014

Re-openning so I can close again...

@remy remy reopened this Jul 18, 2014

Owner

remy commented Jul 18, 2014

This is from live: Sass, SCSS (both with compass and bourbon support), Myth, LESS and Stylus available right now :)

screen shot 2014-07-18 at 16 59 09

@remy remy closed this Jul 18, 2014

lolmaus commented Jul 18, 2014

Great work, @remy!

As for Sass and Compass support, you've kinda reached the level of CodePen, but still far behind SassMeister. You don't even mention which version of Sass you're running (and there are many active versions: Sass 3.2, Sass 3.3, Sass 3.4, libsass 1, libsass 2) and you don't have support for extensions.

SassMeister leverages RubyGems and the Compass extension system. You could go another way and implement support for Sass extensions by importing Sass files directly in Sass code. That's what most nodeheads do: they despise Ruby for some reason (and by rejecting Ruby they reject the ecosystem of Compass extensions) and instead download Sass files with Bower and import them locally. With the rise of Sass 3.3, most Compass extensions no longer depend on Compass and can be used as plain Sass files.

So you could outbid SassMeister by allowing to import arbitrary Sass dependencies by URLs. JSFiddle, for example, does that for JS files. Unfortunately, you can't just import Sass files by http:// URLs, you must have them locally. So you'll have to implement some kind of caching.

Excellent! Thanks Remy, Compass and Bourbon are unexpected icing on the cake :)

scamden commented Jul 18, 2014

thank @remy !

Owner

remy commented Jul 19, 2014

Cheers all.

@lolmaus I don't have any intention to try to compete with sassmeister. Sass and scss have been in long and high demand and since I was making the processors (effectively) thread safe, it made sense to finally meet that demand.

As for versions, here's the details: http://jsbin.com/help/versions#css

As for imports, with jsbin (and we will document this), you can import existing bins (@electricg will confirm my syntax is correct) and of course import anything that is .CSS

@import "wetok/1"

This will pull in the scss bin with the URL "wetok" as a first class scss file on the system.

As for other extensions beyond compass and bourbon - I put the call out and its open source so I'm open to input: http://jsbin.com/blog/new-processors

Relevant links:

As I said, documentation is coming too!

lolmaus commented Jul 20, 2014

As for imports, with jsbin (and we will document this), you can import existing bins (@electricg will confirm my syntax is correct) and of course import anything that is .CSS

@import "wetok/1"

The ecosystem of Sass extensions is huge, and extensions depend on each other.

Duplicating the source code of extensions as separate bins in order to use them is a PITA. And it might not work for Sass.

If you provided a mechanism of importing Sass extension by URLs, that would be a huge, awesome feature. It would make JSBin as powerful in CSS as it is in JS.

Member

electricg commented Jul 21, 2014

The syntax to import another bin is

@import "wetok/1.scss"

or

@import "wetok.scss"

(use .sass for Sass syntax)

Member

electricg commented Jul 21, 2014

@lolmaus as you said, the number of available Sass extensions is really huge.
We "could" implement all of them as local static files to import, but then there would be the problem of how to keep them updated (I count 57 extensions available on SassMeister) and we have to keep in mind that we do not allow the processors to run for more than a few seconds (I don't know all of those extensions and I cannot guarantee they would run smoothly).

We "can" import files via http:// and full URLs, but where would these files been stored? Also, we would probably need a whitelist of allowed urls.

lolmaus commented Jul 21, 2014

@electricg I don't suggest keeping local copies of extensions. I suggest importing extensions by hijacking Sass @import declarations (which you seem to already do), downloading extensions via http:// and caching them serverside.

No whitelist necessary, just limit file extensions and size.

Member

electricg commented Jul 21, 2014

Yes, jsbin already implements our own version of @import.
I'll think a way to make it using other frameworks/extensions more easy and flexible.
In the meantime, if some frameworks are highly demanded (issue and +1 on github) we will try to make everybody happy :D

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment