SimpLESS compiless .less into beautiful .css(wearekiss.com)
wearekiss.com
SimpLESS compiless .less into beautiful .css
http://wearekiss.com/simpless
17 comments
It makes me sad when overly serious people try to suck all the fun out of content that has personality and humor. He even acknowledges this at the end of his faq. So sad.
Humor is difficult to get right. It's very easy to go from humor to douchebaggery in a short step. That dude does, and his product (that, y'know, he wants money for) isn't good enough to offset that for me. SimpLESS, on the other hand, has no such problem for me.
As I said below, if you're developing Apple products you run a fine line with humour because a lot of people aren't going to "get it".
Whether it makes you sad or not is irrelevant. What matters is what the users think, and if Reddit's reaction to it is any indication some will think it's funny and some will think the author is a bit of a dick.
I'm willing to bet that those who don't like it aren't Mac users.
Whether it makes you sad or not is irrelevant. What matters is what the users think, and if Reddit's reaction to it is any indication some will think it's funny and some will think the author is a bit of a dick.
I'm willing to bet that those who don't like it aren't Mac users.
Touché, I was reading his site yesterday and laughed out loud a few times.
Like mentioned above, these apps are programming tools. It's not like he's mass marketing these to uninformed consumers.
Like mentioned above, these apps are programming tools. It's not like he's mass marketing these to uninformed consumers.
CodeKit seems to have taken your feedback to heart.
* I did intend to choose CodeKit (same guys as Less.app), but then read their, frankly immature FAQ.*
Yes, let's please make development less fun, more "corporate" and gray. Humor and professionalism do not match.
Humor is "the quality of being funny", and professionalism is all about "doing your job well". It's obvious that a funny FAQ messes with their ability to code a useful app.
Yes, let's please make development less fun, more "corporate" and gray. Humor and professionalism do not match.
Humor is "the quality of being funny", and professionalism is all about "doing your job well". It's obvious that a funny FAQ messes with their ability to code a useful app.
I've got nothing against humour in a page, and I quite like most of what is on the page, but what irks me is that there are users who would want to know whether there is a Windows version of his software, only to be told in the FAQ that they'd have to get "a Mac". I remember when CodeKit was being passed around Reddit, and the same point was raised (in less than polite words).
There's nothing from with a bit of personality, but it's a tricky road when you're dealing with Apple products. There's a fine line between coming across as fun and a bit of a dick.
There's nothing from with a bit of personality, but it's a tricky road when you're dealing with Apple products. There's a fine line between coming across as fun and a bit of a dick.
Very well polished.
I think it might be super useful to get frontend designers who are afraid of the command line to use LESS even more.
I think it might be super useful to get frontend designers who are afraid of the command line to use LESS even more.
I'm so confused why I would use that rather than http://incident57.com/less/
Thoughts?
Thoughts?
Nobody says you should use it instead of less.app. We simply made this tool because there was no easy solution available for windows to compile your less files.
Because Windows ヽ( ｡ ヮﾟ)ノ
They should probably test twitter bootstrap as many folks will use this with bootstrap. Unfortunately bootstrap compile fails.
Yes, we are aware of that. We will update to the most recent less version this week, together with a couple of other changes. :)
It's not really different from Less.app and just like Less.app you don't need it when developing locally using the client-side approach. If you make compilation part of your deploy you basically don't need these apps at all.
Its seems to have a pretty major difference to less.app in that it supports multiple platforms.
Regarding making compilation part of your deployment, you expose yourself to differences between the development and production code which might prove difficult to trace down the line. Keeping your development code as close to your production deployment seems smart to me.
Regarding making compilation part of your deployment, you expose yourself to differences between the development and production code which might prove difficult to trace down the line. Keeping your development code as close to your production deployment seems smart to me.
ok didn't know about the platform support.
i'm curious what use cases have you run into where the less.js produced different css then lessc?
i'm curious what use cases have you run into where the less.js produced different css then lessc?
I haven't used Less, although I have been considering it recently.
My point was much more general though. A tool like this seems great to help catch problems early - earlier than your deployment step. Can you be absolutely sure that there aren't any latent bugs in Less or differences between lessc and less.js, such that you could never have any differences between your less.js-backed dev code and your lessc-backed deployed code? Even if the codepaths are identical between lessc and less.js, their execution environments aren't.
All I'm saying is that if you're going to use some _thing_ in your deployment scenarios, it would make sense to use the exact same thing throughout your development (where possible). The biggest argument against this in the case of Less is the hassle of compiling it. That's where a tool like SimpLESS or less.app steps up.
My point was much more general though. A tool like this seems great to help catch problems early - earlier than your deployment step. Can you be absolutely sure that there aren't any latent bugs in Less or differences between lessc and less.js, such that you could never have any differences between your less.js-backed dev code and your lessc-backed deployed code? Even if the codepaths are identical between lessc and less.js, their execution environments aren't.
All I'm saying is that if you're going to use some _thing_ in your deployment scenarios, it would make sense to use the exact same thing throughout your development (where possible). The biggest argument against this in the case of Less is the hassle of compiling it. That's where a tool like SimpLESS or less.app steps up.
lessc is part of less.js (https://github.com/cloudhead/less.js/blob/master/bin/lessc), so should be identical, but fair point.
Didn't know about less.app until now - thanks!
+1 for really great, usable design.
Genuinely wondering: it looks like there went a considerable amount of effort into the design, presentation and polishing of what's effectively a small programmer utility. Do the authors expect to somehow generate an income from this? If so, how?
Btw ups for decent cross-platform-ness. Most of the tools in this space are either *nix-only or Windows-only.
Btw ups for decent cross-platform-ness. Most of the tools in this space are either *nix-only or Windows-only.
This product is an ad for their consulting service. Think RoR and a younger 37Signals.
haha first comment that popped into my head "omg you made lessc!"
They also packaged it into an app, added friendly notifications to it, made it cross platform, added a nice UI, drag and drop and other good stuff. Do you think making a GUI for a command line utility / lib is something easy to be sneered at?
Btw: "haha" and "omg" are very rarely good comment material. Neither does the "first comment that pops into ones head".
Btw: "haha" and "omg" are very rarely good comment material. Neither does the "first comment that pops into ones head".
I'm struggling to get it to run in Linux.
The installer doesn't work, and if I run the binary directly, when I drag a folder, it says... (among other things)..
TypeError: Result of expression 'e.dataTransfer' [undefined] is not an object.
Any suggestions?
TypeError: Result of expression 'e.dataTransfer' [undefined] is not an object.
Any suggestions?
Doesn't work for me either. It looks like it's a problem with the Titanium App SDK for linux. https://github.com/Paratron/SimpLESS/issues/8
Someone suggested using the Windows installer in Wine. I haven't tried that. I'll just go back to lessc.
Someone suggested using the Windows installer in Wine. I haven't tried that. I'll just go back to lessc.
SASS/SCSS just work on linux ;)
sass --watch does the "compile on save" thing.
sass --watch does the "compile on save" thing.
Same here. I also had to symlink libnotify.so.1 to get it to start (Mint 12).
This is really nice and it looks to be written all in js using Accelerator Titanium. I've never heard of Titanium before anyone have any experience using it? What's it like?
Sadly appcelerator has decided to pull the plug on titanium desktop a few days ago. We are currently looking for an alternative to continue the work on simpless in the future but har no luck so far :(
Titanium makes the impossible seem possible with native mobile apps. There are some speed/memory issues at times, but as long as you construct your app with best practices in mind you should be good.
SimpLESS and less.app have been around for quite some time now. Yet, it is really painful to see so many developers copying-and-pasting compiled css from the chrome dev console. Further, client-side less.js uses ajax, forcing you to setup a web server on some development environments.
SimpLESS is highly recommended, as it lets you focus on the code rather than figuring out the compilation bit. Auto-minification is a big plus too.
P.S. It's nice to see a good and usable Titanium application. :)
SimpLESS is highly recommended, as it lets you focus on the code rather than figuring out the compilation bit. Auto-minification is a big plus too.
P.S. It's nice to see a good and usable Titanium application. :)
Could someone who uses less regularly lay out the advantages over vanilla css? I see nesting and vender-prefix normalizing, but to me those are pretty small gains. I'm sure I'm missing something.
You. Will. Never. Go. Back.
I mean...variables? Do you never have the same width in two places? That is so simple and so huge. Want to make your shade of green 5% darker? Don't look up a new hexadecimal, just say darken(green,5%).
Make a button "class" where the only input is a color, and it automatically generates a cross-browser rounded-corner button with a slight gradient to 10% darker color, 20% darker border, with 20% lighter inset box shadow.
Really. You will not go back.
I mean...variables? Do you never have the same width in two places? That is so simple and so huge. Want to make your shade of green 5% darker? Don't look up a new hexadecimal, just say darken(green,5%).
Make a button "class" where the only input is a color, and it automatically generates a cross-browser rounded-corner button with a slight gradient to 10% darker color, 20% darker border, with 20% lighter inset box shadow.
Really. You will not go back.
Once you start using mixins, you'll never go back. Add a clearfix, IE hack or a cross-browser CSS3 property at the drop of a hat, over and over again.
I also find that just due to the nature of the nesting, I'm writing much tidier CSS as a result.
I also find that just due to the nature of the nesting, I'm writing much tidier CSS as a result.
Nesting itself is worth it's weight in gold. Add in mixins, variables, etc and it's just icing on the cake.
I also force myself to add hover states to all the links, even if the client didn't specify it in the designs. Being able to use something like:
@link_color: #ffcc66; @link_hover: darken(@link_color, 15%);
is a HUGE perk.
I also force myself to add hover states to all the links, even if the client didn't specify it in the designs. Being able to use something like:
@link_color: #ffcc66; @link_hover: darken(@link_color, 15%);
is a HUGE perk.
http://lesscss.org/
don't think it touches vendor prefixes.
don't think it touches vendor prefixes.
I think you're right that it doesn't have built-in simplification of vendor prefixes, but they are trivial to implement into mix-ins (the example on the page you linked shows how), and I suspect it's one of the first things people set up when starting with LESS
Also, it makes it super easy to hit the CSS rules-per-file limit that Internet Explorer has.
The idea of compilation-on-save is a very useful one, but here's my only gripe: it needs to be integrated with my IDE. Maybe the idea is that "if you build it, they will integrate."
But until then I have my own solution which is that I have a keyboard shortcut that runs a bash script to compile the .less, focus on/open chrome and reload the page (all in one step!). I use the awesome software (windows and mac) quickkeys to do it.
But until then I have my own solution which is that I have a keyboard shortcut that runs a bash script to compile the .less, focus on/open chrome and reload the page (all in one step!). I use the awesome software (windows and mac) quickkeys to do it.
Isn't it essentially already integrated into your IDE? You click the save button, and it compiles the less file.
It's not really integrated because you have to have SimpLESS running in the background whenever you're working on a project - it's not a major hassle, but I noticed a similar friction when working with LESS.app in a project. I could edit almost everything in my text editor and see the results on the page, but would have to leave the editor to start LESS.app when I wanted to tweak the style. Only had to do it once, but it didn't feel like an efficient, integrated workflow.
The free version of WebWorkbench does this for coffeescipt in Visual Studio. I think the pro version does it for less($29). I'm thinking of paying for it depending on if I can get this simpleLess working on Windows or not.
Is CSS honestly that difficult? I mean I see why this could help but this just seems to add another layer of complication. I don't know maybe I'm just being a cynic with all these sorry excuses for technology.
The problem with CSS is that it's not too difficult, but that its too simple. With your typical usage patterns, you'll create lots of repetition which you have to do manually. And that's true even without the need to support separate browsers.
Whether that really justifies that many preprocessors is a good question, though (Instead of m4 or sth. like that). I'm not too fond of the plethora of cutesy DSLs we've got nowadays. Reminds me of Lisp macro overuse. (Never mind the general problem that all this need for HTML/JS/CSS hackery and abstraction layers probably showas that we need a better solution altogether. As Cato the Elder said: I miss PostScript.)
Whether that really justifies that many preprocessors is a good question, though (Instead of m4 or sth. like that). I'm not too fond of the plethora of cutesy DSLs we've got nowadays. Reminds me of Lisp macro overuse. (Never mind the general problem that all this need for HTML/JS/CSS hackery and abstraction layers probably showas that we need a better solution altogether. As Cato the Elder said: I miss PostScript.)
This is like saying "Is a hammer really that difficult? Do we really need to add the complication of compressed air? We don 't need these nail guns. I can already get a nail in some wood."
Less compiles to css. It is faster to build great things than with just css. It is easier to maintain. There is almost no reason NOT to us it instead of straight css. There may be other better tools but if you have to build a lot of css, less is a great tool.
Less compiles to css. It is faster to build great things than with just css. It is easier to maintain. There is almost no reason NOT to us it instead of straight css. There may be other better tools but if you have to build a lot of css, less is a great tool.
Anyone having issues on Windows? I drag my project folder over...I only have one .less file in my /content folder of an asp.net mvc project. simpleLess throws and error saying Syntax Error on line 1.
This Less file works great when using run time compilation.
This Less file works great when using run time compilation.
Hey, try saving your lessfile in UTF8 without BOM. Titanium cant handle the BOM and crashes there.
I guess I'm not hackery enough. I have no idea what this means. I use visual studio to edit this file so I'm tied to how that saves the file. I had actually tried doing a find and replace on the /r/n line endings to see if that was the issue. I have no idea how to tell vs to save without a bytemark.
Well, there should be some setting in VS for what format the ide shouldnuse when saving the file. I have no idea hOw/where to configure this in VS but the exact problem you described above was mentioned to us by a couple of users and it was always because of VS and UTF8 with BOM.
This seems like more of an issue with titanium. They should fix this. If I start jacking with my file save settings it it going to cause problems when my team members start opening my files. As much as I don't like MS having control, titanium should support files that windows produces.
Yeah, you are right with that. But since appcelerator is dropping the titanium desktop framework, i don't believe its getting fixed so far :/
I use this script: https://bitbucket.org/wooptoo/bin/src/tip/lc
SimpLESS is better though.
SimpLESS is better though.
SimpLESS is the perfect name, as the program works brilliantly in the background. I'd highly recommend it for both Mac and PC users.