_Please_ make a client side implementation of Stylus

[adrusi]

I need a CSS pre-processor for my (very) new project, Rooibos. It's a 100% browser-based framework and I would like to keep it that way to remain server independent. The only available CSS engine is LESS, which I don't particularly like compared to other options, especially stylus. As long as you're not using any ES5-only syntaxes (no getters/setters, etc.) most of the code should work in the browser with the help of the ES5 polyfill.

[tj]

compiling css in the client is a terrible idea, with very few exceptions, but it's not something I'm interested in, but yeah with a few tweaks it could work

[adrusi]

Why is compiling on the client such a bad idea? If you mean performance, I compile Coco to JavaScript in 3 milliseconds, so I don't think its too much of a problem.

[tj]

there's no reason to keep re-compiling css all the time, deferring it to the browser doesn't have a point it just prevents you from serving from a CDN like you should etc. Compile time might be reasonable, but I wouldn't call it acceptable to including another 32k of js just to compile on the client-side.

[adrusi]

I see your point about the CDN, but it's 32k uncompressed. Minified and gzipped it should be much smaller.

On Sun, May 29, 2011 at 2:27 PM, visionmedia < reply@reply.github.com>wrote:

there's no reason to keep re-compiling css all the time, deferring it to the browser doesn't have a point it just prevents you from serving from a CDN like you should etc. Compile time might be reasonable, but I wouldn't call it acceptable to including another 32k of js just to compile on the client-side.

Reply to this email directly or view it on GitHub: https://github.com/LearnBoost/stylus/issues/265#comment_1257746

[duncanbeevers]

Have you tried pulling this in via browserify?

[525c1e21-bd67-4735-ac99-b4b0e5262290]

@duncanbeevers It fails in browserify because stylus blindly requires sys regardless of the environment.

[tj]

it would fail browser-side for lots of reasons, @import etc would break as well. I don't see a point to even attempt supporting browsers though

[525c1e21-bd67-4735-ac99-b4b0e5262290]

Haha. Yeah. I ran into the whole @import thing shortly after killing off the sys requires. I've just exposed stylus to the client via DNode for now. It works a charm ;)

BTW This is very much not for production but rather an internal tool. We want a little "live" editing. I'm sure others have similar reasonably sound motives for wanting to compile on the client itself.

[SlexAxton]

I do see the use for this for dev mode. Instead of needing watchers everything can be done statically. Imports would essentially have to work by pulling in things as text and parsing and injecting. I think it could work, but it would take a lot of work.

[8ig8]

I'd use this for development. In fact, I was seeking it out and found this issue. I've switched to LESS from SCSS recently because client-side compilation makes it much easier to pass around the development files since everything is self contained.

[tj]

@8ig8 would it help to have a stylus --server or something? that would be much faster to implement. I'm not really convinced that having it in the browser even speeds up dev really but I understand the lower barrier to entry, even though it would make extensions more complex/awkward

[8ig8]

Thanks @visionmedia. I don't think server or similar would help in my use case. It would still require some of the frontend CSS devs I work with to install something and potentially change their familiar workflow. It definitely is a barrier to entry issue for me (them). LESS.js allows me to sneak in the back door so to speak. With that said, I personally would prefer functionality over the convenience of client compilation so I'd drop my request for this if it complicates the main focus. I can always fallback on something like LiveReload for the reluctant devs. Thanks so much for effort, BTW.

[ghost]

+1 @8ig8. Client-side support would be helpful just to get reluctant designers to try Stylus before they install any Node stuff. Maybe I'll take a crack at it. Meanwhile there's always LESS... I can say "if you like this, you'll really love Stylus!"

[tj]

@tnovelli until then there's styl.heroku.com:

display(type)
  if box == type
    display: -webkit-box
    display: -moz-box
  display: type

section
  display: box

$ curl -F style=@test.styl http://styl.herokuapp.com
section {
  display: -webkit-box;
  display: -moz-box;
  display: box;
}

[billymoon]

Did anyone ever get a client side version done? I was about to go to my mates house in the country, was going to take my iPad, and wanted to do a bit of web-design out there. If there was a client side implementation, I could use Stylus, but there aint, so I will use LESS. I am not going to change back later, because it would negate the work I do. I prefer Stylus in every way except this client side implementation lacking.

