The UI developers touch the CSS, but given that Sass's workflow creates CSS, would any machine that displays the app (servers included?) need to have Ruby and Sass installed to view the app properly?
Or is it enough for anyone just working on the UI to have Ruby and Sass installed, in which case updating the CSS is done by a UI guy, and then the rendered file can be committed to be viewed and used by all?
You only need Ruby to compile Sass, the app will use the CSS (in fact, you don't need Sass files on your production app).
So only the people who are susceptible to work on the UI need to have Ruby (ans Sass) installed.
Sidenote:
Some frameworks allow on-the-fly Sass compilation (I'm thinking to Laravel-SASS for example). In this case, everyone need to have both Ruby ans Sass installed.
Related
I can't get ruby running and i dont want to go through all the hurdles of fighting with my osx version of ruby.
I downloaded dart sass which has no support for compass since it's deprecated. I'm trying to get my old sass code to work while I work on replace all my mixin that I used that rely on compass.
Is there a way I can download the compass/css3 mixin stylesheet?
I found their site http://compass-style.org/reference/compass/css3/ other than going through each page and copying all the code. Is there no master code file that I can download all the mixins?
Thank you.
I am beginning to use Go for web development, but I am having issues with asset management. I would prefer to have a tool like Rails' Asset Pipeline for managing (and compressing) css/js files (as well as SASS), but I am still able to work with css and js files.
While I am able to work with css and js, I am not able to work with SASS. Is there a way to use SASS in a Golang project? I am not using a framework.
Thank you!
I'm not familiar with Ruby on Rails but, I assume, that ruby on rails gave you some sort of tools for managing the source to distribution client-side asset transition (polyfills, transpiling, minification, compiling of SASS/SCSS to CSS, compiling of XScript to JavaScript ... etc).
While a web development framework might do that to try and ease in developers quickly (I assume rails does that, not ruby) its not exactly the way Go does stuff.
Go is a language, not a framework + language, just a compiler, a few build tools and a set of standards for how to write, test, document and indent stuff (with the indent,test and document part being optional).
A go server, at least the way I built servers with go, is somewhat decoupled from the client. It server static assets when they are needed (e.g. it serves the minified JavaScript and the stylsheets and the html, and jsons with info from the databases... etc), but it doesn't really care about what those are, its a server. The go toolchain is made for building golang applications (e.g. said server), but its not made for building client-side web applications (those consisting of js, css and html).
Now, you may use a framework similar to rails written in go that helps "pack up" css, js, html. But I'm unaware if there are any.
You may use a compiler which turns go into client-side code (i.e. javascript) https://github.com/gopherjs/gopherjs , if you enjoy the go toolchian and want to use it for client-side development. But, go-like performance isn't something this gives you AND you are working with a subset of go. Its really just a different way to write javascript.
However, what you most likely need in your case is a "build-chain" for your client side. Here there are 3 tools which (in my opinion) stand out in 2016:
npm
webpack
bower
I could write an essay about using this tools but here's the summary:
Webpack is used to create a "pipeline" for your code which does thing like, calling babel on javascript, compiling sass to css, minifying assets, allowing js to be written with import syntax... etc, really, its a swis army knife in your js development arsenal and probably matches the functionality of whatever you were using before.
Npm is the node package manager BUT even if you are not using node for your server. It can be useful to keep tracks of dependencies for building your application (like webpack) and for downloading modules. Its also useful for running various scripts and deployment, its a bit of an overkill to use both npm and weback though you will probably have an easier time setting up the webpack enviornment if you have a package.json (config file for npm) with each of your project.
Bower is one I actually don't use for small projects. But its basically a repository for javascript libraries (among other things), so you can easily say, write "bower install jquery" and you've downloaded jQuery for your current project.
Again, there are many other tools out there, these are just some of the ones I like, but, check some of them out. They can help you replaces your previous pipeline. Don't think of client and server side code as being the same, they are decoupled and having a strong separation between them might help you a lot.
I've read that SASS uses Ruby to compile. I have a webhosting at One.com, I don't think they support Ruby. Am I able to run SASS on it?
You actually do not need to use ruby to compile sass. There are a few alternatives.
If you are using Laravel 5 you can do this with the new elixir feature which uses gulp to process tasks.
Or you could use gulp along side Laravel 4.
Or you could use grunt.
All of these options use libsass in the background instead of ruby.
Usually SASS is compiled in CSS in development and the production server only serves the CSS.
You would need Ruby if you wanted to compile SASS though. Sometimes that's needed to create more dynamic stylesheets although I'd generally advice against it because it slows down performance.
I am developing drupal themes using omega 4. A lot of the theme depends on sass and ruby extensions, which is great and I would like to develop towards this trend, however, we have a managed server which does not allow for ruby gems to be installed. I think the best solution is to design all my themes on my own personal server and then just copy the theme over to the primary site.
Question 1 - Would this be a practical choice ?
Question 2 - As far as I know, all the sass and ruby extensions are only necissary for development of the theme and layout, as they are all compiled into css at the end of the day. So if I'm correct, I won't need them installed on the end server if I'm not developing or changing them too much ?
T.I.A.
I think that your approach is the correct one. As you say in your question 2, sass, and expecially ruby, are only needed in a development environment, so you don't need to install them on the production server. It may also be safer not to publish your development files in the production server, so you won't let trace on the public server of your development process.
Be sure to compile your CSS files with
environment = :production
in your config.rb file before publishing to production.
I'm just wondering if there is a way to integrate SASS into Jekyll. All that I need is an automatic .scss compilation into .css when I launch Jekyll.
I don't see anything wrong with compiling assets when you launch (which I take to mean run) jekyll. The whole point of running jekyll is to pre-compile your site, which is good for performance.
As for asset conversion-- there are many plugins available that focus on this. I like the Jekyll Asset Pipeline gem, which supports any language (e.g. Scss, Less, CoffeeScript, Erb, etc.) and has a bunch of features (e.g. asset tagging, compression, gzipping, etc.) that set it apart. It also seems to be the fastest growing Jekyll-related gem these days, which I take to mean that it is gaining traction in the community.
If you want to keep it as simple as compass watch you can use the Guard gem along with guard-jekyll and guard-compass (and if you like style injection, guard-livereload).
Guard bundles multiple 'watch' actions under a single terminal window, and is much easier to set up than a robust asset pipeline. Install the gems, configure the .guardfile according to the guard-compass and guard-jekyll instructions, cd to your directory and type guard. Any time a relevant file changes your sass files and/or jekyll site will be recompiled.
Native Sass, and CoffeeScript, processing debuted in Jekyll v2.0:
http://jekyllrb.com/docs/assets/#sassscss
Full disclosure: I am the lead dev behind this project.
The easiest way I've seen to setup Sass with Jekyll is with jekyll-compass. This gem will do exactly as you describe: Any time jekyll builds your website (jekyll build, jekyll serve, etc) your Sass will be compiled into the output folder along with the rest of your website. Check out the readme linked above for full usage details.
There's also some work under way currently by the Jekyll guys to get Sass support into the core of Jekyll so that everyone will have at least basic access to Sass and the wonderful feature-set it provides.