Using Sass And Compass With Tch

[Extreme]

So I opened a ticket with the help desk and have been told something that I am extremely shocked to be told and would like some clarification.

 

As a front-end developer, I spend the bulk of my time writing CSS, JavaScript and building sites within open-source and proprietary CMS's. Everything that I do is in responsive design and my company does alot to keep the company using the most current techniques. An example is the fact that I have been using responsive design for more than 2 years professionally and the initial article describing the process is only 3 years old this month.

 

The point here is that the use of Sass and compass is the future of front-end development. There are those that build with it and those that know nothing about it; the gray area in between is exceptionally small. Now, in order to use Sass and Compass, you need to use Ruby to power the Sass engine. From what I was just told tonight by the help desk is that TCh does not support Ruby on the servers. I would like to know if this is true.

 

I am really curious about this. The dominance of Sass and Compass may not be so large that people will shy away from TCH, but the decision to not allow Sass to run on TCH servers feels like TCH is just not looking to the future and is not evolving. Sure you can write css without sass and everything will work just fine; this much can not be debated. However, you can also write JavaScript without jQuery but there are more people in 2013 that use jQuery instead of standard JavaScript alone.

 

Even Sir Tim Berners-Lee and Oreilly have stated that Sass, and CSS preprocessors are the future. Not to mention that the W3C is adding the sass concepts to the specs and recommendations. To me, for TCH to say that this is not allowed on the servers, tells me that TCH is not evolving with the Internet.

 

I would really like to hear your opinions. Please no flame wars

[TCH-Dick]

My first comment would be that SASS is not the only CSS preprocessor out there, nor is there much of industry standard at this point in time. However. if I had to pick a forerunner today it would be LESS, with SASS slightly running behind it. Note that I make this statement based purely on my dabbling with them, as at this time there is no real information to quantify a leader.

 

Concerning TotalChoice servers, it is correct we do not currently offer Ruby nor SSH on shared hosting, both of which go hand in hand for any real use of Ruby. I won't say this will never change, but at this time is not a product we are offering.

 

At the end of the day it is still just CSS and will render in a browser, you just can't compile your CSS directly on our servers, but you can run your compiled CSS on our servers. There are many tools available for Windows, Mac, and Linux OSes that allow you to compile and edit locally. So far I have only played with scout on Windows as I do most of my local editing on Linux, and because dabbling is about all I have done so far.

 

I know hearing that you are limited to local compilation is probably not what you would like to do, however, it is an option to make use of SASS for your sites on our servers.

[Extreme]

You are correct that there is no definitive front-runner; I can only attest to my experience and the experience of colleagues in the industry and from the conferences. Less is slightly more simple in implementation in that it requires a single js file, but this has serious implications when JavaScript is disabled. Sure there are other processing methods that have surfaced, but none of these are considered official implementations. When we looked for a preprocessor, we did a significant amount of research and chose to run with Sass because of the notion that an additional third-party application is required to make it work without JavaScript. Now I know that there are many that believe that those without JavaScript do not matter; but when you have Fortune 100 clients that are international, you quickly learn that those that do not have JavaScript working by default are the the clients that are paying the bills. Thus, progressive enhancement must be used which means that you cannot depend on less.js.

 

I do not know what the future of Less is to be honest. Not to long ago it was announced that support for Less would be dropped only to have the development picked up by a a group of developers. When this happened, I watched every person in the Web Design Book Club that my company runs (with about 45 members) that used less switch to Sass. There were two things that they all raved about; @extend and Compass. Compass is by far the better aspect in my attention. These days I could not imagine writing behavior without jQuery — the same is true with Compass.

 

In the end, I met with the boss and our sysadmin today to review some analytics related to the server performance of processing sass on the server. The background watch process for sass can be a resource hog for servers that are not equipped for it. In our environment, we are hosting hundreds of sites build in many different languages so we are adequately prepared for it. However, for a ' one-man shop', this is not necessarily required. For now, I will compile locally and upload the css via ftp. However, if the plans that I have for my future side projects come to pass, this will not necessarily serve my purposes.

 

What is the situation on a reseller server; is Ruby allowed in that instance?

[TCH-Dick]

Thanks for the additional information, I deal with a lot of code at times and I mostly just dabble on the design side of things as needed. As for our shared and reseller products, they have the same limitations when it comes to services that require shell access.