Just wanted to make the point that it is not only for lowering entry (which is enough of a reason - you should have live demo on web-page, like coffe-script) but also for unusual circumstances. I know I can always edit text files, and view them in a browser. I don't know if I will be able to install/set up a development environment all the time. I like that I don't have to be at my own computer to make changes to my websites. I really like that I don't need internet to do my dev work - only to publish.

Keep up the good work. Cheers ,~)

[chestozo]

Here I wrote a little script, that supports import, but currently it will handle only files from the same dir: https://github.com/chestozo/stylus/blob/master/browser/stylus-support.js

U can see it in action here: http://chestozo.github.com/stylus/browser/example.html

It also does not support index.styl files, it's the first version that I just wrote.

[ghost]

Good timing - I'm running some JS meetups locally, and there may be designers there who want to mess with Jade+Stylus without installing anything. I'll take a crack at this if I have time.

Meanwhile I wrote a mini server that compiles Jade+Stylus on demand: https://github.com/tnovelli/dserv
Doesn't need an internet connection (call me old fashioned, but I know people who rely on dialup, 3G, etc :-)

[tj]

hmm I used to have http://stylus.herokuapp.com/ but .. it's gone? haha

[525c1e21-bd67-4735-ac99-b4b0e5262290]

not http://styl.herokuapp.com/ ?

[tj]

@tnovelli https://github.com/visionmedia/serve handles jade/stylus as well. that heroku thing was a web service but yeah i dont know what heroku is doing haha all my node stuff is busted

[tj]

@pyrotechnick oh hahah...

[ghost]

@visionmedia LOL, another one. I did 'npm search serv' before I named 'dserv' but somehow overlooked your 'serve' ... there were only ~500 results. Easier to write this script than find someone else's. Yeah, Node/Javascript has a lot of growing pains... some of my 6-month-old demos have already broken, but that's to be expected with Node.. and I was using Coffee back then, gahhh...

[tj]

haha yeah i know what you mean, node is definitely like that now

[devinrhode2]

Yeah, for development this would be great. I use Codekit for auto-compiling, and Codekit is only available on Lion’. My design partner doesn't have Lion. I'm actually using stylus in a chrome extension, which has nothing to do with node.

Writing stylus is easier for designers, why not give the whole development process a little love? Anything a bit easier than the executable would be nice, perhaps an interactive one.

[tregusti]

What about this?

I see there's a client branch which noone has touch for over a year. Is it still something to work on, or is the branch dead but not gone?

[pwnall]

@visionmedia There are reasonable uses for a client build of stylus, such as browser-based serverless IDEs.

Please consider supporting this, so I'm not stuck with less for these apps!

[tj]

those kind of editors are always going to be extremely limited, github.com/visionmedia/rework is an alternative that works in the browser though

[stephenhandley]

@visionmedia are there signficant obstacles to this functioning in the client beyond @import? clientside version without @import would more than be sufficient imo.

[jampekka]

+100

I'd like to get some reasons that actually matter behind "client side compiling is a terrible idea". I use LESS and CoffeeScript with great success in such a way. And would switch to Stylus if this was fixed.

There are probably some premature-micro-optimization arguments. I don't care about those and neither should you. Face it - HTML/JS/CSS is slow, and that's fine. Squeezing a microsecond here or there with all kinds of preprocessing and minimization etc hackery is negligible in the full process and mostly just makes development, debugging and deployment a chore. And you can always switch to preprocessing later on if you're a masochist. Doing it as it should be done (ie compiling client side) could also push browser developers to enable a clean solution to alternative languages (ie decoupling syntax and semantics of CSS/JS/HTML).

I've already wasted too much of my life fighting with building, deploying and compiling languages that arguably sometimes even benefit from it due to bad design. Computers are a lot better, faster and less pissed than you grinding such boring chores, so let them have it and focus instead on stuff that computers suck at.

[vendethiel]

https://github.com/LearnBoost/stylus/tree/client ?

However, I strongly disagree with all your points. Just try to do a benchmark. Client-side compiling and loading is terribly slow. Yes, it's very noticeably slower than just having the compiled files. And it's just a no-go for anything that's supposed to be production-ready.

There are use cases for client-side compilation though, like playgrounds-style websites (where you're supposed to compile everything the client types)

[Panya]

Yep, we already have the client side version (used on http://learnboost.github.io/stylus/try.html and https://jsbin.com). But currently it doesn't support @import/@require and some built-in functions (e.g. image-size).